How to distinguish known issues from real misses and communicate both to management

Question

As am I working in a small firm, there is no QA manager position here right now. We are working with different projects, currently I am focusing on 4 to 6 projects which are using agile development.

My problem is, whenever a sprint is released to the client team, the client users are finding issues that are often captured and logged in JIRA before the client receives the sprint, but the bugs are still present because of time constraints or other issues - sometimes depending on the infrastructure side and sometimes functional issues. Management is making the decision to send the sprint to the client, but blaming us when they receive client results, even though they made the decision not to prioritize the bugs.

How do I identify which issues are actual failures by my team and which are known issues we reported?

More importantly, how to I convince management of this?

Answer 1

As I see this, you've got several problems here, all of them communications problems.

1. You are not communicating to your clients what known issues are in each sprint release. This leads to the client teams finding bugs that you already know about, wasting their time, making you look less capable to your manager, and wasting your time.
2. Your clients are blaming you for not finding the known issues.
3. Your management is blaming you for not finding the known issues.

I'd suggest you try something like this:

• Send a known issues list - Build a report from Jira of bugs reported but not fixed in the current sprint. You will need to make sure there's enough information in the report that the client users will be able to tell if a problem they find is one that you've already reported.
• Tell clients about the known issues list - If you communicate directly with the client test team, all you need is "Yes, that issue was reported on (date), and has not been prioritized for correction yet." No blame, just state the facts. If you're not the one communicating, make sure the person who is knows about the known issues list and has a copy of it or a link to it.
• Tell your management about the known issues list - If your managers don't know you've already reported the problem, they don't know whether your team was doing their job properly or not. If they can see a list of reported bugs that matches up to the issues the client reports, they know what's been reported.

Obviously, anything the client reports that is actually a bug (and not a stealth feature request, not user error, and not an unforeseeable problem like someone trying to install modern software on Windows 98) is something your team needs to analyze to work out why it was missed, and how to prevent similar misses in the future.

The most important thing is this: do not blame anyone. Even with the best people and the best environment, things will go wrong. Your teams goal is to analyze the actual mistakes to determine why things went wrong.