Defect Ticket Guidelines

General

Consistency

• When applicable, always use the terminology from the design website to describe locations and features.
• If a recurring feature/location is not labeled in the design website, use the same term to refer to it across all relevant tickets per the discretion of the primary QAE assigned to the project.
• When referring to abbreviated concepts (most often environments), abbreviate them consistently.
  • Example: Don’t alternate between writing “IE 10,” “IE10,” and “Internet Explorer 10.” Pick one and stick with it.

Neutrality

• Do not communicate anger, impatience, or frustration in any ticket details or comments.
• Use tickets to relay relevant facts and data, with no additional or unnecessary commentary.
• Be respectful, helpful, and supportive.
• Don’t be a jerk.

Diligence

• Be proactive. Don’t wait for developers to request more information. If you’re debating whether a screenshot or crashlog is necessary, just add it right away.
• If you don’t know whether or not a specific step is really necessary to reproduce the issue, test it out and find out before submitting the ticket.
• Always check your work. Once your ticket is completed, run through the steps as written to make sure the issue happens.
• Proofread your tickets. Typos and spelling errors look sloppy and increase the risk of miscommunication. Pretend you’re someone else, and read what you wrote.

Introspective

• Always review tickets, looking for ways to improve your writing.
• Constantly view your writing from different perspectives and attempt to discover potential for miscommunication.
• Whenever developers need to request more information, always assume the ticket is incorrect or unclear and look for ways to improve it before assuming the developer didn’t read the ticket or didn’t follow the directions.
• Whenever a ticket fails a retest, always look for potential areas in which the ticket miscommunicated the issue before assuming developer fault.
  • Never fail a ticket during retest without modifying the ticket to include some additional information.

Inclusive

• If requirement documentation is unclear on whether or not a specific behavior is intentional or defect, always write a ticket to be safe. It’s easier to close an invalid ticket than it is to explain why something wasn’t reported that turned out to be a big problem.
• Exception: Do not write “bugs-of-bugs.”
  • Example: If triggering a reported defect is a prerequisite to causing another issue to occur, add that information as a comment in the original issue. While it’s important to note bug-of-bugs to fully detail the severity of the original issue, it can be assumed that elimination of the requisite issue will make it impossible to reproduce the bug-of-a-bug.

Ticket Fields

Details

• Summary: A short unique statement used to identify the issue at a quick glance.

  • Shouldn’t exceed a single line of text, if possible.
  • Should include environments if the issue is not global.
  • Should include the location of the issue, using consistent terminology for each broad location of the app/site.
  • Should include a high level description of the issue trigger.
  • Should include a high level description of the issue effect.
  • Example: “Android > Add Payment: If the user selects to add a new Discover Card, the app crashes.”

• Issue Description: A lengthier description of all relevant ticket information, organized into a single sentence.

  • Should be formatted roughly as “In this environment, at this location, at this sub-location, when the user performs this action, this issue occurs.”
  • Should include environments if the issue is not global.
  • Should include the location and any relevant sublocations of the issue, using consistent terminology for each location of the app/site.
  • Should include any prerequisites for the issue.
  • Should include a full description of all actions that are required to reproduce the issue.
  • Should include a complete description of the issue effect.
  • If additional issues occur only after the reported issue has been triggered, these can be briefly described in a follow-up sentence to the description.
    • Example: “.... after selecting Add Payment, the user is logged out of the app and is returned to the Login screen. After this issue occurs, the user is unable to log back into the app until closing and re-opening it.”
  • Example: “When logged into the Android app as a user, on the Payment > Add Payment screen, if the user selects Mastercard, the app crashes.”
  • Example: “When logged into the Android app as a user, on the Payment screen, if the user selects Add Payment, then selects Mastercard, the app crashes.”

• Expected Results: A description of what should happen in place of the defective behavior when the trigger occurs.

  • Should be written as a description of the expected behavior as if it is currently happening.
  • Avoid words like “must” or “should.”
  • If multiple approaches can be taken to meet the requirement, it is acceptable to separate multiple expected results statements with “OR.”
  • Only in extreme circumstances, if the project documentation doesn’t describe some behavior that would be inappropriate for the QA Engineer to make an assumption on, it is acceptable to describe what should not happen (“App should not crash”).
    • If this ever occurs, always write a comment, flagging the Product Owner, drawing attention to the lack of requirements.
  • Example: “The user progresses to the payment details screen, and is able to add a new Mastercard.”

• URL: A quick link to the page in which the issue occurs on.

  • Not applicable for mobile app tickets.
  • If the end URL is dynamic and doesn’t lead back to the exact page when followed in a different web session, it’s still helpful to include it, as it may provide useful clues for the developers.

• Prerequisites: A description of any common and recurring conditions that must be met for the steps to reproduce to work.

  • Example: “The user is logged into Facebook.”
  • Example: “The user is logged into the site as an administrator.”
  • Example: “An Event with a latitude and longitude has been created.”

