Providing QA Defect Information for Support Teams

An additional area you may look to for providing customer care with an up to date list on current system issues may come from an unlikely but accurate place: QA production defects. While we may want to have perfect production systems, there is always a list of known issues from QA in the backlog for developers. Why not augment your known bug list this information for support? Your quality assurance department should be the place to look for known defects on production systems. Its likely they already have a full list of known issues.

Surface another set of information on customer facing defects: data from your own QA to better enable support teams dealing with customer issues.

Data to Gather

---

In order to provide accurate information for support teams, it may require the way QA production defect data is gathered to be changed. Additional data points will need to be collected to ensure support teams can use this data.

1. How do identify. What key factors can be looked at in how the software behaves to know this is the issue specifically vs. other problems?

2. Steps to reproduce. What steps can users follow in the user interface or API to duplicate this issue?

3. Expected behavior. How should the software be correctly working? What is the user expecting to happen?

4. Workarounds. Is there anything users or support teams can do to help a customer navigate around this issue and keep the software functional?

A standard bug writeup may include the first 3 data points already. One caveat: workarounds may be the sticking point which QA usually does not capture. You may need to negotiate with them to write this up or you will need to provide this to have a complete list.

Considerations

---

When using defect data its important to filter the data down to exactly what production support personnel need to see to make sure they are getting the most accurate set of known issues from this data. Take in to account these items to see if you can better refine the list to exactly what you need.

Filter down the defects to known versions in production. QA will likely be ahead of the curve and be testing / entering defects for items not yet in production. Its important to not show these defects to support groups as it will cause confusion. This can usually be accomplished by tagging or labeling issues as production.

Dynamic sourcing of the list. A key piece of this list is timeliness and accuracy. The only way that can be achieved is if this list is pulled directly from the most recent list of issues every time a user goes to access this information. If you are relying on users to generate this info that process can be forgotten. Once the list becomes stale users will lose faith in the accuracy.

Finding duplicates between QA list and known triage bugs? If you are seeing items duplicated between the lists it might be time to re-visit how you escalate triage issues for development. If the issues are known to QA already, then link and close as a duplicate to a known issue.

Training. Ensure as new defects are entered against production systems support teams are notified of these new items, identification and workarounds. This can be done as part of a news email or as part of the daily updates with new system issues. Not everyone will remember to go and check a page for updated information.