Bug testing
Bug testing is testing carried out with the explicit goal of making software fail, rather than confirming that it works. It is not a formal stage in any test syllabus but the everyday name for the detective half of quality work: negative cases, boundary values, invalid input and interrupted flows, run by somebody trying to break the build before a user does.
The longer version
The phrase names a posture more than a technique. There are two ways to approach a build: confirm it does what it should, or try to make it fail. The first finds little, because the path being walked is the one the person who wrote the feature already walked. Bug testing is the second, which means going where the author did not: the empty field, the name with an apostrophe in it, the back button pressed halfway through a checkout.
The useful parts of it have names. Boundary value analysis targets the edges of a range, because a comparison written as less-than where less-than-or-equal was meant fails at exactly one value. Equivalence partitioning is its counterpart: inputs the system treats identically need one representative between them, which stops the first technique becoming an infinite list. Negative testing supplies precisely what a field forbids. Error guessing is the least formal and often the most productive: an experienced tester carries a list of what breaks in this kind of software.
Two long-standing observations decide where the effort goes. Defects cluster: they gather in a few modules rather than spreading evenly, usually the ones changed most often or carrying the most complexity, which makes the area that produced the last several reports the sensible place to look for the next one. And tests wear out, an effect called the pesticide paradox: a case that has passed on every run keeps passing, so a suite that never changes stops finding anything new.
A bug found and not reported reproducibly is worth close to nothing: the session ends, the tester moves on, and the knowledge leaves with them. What survives is the written report, with the sequence that makes the failure happen again, the state of the data it happened to, and the conditions around it. The costliest findings are the ones somebody hit once under circumstances they cannot reconstruct.
Common questions
What is the difference between bug testing and QA testing?
Quality assurance covers the whole process that keeps defects out, including the preventive work: standards, reviews, definitions of done. Bug testing names only the detective half, and only its adversarial part, which is the deliberate attempt to make a build fail. It is an activity inside QA rather than an alternative to it.
How do you find bugs that automated tests miss?
Automated tests re-check behaviour somebody already thought to describe, so what they miss is everything nobody anticipated. Reaching it takes unscripted work: unusual data, values at the edge of a range, interrupted flows, real devices and browsers, and a person who knows the system well enough to guess where it is thin. Exploratory testing is the name for doing that deliberately.
Where should bug testing start?
Where defects already cluster, which is usually the code changed most recently and the areas that have produced the most reports before. After that come the paths whose failure costs the most: sign-up, payment, and anything that writes data which cannot be recovered. Spreading attention evenly across a system ignores what past reports already indicate.
What is the pesticide paradox in testing?
It is the observation that a fixed set of tests loses its effectiveness as it is repeated: the defects those cases can catch get fixed, and the cases keep passing while the software changes around them. The remedy is revising and extending the suite so it reaches behaviour it was not originally written for, rather than reading a green run as evidence that nothing is wrong.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.