Software testing is not an activity to take up when the product is ready. An effective testing begins with a proper plan from the user requirements stage itself. Software testability is the ease with which a computer program is tested. Metrics can be used to measure the testability of a product. The requirements for effective testing are given in the following sub-sections.


The better the software works, the more efficiently it can be tested.

•The system has few bugs (bugs add analysis and reporting overhead to the test process)
•No bugs block the execution of tests

The product evolves in functional stages (allows simultaneous development & testing)


What is seen is what is tested

•Distinct output is generated for each input
•System states and variables are visible or queriable during execution
•Past system states and variables are visible or queriable (eg., transaction logs)
•All factors affecting the output are visible
•Incorrect output is easily identified
•Incorrect input is easily identified
•Internal errors are automatically detected through self-testing mechanism
•Internally errors are automatically reported
•Source code is accessible


The better the software is controlled, the more the testing can be automated and optimized.

•All possible outputs can be generated through some combination of input
•All code is executable through some combination of input
•Software and hardware states can be controlled directly by testing
•Input and output formats are consistent and structured
•Tests can be conveniently specified, automated, and reproduced.


By controlling the scope of testing, problems can be isolated quickly, and smarter testing can be performed.

•The software system is built from independent modules
•Software modules can be tested independently


The less there is to test, the more quickly it can be tested
•Functional simplicity
•Structural simplicity
•Code simplicity


The fewer the changes, the fewer the disruptions to testing
•Changes to the software are infrequent
•Changes to the software are controlled
•Changes to the software do not invalidate existing tests
•The software recovers well from failures


The more information we have, the smarter we will test
•The design is well understood
•Dependencies between internal external and shared components are well understood.
•Changes to the design are communicated.
•Technical documentation is instantly accessible
•Technical documentation is well organized
•Technical documentation is specific and detailed
•Technical documentation is accurate

You may also read:

Need for Software Testing

How and when Testing Starts