QA Flow | Step-By-Step

The QA Workflow

1. Initial Review (Development to QA)

Once a developer completes a task in the current sprint, they will move it to the Review column and provide video evidence of their solution.

• SLA: QA must test the task within a 48-hour window from the moment it is moved to Review (excluding weekends).

• Verification Steps:

  1. Review the Acceptance Criteria in the task.

  2. Cross-reference with the Figma design file.

  3. Watch the developer’s video evidence.

  4. Perform manual testing in the application.

2. Documenting Results

• Video Evidence: Record your testing flow using Kommodo. Use audio narration whenever possible to explain the steps.

• Screenshots: Only acceptable for very simple tasks (e.g., a static PDF report or a simple text change).

Scenario A: QA Approved

If the feature meets all requirements:

1. Comment QA Approved (feel free to use colors/formatting).

2. Attach your video evidence.

3. Move the task to the Sprint Completed section for PM evaluation.

Scenario B: QA Failed

If the feature fails or has bugs:

1. Apply the "QA Fail" tag.

2. Add a comment detailing what went wrong.

3. Attach your video evidence.

4. Move the task to the QA Section.

5. Re-assign the developer.

6. The developer has 24 hours to provide a fix and move it back to Review.

---

3. Production Testing (Post-Deployment)

After a sprint is completed and discussed in the Sprint Review, tasks move to Waiting for Deploy.

• Deployment: Devs move tasks from the QA branch to the Production branch (usually on the Monday following the sprint end).

• The Prod Window: You have until Friday of the new sprint to verify all tasks from the previous sprint in the Production environment.

• Approval: Once verified in Production, comment Prod Approved with video evidence and move the task to Completed.

---

Bug Reporting Protocol

The method of reporting a bug depends on the status of the task:

Situation	Action
Task is not yet "Prod Approved"	Post the failure/bug as a comment inside the original task.
Task was already "Prod Approved"	Do not comment on the old task. Create a new Bug Task in the Backlog.

How to create a Bug Task:

1. Title: Bug: [Description of issue]

2. Dependencies: Link the original task so the context is clear.

3. Description Template:

   • Steps to Reproduce: List the specific actions taken.

   • Expected Result: What should have happened.

   • Actual Result: What is actually happening.

   • Evidence: Attach a video recording of the bug.

---

Note: Consistency is key. Keeping our evidence in video format with audio helps developers fix issues faster and keeps our PMs informed.