What does your QA reporting matrix look like in an Agile setup?

Originally sent in question Quick Question
ross

Hi guys anyone has reference on building QA report matrix for Agile development?

thankyou in advance

im a new Manager and looking into how can i report the work of my team to the higher management

Good question from @ross. What advice and resources can you share?

5 Likes

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
3 Likes

The purpose of this report are:

  1. Be Able to show QA productivity and projects quality updates.
  2. Show to the C-levels and Business team importance and value of the QA team
  3. 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

1 Like
  1. Show it to whom? Why? Don’t they understand it without reports?
  2. 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?
  3. This kind of report is not a good basis for improving real product quality and team efficiency :slight_smile: I wouldn’t suggest using metrics like “how well the team did each month”, they won’t work in reality :slight_smile: 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 :slight_smile:

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 :slight_smile:

2 Likes

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

2 Likes

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.

1 Like

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

1 Like

I agree with you that the quality of the project should be the team responsibility.