Testability: Need of the Hour
“The Time you save in testing is the time you gain for testing.”
This can be brought in practice if the software that you are testing is “Testable”. In this article, I am going to throw light on how testability affects and how it can be incorporated during SDLC.
As we know, quality and reliability are becoming the major concerns with the progression in software technology and increasing dependence of human beings on software applications for their day to day tasks, this enforces an emphatic testing to be done to achieve satisfactory levels of software quality and reliability. Nevertheless, this leaves us in a Catch-22 situation as with growing complexity in software systems, testing resources are still limited. Therefore, this brings us to the fact that systems with optimal testability should be designed to increase the impact of testing. Software testability is an external attribute of the software that evaluates the complexity and the effort required for software testing.
“Software Testability” is a non-functional requirement that tell us about the ease with which we can test the software. It should be added in software so that testcases and test scripts can be executed thoroughly. Formally, “The extent to which a software system or its component enables the setting up of test criteria and performance of tests to conclude whether those criteria have been met or not”.
“Low Software Testability” in lot of circumstances degrades the software slowly as it may not be detected at once; the testers, unaware of the fact, may consider wrong reasons and to handle the problem may recommend numerous solutions like extending work hours, assigning more resources, expensive automation tools, risk based testing, need for better estimation and planning, etc. without the proper understanding the problem. This tends to aggravate the situation as the real problem will remain unfocused.
Software Testability is a prerequisite for software development as any SDLC encompasses requirements gathering, analysis, design, coding, testing, implementation, and maintenance. Complete execution of the test scripts can only be ensured if the application that is being developed is significantly testable. Once decent test coverage is applied, most of the defects will be uncovered and fixed before the product goes live in market which, in turn will result in lesser issues being reported by the end users.
Testability of any software product is largely affected by two elements, i.e., controllability and observability.
Controllability is how easily difficult scenarios to test the software under extreme circumstances can be created for the application. For instance, Testing Installation of an application when hard disk space is very low.
Observability means the ability to see the UI and internal flow of the software. When the actual expected output is the same, but the internal processes are not as the way they were stated as in the requirements, defects are mostly identified in some other flow. This is more important for unit and integration testing rather than black box testing.
Testability thus becomes the prime issue that needs to be tackled from the initial stages of the SDLC and has to be integrated in each phase. This can be accomplished as follows:
Software Specifications Phase
Testing team should be asked to review the documents and discussions should be done to get their inputs as well as clarify their understanding of the requirements. Not only the document should contain what it is expected to do in normal conditions but also the behavior of the application in abnormal conditions should be stated. Use cases can be very helpful to communicate the requirements. Checklists can also be maintained to create diverse scenarios that can be tested.
Detailed Design Phase
This phase includes testability by stating expected outputs beforehand. The designer will consider the checklists prepared during the requirement specification phase. The data flow should be transparent to the testers so that it is known which scenario calls which program. A correct expected output cannot completely guarantee that the internal flows are giving the accurate results. Scope for adding extra code or interfaces to test the application should be added in this step.
Coding Phase
This phase requires putting together testability approaches taken in the previous two phases. For this reason, extra design parts or algorithms need to be added and that should be made to undergo unit test as well. To make certain programs observable to the users and testers, test harnesses can be created which enables testers to perform testing at the unit level. Application should be unit tested for all the scenarios that were found in the earlier phases including how should and how shouldn't the application behave.
Testing Phase
All the testability measures taken in the previous steps of the project should be covered in the test plan and test scripts designed for this stage. Besides testing functional and non-functional requirements, they should be exhaustively tested. Any piece of code or functionality that is not reachable should be tested using some other method. Testability at this phase is handled with use of queries, stubs and drivers for integration testing, and test harnesses for specific modules or components.
Testability hence is the most neglected non-functional requirement which if not addressed in Software development may results in several other problems which may lead to other serious concerns which are not the real solutions of the actual problem and traps us in vicious circle which may worsen release after release. Also testable products are easily maintainable and thus cost less and achieving customer satisfaction with such products is therefore much easier. Hence “testability is vital for maintainability of the software”.
