Skip to content

7. QA & Testing
What Accepting a build, analyzing its impact, and running sanity, smoke, and regression testing.
Owner QA (independent team), with Development supplying impact analysis.
Triggers When a complete Build Ticket hands a build to QA.

Summary

QA is an independent function that verifies a build before it can ship. QA only accepts a build when its Build Ticket and impact analysis are complete, because the impact analysis tells QA what changed and therefore what to test. QA then works through a documented test plan in escalating scope: sanity (does the core path even work), smoke (do the main flows work), and regression (does anything previously working now break). Every defect is logged in the tracker against the same JIRA Release.

Full detail

QA acceptance gate

QA accepts a build for testing only when the Build Ticket is complete, including the impact analysis below. QA is accountable for holding this gate: an incomplete handover is sent back, not tested on guesswork.

Impact analysis

The impact analysis is supplied with the build and is required before testing begins. It is captured for both planned changes and for bug fixes.

Impact analysis of the change (not bugs)

  1. Components impacted (select all that apply): Frontend, Backend / API, Database, UI/UX, DevOps/Deployment.
  2. Functional impact: the key functional changes (new, modified, or removed functionality).
  3. Technical impact: the affected modules, classes, functions, database tables, or APIs.

Impact analysis of the bugs

  1. Components impacted (same list as above).
  2. Functional impact.
  3. Technical impact.
  4. Root cause of the issue.

Use the Impact Analysis form.

The three test suites

QA runs testing in escalating scope. The point of the order is to fail fast: do not spend hours on regression if the core path is already broken.

Suite Question it answers Scope
Sanity Does the specific new or changed feature work on its main path? Narrow, focused on what this build changed.
Smoke Do the application's main workflows still work end to end? The critical user journeys.
Regression Does any previously working functionality now break? Broad, across existing functionality, guided by the impact analysis.

The impact analysis directs where regression effort is concentrated: the components and modules it flags are where breakage is most likely.

Test plan and traceability

Testing runs against the test plan that was authored and approved earlier at Test Case Design & ITCR. Each test case is verified and its result recorded, so there is evidence of what was tested and what passed. Defects are logged in the tracker and added to the same JIRA Release the build belongs to, giving a complete picture of what was planned, what was built, what QA found, and what shipped.

QA release go-ahead

When a build passes its test plan with no open defects, QA does not clear it verbally. QA posts a release go-ahead comment on the Build Ticket that:

  • Tags the developer or DevOps responsible for releasing the build, the Support or customer representative, and Management.
  • States what was tested: the areas and features covered.
  • Links the executed JIRA test plan (the one approved at Test Case Design & ITCR).
  • Gives the explicit go-ahead to proceed to release.

This single comment is the audited authorization that allows Tagging & Deployment; nothing is tagged or deployed without it. Use the QA release go-ahead comment template.

flowchart TD
    A[Build Ticket received] --> B{Build Ticket + impact analysis complete?}
    B -->|no| C[Reject, send back to dev]
    B -->|yes| D[Accept build]
    D --> E[Sanity: does the changed feature work?]
    E -->|fail| F[Log defect, return to dev]
    E -->|pass| G[Smoke: do main flows work?]
    G -->|fail| F
    G -->|pass| H[Regression: anything broken?]
    H -->|defects| F
    H -->|clean| I[Record test plan results]
    F --> J[Defect Handling]
    I --> K[Post QA release go-ahead on Build Ticket]

Example

QA receives Build Ticket BUILD-58 for v1.4.0. The impact analysis flags Backend/API and Database as impacted, with the orders module and the orders table affected by the CSV export work. QA runs sanity on the export feature itself, smoke on the core order and checkout flows, then concentrates regression on the orders module and anything touching the orders table. Two defects are found, logged against JIRA Release v1.4.0, and sent back. After re-test they pass; QA posts the release go-ahead comment on BUILD-58, tagging the releasing developer, Support, and Management, and linking the executed test plan TEST-58.