Version 1.1

Status Active

Owner Head of Engineering

Last Updated 2026-06-23

SOP: QA Process

1. Purpose

The purpose of this SOP is to define how engineering work is verified before it is considered complete, accepted, or ready for production promotion.

This SOP explains when work enters QA, what information must be provided, how QA verifies work, how QA results are documented, and how tickets move after QA approval or failure.

The goal is to ensure that QA verification is:

clear,
repeatable,
traceable to a specific version,
documented in the related ticket,
and connected to the Ticket Management, Pull Request, Git Flow, and Deployment processes.

2. Scope

This SOP applies to all engineering work that requires verification before it can be considered complete.

It applies to:

Frontend frontend features, fixes, and user-facing changes,
Backend backend features, fixes, API changes, and service behavior,
DevOps deployment, environment, CI/CD, and infrastructure changes when verification is required,
QA manual QA, regression checks, and verification activities,
Engineering cross-team changes that need validation before completion.

This SOP does not replace the Ticket Management SOP, Pull Request SOP, Git Flow SOP, or Deployment SOP. It defines how QA verification works inside the overall engineering workflow.

3. Core Rule

Mandatory User Stories and Issues must be verified by QA before they are moved to their final status.

A User Story may be moved to Done only after QA confirms that the acceptance criteria are met.

An Issue may be moved to Closed only after QA confirms that the issue is fixed or otherwise resolved, unless the Issue is closed as Not a Bug.

Formal QA verification should happen on the staging environment using a clearly identified version, commit SHA, build, deployment ID, or future release tag.

4. Rule Strictness

Level	Meaning
Mandatory	Must be followed unless there is an approved and documented exception.
Default	Should normally be followed, but exceptions are allowed when justified.
Recommended	Encouraged, but not strictly required in every case.

5. Definitions

Term	Meaning
QA	The process of verifying that a change behaves as expected and meets the agreed criteria.
Formal QA Verification	QA verification performed on staging using a specific version or commit SHA.
Informal Verification	Early checks performed on a PR preview, development environment, or local environment before formal QA.
Ready for Test	A ticket status indicating that the work is ready for QA verification.
QA Handoff Notes	Information provided by the PR author or ticket owner so QA can understand what changed and how to test it.
Testable Version	The specific commit SHA, build, deployment ID, or tag that QA should verify.
Staging Environment	The environment used for formal QA verification and production readiness validation.
PR Preview	A temporary or PR-specific frontend preview environment used for early review or informal validation.
Development Environment	The environment automatically deployed from the `development` branch after PR merge.
Acceptance Criteria	Conditions that must be met before a User Story or Issue can be considered complete.
QA Result	The documented outcome of QA verification, such as Passed, Failed, or Needs Info.

6. Roles and Responsibilities

Role	Responsibilities
PR Author	Completes the implementation, ensures the PR is merged, provides QA handoff notes, provides the testable version or merge commit SHA, and moves the related ticket to `Ready for Test`.
Ticket Owner	Keeps the ticket updated, ensures the ticket has enough information for QA, communicates blockers, and coordinates with QA when clarification is needed.
QA	Reviews QA handoff notes, deploys or requests deployment of the selected version to staging when applicable, verifies the change, documents the QA result, and moves the ticket to the correct status.
Developer	Supports QA when clarification, fixes, reproduction help, logs, or technical explanation are needed.
DevOps	Supports staging deployment, environment issues, pipeline failures, and deployment troubleshooting when required.
Responsible Individual / Team	May verify work, deploy selected versions, or approve QA/deployment actions when QA is not the only responsible party.
Head of Engineering	Owns the QA process, resolves escalations, approves exceptions, and decides release-blocking questions when needed.

7. What Requires QA

7.1 User Stories

Mandatory User Stories require QA verification before they are moved to Done.

QA verifies User Stories against their acceptance criteria and any relevant product, design, API, or business requirements.

7.2 Issues

Mandatory Issues require QA verification before they are moved to Closed when a fix or change was made.

QA verifies that the issue no longer reproduces and that the fix does not create obvious related regressions.

Issues may be moved to Not a Bug without normal QA verification when the behavior is expected, invalid, duplicate, out of scope, or not reproducible after reasonable investigation.

7.3 Tasks

Default Tasks do not require individual QA verification by default.

Tasks are usually verified indirectly through their parent User Story.

