Context-driven testing, or contextual quality assurance, is a testing approach that puts the context of the software being developed and the people who use it at the core of the testing process. As we’ve covered in previous posts, this testing method promotes the idea that human behavior and feedback should inform testing goals. Rather than following a test plan with specific lists of actions, testing teams are trusted to use their judgment and skill to determine how they need to test to meet the expectations of users. Utilizing this approach can provide organizations with helpful insights about the product in development and help them identify issues with the software more quickly, explains Krishna Prasad, director of delivery for emids.
Sounds like a smart strategy, right? We think so, but implementing context-driven testing takes careful consideration. Here some points to remember when considering it.
It’s not for everyone. This is not so much a recommendation as it is a warning. Context-driven testing works best when quality assurance has reached a mature state—when service-level agreements and metrics are under control and progressing in a positive direction.
Choose domain experts carefully. The testing team will enlist so-called domain experts to gather information from users, analyze data and usage patterns and make recommendations. These domain experts typically are physicians, nurses, care managers, cross product owners or members of the operations team. They should not be biased, but they should be knowledgeable about the product and its goals. They should have soft skills for interviewing, as well as be good observers and documenters.
Be nimble. One of the founding principles of context-based testing is that projects unfold over time in ways that are unpredictable. Another is that people, working together, are the most important part of any project’s context. Put those together, and you can see how being nimble and open to change is important for context-based testing. Flexibility is key, because what works for one project may not work for another.
Be curious. According to this post on SmartBear, without asking questions, “it’s extremely difficult to understand the context of a project, which in turn makes it very difficult to obtain maximum test coverage.” Therefore, any context-driven tester should ask questions of stakeholders, the development team, as well as fellow testers, according to the post.
View our white paper to learn more about context-driven testing.