Every new project has its own goals. Without keeping these goals in mind, we – the testers – can’t handle any discrepancies and inconsistent situations. Likewise, test reporting is not the same for every test project and sometimes it needs to be revised for better outcomes.
This is the story of our Tim, a QA tester just like you.
A few months back, Tim was assigned a new project. He explored it and wanted to discuss the elements of test reporting and goals associated with his project manager; information required, decision-making, and reporting any lags in the current test reports.
Test Reporting – New Courses and Styles
In the meantime, Tim’s test project had received a blessing in disguise. The test manager he was working with got promoted. Meanwhile, he got a little more time before the meeting and so, used it more productively by researching various test reporting formats and styles analytically.
This time, however, he discovered more creative and constructive test reporting methods for his project. That’s when he felt it’s going to be good!
A new project manager was assigned to the project. And so Tim had a detailed meeting with him discussing all the test plans and goals linked to the project’s success.
Time to assess the testing scope
After the meeting concluded, the process resumed and the team started out with their very first attempt to analyze the scope of our project. So, we counted how many test charters were scripted vs. how many were completed. No surprise, but only the first attempt had a disturbing amount of flaws.
Where did Tim go wrong?
Initially, the number of test charters required were unknown for the project.
He didn’t script any test charters for product features or bugs until they were added to the log. Not writing charters meant that their number wasn’t important because the number could have increased as the process proceeded.
Moreover, it was understood that the charter number wasn’t a valuable metric for the project. Also, Time felt that he wasn’t putting any time constraints against the test charters because some charters could take an hour while some took a whole day to create accurate test data or assess the end-results. Subsequently, it became difficult for him to evaluate the process status, even determining the product quality got me confused.
How he resolved the problem?
So Tim mapped out a new reporting strategy. He considered our feature and bug tracking tool as a base since the reporting strategy of the test project was based on testing app features and bugs. The project was previously following a tree to classify the features, but Tim replaced the tree element with a script.
And it turned out GREAT!
The script, as per the plan would distribute that tree into a color-coded map that will give a quick glimpse of features tested and defects found. Surprisingly, this mind map turned out to be extremely helpful. It did not only allow him to get a quick report of the features and defects but also helped him view the areas where less development was done.
This allowed him to assess more severe and fragile bugs associated with a specific feature.
Just a little change could make the whole process much easier and exciting!
Tim presented this new reporting plan to the new test manager who was very impressed and appreciated my efforts on the project.
Conclusively, the whole team agreed that this reporting format is of great value to the project.
Also, Tim felt that there must be a specific dashboard with a simple format that displays every feature and defects on-board.
To get the same experience, rethink and redefine your test reporting strategy and become the hero for your next test project.