A Task may require QA verification when it is independently testable, risky, user-facing, not attached to a larger User Story, or explicitly marked for QA.

7.4 Epics

Mandatory Epics are not directly QA tested.

Epics are completed based on the completion of their required child User Stories, Tasks, and related Issues.

8. QA Environments

8.1 Formal QA environment

Mandatory Formal QA verification should happen on the staging environment.

QA should verify a specific selected version on staging, identified by a commit SHA, build, deployment ID, or future release tag.

Since release tags are not currently used, the merge commit SHA should be used as the primary version reference.

8.2 Development environment

Recommended The development environment may be used for early checks, investigation, debugging, or informal validation.

The development environment is automatically deployed after changes are merged into development.

Development environment checks do not replace formal QA verification on staging unless an exception is approved.

8.3 PR previews

Recommended Frontend PR previews may be used for early review, early feedback, visual inspection, and informal validation.

PR previews are especially useful before a PR is merged.

PR previews do not replace formal QA verification on staging unless an exception is approved.

8.4 Backend previews

Default Backend preview environments are not required by this SOP.

Backend work should be verified through CI checks, development deployment, and formal staging verification. Backend preview environments may be introduced later if needed.

9. QA Entry Criteria

Mandatory A ticket may move to Ready for Test only when it is testable.

A ticket is testable when:

the related PR is merged,
the change exists in development,
the automatic development deployment completed successfully or a testable version is otherwise available,
the merge commit SHA or testable version is provided,
QA handoff notes are provided,
acceptance criteria or expected behavior are clear,
known limitations are documented,
and the ticket owner is clear.

If these conditions are not met, QA may return the ticket to Needs Info.

10. QA Handoff Notes

Default The PR author or ticket owner must provide QA handoff notes before requesting QA verification.

QA handoff notes should be added directly to the related ticket.

10.1 Required QA handoff information

QA handoff notes should include:

related PR,
merge commit SHA or testable version,
summary of what changed,
how to test the change,
expected result,
test user, account, role, or permissions when needed,
known limitations,
risk areas,
and any relevant screenshots, logs, API examples, or configuration notes.

10.2 QA handoff template

## QA Handoff

Related PR:
Merge commit SHA / testable version:

What changed:

How to test:

Expected result:

Test user / account / role:

Known limitations:

Risk areas:

Additional notes:

11. Staging Deployment for QA

11.1 Selecting the version to test

Mandatory QA should verify the version identified in the QA handoff notes.

QA may select the provided merge commit SHA or another appropriate version from development when a different version is required for verification.

If QA tests a version different from the one provided in the handoff notes, the tested version must be documented in the QA result.

11.2 Deploying to staging

Default QA or a responsible individual/team may manually trigger the staging deployment pipeline using the selected version.

The staging deployment pipeline may require approval from the responsible reviewer, team, or individual before deployment starts.

If the staging deployment cannot be completed because information is missing, approval is missing, or the pipeline fails, QA should document the reason in the ticket.

11.3 Staging deployment traceability

Default The tested staging version should be documented in the QA result.

The Deployment SOP defines the full deployment documentation process. For QA purposes, the minimum required traceability is the tested version or commit SHA.

12. QA Verification

12.1 What QA should verify

QA should verify:

acceptance criteria,
expected behavior,
main happy path,
important edge cases,
error handling,
related regressions,
UI behavior when applicable,
API behavior when applicable,
permissions and roles when applicable,
and any risk areas documented by the PR author or ticket owner.

12.2 QA depth

Default QA depth should be proportional to the risk and impact of the change.

Small, low-risk changes may require focused verification. Large, risky, user-facing, security-sensitive, or business-critical changes may require broader regression testing.

12.3 QA may reject unclear tickets

Mandatory QA may return a ticket to Needs Info if the ticket is not testable.

A ticket may be considered not testable when:

acceptance criteria are missing or unclear,
expected behavior is unclear,
QA handoff notes are missing,
merge commit SHA or testable version is missing,
test account or permissions are missing,
the change is not available for staging deployment,
the staging deployment fails,
or required clarification is missing.

13. QA Results

Mandatory QA results must be documented in the related ticket.

QA should use one of the following results:

Passed — QA verified the work and no blocking issue was found.
Failed — QA found a problem that requires developer follow-up.
Needs Info — QA cannot verify because information, access, version, environment, or clarification is missing.

