Tests grounded in the product. Releases gated by people.

The test design agent follows an explicit anti-flake policy, and the QA lead checks it during approval. A test that flakes twice within 30 days is quarantined: it cannot block a release or file a bug until it has been rewritten and approved again.

• Use dedicated test IDs, never screen position, styling or generated class names.
• Wait for a specific UI or API condition, never a fixed delay.
• Give each test independent data setup and cleanup; avoid run-order dependencies.
• Use fixed, known data without relying on the current date, time zone, random values or live third-party services.
• Give each test one clear goal so a failure points to a cause.

Before each run, the execution flow checks QA environment health. An unhealthy environment pauses testing and is reported as an environment issue. Failed tests are retried once before triage separates product defects from test and environment problems.

Confirmed bugs require steps to reproduce, expected versus actual results, screenshots or video, logs and severity. Jira rejects agent-filed bugs missing any of that evidence. A developer fix references the bug ID and triggers every test case for the story again.

• Health check before execution.
• One retry, then triage.
• Complete evidence before a Jira bug.
• Full-story retesting after each fix.

Developers can dispute an agent-filed bug with a valid written reason. The QA lead rules; stakeholders see the dispute and its outcome. If accepted, the bug closes, the test cases are corrected and the story returns to In QA. If the bug stands, the developer fixes it.

Every accepted dispute becomes a correction to the test cases so the same false report does not recur. The monthly review tracks overruled agent bugs as a measure of report accuracy.

The manual tester receives a build that has passed automated testing and decides the UAT outcome. A UAT failure caused by a missing test adds that case to the suite.

Flagged items go to the Jira backlog linked to the original story. The tester may still approve the release with that item noted; this remains a human decision.

Sanity runs first after deployment, checking critical paths in the first minutes. Full regression follows and incorporates the story’s approved tests. Both run inside a dedicated production test brand with test data isolated from customer data, billing and analytics.

A sanity failure immediately notifies stakeholders. The agent gathers evidence; a QA engineer decides whether it is a real product issue, a test problem or an environment problem. Rollback never happens automatically, and the tech lead and developer are notified so they can respond if the decision requires a rollback or hotfix.

• Critical-path sanity before full regression.
• Test data isolated from customer activity.
• Human decision on every sanity failure.

Only P0 and P1 Jira tickets enter the hotfix process. Testing targets the fix and approvals are fast-tracked, while every gate still applies. The proposal specifies an eight-step hotfix flow with three human decisions.

A QA engineer and tech lead are named on call each week. The back-merge at step 7 is mandatory: the ticket cannot close before it is complete. Every hotfix is reviewed monthly to understand why the issue reached production.

• P0 / P1 only; other changes use the standard eight stages.
• Targeted tests and fast-tracked human approvals.
• Mandatory back-merge before closure.
• Every hotfix enters the monthly quality review.

QA and UAT share an environment, so overlapping PRs are deployed there one at a time. The QA lead sets the order when parallel PRs have equal priority. Every new PR commit is retested, and Bitbucket resets approvals when the PR changes after approval.

A changed PRD notifies stakeholders and sends test cases through update and reapproval. An agent or pipeline outage notifies the team for DevOps to restore service. The proposal describes a 12-state Jira lifecycle: the orchestrator tracks transitions, while people retain test approvals, UAT decisions, release, dispute rulings and sanity decisions.

The Jira issue and team chat channel carry notifications to the responsible people. Stakeholders include the developer, QA lead, manual tester, tech lead and product owner.

• Test approval waiting → QA lead approves or rejects with comments.
• Evidence-backed bug → developer fixes or disputes; QA lead is notified.
• Dispute and ruling → stakeholders follow the QA lead’s decision.
• UAT failure → developer, QA lead and tech lead follow the tester’s chosen response.
• Sanity failure or hotfix → stakeholders are notified immediately; the named decision owners respond.
• Pipeline outage → stakeholders are notified and DevOps restores service.
• Equal-priority PRs → QA lead and both developers resolve test order.
• PRD change → stakeholders update and reapprove tests.
• Completion → stakeholders receive the attached release report.