Skip to content

8. Defect Handling
What Fixing defects QA finds during testing, on the frozen release branch, until the build is clean.
Owner Engineering (fixes), QA (re-tests and confirms).
Triggers When QA logs a defect against a build under test.

Summary

When QA finds a defect during testing, the fix does not go on a new release line or a fresh branch off develop. It goes on a bug/<ticket> branch cut from the same frozen release branch that is under test, then merges back through a reviewed pull request. QA re-tests the fix. This loop repeats until the build is clean, at which point QA posts the release go-ahead comment on the Build Ticket. Every defect is logged against the same JIRA Release as the build.

Full detail

The fix loop

  1. QA logs the defect in the tracker against the same JIRA Release as the build.
  2. The assigned developer cuts a bug/<ticket> branch from the frozen release branch (for example release/v1.4.0 becomes bug/ABC-1325).
  3. The developer fixes the issue, adds or updates tests, and opens a pull request back into the release branch.
  4. The fix goes through normal code review and the static analysis gate.
  5. Once merged, a new build is produced and the Build Ticket is updated (or a new one created) so QA knows exactly what changed.
  6. QA re-tests: the specific fix, plus regression around the affected area per the updated impact analysis.
  7. Repeat until the build is clean.

Why fixes stay on the release branch

Branching the fix from the frozen release branch keeps the release self-contained: everything that ships in this version, including its QA fixes, is in one place and one JIRA Release. Cutting fixes from develop instead would pull in unrelated in-progress work and break the guarantee that the tag reflects exactly what was tested.

%%{init: {'gitGraph': {'mainBranchName': 'release/v1.4.0'}}}%%
gitGraph
    commit id: "frozen release"
    branch bug/ABC-1325
    commit id: "fix defect"
    commit id: "add test"
    checkout release/v1.4.0
    merge bug/ABC-1325 tag: "PR + re-test"

Bug impact analysis is required

Each defect fix carries its own bug impact analysis: components impacted, functional impact, technical impact, and root cause. The root cause matters beyond this fix: it feeds Escaped Defects Analysis if a similar issue later escapes to production, and it can reveal missing logging or test coverage to close.

Exit condition

The loop ends when QA confirms the build passes its test plan with no open defects. QA then posts the explicit release go-ahead comment on the Build Ticket, which allows the release to move to Tagging & Deployment. Without that go-ahead, nothing is tagged.

Example

Testing v1.4.0, QA logs ABC-1325: the CSV export drops the last row for accounts with exactly one order. The developer cuts bug/ABC-1325 from release/v1.4.0, fixes the off-by-one, adds a test for the single-order case, and opens a PR back into the release branch. After review and a fresh build, QA re-tests the export and runs regression on the orders area. It passes. With no other open defects, QA posts the release go-ahead on the Build Ticket.