Exploratory Session Finds a Data Corruption Bug
A tester runs a 90-minute time-boxed exploratory session on an inventory sync feature. She finds that when two warehouse clients update the same SKU within 2 seconds, the second write silently overwrites the first, and stock counts drift. She has notes and a screen recording but no written charter beyond "explore sync". The sprint ends in 3 days. The product owner says the scenario is rare and wants it logged as a low-priority backlog item. The developer says it is a known limitation of last-write-wins and not a bug. The tester must decide how to report and escalate.
1. Is this a defect, a known limitation, or both? Justify and state what the tester should document.
Read the worked answer
It is both a defect and a known limitation, and those are not mutually exclusive. Last-write-wins may be an accepted design choice, but silent data loss with drifting stock counts is a business-impacting outcome. If the limitation was known, it should have been documented, risk-assessed, and communicated; the fact that a tester found it in exploratory testing suggests it was not visible to stakeholders.
Documentation should include: the exact conditions (two clients, same SKU, under 2 seconds), the observed result (overwrite, count drift), expected behavior, reproduction steps, the recording, environment, and frequency estimate. Classify severity by impact, not rarity: incorrect inventory can cause overselling, financial loss, and customer harm. Rarity affects likelihood, not severity. The tester should not downgrade severity just because the product owner called it rare; instead, present the impact and let the risk owner decide priority with full information.
2. How should the tester escalate, and how does the weak charter affect the credibility of the finding?
Read the worked answer
Escalate through the defect report and a direct conversation with the product owner and developer, framing it as a risk decision rather than an argument. Ask: is last-write-wins intentional, and if so, where is it documented and what mitigation exists? Offer options such as optimistic locking, conflict warnings, or reconciliation reports. If the owner still deprioritizes, record the decision and the accepted risk in the backlog item so accountability is explicit.
The weak charter ("explore sync") does not invalidate the finding, but it weakens the session's traceability. A charter should state the target, risks, and time box, so coverage can be judged. Here the tester can strengthen the report by adding a short session sheet: charter, duration, areas covered, what was not covered, and the bug. Recommend that future charters name the risk (for example, concurrent updates) so findings connect to a test objective. The bug stands on its evidence; the charter only affects how much confidence the team can place in the session's overall coverage.