Both make the problem disappear from the screen. Only one of them makes it disappear from the system, and the screen is where you are looking.
The error is gone in both. In one of them the wrong number is still being calculated.
The finance dashboard threw an error, so the error display was hidden. The dashboard loads cleanly now.
Traced it: rows with blank dates were being dropped in the aggregation. The aggregation now handles them, and a test covers it.
One removes the defect. One removes the sign of the defect, which is the part you can see.
An error message is a symptom, and silencing a symptom is not treatment. The defect never reads the message — it carries on doing whatever it was doing, now without an announcement.
And suppression is worse than the original bug in one specific way: it converts a loud failure into a silent one, which buys the problem months instead of minutes.
Tap a change, then tap whether it removed the cause. Then see where each one comes back.
Pick a situation. Something was silenced, and the thing it was warning about carried on.
The dashboard loads now. The error is gone. The numbers on it have not changed at all.
Five questions. Nothing is scored.
Five terms, not two. Tap one.
Check whether the underlying cause was changed or only the output was altered. If the same issue cannot appear elsewhere, you have a fix. If the problem can resurface in a new way, it was likely suppressed.
Suppressed symptoms can hide serious defects. The problem may return in a different form, cause data loss, or trigger failures elsewhere. Suppression can also make future debugging much harder, as the real cause is masked.
A dashboard that stops showing error messages when data is missing, but does not fix the missing data itself. The dashboard looks fine, but decisions are made on incomplete information.
Suppression can hide missing or incorrect records, leading to inaccurate reports. During an audit, gaps may be found that were never flagged, putting the organisation at risk of penalties or failed compliance checks.
Suppression can let hidden defects grow, leading to bigger failures later. Teams may spend more time debugging, patching, and explaining problems that could have been solved early, costing time, trust, and money.
In rare cases, suppression is used as a temporary workaround while a real fix is prepared. It should always be documented, tracked, and removed as soon as the root problem is fixed.
| Aspect | Bug fix | Symptom suppression |
|---|---|---|
| Impact on QA | Improves software quality and reliability | Makes QA harder by hiding real issues |
| Long-term effect | Reduces future bugs | Increases risk of hidden failures |
| Testing outcome | Passes for the right reasons | May pass tests but fail in production |
The error message going quiet is evidence about the message. The defect never reads it.
Copyright © Pawan Nayar · LLOS.ai · 2026 — Bug fix vs Symptom suppression: removing the cause, versus hiding the sign.Original pedagogy, voice, and design — all rights reserved.