Recording defects with reproducible steps

Record a defect so another person can start from the same state, follow the same actions and compare the actual result with the expected one. Include the app version, user role, test record and route used. “The request form failed” is too vague to reproduce or verify.

Capture the conditions

Note the app version, page or task, account role, relevant device or browser, and whether the record was new or existing. Use a safe test record ID, not personal details. If another system was involved, name the operation and state whether its outcome is known. Keep credentials and sensitive request data out of an ordinary defect ticket.

State the starting status and any preparation. A pre-filled form may behave differently from a fresh one; a request awaiting review may offer actions that a closed request does not.

Separate steps, expected result and actual result

Number the actions in order. Name a control another tester can find and give the input needed to trigger the issue. State what should happen and what did happen, and copy relevant error text accurately. If a write was attempted, inspect the resulting record where the tester is authorised to do so.

This report is illustrative, not an observed defect:

Title: Request status appears unchanged after correction

Context: Test version A; requester role; fictional request R-104, initially “Needs information”; desktop browser.

Steps: 1. Open R-104 from the request list. 2. Enter room number 12 in the missing room-number field. 3. Select “Send update”. 4. Reopen R-104.

Expected: Room number 12 is saved and the requester sees the agreed next status.

Actual: Room number 12 is present, but the displayed status remains “Needs information”.

Impact to assess: The requester cannot tell whether the coordinator has the correction.

This separates the saved value from the displayed status without guessing whether the cause is a rule, refresh or screen fault.

Add only useful, safe evidence

A screenshot can show a clipped control or confusing message, but it rarely explains the starting state and actions. Attach one when it adds information, with sensitive details removed. For an intermittent fault, record how often it occurred in the checks actually run; one attempt cannot establish a frequency. Include a safe diagnostic reference if the owner can use it.

These details can be recorded in a simple shared log; no specialist tool is required.

Triage and verify

Give the defect an owner and status. Set priority from the task blocked, people affected and consequence of a wrong result. Keep observed impact separate from a suspected cause. Link reports of the same failure, but retain a distinct case when its starting conditions or fix differ.

After a change, repeat the recorded steps with a safe record and relevant role. Check the screen and saved data, then a nearby ordinary path if the change could affect it. Record the version and observed result. Close the defect when the agreed outcome has been verified, or state why it remains open.