Boundary Value Analysis: What Happens When You Push the Limits
Some of the most interesting bugs I encountered as a QA intern weren't about whether a feature worked, they were about what happened right at the edge of what it was supposed to handle.
Testing the edge
Early in my internship, I mostly tested with "normal" inputs, a reasonable name, a reasonable file size, a reasonable date. It wasn't until I was assigned to test the RocketSingh app that I really understood boundary value analysis: instead of asking "does this work normally," you ask "what's the exact limit, and what happens right at it, just under it, and just over it."
The 10 MB test
RocketSingh's booking form specified a file size limit for image uploads. So I uploaded a file just over 10 MB to see what would happen. The result was actually a success story for once: the form displayed a proper error message instead of crashing or silently failing. That's what good boundary handling looks like, a clear, expected failure instead of a confusing one.
The file format test
Cleaning sewa’s booking form included a company photo or pdf input section where I uploaded a large video file and it was accepted perfectly. This was a huge failure for the website form validation.
Not every limit is documented
The tricky part of boundary testing is that not every system tells you where its limits are. Sometimes you have to find them by testing progressively larger inputs, longer text strings, bigger images, more form fields filled out at once, until something breaks or the system tells you it can't go further. That process of narrowing in on a system's real limits, rather than its assumed ones, is where a lot of genuinely useful bugs live.
Why boundaries deserve special attention
It's tempting to think boundary bugs are edge cases that barely matter. In practice, they're often the first thing that breaks in production, because most manual testing skips right past them. A tester who only checks the middle of the range will miss the exact scenario a real user is most likely to hit by accident, uploading a photo that's slightly too big, typing a description that's slightly too long, or picking a date at the very edge of what's allowed.
Pairing boundaries with expected behavior
The RocketSingh example stuck with me because it showed the goal isn't to prevent every large file, it's to make sure the system responds predictably when limits are reached. A good boundary test isn't just "does it break," it's "does it fail gracefully, with a message the user can actually understand and act on."
The takeaway
Boundary value analysis taught me to stop thinking about testing as pass or fail on "normal" cases. The real question is always: what happens at the edge, and does the system handle that edge with the same care it handles everything else?
