0

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?

5

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.

  • @ Kate Paulk -- We are sending the known issue list to the client but here problem is apart from the known issues some issues need to be addressed that is listed in the JIRA but those issues are not fixed and team is jumping into next sprint. The same issues which is reported by me is coming back again from the client team. Really am not blaming anyone am just thinking how i can solve this problem for the future releases – Anand Jun 18 at 7:31
  • Like I said in my answer, the first part is to make sure everyone involved knows what's happening. Once you have that down, you can start campaigning to have known bugs fixed as part of the next sprint. One of the ways you can do this is to be able to pull stats that say "In the last 5 sprints, 90% of issues reported by clients were also reported by my team, but have not been prioritized for correction. Risks of leaving these issues uncorrected include... We need to allocate part of each sprint to correcting issues from prior sprints." – Kate Paulk Jun 18 at 11:39
  • Thank you very much let me try out that – Anand Jun 18 at 12:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.