no more testers?


I gave a keynote at EuroSTAR on the future of software testing where I began by painting a picture of the promise of software as an indispensible tool that will play a critical role in solving some of humankind’s most vexing problems. Software, I argued, provides the magic necessary to help scientists find solutions for climate change, alternative energy and global economic stability. Without software how will medical researchers find cures for complex diseases and fulfill the promise of the human genome project? I made the point that software could very well be the tool that shifts the balance of these hard problems in our favor. But what, I asked by means of a litany of software failures, will save us from software?


Somehow as I painted my predictions of a future of software testing that promises a departure from late cycle heroics and low quality apps, some people got the impression that I predicted ‘no more testers.’ How one can latch onto a 20 second sound bite while tuning out the remainder of a 45 minute keynote is beyond me. The US elections are over, taking sound bites out of context is no longer in season.


This blog is replete with my biases toward manual testing and my admiration for the manual tester. If you read it and if you managed to listen for more than a couple of minutes during my keynote you’d have to conclude that I believe that the role of the tester is going to undergo fundamental change. I believe that testers will be more like test designers and that the traditional drudgery of low level details like test case implementation, execution and validation will be a thing of the past. Testers will work at a higher level and be far more impactful on quality.


I quite imagine that the vast majority of testers who actually listened to my full message will rejoice at such a future. I invite the others to take a second read.


 

Comments (8)

  1. travelgirl says:

    would you care to comment on why microsoft (and other companies) are headed towards the "let’s automate everything" end of the testing spectrum, where requiring test engineers to become what is in essence a junior developer position is the norm around the company?

    i’m a contractor on a very visual project, and i’m constantly surprised by the amount of time we spend to automate the simplest tests, tests that could and should be done manually for a wide range of reasons, not the least of which is the total cost to implement the automation…

  2. mm31 says:

    I’m not from MSFT, so JW will be able to give his (inside) thoughts on this, but here’s mine.

    Automated testing is prefered to manual in many respects, but mostly because of reuse in regression testing.  MSFT has so many platforms, environments, versions, patches, etc, etc, to test on, manually doing each of these becomes intractable (all depends on the product, obviously).

    A manual tester’s "time" spent testing is a one-off activity – maybe it finds bugs, maybe it doesn’t in that environment/version.  A tester creating an automated test becomes an "asset", like code (once again, really depends on the "quality" and "usefullness" of the test case).

    In saying all this, I’m very much with James that manual testing is not only practical, but necessary – many bugs simply cannot be found in an automated way.  However, we really need to be automating more, and pushing that state-of-the-art because as software gets bigger/more complex, the issue(s) of testing it all become intractable for the number of testers we have.  

    That (IMHO) is one of the things James is pushing for – increasing the role, and skills, of testers into the developement so we can have more impact.

  3. nachrichten says:

    Maybe most of present tools are very successful. And they prefer simply to use them instead of testing new ones 🙂

  4. MSDNArchive says:

    Good points but I don’t think Microsoft is headed in the automate everything direction any longer. I think that there is a very good appreciation for manual testing. Let’s face it, there are some bugs that require a brain in the loop to find.

    There is a wave of interest and appreciation for manual testing here that I think you are going to be hearing a lot more about on this blog in the coming months.

  5. Mister Li says:

    Oh Michael was probably just teasing you James 😉 As a "real tester", he will certainly have caught the message.

    As to "there are some bugs that require a brain in the loop…": I would say: the real bugs are a result of the fact that software development is essentially a social, creative process. Bugs do not come about because someone intentionally put them where we found them (or at least I like to think so :)), but because all people involved so far have not thought of the possibility of the real-world-software-reality which is exposed at that time.

    Anyway I greatly enjoyed your presentations (as you will have guessed from my smile :))

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

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