There is a Marketing Saying along the lines of:
“If you do something but you don’t advertise it, it’s like you didn’t do it at all”
This saying is also very accurate in the case of testing, where if you do a test that finds critical issues but then you fail to report them it is as if you had not done a thing (or worst!).
So the trivial lesson is: Find a bug, make sure you report it.
But as Test Managers our problem is more complex than this. At times, even if we work right and report all our findings to the rest of the team, we see them disregarding our warnings and acting as if we had not said anything to them (e.g. choosing not to fix critical issues, or releasing a product that is not ready for the market).
We can try to blame the rest of the Organization for failing to listen, but this would be “taking the easy way out”. I think that most of the times when the rest of the team fails to understand what we are trying to say it is because we didn’t communicate correctly with them. Or as a friend of mine once said, because our message was “clear as mud“.
Thinking about your audience before writing
Providing information is about telling people what they need to know, when they need to know it, and in a way that will be useful to them. We need to think about our readers, in this case the rest of the Development or Management Team, and understand what information they need and in what format it will be useful to them.
Many times we write reports as if they were intended to be read by the QA team only. They include information in a format and style that may not be easy to understand by people outside our team, or that can even be alienating for non-technical people. In many cases we simply write too much information that is not useful to anyone!
Our external documents and reports need to be formatted based on the needs and customs of our readers, and include the important information in a way that will make immediate sense to them, and will allow them to make decisions quickly and easily without the need to decipher, analyze or in some cases even translate the information from our internal jargon to the non-techie language they understand.
Remember that many times, and specially in written reports, Form is as Important as Content.
Deciding what information should not go into the report
As I started writing above, one of the most important things is to decide what information to include and what to leave out of your reports and documents. Your audience (the people you want to read your stuff!) have limited time and they expect you to choose what information is relevant for their decisions.
People expect you to to understand what stuff is important and what is secondary to the decisions being made. If you are not sure about this you can consult with one or two members of your audience, and try to understand not only what is important in your current report but what are the principles that make something important so that you won’t need to consult with them all the time.
Value your audience’s time and they will value your opinion.
When to speak up and when to keep quiet
A critical aspect when taking part of a meeting or review process is to decide when to speak up and when to keep quiet. What you are trying to avoid here is to be taken as the guy (or girl) who is always bringing forward the negatives points on each decision, and when there are not negatives points to make them up just for sport.
Even if your task is to bring forward the risks, bugs and drawbacks you need to make sure to point them out only when relevant and not to fall under the definition of “the boy who cried wolf” in your team.
Provide Information and Stop Being the Gate-Keeper
To summarize, we need to keep in mind that our Job as Testers is to provide the information that will allow the Management Team to make the right decisions.
Management are not very interested in our tests, mostly in our information. These guys want to know whether the product can be released. If yes with what risks or potential bugs, and if no why and what needs to be achieved (or fixed) before we can do it.
Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.
Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.
With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.