Improving software test efficiency

Software testing. Not a well known job, and usually not regarded as a fair value for those who know about it. Yet, software testing is an essential part of the software creation process. Why do you think most of the softwares you use are bugfree ?

During the development process of every software, there are 2 major stages : programming and testing. These two stages are dependant from eachother, and the software is going to go back and forth a large number of times, until testing team gives what’s called the « Go » decision. At this point, the software can be deployed or pushed out on the market.

Testers have to follow a test plan, which is defined upstream. This test plan is usually included in a test management tool (the most used one is HP Quality Center).

Every time testers receive a new version or a new release of the software, they have to follow this test plan in order to make sure every component of the software is working properly. Why do testers have to play the test plan over and over ? For one simple reason…

When testers find a bug in the software, they send it back to developers. Developers will correct that bug and send the new release of the software to testers again. You might then think testers only have to test this specific component ; but they can’t, because of regression risks. What are regressions ?

When developers correct a bug, they have to modify some parts of the source code. But doing this, they can affect other components of the software also using the modified part of the source code. This is a regression : correcting a bug in module 1 can introduce a bug in module 2, which was bugfree before the change. Thus, testers have to test all over to make sure no other bug has been introduced, and to find these bugs if not. This is regression testing.

Also, if a test plan have been setup upstream, how to be sure that every part of the software is well covered by tests ? Knowing every possible cases is not really possible, and as there are frequent modifications or improvements, the code can change with time. If the test coverage is not sufficient, bugs can be introduced but not detected by testers as no test have been defined for these cases !

Kalistick, a software editing company, has developed a tool that will help testers to make all these situations easier. This tool is Cloud based and thus can be accessed by any web browser.

With this, regression tests, test coverage and Go decision can be improved and can be accelerated !

As testers don’t like to get their hands dirty, the first point is that no code is going to be shown to testers.

This tool is able to help testers to choose the right test strategy : change based testing, risk based testing, regression testing, agile testing…

Choosing the right strategy will allow testers to accelerate their process.

Using the appropriate strategy will help testers to know what changed in the software and which are the related risks. It will also tell testers what didn’t change ! So, no need to loose time with useless testing. If a component hasn’t been modified and has been successfully tested before, so testing it again is not needed.

Finally, the tool will check the test coverage. This means that it will tell testers what hasn’t been tested, and what can’t be tested because of the lack of tests ! It will then help testers to define new tests for uncovered modules.

With all these data, the final decision, know as the « Go » decision, will be much easier and much faster. This decision is one of the more important : it allows the deployment of the application. This means the program is ready to be used by clients. As all softwares, zero bugs is never the case, but with Kalistick’s tool, you can be sure that the bugs are fewer than ever.