Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

QA Project Defect / Bug Reporting

This document contains the defect/bug report standards during the development process. In Hungry Hub, we use ClickUp as our project management tool for managing both task-based tickets and defects/bugs.

What should I do if you find a Defect / Bug when testing a project?

  1. Raise it as a ticket in the same ClickUp project.
  2. Assign the ticket to the relevant people.
  3. Follow up once it has been fixed and assigned back to QA.

On which Board should I raise the Defect/Bug?

  1. Create a ticket on the to-dos board for the project being tested.
  2. Once in the to-dos board, create a new list according to which platform the defect/bug was found.
    1. Bugs & Feedback WEBSITE: For defect/bug tickets that occur on the website / Mobile Web.
    2. Bugs & Feedback Mobile Apps: For defect/bug tickets that occur on the apps (iOS / Android).
    3. Bugs & Feedback DASHBOARD: For defect/bug tickets that occur on the Dashboard / Owner Dashboard.

What is the format to report a Defect/Bug****?****

  1. Title. The title should be brief and clearly describe what happened. And must contain the following information:
    1. Type.
      1. Bug: A ticket for an error, flaw, mistake, failure, or fault in the program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.
      2. Suggestion: This is a suggestion from QA that might add quality to a feature function, behavior, and product.
      3. Question: A ticket for the official question to relevant stakeholders for any result in the feature behavior.
      4. Feedback: A feedback ticket from the stakeholders in order to further optimize the feature and better the results.
    2. Platform.
      1. WEB: If the bug occurs on the web.
      2. Mobile Web: If the bug occurs on the mobile web.
      3. iOS: If the bug occurs on iOS.
      4. Android: If the bug occurs on Android.
      5. Dashboard: If the bug occurs on the dashboard.
    3. Severity. It means how badly the bug has impacted the functionality of an application.
      1. Critical: Any issues that might cause the complete shutdown of the feature. Or affect the application in a way that the user cannot proceed to the next task and blocked the functionality of the feature. Such bugs need immediate attention. Example: Apps crash, the feature doesn’t follow the requirement/design.
      2. Major: Any issues that do not collapse the whole feature, none less hamper major parts of it. But causes the system to produce incorrect, incomplete, or inconsistent results. However, certain parts of the system remain functional. Example: Inconsistency behavior between buttons result.
      3. Medium: Any issues that have a noticeable impact on functionality but do not completely block the user from completing a task. Example: Form validation missing on a non-mandatory field.
      4. Minor: Any issues that have a minor impact on the functionality of the application. Example: Display issue, text spill out.
    4. Bug Location. The location where the bug occurs.
    5. A Brief explanation of what happened for the feature, and what is the effect.
  2. Bug title Example:
    • [Bug][Web][Major][Profile] The vouchers that have been purchased are not available in my voucher menu.
    • [BUG][WEB][iOS][Medium][Profile] Expired voucher doesn’t have expired status.
  3. Description. The description of a bug must be clear and concise, containing what happened and the effects of the bug on the application. And must contain the following information:
    1. What is the bug and what is its effect on the application?
    2. What is the expected behavior?
    3. If the bug has specific reproduction steps, the description should also contain the steps to reproduce the bug.
    4. Provide image/video proof for the bug.
      1. If in the form of an image, please mark where the bug occurred.
      2. If in the form of a video, must go straight to where the bug occurs and what the bug is.
    5. Environment / Link (Production, staging, Staging 2)
    6. Platform
      1. Client (Web, iOS, Android, hybrid app, partner app)
      2. Server/Backend (Dashboard, Restaurant admin dashboard, Email, SMS, etc) Bug description example: When the user has an expired voucher, he will notice that in the profile menu, the expired voucher doesn’t have an expired status. The should be an expired status for the expired voucher to indicate to the user that the voucher already expired. Environment: Staging Platform: Web Image proof.