13.1 QA result template

## QA Result

Result: Passed / Failed / Needs Info
Environment: Staging
Tested version / SHA:
Tested by:
Date:

What was tested:

Result summary:

Issues found:

Evidence:

Additional notes:

13.2 Failure details template

## Failure Details

Steps to reproduce:

Expected result:

Actual result:

Environment:
Tested version / SHA:

Screenshots / logs:

Severity:

Notes:

14. Ticket Status Updates After QA

14.1 User Story passes QA

Mandatory If a User Story passes QA, QA or the ticket owner may move the ticket to Done.

The ticket must include the QA result before it is moved to Done.

14.2 Issue passes QA

Mandatory If an Issue passes QA, QA or the ticket owner may move the ticket to Closed.

The ticket must include the QA result before it is moved to Closed.

14.3 QA fails

Mandatory If QA fails, the ticket should be moved to Reopened.

QA must document what failed, how to reproduce it, the expected result, the actual result, the tested version, and any useful evidence.

The PR author, ticket owner, or responsible developer is responsible for follow-up.

14.4 QA needs more information

Mandatory If QA cannot verify the ticket, the ticket should be moved to Needs Info.

QA must add a comment explaining what is missing.

The ticket owner is responsible for providing the missing information and moving the ticket back to Ready for Test when it is testable again.

15. Failure Handling

15.1 Same-ticket failure

Default If QA finds a problem directly related to the ticket scope, the same ticket should normally be moved to Reopened.

The developer should fix the issue, open or update the related PR, and return the ticket to Ready for Test when the fix is ready.

15.2 New unrelated issue

Default If QA finds an unrelated issue, a new Issue should be created instead of blocking the original ticket unnecessarily.

The original ticket may still pass QA if its acceptance criteria are met and the unrelated issue is not blocking.

15.3 Release-blocking disagreement

Default QA can mark a ticket as failed or not acceptable for release.

If there is disagreement about whether a QA finding blocks release, the decision should be escalated to the Head of Engineering, responsible owner, or responsible team.

The final decision should be documented in the ticket.

16. QA Timing Expectations

16.1 First QA action

Default QA should aim to start verification within one business day after a ticket is moved to Ready for Test.

First QA action may include:

starting verification,
deploying or requesting deployment to staging,
asking for missing information,
or commenting with a reason why verification cannot start yet.

16.2 QA result or blocking reason

Default QA should aim to pass, fail, or document a blocking reason within two business days when possible.

If QA cannot complete verification within two business days, the ticket should include a comment explaining why.

Valid reasons may include missing information, staging deployment issues, unclear requirements, environment problems, higher-priority work, or waiting for another person or team.

17. Production Verification

Recommended QA may perform production smoke checks after deployment when requested.

Production smoke checks may include verifying that the application loads, critical flows work, and no obvious production issue is visible after deployment.

The Deployment SOP defines the full production deployment and post-deployment verification process.

18. Procedure

18.1 Moving work to Ready for Test

Confirm the related PR is merged.
Confirm the change exists in development.
Confirm the automatic development deployment succeeded or a testable version is available.
Add QA handoff notes to the ticket.
Add the merge commit SHA or testable version.
Confirm acceptance criteria or expected behavior are clear.
Move the ticket to Ready for Test.

18.2 Preparing staging for QA

Review the QA handoff notes.
Confirm the version or SHA to be tested.
Trigger the staging deployment pipeline when needed.
Wait for required deployment approval when applicable.
Confirm staging deployment completed successfully.
Document the tested version in the QA result.

18.3 Performing QA verification

Review the ticket description and acceptance criteria.
Review QA handoff notes.
Verify the expected behavior on staging.
Check relevant edge cases and risk areas.
Record evidence when useful.
Document the QA result in the ticket.

18.4 Passing QA

Document the QA result as Passed.
Include the tested environment and version/SHA.
Move User Stories to Done.
Move Issues to Closed.
Notify the ticket owner or responsible team when needed.

18.5 Failing QA

Document the QA result as Failed.
Add reproduction steps, expected result, actual result, and evidence.
Include the tested environment and version/SHA.
Move the ticket to Reopened.
Notify the ticket owner or responsible developer when needed.

18.6 Returning a ticket for more information

