Many disagreements can be attributed to communication problems. The worst cases are those in which we don't even realize that our message isn't getting across the way we intended, and that's often because we're working in different contexts. Here are a few lessons that we've learned from years of discussions with context-driven testers.
In his blog, James Bach writes, "'Context-driven' means to match your solutions to your problems as your problems change". In the context-driven community, we don't believe that there are best practices; that is, there are no approaches that work universally for every project. It's fine to discuss practices that have worked in a particular context, but it's important to identify the aspects of the context that might be related to the success or failure of the practice-and how the context may color the ways in which the advice is given or received.
What's the Context?
There are dozens of possible dimensions of context that might vary from one development project to another. The context-driven principles state that people, working together, are the most important part of any project's context. Other key aspects of context include the product, customers, development group, schedule, budget, and resources. This isn't an exhaustive list by any means, and sometimes contextual elements can be subtle. In one company that Michael worked with, a change in the corporate email client had a profoundly negative impact on the company culture. eXtreme Programmers suggest that the arrangement of the workspace can make huge differences in team dynamics. Recognizing such differences and how they might matter is an important skill for people who are giving and getting advice.
What's the Problem?
A common trap is to argue about solutions without considering what the problem is in the first place. For example, someone who needs to efficiently execute a suite of functional tests through a Windows GUI every night might innocently ask "What are the best test tools?" That person might be surprised by recommendations for a unit test automation tool or a test management tool for manual test cases because he didn't mention the problem he's trying to solve.
Leaving the problem statement out of the discussion can limit the range of solutions that people offer-or can lead people to propose solutions to problems that you don't have. Open yourself up to creative solutions by keeping the problem in the open.
Be careful about saying "always," as in "Always automate your tests." From a context-driven point of view, an absolute suggestion would have to make sense in all possible contexts. To be credible, you have to understand all contexts. Even if you had this kind of omniscience, it would be difficult to convince anyone else that you did.
Often when people say "always," they are referring to a particular context that isn't stated explicitly. If you're not sure what that context is, trying to find counterexamples to the assertion you're discussing can be helpful in framing the context. For example, when faced with the edict "Always automate your tests," you might ask:
- If we're a week away from a big release and we've never automated a test before, should we start automating now? (Timing is part of the context.)
- Should we automate usability tests? (The context might involve just one of many types of testing.)
- Should we automate tests against an interface that is changing frequently? (This is a context that may have a poor return on investment for automation.)
When context-driven people talk to each other, we often ask clarifying or definitional questions. Why all the fuss about definitions?