No two software projects are alike, so why should their testing methods be the same? This is the premise for context-driven testing, which promotes the idea that human behavior and feedback should inform software testing goals.
According to Krishna Prasad, director of delivery at emids, conducting context-driven testing starts with identifying the intended market for the software product and evaluating the environment in which customers are likely to use it. Examples might include nurses using mobile devices in the Emergency Room (ER) or healthcare executives using smartphones to connect remotely to hospitals in their network.
Rather than just evaluating whether the software feature is performing as expected without glitches, “context-driven testing validates the behavior, perspective, acceptance and satisfaction levels of users and the way they are accessing the product or system,” Prasad says.
In context-driven testing, there are no best practices. Instead, this approach requires the tester to adapt to the context of the software or tool in development. As a result, the theory goes, organizations can better explore how the product should work from a user’s point of view, and identify and address barriers that prevent users from fully adopting or accepting the product.
The approach was developed in 2001 by a team of software engineers who published this set of principles:
- People, working together, are the most important part of any project’s context.
- Projects unfold over time in ways that are often not predictable.
- The product is a solution. If the problem isn’t solved, the product doesn’t work.
The founders of this approach also assert that good software testing should be a challenging, intellectual process, and testers should use judgment and skill in carrying it out. Simply put, the methods used in context-driven testing should not be easy or rote.
While the concept of context-driven testing has been around for 15 years, it’s an approach that is still evolving in the healthcare technology marketplace, Prasad says. Context-driven testing works best when quality assurance has reached a mature state, he notes, and when service-level agreements and metrics are under control and progressing in a positive direction. It’s not for every organization, and it’s not a replacement for other forms of testing.