the future of software testing (part 7)

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.

Comments

• Anonymous
  October 07, 2008
  PingBack from http://www.easycoded.com/the-future-of-software-testing-part-7/

• Anonymous
  October 07, 2008
  The comment has been removed

• Anonymous
  October 08, 2008
  The comment has been removed

• Anonymous
  October 08, 2008
  I got this question, entitled "Confused" in email: "Part 6 of your 'future of software testing'seems to imply that involving testers in design is not the right thing. However part 7 reads as though this is the way forward. Have I really misread these two blog posts or have you changed your mind?" Here's my reply" "Confusion is not always a bad thing I used to tell my students...it means that you are thinking about it deeper than most. People who never get confused are those who never question anything. This is a bit subtle. It's the word design and what is being designed that is the key. I said in 6 that testers shouldn't design software and I stand by that, now and in the future. But in 7 I said that testers will design tests. Big difference. Right now I think we develop tests. In the future we will design them. Our present is tactical, our future is strategic. Thanks for the mail."

• Anonymous
  October 16, 2008
  As a QA manager in a company providing solutions to financial institutions, this is very much my current experience - we are moving part of QA away from the traditional sort of testing activities; to working with development at design stage, building tests and test data alongside code. This means that the testers have to have a much higher degree of business logic understanding, and much more interaction with the customers (to determine appropriate data and conditions).

• Anonymous
  February 03, 2009
  [Nacsa Sándor, 2009. január 13. – február 3.]  A minőségbiztosítás kérdésköre szinte alig ismert

• Anonymous
  February 08, 2009
  [ Nacsa Sándor , 2009. február 6.] Ez a Team System változat a webalkalmazások és –szolgáltatások teszteléséhez