You need to know what's on the cutting-edge of technology. Find out what's coming and the unique Warptest POV with just one click on the "Blog" tile.

Core QA: How I handle Bug Triage

Core QA: How I handle Bug Triage

If you are on LinkedIn then joining groups and participating in discussions is a good way to raise your profile on the site.

linkedin One of the groups I belong to Project, Product & Program manager In Israel is a constant source of interesting discussion and debate for me (whether I am reading / listening from the sidelines or actively participating).

A discussion is usually prompted by a question either to trigger discussion or an actual request for information. Recently one of my contacts Itay, who has impressed me as a serious Project Manager asked the following:

linked_groupMy first thought was, “Great question!”

I was a little busy, newborn in the house and all but I got around to answering and I let myself give a quite detailed answer. For those of you who aren’t members of the group here it is:

—————————————————————————————————————–

The first stage of any triage process is to get all the parties involved on board with common standards of Severity and Priority. I recommend having no more than four severities keeping in mind that most organizations tend to marginalize any bug found below medium severity.
Severity is normally a QA function to define (I have a brief ppt on this I can share if you would like) but this too should be a standard that all involved parties agree on prior to testing beginning.
Priority is normally defined by at what stage (now, iteration, version or arbitrary date) either by the Product Owner/ Manager or in a Bug Review Meeting: both combining knowledge of Client requirements and commitments to actual targets.
Then you define the process for reporting, testing, reproducing, assigning and workaround/ resolution of the bug. Again if all parties are in agreement about the standards for this then there are no false expectations.
Bug reporting should be in real time and is the responsibility of whoever finds the bug or is POC with the external user providing information on a prospective bug. This should only be done via the Lifecycle Management or Defect Tracking Tool implemented by QA and not via email, over the phone, SMS, in an Excel file etc. "Bugs not reported in the system do not exist".
QA should not be tasked with data entry of all bugs anyone finds as they will never progress beyond this. Furthermore, the person with firsthand knowledge will be able to provide the necessary detail for QA to proceed with reproducing the bug / connecting it to an existing issue or upscaling / downscaling severity where required.
This all deals with new bugs however this must also be balanced with continued testing of major changes/ fixes to existing bugs.
All bugs in the system are subject to status being changed in bug tracking after Dev fixes, QA tests etc. allowing all interested parties to track changes to the overall health of the testable at any given time.
There should always be an emergency procedure in place for handling the showstoppers from discovery to resolution.
Finally, Bug Review meetings should be scheduled based on the cumulative impact of the total number of bugs found for a given set of tests i.e. if a high number of high severity bugs are found in one day then an impromptu meeting might be in order.

—————————————————————————————————————–

Now I should probably take the time to reformat and bullet this, there is a lot to digest. But ultimately feel free to read, comment and if you like use what is written here. As I have written in the past I am a strong believer in the philosophy,

Shared Information is Power / Empowering.

Now obviously this is just an outline but I think it gives you an idea of the way I like to work. If you would like to hear more or think I can help you in an area related to this then don’t hesitate to contact me, easiest is probably via Twitter @jonathanross

 
Comments
Leave a Reply