At my company, we don't have good tracking for escaped bugs (or awareness of in QA a lot of the time) once releases go to prod.

When the users find bugs they have a tendency to go straight to the developers and the developers don't tell the testers about it until they have a fix ready.
The problem with this is that there have been many times when it wasn't actually a bug, but a missed requirement or a requirement that was too ambiguous and wasn't coded and tested the way the user intended it to work. Both of those things need to be tracked too, but from a QA metrics perspective, they aren't being caused by something we missed in testing.

The other problem for me as a tester, is that if I missed something I want to know what it is for any number of reasons.

Have other teams had the same experience? How did you remedy it? Our users don't have access to open bugs (we use TFS) so that isn't an option.

  • You could ask your testers to ask experienced testers or any developer they trust, if the issue is/might be a bug and then report it. The developers can then close the issue if it is not a bug and also provide reasoning for closing it. Anything preventing you from doing this ? Also, are you 100% sure that bugs logged in TFS can't be accessed by everyone ? If not, then you need to use a bug tracking tool that can be accessed by everyone, not just developers/qa. – JohnSink Oct 24 '17 at 20:45

This is process related - nothing you can solve as regular QA tester.

Your QA manager need to talk to DEV manager how to improve communication between devs, QA and customers, and how to track relevant info to gradually improve your whole process.

Bug tracker is just one part of it. But as QA, you cannot make developer enter a bug to tracker, or do anything - only their own manager can do that, and only if s/he will see any value from that improved process.

Your QA manager needs to do that either with dev manager, or the higher boss above both of them.

And you need better argument that "you just want to know if you missed something". You (or better, QA manager) need to explain how establishing such process would benefit the whole company, how it improves the quality of your product and overall customer experience, not just solves something for QA.

One thing what should help you to get to your goal is that what you propose is considered industry standard best practice :-)

Regarding your customer's access to bug tracker: You should track customer feedback, but not in bug tracker. Don't offload to the customer tracking the bugs, dupes, blockers etc. Customer does not, and should not, care about your inner process. Use separate feedback tracker.

| improve this answer | |

Ideally when end users find a bug testers team is informed before developers. Then after it goes to developers because testers are to be blamed for leftover bugs :-). You should make some arrangement that users does not report directly to developers. They first consult testers for open bugs. Then testers obviously get informed before developers.

| improve this answer | |

Someone needs to enter these bugs into the bug tracking system. If the users can't/don't, then someone must do it on their behalf.

Developers shouldn't be acting on issues until after a bug report is written.

If there is a Help Desk, then the Help Desk should be entering bug reports on behalf of the users. If there is no Help Desk, then Developers should be entering these bug reports. And if everything else fails, the issue should be passed on to QA to write the bug reports.

No doing any of this is just silly. Management should educate folks about proper reporting of bugs.

| improve this answer | |

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.