Sunday, May 16, 2010

Beyond Testability

As testers, we are always worry about how a particular feature can be tested. We review specification, dev design - at each step ensuring that what lands in our plate as a product/feature is testable. We know what it needs to do, the design is open enough to allow access to whatever results we need - our tools and the product are compatible.
Last week I realised another aspect of the product we should worry about/review before the devs start implementing - does their design lead to unnecessary avenues of testing. In my case, this was in the scope of reuse. Our design was such that we were reusing an existing subsystem, but not the way it was meant to be. That was increasing our testing to a level that we had to retest the entire subsystem in a context it was never meant to cater. The development approach was simple , refactor the system to include our needs. A simple question from a tester perspective was that was it really necessary. What about doing some prework at our end before we call the subsystem. Turns out no one from the development team had bothered to go that route. On our insistence, they spent a day in trying out our approach. They found a couple of cases where this approach would never work. We are using the approach which was first defined in the dev design. I as a tester am happy that we have thought of everything before taking this decision. The extra test effort that we have feels necessary and we're happy doing it.
That made me realise that when reviewing the dev design, we need to think beyond testability. We have to ensure that no unnecessary threats are being exposed. The decisions we are taking are required and well thought through.