General Reporting Procedures


You can increase the chance that your bug will be fixed quickly by using the proper format and content. These guidelines will provide you with a framework to properly write an effective report.



  • Be specific.
  • Use clarity. Succinct bullet points are helpful.
  • Refrain from using CAPS for sentences or whole words anywhere in your report.
  • Include at least one attachment (video, image, log, etc.) with each report.
  • Reports that do not contain at least one attachment will be rejected.



  • Report on all bugs, no matter how small they may seem.
  • Prepare a separate report for each bug detected.
  • Reports should include facts only; do not try to speculate about what happened.


Preliminary Steps

  • Use a recent software build to reproduce your bug before preparing a report.
  • Always check the database to see if your bug has already been reported.
  • Do not submit a duplicate bug report or it will be rejected.
Reporting a New Bug


Bugs should be classified according to severity. Classifications to use are as follows:


Critical Bugs: Also known as Severity A Bugs, critical bugs cause a complete failure of the software system or a software system component. They completely halt productivity and there is no solution or workaround. Examples of critical bugs include:

  • Bugs that halt the application, tools or engine
  • Reproducible crashes that prevent the user from using key app features such as save and share
  • Bugs that impede the app production workflow
  • Reproducible crashes that stop the user from accessing app menus
  • Bugs that cause severe production or publishing deadlines
  • Any bug that completely halts continued product testing


High Severity Bugs: These bugs share many of the same criteria as critical bugs. However, they are not classified as critical because they don’t completely halt the workflow or application. Additionally, high severity bugs can usually be avoided by using a workaround. High severity bugs:

  • Bugs that cause a severe reduction in application functionality
  • Irregular bugs or those that are challenging to reproduce
  • Bugs related to compliance failure


Medium Severity Bugs: This type of bug does not result in complete system failure or completely halt workflows or programs. However, medium bugs usually cause significant annoyance or frustration among users and can reduce efficiency or productivity. Examples include:

  • App design and UI bugs
  • Bugs that prevent music, video or audio from being played
  • Pathfinding bugs
  • Bugs impacting shaders and other graphic design elements
  • Camera or clipping errors
  • Localization errors
  • Documentation errors
  • Legal issues


Low Severity Bugs: Low severity bugs are mildly annoying but do not cause system failure or impede work performance. They are more aesthetic in nature and testing can unfold without interruption. Examples include:

  • Typing errors in documentation
  • Screen formatting errors
  • Layout issues


Usability Bugs: This type of bug is caused by an error that surfaced during the design of the user interface. The result is an interface that is challenging to learn, difficult to read, and inefficient. Usability bugs can range from minor to severe, and are always a source of annoyance and inconvenience to users. Examples include:

  • Minor cosmetic issues such as poorly aligned fields
  • Font that is cut short due to improperly sized text entry fields
  • Missing menu commands
Completing a 10 Point Summary


Every bug report should contain a summary of the problem. Your summary should be concise and informative. It should contain all relevant details but should not contain any speculation. Each bug report must include the following 10 components:


1) A short but informative headline that includes a short description of the issue

2) When did you first notice the bug?

3) How frequently does the bug surface?

4) Where does the bug appear? (For instance, on the main menu screen or splash screen)

5) Can the bug be reproduced over and over or only sporadically?

6) What are the exact error messages that you are receiving?

7) Is there any other relevant error information to report?

8) List the steps you took to reproduce the bug. Be specific.

9) If you can’t reproduce the bug 100% of the time, indicate how often you can reproduce it (For instance, 3 of every 10 attempts).

10) State how the bug has affected your expected results. Include any suggestions that you feel could potentially fix the bug.


Example of a good summary:

  • “What: [iPad][iOS 5.1.1] interrupting the application when uploading profile picture crashes the app 3 out of 10 tries.”


Examples of a poor summary:

  • “App not working on my tablet”
  • “App keeps crashing”
Guidelines for Attachments


Remember that every bug report should include at least one attachment. Acceptable attachments include videos, images, screenshots, and logs. Please follow the instructions below when including attachments.




Images and Screenshots

  • Please submit images and screenshots using *.jpeg or *.jpg format
  • Images in other formats (.GIF, .TIFF, .PNG, for instance) should be converted to .JPEG
  • Follow these instructions to convert screenshots and images to .JPEG:


Storage and Proper Use of Attachments


  • Upload videos, images, and screenshots directly to the Tester Work tracker for storage
  • Refer to the Tester’s Instruction documents for additional information on storage
  • Failure to use the required formats for attachments will result in penalties