Lisa Shepard, WebMD
Software QA Analysts take great pride in thoroughly testing every aspect of a product’s functionality. As complexity and variability of a product increases, so does the need for more thorough testing to ensure excellent quality and few bugs. At WebMD, we have found that one of our biggest impediments to thorough testing is over-documentation of all the tests that have already been run. To combat this, we encourage our QA Professionals to think critically about what manual tests to document. More specifically, we ask them to think strategically about what manual tests NOT to document. For most QA Analysts, it’s a natural instinct to document everything that was tested: for posterity, for future regression testing, to prove their worth to their manager, or a variety of other well-intentioned reasons. This over-documentation not only wastes the individual test writer’s time, but it creates a stockpile of indigestible artifacts that ends up having a negative effect on overall quality. This paper gives concrete examples of when we should and shouldn’t document a manual regression test. This information will help QA professionals, developers and managers who erroneously equate the quantity of tests with the quality of testing and inadvertently sabotage their organization’s testing efforts in the process. This provides details about what should be included in a regression test. Just as importantly, it highlights those details that should not be documented. Using what is learned in the paper, QA professionals will be better equipped to write manual regression tests that are robust, readable, and low-maintenance. In doing so, these QA professionals and their development teams will be in a position to see huge benefits of spending more time testing and less time documenting excessive details.
Lisa Shepard, 2012 Technical Paper, Abstract, Paper, Slides
