Category Archives: Software Testing

Could Robotics Process Automation (RPA) Be the Future of Testing?

According to blogger, Swapnil Bhukan, robotics process automation is indeed the future of software testing. In his blog post, Robotic Process Automation(RPA) evolution and it’s impact on Testing, he predicts that RPA will perform about “50 to 60% of testing tasks” by the year 2025. If you are not familiar with what RPA is, Bhukan also made a blog post describing what it is, how it works, and some of its benefits. Essentially RPA is a way to automate any repetitive task using bots that are taught how to do said tasks. Currently, according to Bhukan, RPA is only used to perform only about 4% of software testing tasks but that is sure to change as RPA technology advances. Today, the main use case for RPA has to deal with pretty basic data entry tasks.

The reason I chose to write about Bhakan’s blog post is because I found it quite interesting; especially since I was able to relate to the growth of RPA through past experience. Over the summer I had the opportunity to work an internship at an insurance company and all the IT interns had the pleasure of getting to sit down and talk with the EVP/Chief Innovation Technology Officer and ask him some questions. I asked him what kinds of new technologies the company was looking to invest in as well as what new technologies he was most excited about. His answer to both of these questions, requiring little time to think, was, hands down, RPA. Companies today are striving harder and harder to automate as many tasks as possible in order to save money.

One of the downsides to RPA, as Bhukan points out, is that it could potentially put many software testers out of a job. Some of the things keeping RPA form taking over the field of software testing at the moment are budgetary issues (RPA software is pretty expensive), companies being reluctant to adopt such new technology, and apprehension due to the possibility of losing customers if the tests aren’t done correctly. However, I believe that software testers may just have to realign their expertise as RPA technology evolves. By this I mean that the software testing professionals/developers should begin to learn how to teach these bots and leverage the bots’ usefulness in completing repetitive tasks; after all, the bots can only be as smart as those that teach them. I think Bhukan shares this view when he says at the end of his blog post, “sooner or later we (Software testing professionals) need to upgrade our skill set to train the Robots.”


September 24, 2017

-Caleb Pruitt


From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Week 4 (2/7 – 2/13) Clean Coder Ch. 7 & 8

When I decided that I wanted to become a programmer, I thought it would be 99% program code and 1% test code. I thought I could mindlessly write as much code as I wanted and just know if it works or not by running it. I was wrong. Completely wrong. After having more insight into being a software developer, I realize now that testing is so under-rated and overlooked. After reading chapters 7 and 8, this concept is reinforced even more.

If you really think about it, its quite simple. You want your program to work and the only way to know if it correctly works or not is to test it. This is where acceptance testing comes into play to tell you when a requirement is done and that is obviously important because if you don’t know the requirements then how would you even know what to test?

Chapter 8 was somewhat broad since it covers a big array of topics regarding which tests to use depending on which level of the system you are working on but nonetheless it was good review. It’s always good to review testing strategies because at the end of the day, your program is only as good as your tests are. 

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

White-Box, Black-Box, and a Little of both, Gray-Box Testing

When testing a software product the testers need access to some amount of information. The can be given access to just the finished product, just the code, or both. In each case the type of testing can vary.

Black-box testing refers to testing software where you have not been given the source code. In most cases the tested would be given a set of specifications. The tested the preform test on the  product and ensure it complies with the specifications. The main way in which black box testing works is by providing input and verifying the output is what is expected.

With white-box testing the testers have access to the source code. This means the they can examine how the code works. This can prove to be more complex but allows for much more thorough testing. This is where unit testing can really work and test cases can be written to test the code. Metrics can also be generated to show how much of the code was actually covered by test.

The third options involves a little of both categories, this is known as gray-box testing. In most cases involving gray-box testing the tested don’t have access to the source code but do have some knowledge of the inner workings of the program. One example of this would be a team that understands the formulas and methods used by software. This allows them to create more specific test than black-box testing that can target areas that are more likely to have issues. This is a good place for boundary value testing.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Reviewing Code

