How to write a QA Report and not die trying
All of us that have been around the block in the Tech industry, and specifically Testers, know that it’s a very fast paced environment. Some days are slower than others but in general we start to run against the clock at some point, sooner than later, if it isn’t because the sprint has 4 days to go and we just gotten the code ready, its because a production issue was detected and we need to fix it and test it ASAP.
In the middle of this chaos, we still need to make sure our numbers are in order, test cases are created and even in some companies we need to add our evidence for every execution.
How can we help ourselves along the way and not die trying?
1. Create a dynamic report
The less work you need to do on your own, the better. Automate as many processes as you can.
Testrail (And surely every Test Management Tool) has a great HTML based report that let’s you create one from one or several Test Runs and looks like this:
You can clearly see the execution progress, how many test cases are passed, how many failed and how many are pending.
It can be customizable to run everyday at the same time or once a week or ad-hoc, whenever needed.
2. Use Jira filters
If you use a tool like Jira to track the process of the tickets, use the advanced search to query by Bugs, by User Stories or by all the tickets created by you. The possibilities are endless really. This can come handy to show the progress on the amount of open bugs, status and progress.
For example, you can show how many tickets are left for a sprint, how many are ready for QA, how many are still under Dev team. Give full transparency and avoid unnecessary questions.
3. Add an overall Status for the Project
The QA opinion matters more than you think. Don’t be afraid to state yours about the status of the project in regards to the issues, progress and time left. The stakeholders or business in most cases wouldn’t dare to move into Production or UAT without the QA Sign off, knowing that it might mean sending bugs and untested features into Production, and if you think the product is not ready you can say so.
Usually setting a color for every status is enough:
Green: Things are running smoothly.
Yellow: Starting to see some risks (in this point it is helpful to clarify the possible risks and mitigation).
Red: Point of no return. We can’t meet the deadline, we can’t move forward with the release. At this stage we need to specify the back up or fallback plan.
It’s good to discuss the status of the report with your PM just to be on the same page and not send mixed messages (but if your PM doesn’t listen, then it’s a good way to show that your opinion differs from theirs). In the end, you are the one testing the product.
4. Add your timelines
Give visibility on the date by when you have to finish your testing. This can be your UAT date, Production date, the day they need to remove the code from your environment, etc. This will help everyone else to get some context and understand the overall status.
5. Mix and Match
Maybe it’s another type of chart, numbers instead of colors or amount of total test cases instead of execution rate. It doesn’t matter, you can adapt the report to whatever works for you and your team.
Mix this items into an email or page (like Confluence) and send the link daily, weekly, whenever is needed to the people involved (PM, Product Owner, Stakeholders, rest of the QA team, Tech Lead, Team Leads) to keep them updated on your work. It will make yours and their work easier, and you will have a safe space to speak your voice.
