Testers are all working in the context of a software project, a business domain, a technology stack, and their assumptions. We fill in our assumptions along the way with things we learn while testing software and while talking with people. Sometimes the information we learn is good, but sometimes we miss something important.
Here are two quick wins I like to use for filling in those assumptions with good information.
In several of my roles, the first time I got information about a new feature or change was when it popped into my work queue as ready to test. The card usually contained a brief summary of what was changed, and maybe a suggestion or two about what to test. Testers are masters of working in uncertainty, but that doesn’t make this situation ideal.
Closing a gap in the communication loop is one way to build context. I usually start by moving up to product management. Product managers hold primary-source knowledge about your customers. They study the market and talk directly with customers before designing new product features. Product managers distill what they learn into a message developers use to guide making code changes. And like a game of telephone, eventually you get that message, but it’s altered in a few ways.
Moving closer to product management by talking with them daily when you have questions, or even by sitting in on some of their meetings, closes a significant gap in a tester’s understanding of the customer and what they value.
Each aspect of a development organization—product, development, and testing—has some sort of flow they follow. You can watch the flow of information in those groups, but sometimes these workflows are hidden if you are not explicitly looking for them. This illustrates context gaps. One I see most testers happily ignore is development and code.
Your source code repository holds secrets, but they aren’t held firmly. I like to ask for access to the source code repo, frequently GitHub, and have a look around. Most changes will go through a gatekeeping process called a pull request. Here you can read the change, see how the developer tested that change, and learn what other people think of it.
This should inform your testing. It will tell you what parts of the change others think are risky, you can see what test coverage exists and what is missing, and you can get a feel for how much this change might affect other parts of the product. Reading code is a new skill, and it will be difficult at first, but you will get good at it over time.
Building context is a key ability in testing. Every member on your team holds little bits of this context that can help fill out your understanding of the product. By talking to your product managers to learn about your customer and talking to your developers to learn about your code, you can inform your own testing.
