Course 6: Triage Guidelines

Learn some triage guidelines.

Triage Guidelines

Follow these best practices to triage all issues smoothly.

A Useful Guide to Judging the Value of a Bug

Ask yourself two questions:

  • Does this bug fall in line with the expectations of the cycle?

  • Does this bug impact my application?

When the answer to the above two questions is generally yes but you are either unable to reproduce the issue yourself, remember the TTL also does this as part of triage or you cannot prioritize the issue to be fixed, designating the bug as “Won’t Fix” will still credit the tester for their work.

Use Your Test Team Leader (TTL)
  • The goal of the TTL is to speed up your triage process and manage the testing group

  • TTLs are asked to review and replicate every issue within 24 hours of filing

  • For each issue you should see a recommendation broken down into the following:
    • Could they reproduce, was it a duplicate, is it in scope, do they recommend approval or rejection and what value

  • The TTL is asked to verify that every report has all the information you requested and has provided clear steps and followed our reporting standards. They may also leave a comment under the recommendation section to explain further

  • The TTL is your immediate source to help redirect testers or modify instructions. Feel free to reach out to them if something needs to change during a cycle

Triage Early in the Cycle

When you start approving issues testers can learn what is valuable to you and what is being approved and rejected. Doing this while the cycle is active early is a means of keeping them focused and engaged.

Do Not Fix Bugs Before Approving Them in the Platform

This will make it harder for you to keep track of the status and progress of issues and may also confuse things for the testers, especially if you attempt to run a bug fix verification cycle later on. The smoothest flow for you would be to review the triaged bug results in the platform from the TTL, make your final bug value determination, push the results to your BTS and then assign to your developers to fix. Once fixed, we can run a bug fix verification cycle for testers to confirm the fix was successful.

Be Careful About Exporting Non-Approved Bugs to BTS

Integration with your bug tracking system will save you tons of time and energy in sending discovered issues to your developers. Although you can export bugs into your BTS prior to approving them in the Applause platform, keep in mind that testers typically get compensated for their bug finding efforts, so it’s important to keep the community engaged and interested in your product by going back and approving those bugs shortly thereafter.

Notes on Works as Designed (WAD) Rejections
  • When you reject for this reason, the tester’s ratings are not affected, so anything that they could not have known should be rejected as WAD

  • The Works as Designed rejection as well as Approving as “Won’t Fix” is designed to encourage testers to submit issues when they are unsure about them, so potential concerns aren’t missed for fear of rejection

Bug Severity vs. Bug Value
  • There are times when the issue itself may not be that severe to the site, but because of limited scope or a mature product, the tester has found something right on target to the task given in scope. In those situations it may be appropriate to value the bug based on being on scope rather than the priority level it will be assigned

  • Occasionally you will see some high quality testing that required a lot of effort but the value of the issue is not that big a concern. Feel free to reward good testing/reporting as well as high priority issues. This keeps them going for more

Too Many Somewhat Valuables
  • Why it’s important to a tester - Testers are paid according to your value of the bug and the scale is significantly weighted to provide them incentives for looking for high value issues. If too many of their bugs are being valued at the lowest level, they will stop testing to avoid diluting their rating

  • Why it’s important to you - Assigning the right value to a bug is the ultimate aligning of expectations for our testers. For your sake, approving as very or exceptionally valuable is telling the testing pool “this is what I want to see the more of” – when appropriate of course

Too Many Very Valuables

Conversely to the above, if too many tickets are overvalued you will see testers throw a lot more against the wall and you may see them “over reporting” the same issue in different locations in order to garner another high payout.