Thursday, 1 September 2011

What is manual testing good for?

I don't closely follow Michael Bolton (the test specialist, not the one that sucks - see "Office Space"). But this passage in his uTest interview resonates with what I believe manual testing should be about.
 
" Meanwhile, I observe that many Western firms—mostly the Americans—are making life difficult for testers in India and other developing countries. These firms didn't know much about testing to begin with. They viewed it as a rote, clerical activity, piecework, checking work, commodity work that delivered little value. They knew how to do checking, sort of, very slowly and very expensively. But they didn't know how to do testing, or how to increase its value, so they focused on cost and outsourced it.
The developing countries have millions of intelligent people who want to develop skills, but the West is still requiring these overprescribed, expensive, low-value, confirmatory approaches in which smart human testers are being asked to behave like slow, dumb machines. Confirmatory tests do find problems, but to a great degree, programmers should be pairing and low-level automated tests to squash those problems before testers ever see them. Then free up the testers to look for higher-level problems and previously unanticipated risks."

Testing the Limits with Michael Bolton: Part I | Software Testing Blog
http://blog.utest.com/testing-the-limits-with-michael-bolton-part-i/2010/01/

The manual testing is most effective when it's done to generate ideas about how to test an application or when it is impossible or not cost effective to automate. At Google we try to play by this rule when making decisions when to introduce manual testing resources for a project.

Some call this the "exploratory testing", and I couldn't care less about the nomenclature. :) 

0 comments:

Post a Comment