In previous posts, we defined context-driven testing, which evaluates how a software tool should work from a user’s perspective, and explored the benefits of using this testing model to minimize production defects in diverse software projects.
Conducting this type of testing involves identifying the intended market for the software product and evaluating the environment in which customers are most likely to use it. The two best approaches for achieving this include:
People-centric Approach: In this approach, the testing team enlists so-called domain experts to interview software users and gather input on their experience with the product. Typically, domain experts might include a team of Subject-Matter Experts (SME), including those in the actual roles being interviewed such as nurses, providers and care managers, along with User Acceptance Testing (UAT) users, developers, business analysts and quality assurance testers. These experts should be knowledgeable about the software, but it’s also important that they remain unbiased so that they do not influence users based on their own experience with the product. Once the feedback is collected, domain experts use data from those interviews and experiences to create and conduct exploratory tests. Based on the outcomes of the tests, experts analyze the data and provide feedback to the business team concerning usage patterns, defects, and enhancements that could be made to the product itself as well as its documentation. This analysis can also help the testing team improve their evaluation strategies.
Technology-based Approach: This approach to context-driven testing is similar to the people-centric approach. In both approaches, data collection and analysis take place that reveal usage patterns and help inform product and documentation enhancements, as well as testing strategies. The main difference is that this approach uses technology—usually a lightweight, discreet agent on a computer or another device—to capture the user actions and test data.
Which approach should you use? Since context-driven testing places more emphasis on the people using the software, logic would suggest that a people-centric approach would be better. The more likely determinant for using one approach over the other, though, is what your organization and the users of your software will allow. If your organization won’t allow the testing team to install an agent that captures actions performed by users (as is often the case), the people-centric approach is your best and only option.