Testers as Designers

Modern testers play largely a role of late cycle heroics that often goes unappreciated come review and bonus time. When we find the big bug it is because we were supposed to … that’s the expectation. When we miss the big bug, people ask questions. It’s often a case of ignored-if-you-do and damned-if-you-don’t.

This is going to change and it is going to change soon because it must. My friend Roger Sherman (Microsoft’s first companywide Director of Test) describes this change as the testing caterpillar becoming a butterfly. According to Roger: testing’s butterfly is design.

I couldn’t agree more. As testing and test techniques move earlier in the process testers will do work more similar to software design than software verification. We will place more emphasis on designing quality strategy for all software artifacts and not just the binary. We will spend more time recognizing the need for testing rather than actually executing test cases. We will oversee and measure automation rather than building and debugging it. We will spend more time reviewing the status of pre-existing tests than building new ones. We will become designers and our work will be performed at a higher level of abstraction and earlier in the lifecycle.

At Microsoft this role is that of Test Architect and I think most testing jobs are moving in this direction. If you’ve read the first six posts on this Future of Testing thread then you’ll appreciate the changes that are making this design centric role possible in the first place.  

Now this sounds like a nice future but there is a decidedly black lining to this silver cloud. The blackness comes from the types of bugs and the types of testing we are currently good at in 2008. It is no great stretch to say that we are better at finding structural bugs (crashes, hangs and bugs having to do with the software and its plumbing rather than its functionality) than we are at finding business logic bugs. But the future I’ve painted in this series has any number of technological solutions to structural bugs. That will leave the software tester to deal with business logic bugs and that is a category of issues that I do not think our entire industry deals with in any organized or intentional fashion.

Finding business logic bugs means that we have to understand the business logic itself. Understanding business logic means far more interaction with customers and competitors; it means steeping ourselves in whatever industry our software operates; it means not only working earlier in the software lifecycle but involving ourselves with prototypes, requirements, usability and so forth like we have never done before.

There’s hard work early in the software lifecycle that testers aren’t experienced in doing. Performing well up font will mean facing these challenges and being willing to learn new ways of thinking about customers and thinking about quality.

Things are decidedly different at the front end of the assembly line and it’s a place more and more testers will find themselves as the future makes way for the present.