Open Category List

Working With Issue Reports

6 minutesread

Accessing and working with bug reports in the Applause Platform is very easy. In this article, we’re going to walk through how to access the bugs, as well as what information is displayed in the bug.

First and foremost, you’ll need to access the particular cycle you’re reviewing the issues for. You can do this by clicking on the name of the relevant cycle in your Testing Progress module on the Dashboard.


Doing this takes you to the cycles Issues page. This page gives you a quick heads up breakdown of the current testing progress on your cycle, as well as a list of issues submitted.


There are several features on this page that will allow you to streamline and customize your views of the issues.

First, you can perform a batch action on the issues listed by either checking the individual check boxes to the left of the Issue ID, or by selecting all issues by utilizing the top checkbox next to the ID header. With this, you’ll be able to perform the following actions, located in the Actions dropdown box:

  •      Export: Allows you to export the list of issues either to a customizable CSV file, or to your external bug tracking system, such as JIRA


  •      Send for Verification: If a fix has been committed and a new build provided, you’ll be able to send this back to a tester to verify if the issue is fixed on the build you select from the Choose Build dropdown. You will also be able to add a fix verification comment – it’s a best practice with this field to specifically layout what was addressed, as in some cases not all aspects of a bug will be fixed.


  •      Mark as Resolved: Marking an issue Resolved signifies that work has been completed and verified on the bug and will remove it from the list of active issues.

To view or manage a particular bug, you simply need to hover over and click on the issue in the list of bugs, either from the dashboard, or within the Issues tab.


After clicking the issue, you’ll be brought to the issue detail screen, which allows you to review the tester’s findings and corresponding technical data, approve or reject the bug, or request more information as needed.

Information Displayed in A Bug

There is a lot of relevant information displayed on the bug details page


  •      Tester: The name of the tester that submitted the bug. Clicking the testers name will bring up the testers profile. Additionally, you can click the blue badge next to their name to mark them as a Favorite Tester.
  •      Environment: Where the bug was found – either a mobile device, web browser, or the like
  •      Build: The build of the product the issue was found on
  •      Product: The name of the product being tested
  •      Bug Type: What kind of bug it is – either Technical, Functional, or GUI.
  •      Severity: A gauge of the testers opinion on the bugs impact – either Critical, High, Medium, or Low.
  •      Resolution: Will detail whether or not the bug has been resolved
  •      Export: Whether or not the export has been sent to your Bug Tracking System
  •      Status: If the bug is Approved or Rejected
  •      Approval: The value of the issue, detailed in the Bug Approval Process below
  •      Frequency: How often the issue occurs
  •      Action: The steps the tester followed to find the issue
  •      Expected Result: What the tester feels should occur in this situation
  •      Actual Result: What actually happens when the bug is encountered
  •      Error Result: The error message displayed to the user, if any
  •      Additional Information: This can be used to detail whether or not the tester was on a Wi-Fi connection or Mobile, the Fix Verification status of an issue, what browser was used, or any other information the tester feels is necessary to pass along
  •      Attachments: Typically screenshots or videos that are relevant to the bug, but can also be used to upload crash logs and other files that might help in resolving an issue

Discussion Tab

The Discussion Tab allows you to make comments or notes.

  •      Discussion: Used to communicate between yourself and the tester. Entering text into the text field and adding the comment will keep a running transcript of the communication between all parties.


  •      My Notes: This can be used to communicate between yourself, the PM of the project, and the Test Team Lead of the project. These notes are not visible by the tester.

History Tab

The History tab is a living, running track of any and all changes that get made on a bug. All changes, from something as minor as a text field to as major as a change in status are stored and tracked on this page.


Bug Approval Process

The bug approval process is very straightforward. You’ll notice at the top of a bug three buttons that you can use:

  •      Approve: Used when a bug has been reviewed and triaged and found to be of value. Approving a bug also requires you to rate the value of the issue as either Somewhat Valuable, Very Valuable, or Exceptionally Valuable. These rankings are very important, as they dictate the testers payout and directly impact their rankings in the Applause system.
  •      Reject: If a bug is found to be Duplicate, Out of Scope, Working as Designed, Invalid, or some other similar reason, no payout will be triggered to the tester for the issue, and their ranking will be impacted as a result.
  •      Request More Information: Sometimes when a bug is submitted, necessary information is missing. The Request More Information button prompts you to enter what information is needed in a dialogue box, and then sends that request to the tester who submitted the issue. At this point, the issue is out of your hands. If the tester fails to respond to the information request and fails at supplying the requested information, when the cycle is closed the issue will automatically be Rejected.

For more information and tips, please visit the [ilink url=””] Bug Triaging Best Practices[/ilink] help topics page.

Actions Menu

On the upper right hand side of the screen is the Actions dropdown menu, which gives you further options you can perform alongside the Approve, Reject, and Request More Information buttons. You will also see Approve, Reject, and Request More Information in this dropdown, giving you another way to perform these actions. Please note: After a bug is approved, the Approve, Reject, Request More Information options will be grayed out and inaccessible.


  •      Edit Bug: This will allow you to edit information contained within the bug report itself by opening a modal with the following editable fields: Title, Bug Type, Frequency, Severity, Attachments, Actions Performed, Expected Result, Actual Result, Error Message, and Additional Info.
  •      Export (Sent): Exports the bug to your bug tracking system. It will only show as (Sent) after the export has been sent.
  •      Mark as Won’t Fix: Sometimes when a bug is submitted, extenuating circumstances prevent a valid issue from being fixed. When this occurs, you can mark the issue as Won’t Fix. This still triggers a payment to the tester, as it’s a valid issue, but you can go about fixing other issues instead of this one.
  •      Verify (Fixed): After a bug has been triaged and work has been done to address the issue, you can Verify the issue as Fixed. This will prompt you to select the build it was fixed on, and make a comment to the tester about what was fixed, as detailed earlier. This will only show as (Fixed) after the bug fix verification process has been initiated.
  •      Mark as Resolved: Marking an issue Resolved signifies that work has been completed and verified on the bug and will remove it from the list of active issues.


6 minutesread

Related Knowledge Base Posts