I’ve been doing some reading this week in preparation for the internship kick-off on January 4. Elena (one of my mentors) suggested some articles, including Four Schools of Software Testing by Brett Pettichord, which compares and contrasts these approaches:
- Analytical—Focuses on the internal structure of the software and aims for comprehensive code coverage. Requires a detailed specification. Tests are technical (usually requiring programming skills) and have a binary pass/fail result.
- Factory—Testing for which there’s a predictable template that can be applied to different projects. In other words, something that is standardized and can be easily managed. Additional goal of cost-effectiveness. Focuses on requirements testing.
- Quality Assurance—Focuses on enforcing and improving development processes. Notion of having to “protect users from bad software.”
- Context-Driven—Takes into account the context of a software project (stakeholders, resource & schedule constraints, etc.) when determining the right testing strategy for this particular project at this particular time. In other words: flexible and pragmatic. Focuses on “exploratory testing,” in which each tester is highly engaged in understanding the stakeholder interests and the specs (both explicit and implicit) and aims to design tests that will advance the whole team’s understanding of the software.
Pettichord says right up front that his purpose in comparing these schools is to highlight how his own school (Context-Driven) differs from the others, so there’s extra attention devoted to that approach in the final third of the presentation. It interested me enough to follow some links and do some extra reading. Here’s what I learned:
Context-Driven or Exploratory testing starts with the acknowledgment that it is impossible to test everything about the software. (If you don’t believe that, check out You Are Not Done Yet, a testing checklist by Michael Hunter. I just skimmed it but was still overwhelmed!)
Given the almost limitless potential size of the task, the most effective and efficient way to proceed is to focus on, as Cem Kaner (a founder) puts it, “risks or issues that are of critical interest TODAY.”
That’s not all there is to it, of course. Another tenet of Context-Driven testing concerns gradually expanding test coverage to more and more avenues of exploration rather than simply repeating the same tests over and over again.
But the emphasis on immediate risks and issues along with the team focus and the idea of having ALL testers fully engaged in the problem-solving made me think of this scene from Apollo 13:
BarbV 