Document the QA result as Needs Info.
Explain what information, access, environment, version, or clarification is missing.
Move the ticket to Needs Info.
Wait for the ticket owner to update the ticket.

19. Exceptions

19.1 Urgent production incidents

Urgent production incidents may require accelerated verification.

In this case, QA may perform focused verification instead of full standard verification.

Any skipped QA steps, accepted risks, and follow-up actions must be documented.

19.2 QA outside staging

Formal QA should happen on staging by default.

QA may verify outside staging only when there is an approved reason, such as an urgent incident, staging outage, environment limitation, or explicitly approved exception.

The environment and reason must be documented in the QA result.

19.3 Missing QA capacity

If QA capacity is limited, the Head of Engineering or responsible owner may prioritize which tickets should be tested first.

Lower-risk tickets may be postponed, grouped, or verified by another responsible individual when approved.

20. Definition of Done

QA verification is complete when:

the ticket was verified on staging or an approved alternative environment,
the tested version or SHA is documented,
the QA result is documented in the ticket,
failures include reproduction steps and evidence when applicable,
missing information is clearly requested when applicable,
the ticket status is updated correctly,
and any release-blocking decision is documented when needed.

21. Short Checklist

21.1 Before moving to Ready for Test

Related PR is merged.
Change exists in development.
Merge commit SHA or testable version is provided.
QA handoff notes are provided.
Acceptance criteria or expected behavior are clear.
Known limitations are documented.
Ticket owner is clear.

21.2 Before starting QA

Ticket is in Ready for Test.
QA handoff notes are understandable.
Testable version or SHA is clear.
Staging deployment can be performed or has already been performed.
Required test account, role, or permissions are available.

21.3 Before passing QA

Acceptance criteria are met.
Expected behavior is verified.
Important risk areas are checked.
No blocking issue remains.
Tested version or SHA is documented.
QA result is added to the ticket.

21.4 Before failing QA

Failure is reproducible or clearly described.
Expected result is documented.
Actual result is documented.
Tested version or SHA is documented.
Evidence is attached when useful.
Ticket is moved to Reopened.

21.5 Before returning as Needs Info

Missing information is clearly documented.
Missing access, version, or environment issue is explained.
Ticket owner is notified when needed.
Ticket is moved to Needs Info.

22. Workflow Diagram

22.1 Standard QA workflow

flowchart TD
  A[PR Merged into development] --> B[Automatic Development Deployment]
  B --> C[Author Adds QA Handoff Notes]
  C --> D[Author Provides Merge Commit SHA]
  D --> E[Move Ticket to Ready for Test]
  E --> F[QA Reviews Ticket]
  F --> G{Enough Info to Test?}
  G -- No --> H[Move Ticket to Needs Info]
  H --> I[Owner Adds Missing Info]
  I --> E
  G -- Yes --> J[QA Selects Version or SHA]
  J --> K[Trigger Staging Deployment]
  K --> L{Deployment Approved and Successful?}
  L -- No --> M[Document Reason]
  M --> H
  L -- Yes --> N[QA Tests on Staging]
  N --> O{QA Result}
  O -- Passed --> P[Document Passed Result]
  P --> Q{Ticket Type}
  Q -- User Story --> R[Move to Done]
  Q -- Issue --> S[Move to Closed]
  Q -- Task with QA --> T[Move to Done]
  O -- Failed --> U[Document Failure Details]
  U --> V[Move Ticket to Reopened]
  O -- Needs Info --> H

22.2 QA failure flow

flowchart TD
  A[QA Finds Problem] --> B{Related to Ticket Scope?}
  B -- Yes --> C[Document Failure Details]
  C --> D[Move Ticket to Reopened]
  D --> E[Developer Fixes Issue]
  E --> F[PR Review and Merge]
  F --> G[Update QA Handoff and SHA]
  G --> H[Move Back to Ready for Test]
  B -- No --> I[Create New Issue]
  I --> J{Original Ticket Still Acceptable?}
  J -- Yes --> K[Original Ticket May Pass QA]
  J -- No --> L[Escalate Blocking Decision]
  L --> M[Head of Engineering or Responsible Owner Decides]

23. Version History

Version	Date	Author	Changes
0.1	2026-06-15	Head of Engineering	Initial draft.
1.0	2026-06-22	Head of Engineering	Active.
1.1	2026-06-23	Head of Engineering	Aligned failed QA ticket transitions with Reopened status.