One way of ensuring good quality is by creating a test suit that actively test the code to fine flaws. Another way is to comb through the code and verify there are no errors in the logic. This process in known as a software technical review.

A software technical review consists of 4 parties, the producer, the recorder, the review leader, and the reviewers.

The producer is the entity that develops the code this could be a single developer and development team or an outside company. They are responsible for providing a frozen copy of the code and a set of requirements and expectations. It is important that the code does not change during the technical review process.

The recorder is responsible for taking notes and documenting what takes place during the review.

The review leader is responsible for scheduling the review, suppling what is necessary for the review, as well as producing the final report and sharing the findings.

The code reviewers as well as the leader and the reported are responsible for looking through the code before the meeting and documenting all errors of other issues found in the code.

During the review each member shares what they found and compares it to the others. As a group the determine if what is found is actually an issue that needs to be fixed. The team does not make suggestions to how the issues can be resolved.

The review leader then takes the information from the review session and generates a final report to be shared with the producer.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Importance of Acceptance Testing

Most software development companies don’t start with a fresh idea of there own and see it through to the end. In many cases a client will contact a development software company with and idea for a project the would like built to fill a certain need of theirs. In this type of situation there must be communications between the client and the development team. Most of the time the developers themselves wont have specific knowledge in the area of the new software.

This process starts with getting the client to form a set of requirement and expectations. This process can be aided by the developer by asking questions to clarify what the client is looking for. Even with a great plan and list of what the client is looking for it the final program doesn’t always do what is really wanted.

I have seen this first hand working a a small Internet company. There has been several times the owner of the company has gone to the development team with and idea. As a team they listen to what the owner is looking for and repeat their interpretation of it. They continue this back and forth until both side are satisfied. The development team then works to produce the discussed program. After the program is complete the final product is presented to the owner. Usually everything is all set but in some cases the response is “this doesn’t do what I want it to”.

There are several reasons that can lead to situations like this. First is an unreal expectation. Some projects are to complex or just not feasible. Some times it is because the client didn’t, themselves, really know what they wanted. Other times it is because the developer didn’t understand the requirements completely.

In any case, the situation could benefit for acceptance testing along the way. As the development team starts to develop starts to produce a product they can go back to the client and show them the current status to ensure it is what they are looking for. On method that would help is the use of Wireframes. I have written about this is a previous article.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Integration Testing

Integration testing is one of the three major categories of testing. It falls between unit testing and functional testing. Integration testing is the step when you begin to test the individual parts of a program with each other. This can be a tricky task as there are often times when not all the required parts are developed.

There are three ways of preforming integration testing:

~ Top Down

~ Bottom Up

~ Big Bang

In top down integration testing you start with the top level and work your way to the bottom. As you start with the top many lower levels have not been coded yet. For these you write stubs that hold the palace and provide canned answers. These stubs do just enough so that you can ensure you upper levels work. A disadvantage of this method is the amount of throw away code required for the stubs.

The next approach is bottom up. This is, as it sounds, the opposite of top down. In this method you start by testing the lowest level parts and work your way up. Like in the top down approach there is a certain amount of throw away code required. The difference is instead of stubs you must write drivers. These drivers are used to call the necessary actions to ensure the low levels are working. This method leaves on main issue, design flaws in the project are usually not discovered until a lot of effort has been put in.

The Final method of integration testing known as the big bang approach. This involves waiting for most of the code to be developed and integrating all at once. This is good because there is no throw away code but it becomes very hard to identify issues.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Unit, Integration, and Functional Testing

When talking about software testing there are different levels to consider. These different stages of testing go along with the different stages of development. It is obvious you can’t test the final program while only several small parts have been coded. And it would not make sense to wait until you have a completed project to start testing. The two processes need to work together. These different levels of testing can be summarized by three categories; Unit Testing, Integrations Testing, and Functional Testing.
I like the cell phone example Sushma S. uses in her blog.

~ Unit testing: the battery is checked for its life, capacity and other parameters. Sim card is checked for its activation.

