- to generate" scenarios should be added in this step.
- Coding Phase: This phase is the most crucial phase. Testability approaches taken in the last two phases should be incorporated here. To achieve this, additional design parts or algorithms can be added and should be subjected to thorough unit testing. In order to make certain programs visible to the users and testers, test harnesses can be generated in this phase so that the testing team can start some testing at the program and component level. All the scenarios covering what the application should and should not do that were derived in the previous phases should be incorporated and unit tested at this phase.
- Testing Phase: The test plan and test scripts designed for this step should cover all the testability measures taken in the previous steps of the project. They should be thoroughly tested along with other functional and non-functional requirements. Any functionality, code, or program that is not accessible via User Interface or any other commands, should be subjected to other plausible methods of testing. Testability can be addressed at this phase by using specific queries (for certain applications), generation of stubs and drivers for integration testing, and using test harnesses for specific modules or components.
From the above discussion, it does not seem that testability is a very difficult property to incorporate in any software or component. On the other hand, if software is testable, it is much easier to execute test plans and test scripts systematically without using much ad-hoc measures during the testing phase. Then what stops us from testing testability?
Some myths about testability delay its introduction in the project artifacts. Testability is perceived to be expensive because the cost of adding testability in the different phases is very easy to identify, but the losses incurred due to its absence are not very easy to determine. This is because customer satisfaction and maintenance are not even evaluated until the product's implementation or the end of the project. Some of the commonly found myths are:
Myth: Testability is expensive.
Testability doesn't have to be expensive. A small investment throughout the project phase can give us a major improvement in fault detection.
Myth: Testability can be a plug-in.
Testability is a way of ensuring quality. Just like quality cannot be added in a product as a separate ingredient, testability follows the same trend. It has to be gradually built into the product over time.
Myth: Low budget applications cannot afford testability.
Low budget applications will normally have large volumes of sales with large number of user licenses. This will increase the cost of maintenance if the application is not maintainable. Thus a modest investment right at the start can save a lot of hassles and maintenance costs after the sale and implementation of the software.
The discussion above points out the importance of probably the most neglected non-functional requirement of modern day applications. It also points out the myths that are associated with it. But the fact is in order to be competitive in the market place and get our money's worth, it is important that testability is recognized and steps are taken to address it from day one of any project.
- Gupta, S.C and Sinha, M.K, "Improving Software Testability by Observability & Controllability Measures". 13th World Computer Congress, IFIP Congress 94, Aug-Sep 1994
- Hare, M.; Sicola, S.; IEEE Region 5 Conference, 1988: "Spanning the Peaks of Electrotechnology", 21-23 March 1988, Pages 161-166
- Lutz, M, et al, "Testing tools", IEEE Software, pp 53-7, May 1990
- Wallace, D.R, "Verification & Validation", in Encyclopedia of Software