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

Escalation Ticket QA Procedure

Escalation Ticket QA Procedure

This page contains the escalation ticket from the customer procedure.

  • Every escalation issue will be shared to slack in the #bugreport channel.
  • All tickets from the escalation issue will be added to the Defect Master List.

Flow:

Description:

1. The product team.

The product should also share the priority of the issue (how urgent is the issue should be checked/fixed by the team from the product perspective) Priority list and the target to fix the issue:

  •   *   **P1: Critical**Definition: Critical, application crash, loss of data, and major loss of function preventing users from making a purchase across the platforms or affecting the majority of the users.
    • ETA:
      • Must be checked by QA right away.
      • Must be fixed by PRG on the same day.
  •   *   **P2: Major**Definition: Major loss of function in regard to making a purchase.
    • ETA:
      • Must be checked by QA right away.
      • Must be fixed by PRG within the next day.
  •   *   **P3: Minor**Definition: Minor loss of function that does not prevent users from making a purchase.
    • ETA:
      • Must be checked by QA in 24 hours.
      • Must be fixed by PRG within the next sprint (depending on the effort involved and the work PRGs currently working on).
  •   *   **P4: Suggestion**Definition: New suggestion/hardware problem.
  *   Feature suggestion: Assign to PM and they will evaluate, if worth the effort then move to Product Backlog and proceed to create PRD.
  *   Suggestion related to hardware/server/system: assign to EM and evaluates and proceed accordingly.

2. QA Team.

After the issue has been raised by the Product team, QA should start the test according to the priority and inform the product team when the issue will be checked. The priority:

  • P1 and P2: Must be checked and reported as tickets right away
  • P3 and P4: Should be checked and reported as tickets no longer than 24 hours. (tips: can be checked before the end of the day or before the next day starts) If the issue still can’t be checked due to QA capacity, the issue request should be added to the QA backlog. What should QA do?
  1. QA should check/replicate the issue on the staging first, and if it cannot reproduce on staging, it should be checked on Prod.
  2. After QA checked the issue, QA should report the issue to the clickup.
    1. QA should follow the ticket standard.
      1. Title:
        1. Bug ID should follow the format Priority | Platform | Year | Month | #
        2. Example: P2IU2112001, which means P2 (priority), iOS for users (platform), 2021 (year) December (month), and Ticket number 1
        3. After the ID, the title can be following the QA ticket standard.
      2. Description:
        1. Issue link, the link can be copied from slack in the #bugreport channel.
        2. Add detailed issues from slack.
        3. Add the QA result, the template can be following the QA ticket standard.
    2. Inform the PRG and let the PRG set the ETA to fix the issue.
  3. Once the issue is already fixed by PRG, QA should follow up on the issue accordingly.
    1. If the issue doesn't fix yet, please inform the PRG and add the proving image/video to the ticket.
    2. When the issue is fixed, please close the ticket and approve the PR.

3. Programmer team.

After the PRG assigned the ticket, PRG should fix the ticket according to the priority of the product team.

  1. Add the estimation the ticket will be fixed in the ticket clickup. Please also consider the QA testing time so don't give an estimate that's too tight with the target. And if your estimation is longer than expected, please inform to the team.
  2. Use the standard follow-up ticket report.
  3. Please also inform the PR link to QA.