01 Overview
Data loss and crashes both feel urgent, but they are not the same kind of urgent. A crash is loud: the application stops, the user sees an error or a closed window, and the failure is obvious. Data loss can be quiet. A record disappears, a field reverts, a sync overwrites a newer version, or an export silently omits rows. The user may not notice until much later, when the missing data matters. That delay changes how we should think about severity and priority.
This article is about the craft of judging data-loss defects against crashes. It is not about any particular tracker or test tool. It is about the reasoning a tester or engineer applies when writing the report, assigning severity, and arguing for priority in triage. The central claim is simple: data loss outranks a crash only sometimes. Sometimes a crash is worse because it blocks all users from a critical path. Sometimes data loss is worse because it destroys work that cannot be recreated. The skill is in telling those cases apart without inflating every defect into an emergency.
Good triage depends on clear language. A report that says “data loss” without saying what data, under what conditions, and with what recovery options forces the team to guess. Guessing leads to either panic or neglect. The sections that follow walk through what the report is actually claiming, how severity and priority differ, how to write steps that reproduce the problem, how to run a triage queue, and what to do when a defect returns after being marked fixed.
02 What the report is actually claiming
When someone writes “data loss,” they may mean several different things. They might mean that data was never saved, that it was saved but later overwritten, that it was saved to the wrong place, that it was deleted by a user action that was not clearly confirmed, or that it became inaccessible because of a permissions or corruption issue. Each of these has a different severity profile. A tester’s first job is to translate the vague phrase into a specific claim: what data, in what state, was expected to persist, and what actually happened instead.
The report should also distinguish between permanent loss and temporary unavailability. If a record is missing from a list but still exists in the database and can be recovered by a support action, that is serious but different from a record that has been overwritten with no backup. Similarly, a failed save that leaves the original data intact is less severe than a partial save that corrupts the original. The claim should say whether the data is gone, altered, duplicated, or merely hidden. It should also say whether the loss is reproducible or was a one-time event, because a one-time event may still be severe but is harder to triage without more evidence.
Finally, the report should identify the affected area precisely. “The app lost my data” is not enough. Was it the save button, the autosave timer, the sync process, the import, the export, or the delete confirmation? The affected area determines who owns the defect and what tests need to be run. A good report makes the claim falsifiable: another person should be able to read it and say, “I understand what you expected, what happened, and how I could check whether it is true.”
03 Severity versus priority
Severity describes how much damage a defect causes. Priority describes when the team intends to fix it. These are related but not identical. A defect can be high severity and low priority if it affects a rare configuration and the fix is expensive. A defect can be low severity and high priority if it is highly visible, blocks a demo, or undermines trust in a core workflow. Data loss tends to push severity upward because the damage may be irreversible, but that does not automatically make it the highest priority in every release.
Consider a crash that happens on every launch for all users. That is high severity because the product is unusable, and it is also high priority because nothing else can ship until it is fixed. Now consider a data-loss defect that occurs only when a user edits a record offline, then syncs after a specific sequence of changes. The damage is severe for the affected users, but the defect may be rare and the fix may require a redesign of the sync logic. The team might choose to mitigate it first, such as by warning users or disabling the risky path, and schedule the full fix later. That is a priority decision, not a denial of severity.
Triage works best when severity and priority are argued separately. The severity argument should focus on the harm: how much data, how recoverable, how many users, and whether the loss is silent. The priority argument should focus on timing: what else is competing for the same engineers, what the release commitments are, and what mitigation is possible now. Mixing the two arguments leads to fights where one person says “this is critical” and another says “we cannot fix it this week,” and neither is actually disagreeing about the facts.
04 Writing steps someone else can follow
Reproduction steps are the backbone of a data-loss report. Without them, the team cannot confirm the defect, cannot estimate the fix, and cannot verify the fix later. The shortest reliable sequence is better than a long narrative. Start from a known state: a fresh account, a specific record, a particular file, or a documented data set. Then list the actions in order, using the same names the interface uses. If a step depends on timing, such as waiting for an autosave or a sync cycle, say so explicitly. If a step depends on a setting, state the setting and its value.
Describe what you expected and what you observed in concrete terms. “Expected the record to keep the new title; observed the title reverted to the old value after reopening the record” is more useful than “data loss.” Include the smallest amount of data that shows the problem. If the defect only appears with a large file or a long text field, say how large or how long. If it only appears after a specific number of edits, say how many. These details help the team reproduce the issue and also help them judge severity, because they show how close the defect is to normal use.
Finally, note anything you already tried. If you attempted a workaround, such as saving twice or exporting before closing, say whether it helped. If you could not reproduce the defect a second time, say that too. A report that admits uncertainty is more trustworthy than one that overstates confidence. The goal is not to prove a theory; it is to give the next person enough information to see the problem for themselves and to decide what to do about it.
05 Running the triage queue
Triage is a routing decision, not a debate about worth. The queue should move defects toward an owner, a severity, a priority, and a next action. For data-loss reports, the first question is whether the claim is understood. If the report does not say what data was lost, under what conditions, and with what recovery options, it should go back to the reporter for clarification before it consumes engineering time. That is not a rejection; it is a request for the minimum information needed to make a decision.
Once the claim is clear, the team should assess severity and priority separately. Severity should be based on harm: is the data permanently gone, is it recoverable, how many users are affected, and is the loss silent or obvious? Priority should be based on timing: what release is affected, what mitigation is possible, and what else is competing for the same work. A data-loss defect that is severe but rare may be scheduled after a less severe defect that blocks a larger group. A data-loss defect that is severe and silent may jump ahead of a crash that is loud but recoverable, because silent loss erodes trust in ways that a visible crash does not.
The output of triage should be a clear status and a clear next step. The defect might be assigned to a team, marked as needing more information, linked to a mitigation task, or deferred with a note about when it will be revisited. The important thing is that the decision is recorded. A data-loss defect that sits in a queue without a decision is worse than one that is explicitly deferred, because no one knows whether it has been considered. Triage is how a team turns a pile of reports into a plan.
06 When a defect comes back
A data-loss defect that returns after being marked fixed is a special kind of problem. It suggests that the original fix addressed a symptom rather than the cause, or that the reproduction steps were incomplete. The first step is to compare the new report with the old one. Is it the same data, the same affected area, and the same sequence of actions? If the steps differ, it may be a related but distinct defect. If the steps are the same, the fix did not hold, and the team needs to understand why before attempting another fix.
Reopened defects should be triaged again, not simply reassigned to the original owner with a note. The severity may have changed if the defect now affects more users or a more critical path. The priority may have changed if the team has already shipped a mitigation or if the defect is now blocking a release. The new report should include any additional evidence, such as logs, timestamps, or a screen recording, that was not available the first time. That evidence may explain why the defect survived the fix.
It also helps to ask whether the verification was adequate. A fix is not verified until someone has tried to reproduce the original loss using the original steps, and ideally some variations. If the verification only checked that the immediate error disappeared, the underlying data path may still be fragile. A returned defect is a signal to strengthen the test, not just to patch the code. The goal is to close the loop so the same loss does not come back a third time.
07 Frequently asked questions
Does data loss always outrank a crash? No. A crash that prevents all users from accessing a critical workflow can be more urgent than a data-loss defect that affects a rare path. The comparison depends on harm, reach, recoverability, and timing. The phrase “data loss outranks a crash” is a useful default, not a rule. The point of severity and priority is to make the trade-off explicit rather than assumed.
How do I decide severity when the data is recoverable? Recoverable data loss is still severe, but it is usually less severe than permanent loss. The key questions are how much effort recovery takes, who can perform it, and whether the user knows the data is missing. If recovery requires engineering intervention or if the user may never notice, the severity should reflect that. If recovery is a simple undo and the user is clearly warned, the severity may be lower.
What if I cannot reproduce the defect? Report it anyway, with as much detail as you have. Say that you could not reproduce it, and include the conditions under which it occurred. A single report of silent data loss is worth investigating, even if it is not yet reproducible. The triage team can decide whether to gather more evidence, add logging, or wait for a pattern. The worst outcome is not a false alarm; it is a real loss that no one recorded.
Should priority ever be higher than severity? Yes. A low-severity defect can be high priority if it is highly visible, blocks a release, or damages trust in a core feature. Priority is about timing and context, not just harm. The two measures are meant to be argued separately so the team can make a clear decision about what to fix next.