A QA tip about why a "harmless" crash on a long number is bigger than it looks.
Here's a QA tip that has uncovered more serious problems than it has any right to.
Take any field that expects user input. A search box. A sort parameter. An ID field. Anywhere a value travels from the user into the database. Now feed it something it was never designed for: an unusually long number, far bigger than anything a normal user would ever type.
Most of the time the application handles it gracefully.
And sometimes, instead of a clean "invalid input," it throws a raw database error straight onto the screen.
That second outcome is the one worth paying attention to.
A crash is the symptom. The leak is the story.
When most people see an error on screen, they log it as "app breaks on long input" and move on. That is the bug. But it is not the interesting part.
A raw database error leaking to the user can reveal what is sitting underneath the application. Table names. Column names. The type of database running in the background. Sometimes a fragment of the actual query that failed.
Think about what that means for a second. A random oversized number, typed into an ordinary field, just convinced the application to describe its own internals to a complete stranger.
That is no longer a cosmetic bug. That is the system handing out a partial map of itself.
Why testers should care more than anyone
Here is the deeper signal. An application that spills a raw database error is almost always an application that is not properly validating and sanitising input before it reaches the database.
And that exact gap, unvalidated input flowing straight into database queries, is the root of some of the most serious and most exploited security problems on the internet.
So when a long number produces a database error, the number did not really "break" anything new. It exposed something that was already true: the layer between user input and the database needs a much closer look.
The crash was loud. The real problem was quiet, and it was there the whole time.
The defensive checklist
The good news is that fixing this is well understood work. None of it is exotic. It just has to actually be done, on every field, including the boring ones nobody thinks about.
Validate input before it reaches the database. Decide what each field should accept, and reject everything else.
Set sensible limits. A field that expects a small number should not silently try to hand a 16-digit value to the database.
Sanitise everything. Treat all user input as untrusted by default. Always.
Never let raw database errors reach the user. Catch them, log them privately where your team can see them, and show the user a clean, generic message instead.
That last point matters twice over. It protects your users from a confusing experience, and it stops your application from quietly narrating its own structure to anyone curious enough to type a weird value.
The mindset behind the tip
This is the part that outlives the specific trick.
Good QA is not only about asking "did it work?" It is about asking "what did breaking it reveal?" A crash is rarely just a crash. It is the system telling you something about what is happening beneath the surface, but only if you are paying attention to what comes back, not just whether it failed.
So the next time a field falls over on a strange input, do not stop at "throws an error." Ask what that error is exposing. Read it the way a curious outsider would. The bug is the symptom. What it reveals is the actual story, and usually the more important one.
If your application accepts user input, and every application does, it is worth checking how it behaves when someone hands it something it never expected. Far better that you are the one who finds it first.
Part of an ongoing series of honest notes from the testing trenches. If your "simple" input field has a story like this one, I would like to hear it.
Top comments (0)