~ Integration Testing: battery and sim card are integrated i.e. assembled in order to start the mobile phone.

~ Functional Testing: the functionality of the mobile phone is checked in terms of its features and also battery usage as well as sim card facilities.

Unit testing is the lowest level of testing. As a developer begins to code the parts of a system it is important to test that the it preform as expected. These individual parts are tested in units. Once there are several units developed one must ensure they work together. This could include having access to the necessary information as well as making sure the output of one part lines up with the input of the next. The final level of testing is functional testing. This is where the overall product can be tested to see if it operates in the way it was intended and to see that if satisfies all the needs of the end user.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.


Many programs are interactive and require input from the user to function. In a perfect world, the input provided by the user would be exactly what is required, this is obviously isn’t a safe assumption. There are some many ways input can cause issues to the program. Many times invalid input will cause a program to return an incorrect answer or behave in an unexpected way. Other time it will cause and exceptions that causes the program to crash. In more serious cases, like buffer overflow type attacks, these issues with input can cause security risks. Because of this programs need to be able to validate and check input values. Most programmers are aware of what may be entered and program defensively as to catch the invalid input and prompt the use to make a correction.

This being said it is hard to think of all the input could be entered incorrectly. To check to see how your program handles the different types of input it is useful to try entering input and seeing what happens. This is very time consuming and suffers from the same flaw, its hard to come up with invalid input to test. This is where fuzz testing comes in. Fuzz testing, commonly referred to as fuzzing aims to do this automatically. The fuzzing software will attempt to generate input of all sorts to see how the program responds. This input can include items like numbers random letters and symbols, it also tries very large input. With the informations provided by the testing a programmer can make changes to the code to better catch the issues before it is an actual issue.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

V-Model Testing (WEEK 12)

The meaning of V-Model is Verification and Validation model. This model has the shape of V, the V-shape model is a path of executions which is followed in a logical order. Each phase must be completed before the next phase begins.When we have test a product must be planned in parallel with the corresponding phase in V-Model. First is very important to understand the Verification and Validation techniques before we learn about V-Model. Verification testing technique is done without executing any code and Validation testing technique is done by executing the code, Verification is a static analysis technique, Validation is a dynamic analysis technique. Both techniques are par of the V-Model. There are 7 phases that take place in V-Model. Here I’m listing the seven phases of V-Model: Requirement Specification, Preliminary Design, Detailed Design, Coding, Unit Testing, Integration Testing and System Testing. We usually apply V-Model for small to medium sized projects where requirements are clearly defined and fixed. 

This design shows the sequential path of execution process of V-Model.

In this paragraph I’m covering the pros and cons of V-Model. Some of the pros are: Development and progress is very organized. This model works well for smaller and medium sized projects. Another positive factor is easy to manage as each phase of this model. Some of the cons of V-Model are : V-Model doesn’t work for big and complex projects. The V-Model is not suitable if the requirements are not compatible.

To learn more about V-Model Testing please visit the website below.


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Pass by object reference

Python’s passes parameters by object reference. What does that mean? Let’s first explore the pass-by-reference and pass-by-value parameter passing paradigms.


In pass-by-reference, the variable is passed directly into the function.


The new variable points to the same object as the old variable. We just created a new reference to point to the same object.


In pass-by-value, the function receives a copy of the argument objects passed to it and is stored in a new location in memory.


The new variable points to a different object (a copy of the old object).


Python is different than languages like Java(pass-by-value)  in that it supports both pass-by-value and pass-by-reference. Variable in Python are not like the variable we know from other programming languages: variables in Python are object references. The value stored in a python variable is the memory address of the value, not the actual value. It is the memory address that is passed into a function, not the actual value. This means Python’s functions support call by object-reference semantics.

Based on the type of the object referred to, the actual call semantics used will differ. If the variable refers to a mutable value, call-by-reference is used. If variable refers to a immutable value, call-by-value is used.



  2. Head First Python, 2nd Edition by Paul Barry

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.