Designing the Software Testability
an abstract about testability
Testability is the extent to which a piece of software can be tested. In order to achieve a higher degree of testability, it has to be carefully considered right from the design phase throughout development. User-friendliness, User-experience, performance, scalability and security are the most common things that come in to picture when software are designed. Testability is one of the most important factor that generally gets overlooked in the design and development phase of software production. Development practises like TDD and BDD actually helps in early testing and test-driven developments but whether all possible aspects of testing are considered practically is a question. In most of the cases the practical TDD / BDD helps only with verification of implementation i.e., “Is the code right” whereas testing should also verify “Is it the right code” even if the specifications based on which it was developed are already validated in the design phase itself, that is what actual end-user testing is.
In Design / Development phase, the fundamental assumption that causes deviations from testing considerations is a perspective that everything can be tested on the finished product. Of course everything can be tested after a product is finished but is that needed and is it right to place all the tests at a stage prior to delivery is what needs rethinking.
Exhaustive Testing
Exhaustive testing is practically better and easily achievable if applied isolatedly for every component on all possible measure that adds to its quality instead of trying to test the finished product with use-cases that tries to address all components. This raises another question, “Are all components testable” ? The answer is “build components highly testable as much as possible”.
However in addition to all these isolated tests an optimal system level test also should be carried out to ensure the End-To-End completeness.
Exhaustive testing is placing right set of tests at right levels i.e., more isolated tests and optimal system tests.
Look at the pictures above (components and finished product).
Would you prefer to test each and every component exhaustively before assembling it or make components, assemble it into a bike and test it ?
Test Hooks
Test hooks are very much essential for exhaustive testing. These are special purpose implementation added to enable high testability. Think about what is going to be the input for a component and what will be it’s output. Place a right set of test hooks at both the end. A test hook could be a private API, a test UI or any interface through which the functionalities it depend on can be emulated through stubs or test fixtures and its output can be verified against expectations. Test hooks can / should be concealed when rolling out to production.
for instance, Let’s consider a Reports feature in a web application. The data gets captured as part of user interactions with the system. Information needed for generating a report has to be extracted from the tables / data stores. Transform the information by applying necessary business logic as per reports and Load the transformed information to the report rendering / generating (Information visualisation) engine.
The core components involved are the actual system to which Users interact, the Extraction component that selects and fetches the data from system, the Transformation component that applies the report’s business logic and converts the selected data into intelligence, the Load component that feeds the intelligence in to the report generator and the final component that decorates the information and outputs it to the end-user friendly interface.
System UI || E-T-L || Report Generator || System UI
The only way to do exhaustive testing for a system like this would be to connect all the components and perform tests end-to-end if no test hooks were built for individual components which makes the fault-isolation very difficult. Though it may not be a functional requirement to have APIs for E-T-L and Report Generator, building private APIs for them would really increase the degree of testability of the system.
Testability ∝ Delivery
Testability is directly proportional to delivery and maintenance of software.
