Good question from @ross. What advice and resources can you share?
Hi!
@ross are you sure you need an exact QA report matrix and not other approaches to provide/track some status updates/testing progress? What are the main reasons to build this matrix? Who are the targeted audience who will use it and data from it?
The simple example for the QA reporting matrix, I assume could be like that (but I’ve never used it):
Story/Feature | Priority | Test Cases | Test Status | Defects | Cycle Time | Risk Level | Comments |
---|---|---|---|---|---|---|---|
Feature 1 | High | 90 | 80 Passed, 10 Failed | 1 Critical | 7 Days | High | Needs better test data |
Story 2 | Medium | 70 | 7 Passed | 0 | 15 Days | Low | Needs additional integration testing for the backwards compatibility |
The purpose of this report are:
- Be Able to show QA productivity and projects quality updates.
- Show to the C-levels and Business team importance and value of the QA team
- Make this report a basis for things to improve and how well the team did each month
im looking into having these matrix as simple as it could be for me to be able to consistently maintain the report
one more thing to consider is that the team is working on multiple projects and there is automation report to add as well
- Show it to whom? Why? Don’t they understand it without reports?
- Have they asked for this particular report? Have they told you what information they need and why, how they will use all the details, which format they prefer, etc?
- This kind of report is not a good basis for improving real product quality and team efficiency I wouldn’t suggest using metrics like “how well the team did each month”, they won’t work in reality especially if “you’re looking into having this matrix as simple as it could be”. And the reason for its simplicity is not about making it easy for you to do but to make it useful, real, and according to the requirements of people who will use data from this report so it might be challenging to maintain the report consistently.
I would suggest using reports per project and you can include info regarding the automation efforts, I hope you don’t need to write the whole report solely on automation
Think about the values, goals and purposes of the reports, it’s not about writing them regularly just because you asked to, it’s about understanding how the info from them is used, how it helps improve quality. If there is no clear vision and understanding of these aspects it’s better to ask how to change the situation in your organization
I produced a line chart of how many bugs we had to fix against time. If I was doing it again I would make it an XMR chart
Something else I did was produce control charts showing the number of unit test created by each dev team each week. This showed that one of the teams was not following good engineering practice and explained the number of bugs found in their work.
I wonder whether there is a danger of maintaining an ‘us and them’ approach to QA on an Agile project, which by normal definitions is meant to be a team approach, not a team within a team…? Of course I am well aware that Agile has many methods of implementation and controls
I agree with you that the quality of the project should be the team responsibility.