# QA testing brief and evidence record

Use this editable brief to agree what a testing engagement or release review must establish. Replace the bracketed fields. The filled rows describe a fictional order portal; they are proposed requirements, not findings from a customer system or a completed user study.

Project / release: [name and revision]

Business and engineering decision owners: [roles / names]

Testing owner and reviewers: [roles / names]

## 1. Identify the change and what could go wrong

- Changed behavior and affected users: [specific workflow / roles]
- Existing behavior that must remain valid: [agreed baseline and requirement reference]
- Connected components: [API / database / browser / jobs / external systems]
- Serious consequences to check first: [data exposure / lost work / unusable task / other concrete impact]
- Supported environments and actual dependencies: [browsers / devices / runtime / database / providers]
- Known defects or unresolved behavior decisions: [record and owner]
- Explicit exclusions: [what this review will not establish and who owns it]

Do not use a test count as a coverage target. Explain which failure each check is intended to detect and why the selected environment can expose it.

## 2. Turn risks into evidence requests

| Risk / question | Proposed method | Expected evidence | Decision owner |
| --- | --- | --- | --- |
| A signed-in user receives another workspace's orders | HTTP/database regression test with mixed-workspace fixtures and an attempted workspace override | Exact response records, denied guest request and the revision/environment tested | [engineering owner] |
| A status filter silently changes the returned records or order | Exact-response regression cases for valid filters, invalid input and stable ordering | Inputs and expected versus actual results, including an empty valid result | [engineering / product owner] |
| Staff cannot work out an order's state from the interface | Moderated usability session using a realistic question and agreed observation rubric | Task wording, participant context, observed actions and interpretation kept separate | [product / research owner] |
| A keyboard user cannot reach or operate the filter | Manual keyboard examination alongside appropriate automated checks | Tested screens, navigation path, specific failures and unresolved coverage | [accessibility owner] |
| Response time worsens at the expected workload | A separately designed performance check against a defined workload and target | Data volume, concurrency, environment, timings, errors and comparison to the target | [engineering / operations owner] |
| A changed external dependency stops a downstream update | Controlled failure and recovery exercise at that integration boundary | Correlated events, visible failure, owner and recovery outcome | [integration owner] |

The published regression example exercises only its defined HTTP/database cases in an isolated fixture. It does not perform the user sessions, accessibility examination, workload test or external-service exercise above. Decide which evidence the real release requires.

## 3. Agree the correctness contract

For the example order-list endpoint:

- A user may receive only orders from their authenticated workspace.
- A caller-supplied workspace identifier must not replace the authenticated user's workspace.
- A guest request receives a denial instead of order data.
- Only the agreed fields appear in each response; IDs have a defined type and ordering.
- Supported status filters have explicit expected results; invalid values have an agreed validation response.
- A valid filter with no matching records returns a successful empty result.

Record your own contract before selecting assertions:

| Requirement / case | Starting data and identity | Action | Exact expected observation | Evidence location |
| --- | --- | --- | --- | --- |
| [reference] | [records / role / scope] | [request or task] | [response / state / absence of side effect] | [run / artifact] |
| [reference] | [failure or invalid input] | [action] | [denial / unchanged state / visible exception] | [run / artifact] |

Include more than one workspace in access fixtures so removing a scope restriction changes the observable result. Choose explicit expected records rather than reproducing the application's query in the assertion. For a real application, tests must exercise its real routes and access model; a standalone teaching route cannot establish the application's behavior.

## 4. Prepare a small human research session

**Study question:** [what you need to learn about the task or interpretation]

**Relevant participant characteristics:** [experience, role and access needs linked to that question]

**Prototype or interface:** [version, available screens and limitations]

**Proposed task prompt:** “A customer asks whether their order still needs attention. Use this portal to find its current state and explain what you would tell them.” Replace the scenario and identifier with records available in the study interface. Avoid telling the participant which menu, filter or button to use.

**Observation rubric:** [what counts as completing the task without help; what counts as assistance, incorrect interpretation or abandonment]

**Facilitation plan:** [neutral prompts, when to offer help, how that help is recorded, recording agreement and data handling]

| Participant code / task | Observed action or exact comment | Outcome under the rubric | Interpretation / uncertainty | Proposed change and later check |
| --- | --- | --- | --- | --- |
| [code / task] | [observation] | [outcome; help given] | [possible explanation, not assumed cause] | [decision / owner] |

Do not fill this table with imagined participants or results. A small qualitative study can reveal a problem without establishing how common it is in the wider population. If comparing success rates or task times, specify the measurement rule and study design before interpreting differences. Automated endpoint tests do not replace observing a person use the interface.

## 5. Record a defect so another person can investigate

- Short description and affected requirement: [record]
- Build/revision, environment and relevant fixture: [record]
- Starting identity, scope and data: [sanitized record]
- Reproduction steps and frequency: [record]
- Expected observation and actual observation: [record]
- Evidence: [request/response, logs, screenshot or recording reference as appropriate]
- Impact and urgency: [who is affected / consequence / proposed priority]
- Investigator, decision and fix reference: [record]
- Confirmation of the fix: [same failing case / result]
- Related regression checks: [surrounding behavior / result]

Checking the original failing case confirms that particular fix. Regression checks examine other behavior that the change could have affected. A changed expected result needs a requirement decision; do not update it merely to make a failing check pass.

## 6. Make the release decision traceable

| Evidence item | Revision / environment | Result and artifact | Coverage limit / unresolved issue | Reviewer and decision |
| --- | --- | --- | --- | --- |
| Automated correctness checks | [record] | [pass / fail / blocked] | [record] | [record] |
| Manual or exploratory checks | [record] | [observations / defects] | [record] | [record] |
| Human research | [record] | [study evidence, if required] | [sampling and prototype limits] | [record] |
| Accessibility / performance / integration evidence | [record] | [specific checks required by scope] | [record] | [record] |

- Required checks and unacceptable unresolved outcomes: [agreed criteria]
- Changes made after the recorded evidence: [what must be rerun]
- Known limitations accepted for this release: [reason / accountable decision owner]
- Support and monitoring after release: [owner / signals / response]
- Recovery or rollback constraints: [procedure / limits / evidence]
- Handover: [test sources, fixtures, setup instructions, reports and maintenance owner]

Keep credentials and personal data out of reusable fixtures and reports. Agree who can access study recordings and defect evidence, and how long they are retained.

Guides and runnable example:

- https://nomadicsoft.io/blog/software-qa-testing-services
- https://nomadicsoft.io/blog/automated-regression-testing
- https://nomadicsoft.io/blog/user-testing-vs-usability-testing-understanding-the-key-differences
- https://nomadicsoft.io/downloads/qa-regression-example.md