• Steps to Reproduce: A numbered list of specific steps required to reproduce this issue.

  • Steps can assume the condition set in the Prerequisite field has been met.
  • The first step should always contain a static/stable starting location.
    • Example: “1. Launch the iOS app.”
    • Example: “1. From the User Dashboard, select the Menu icon.”
  • The final step should always be an instruction to observe the issue occurring, including a description of the defective behavior.
    • Example: “Observe, the app crashes.”
    • Example: “Observe, the user is logged out of the app and returned to the Login screen.”
  • Steps should start from an obvious location, and be written clearly enough to guide a user with no prior project experience to the issue.

• Priority: Indicates the importance of the issue, based on the following definitions.

  • Blocker: This issue prevents further testing and/or development.
  • Critical: The defect affects critical functionality or critical data. It does not have a workaround. Many users unable to work, critical functions cannot be performed. The defect prevents or has the potential to prevent the system or application from meeting the majority of the client requirements.
    • Example: Unsuccessful installation, complete failure of a key feature.
  • Major: The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Some users are unable to work/use the system. The defect prevents or has the potential to prevent a major function of the system or application from meeting the requirements and there is no effective work around to meet these requirements. All functional issues for Major defects must negatively affect or prevent a user from performing an expected action with the product.
    • Example: A feature is not functional from one module but the task is doable if 10 complicated indirect steps are followed in another module/s.
  • Minor: The defect affects minor functionality or non-critical data. It has an easy workaround. User is impacted, but work continues in an impaired manner.
    • Example: A minor feature that is not functional in one module but the same task is easily doable from another module.
  • Trivial: The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience. The issue consists of "how to" questions including issues related to inquiries, enhancement requests, or documentation.
    • Example: Petty layout discrepancies, spelling/grammatical errors.

• Environment: A list of all supported environments that the issue is known to occur on.

  • If the issue is not environment-specific, it is OK to write “Global.”
  • Should be written in the format of “OS - Device - Browser.”
  • Device can be skipped for desktop browsers.
  • Desktop environment should contain the browser’s version number.
  • Example: “iOS 8.1.2 - iPhone 6 - Mobile Safari”
  • Example: “Android 4.4.2 - Nexus 7 - Chrome”
  • Example: “Mac OS X 10.10.2 - Chrome 42.0.2311.90
  • Recommendation: Keep a master list of Vokal devices and current browser versions for quick copying and pasting.

• Frequency: A drop-down menu containing options to indicate how often the issue occurs when the steps to reproduce are followed.

  • This field is mostly intended for clients who may not be willing or able to research issues adequately enough to provide concrete issue triggers. In almost all cases, Vokal QAEs should submit tickets with enough research to be able to set the Frequency to “Always (100%).”

• Discovered in Build: If available, the number of the build the tester was using when the issue was discovered.

  • This field should be used in most iOS and Android app bugs.

• Attachments: Any additional files that can help clarify the issue.

  • Example: Screenshot displaying the issue.
  • Example: Screenshot comparison showing both the site and the design documentation, highlighting differences.
  • Example: Crash logs.
  • Example: Files used that cause the issue to occur (like specific images that cause an image uploader to fail).

Triage

• Assignee: The issue should always be assigned to the person who must take the next action on the ticket.

  • When writing new tickets, they should be assigned to the Product Owner for prioritization.

• Fix Version/s: This field should be set to the release version of the app that the issue will be resolved in. This will often be set by the Product Owner.

  • When a version of the app is completed, there should be no open tickets associated with that Fix Version/s. If there are any, work with the Product Owner to get them addressed or reprioritized to a future release.

• Epic Link: This field should be set to the most relevant Epic on the project.

  • Epics are set up by the product team, and can be viewed on the projects Agile board.

• Sprint: This field should be set to the sprint of the app that the issue will be resolved in. This will be set by the Product Owner.

  • When a sprint is completed, there should be no open tickets associated with that sprint. If there are any, work with the Product Owner to get them addressed or reprioritized to a future sprint.

• Story Points: An estimate of how many hours it will take the developer to resolve the issue.

  • This will be determined by the developer.

• Component/s: This field should be set to the development team that will need to make modifications to address the issue.

  • Sometimes the QA team will be unable to tell where the code change is needed. If that is the case, the component should be set to the relevant client-side component (Android, iOS).
    • Example: Android.
    • Example: Design.
    • Example: Systems.

• Labels: Any additional tags that can be used to group similar issues together.

  • Unlike components, labels are not set on a per-project basis, and are only limited by your imagination.

• Linked Issues: A place to link tickets to user stories, tasks, tests, and other defect tickets.

  • Issue links are typically created to connect duplicate issues, issues that are blocked by other defects, or issues that share a root cause.

• Fixed in Build: If available, the number of the build that contains the fix for the issue.

  • When this field is used, it will be set by the developer.