Software QA / Basic: reasoning and test design / Lesson 6

Defect reports and exploratory investigation

Investigate an uncertain failure, preserve useful observations, and communicate a reproducible defect. Combine a focused exploratory charter with clear severity and priority discussions.

About 4 min readContent reviewed 2026-10-23

On this page

Lesson goals

Write actionable defect evidence without blame.
Use a charter, notes, and debrief for exploration.
Separate observed facts from hypotheses.

Observe before explaining

A learner reports that a saved assessment answer disappears. First capture the build, browser, account role, item identifier, and precise sequence. Distinguish what you observed from your explanation: “answer absent after reload” is a fact; “database lost the write” is a hypothesis. Check whether the save request completed, whether the response indicated success, and whether another view can read the answer. Reduce the sequence carefully while retaining a reproducible original, because simplifying away a timing condition can make an intermittent failure disappear.

Worked case: a useful report

In an isolated test account, opening the same assessment in two tabs and saving different answers can reveal overwrite behavior. Record which tab loaded first, the exact values, and response order. If the agreed rule rejects stale updates, the second save should show a conflict and retain the first saved value. Report actual overwrite as a discrepancy against that rule. Attach a sanitized request timeline rather than session cookies or learner data. A concise title names the trigger and harm, making triage faster than “save is broken.”

text Illustrative report, not a claimed production incident

Title: stale second-tab save overwrites confirmed answer
Build: qa-demo-17; browser and role recorded
Steps: load A and B at version 1; save A="yes"; save B="no"
Expected: conflict on B; stored answer="yes"
Actual: B succeeds; stored answer="no"
Evidence: sanitized response versions and timestamps

The report supplies the oracle, reproduction path, and material outcome without asserting an unverified root cause.

Explore with a question and a boundary

Exploratory testing combines learning, design, and execution as understanding develops. A charter might say: investigate answer recovery across refresh and interrupted requests using two test tabs, to discover silent data loss. Set a timebox, establish test data, and record meaningful actions, observations, questions, and coverage. Adapt when a useful clue appears; the charter gives direction rather than prescribing every click. A session without notes is difficult to review, while a rigid script may miss the very anomaly that justifies further investigation.

Worked case: follow a timing clue

During a recovery session, suppose a controlled delayed save response arrives after a newer save. Record the order of requests and responses, then compare the final displayed value with persisted state. The oracle may require the newest accepted version to remain authoritative. Repeat using explicit version identifiers rather than relying on visual speed. If only the display reverts while storage is correct, the investigation has narrowed to a different risk than lost persistence. Save this sequence as a candidate regression case and review the expected ordering rule with the team.

Triage, confirm, and learn

Severity describes impact; priority expresses when to act given exposure, release goals, and workarounds. A defect can be severe but low priority if its affected feature is unavailable in the planned release; document that assumption. During triage, decide ownership and next evidence, not personal fault. After a fix, rerun the original reproducer for confirmation and investigate related paths for regression. Debrief the exploratory session: what was learned, which risks remain, and which stable examples deserve automation. Keep unresolved questions visible rather than turning uncertainty into a false pass.

Common errors and fixes

A report says only “sometimes fails”

Why it happens: Context and sequence were not preserved.
How to fix it: Add observed conditions, timestamps, frequency, and a minimal known reproducer.
Prevent it next time: Capture session notes while investigating.

A hypothesis is stated as root cause

Why it happens: The reporter jumps from symptom to explanation.
How to fix it: Label the hypothesis and include supporting or conflicting observations.
Prevent it next time: Separate expected, actual, and suspected cause fields.

Exploration becomes unrecorded clicking

Why it happens: No question, timebox, or debrief guides learning.
How to fix it: Use a charter and record findings plus uncovered areas.
Prevent it next time: Schedule a brief evidence-based debrief.

Check your understanding

1. Rewrite “database corrupts answers” when you have only seen an empty field after reload.

Show worked solution

Use “Saved answer appears empty after reload under [recorded sequence].” State the expected retained answer and actual empty field, attach the save/read response evidence available, and label persistence loss as an unconfirmed hypothesis. This invites investigation without narrowing it prematurely.

2. Write a 20-minute charter for a course filter.