Summary
In this chapter, we covered some basic primitives of software testing. Recipes tell us how to test things that are not intuitively obvious. Coverage can give us a high-level view of the software, plus an understanding of how well we are currently testing, and the status of those components. Understanding coverage can help us understand if we are done, and where to invest the scarce resource of our time for what to test next. Coverage can help us make tough decisions such as “Are we done yet?”
Speaking of tough decisions, defects are a major source of information about the problems with the product and where to go next. The schedule for our testing determines a cadence; it needs to fit in with the rest of the delivery cycle. We considered the test strategy and how it evolves, specifically concerning addressing risks and priorities, including Karen Johnsons’ RCRCRC heuristic. To communicate our primitives, we introduced the idea of the dashboard, which...
