When we deliver software products, we need to be able to tell our customers what they're getting. Not only product documentation, but specifically, every time we deliver a new release we need to relay what problems were fixed and what new features were added. If the software is subject to periodic audits, we need to tell them even more, especially the abiltiy to trace a requirement or change request to what was changed.
What’s happened to the links between requirements and tests? How do we know what to test and when? How do we, and the customers, know we got the system being built right? What’s the traceability between the two disciplines?
The role of the software tester is continuing to evolve, becoming more complex and more technical. As new methodologies, technologies, and platforms emerge, testers are bombarded with new, so-called "best practices" on how to do their jobs. The problem is that testers have heard the same songs with different lyrics for more than twenty years now. Clint Sprauve takes a contrarian’s view of testing and the quality assurance industry. He examines some of today’s typical testing "best practices"-keyword-driven testing, requirements traceability, the tester’s role in agile development, quality reporting, tool expertise, and quality certification programs-while providing alternative approaches for how to view each practice.