A bug report can describe exact steps and still leave an important question unanswered: under which conditions does the failure occur? A reproduction matrix compares a small number of relevant variations while keeping the basic task stable. It helps prevent scattered attempts from becoming an unreliable story about what always happens.

This guide uses a fictional form that may lose text after validation. The matrix is an investigation note, not a claim about a real defect. It complements a reproducible bug report by organizing conditions and results; it does not establish a root cause by itself.

Start with one baseline case

Write a complete baseline: initial state, harmless input, steps, expected result, and observed result. The matrix should point to that case rather than repeat the instructions inconsistently in every row. A comparison is difficult to interpret if each attempt changes both the input and the action sequence.

If the baseline does not reproduce the issue reliably, record that uncertainty. Do not build a table of variations around a result you have not actually observed. You may first need to identify a missing setup condition or capture a more accurate sequence.

Choose variations with a reason

Select factors that could plausibly change the behavior, such as signed-in state, input shape, or a relevant browser version. Explain why each factor is included. Avoid trying every available setting simply because a larger table looks thorough.

For the fictional form, start by comparing valid and invalid email-shaped input while keeping the message text unchanged. That tests one specific distinction. Changing the browser, account, message, and input together would make a different outcome harder to explain.

Use explicit result labels

Keep expected behavior separate from actual behavior. Useful actual-result labels include reproduced, not reproduced, inconclusive, and not tested. Define what reproduced means for this issue, such as the message field becoming empty after a validation warning.

An empty cell should not imply success. Mark untested combinations visibly. A matrix with honest gaps is more useful than one that appears complete because nobody recorded the missing work.

A fictional matrix structure

Baseline: Signed out, empty form, fixed harmless message, select Send once.
Case A: Invalid email-shaped value; result to be recorded.
Case B: Valid harmless email value; result to be recorded.
Case C: Same as A after a fresh page load; result to be recorded.
Case D: Same as A in another approved test browser; not tested yet.
For each case: Record time, relevant version, observation and evidence link.

These rows are a plan for checks, not fabricated outcomes. Replace “result to be recorded” only after performing the corresponding attempt. If the expected behavior differs across cases, state that difference before interpreting the results.

Change one factor at a time where practical

A controlled variation makes a result easier to interpret. If Case A reproduces and Case B does not, the input difference becomes worth investigating. It still does not prove that a particular validation function caused the loss.

Some interactions require several factors together. When that happens, expand the matrix deliberately and label the combination. Keep the original single-factor checks so the reasoning remains traceable. A small, well-explained matrix is preferable to an exhaustive-looking grid with unclear conditions.

Record inconsistent results without averaging them away

If the same case succeeds once and fails once, retain both attempts with their conditions. Look for differences in starting state, timing, or available evidence. Do not convert two attempts into a precise failure percentage that suggests a broader measurement.

An intermittent result may require a more specialized test method. The note can identify that need without pretending the uncertainty has been resolved. “Inconclusive; starting state may differ” is a useful observation when it directs the next check.

Summarize the boundary of the finding

A bounded summary might say, “Observed loss with the invalid-input case in two attempts; valid-input case did not show loss in one attempt; other browser not checked.” That is more informative than “validation is broken.”

Keep hypotheses in a separate section and identify evidence that would help assess them. The matrix organizes observations. The explanation of the defect may require inspecting code, logs, or system behavior through the team's approved process.

Use the matrix for retesting

After a fix, repeat the relevant baseline and variation cases. Record the version and date, then compare results without deleting the original observations. A new issue should receive its own description rather than being hidden inside an old pass label.

Move the final matrix into the issue record or test system used by the team. A browser note can help organize the investigation, but the durable record should keep the cases, evidence, and limitations together. The useful outcome is a clearer boundary around the behavior, not a table that claims more coverage than the checks actually provide.

Use the BiNotePads online notepad to adapt this example. For a separate copy of important work, follow the browser-note backup guide.