Article from Inform IT
Manual software testing usually happens in one of two ways, using tests scripts prepared in advance and then executed rotely or exploratory where testers plan on-the-fly as tests are executed. In this article, James Whittaker argues that both techniques miss the mark and suggests a better way to think about manual test design.
Google started like many companies, with software developers writing and testing their own code. We developed and tested Search. We developed and tested Ads. The number of products and projects grew along with our campus, our employees, and our market share.
As Google grew, the company hired contractors to perform manual testing. A line was drawn in the sand. On one side of that line, developers performed unit testing, managed the build process, and performed basic integration testing on the software we created. On the other side, the contractors — often in obscene numbers — performed the manual testing. The image in my mind is one of bees buzzing around a hive.
As you might imagine, the growth of Google created a veritable army of contract testers. Testing became an expensive, unpredictable process that depended on individual talent and the sheer weight of contractor labor.
