The problem with sharing the value of software testing
In a recent lecture, I asked a large audience of testers if their organizations value their work. More than 80% of them said no. I was left wondering what led them to this conclusion when the overwhelming majority of them felt this way. What did they think it meant to “be valued”? And how was this “value” being defined?
The problem is that value isn’t necessarily an objective measure.
Sure, there’s things like ROI and attribution models that can determine the monetary value of a certain activity, but when it comes to bigger questions like, “Should we invest in QA?” Value is frequently viewed and interpreted in a subjective manner.
As you can see, many times there is an abysmal value gap from team to team, and in my experience, this a direct result of lack of communication between them.
It’s interesting to see the difference between how testers and non-testers value software testing work. Some people who don’t test might think that this work just looks for useless bugs that won’t be fixed and wastes time on tests that don’t matter. In the meantime, testers are aware of how important it is to gather product-related data and present it to stakeholders so that they can use it to make sound decisions. Even when it appears that a particular test has a low probability of uncovering a major catastrophe, tests are a necessity and bugs are a byproduct. It is interesting to observe the distinction between how testers and non-testers value software testing work. Some people who don’t test might think that this work just looks for useless bugs that won’t be fixed and wastes time on tests that don’t matter. In the meantime, testers recognize the value of gathering and presenting product-related information to stakeholders for their assistance in making sound decisions. Bugs are a by-product and tests are a necessity, even when it seems like a specific test has a low probability of unearthing a major catastrophe.
Beyond water cooler talk
It’s not enough to just talk about how valuable your team’s work is at lunch. Great communicators know how to share and distribute information in a way that generates real value for all involved. So how can we testers do this? We need to work strategically: we need to gather the data that important stakeholders need, arrange the information in the right way, and make sure it is processed correctly.
In many cases, we see that testing data does not become actually valuable mainly because testers fail to communicate the importance of their tasks and the value of their work.
That is where test management tools come in. By sharing your testing metrics and interactive dashboards across your organization, these tools help you structure your communication and convey value.
Your message is important – make sure your data supports it!
As part of our work as testers, we collect data about the product and project status. While some of this data may not be as relevant to your stakeholders, others are very important. As a tester or test lead, it’s important to constantly ask yourself what information your stakeholders need, and make sure your testing operations are gathering this information and processing it.
Additionally, if your data comes from a variety of sources, combining them into a single location will provide a complete picture that will be simple for your busy audience to comprehend.
A dashboard like the one below, for instance, gives you a lot of information that can help you show how valuable the work being done is. In this particular instance, the tester has gathered crucial information regarding the kind of bugs discovered, the number of issues the team is working on, their status, and even who is working on each issue. Stakeholders are able to appreciate the team’s work when they have this clarity about what they are working on.
Interpretation is no less important than the data itself
In my experience, all good communication fulfills a few important criteria. In my work with stakeholders, I like to follow the SMART principles:
- Simple. Try to convey your messages using one-liners instead of paragraphs. Whenever possible, use graphs instead of words. Assume your reader has little time and a limited attention span.
- Measurable. Numbers and statistics speak louder than opinions and descriptions. This doesn’t mean that your opinions are worthless—sometimes with experience you simply know the answer based on your gut feeling—but supporting this feeling with hard data and evidence will make it more credible.
- Actionable. Data analysis is most effective when it suggests a solution instead of only pointing out flaws. In many cases, you, as a tester, are the best source of knowledge. Humility is always important, but if you have a solution, don’t be afraid to speak up.
- Repeatable. When you are providing information, you will most certainly be asked what was the previous status of the issue. The most common question you will hear is, “Is this a regression?” This means that your checks and tests should be repeatable, and you should strive to have historical information whenever possible.
- Timely. Provide information while it is still relevant, and when your stakeholders will be able to make good decisions. If you say the right thing, but at the wrong time, it will have little or no impact at all. For example, if you find an issue that will take weeks to solve when you are only days from the release date, it means that your team will either ignore the issue or they will have to delay the release. Keep your release date in mind so that any issues can be addressed before it’s go time.
Remember: your deliverable is information, not testing
Could it be that we, the testers, are the guilty ones for making our organizations undervalue our work?
If all we are doing is running tests, complaining about the lack of testing environments, or simply putting together tables with tons of data that people cannot comprehend, then we are not really helping the process of delivering great products to the field.
It’s about time we all understand that fundamentally, our main job is to help make decisions that will deliver a better product, on time, and within the scope! This is a harder job than just running tests and reporting problems, but especially in today’s environment of rapid delivery, we all need to help steer the ship in the right direction.
YOU MAY BE INTERESTED IN
The Art of Software Testing: Beyond the Basics
Automation testing course in Pune