"There's a bug in the app" is how most people describe a software problem. It is a perfectly good phrase for everyday conversation. Professional testers, though, break that one word into three, because each describes a different moment in the life of a problem, and each points to a different way to prevent it.
This is the second step in our software testing learning path. If you have not read What Is Software Testing?, start there.
The chain: error, defect, failure
Think of a software problem as a chain of three links.
An error is a human mistake. A developer misreads a requirement. A designer forgets that some users have very long last names. A product manager writes "prices include tax" when the business meant the opposite. Errors happen in people's heads and in their decisions.
A defect is the mistake as it exists in the work. When an error ends up in something people produce, such as code, a design, a requirements document, or a configuration file, that flaw is a defect. Programmers often call it a bug, and the ISTQB vocabulary also uses the word fault. A defect can sit quietly in the code for a long time without anyone noticing.
A failure is what users see. When the software runs and the defect gets triggered, the system does something it should not, or fails to do something it should. The total on the receipt is wrong. The app crashes. The password reset email never arrives. That visible wrong behavior is the failure.
Put together: a person makes an error, which creates a defect in the software, which causes a failure when the right conditions occur.
Why the difference matters
Separating the three links changes how a team fixes problems.
- Fixing a failure means handling one symptom: refunding the customer who was overcharged.
- Fixing the defect means correcting the code so it stops happening: the tax calculation is repaired.
- Fixing the cause of the error means preventing the whole category: the requirement is clarified and the team adds a review step so ambiguous wording gets caught before anyone writes code.
Good teams do all three. The third is where testing and quality engineering pay off most, because it stops future defects from being created at all. Asking "what was the root cause?" after a serious failure is one of the most valuable habits in the profession.
Not every defect causes a failure
A defect only causes a failure when the conditions that trigger it actually occur. A defect in the code that handles leap years might stay hidden for years. A defect that only appears when two people edit the same record at the same instant may show up once a month. This is one reason testing is a skill: testers deliberately create the unusual conditions that expose hidden defects, instead of waiting for customers to stumble into them.
It also works the other way. Something can look like a failure when there is no defect in the software at all, for example when the test itself was set up wrong or the expected result was out of date. Testers call this a false positive. The opposite, a real defect that the tests miss, is a false negative. Careful testers check their own tests as rigorously as they check the software.
Severity and priority: which problems get fixed first
Every real project finds more defects than it can fix at once, so teams sort them using two separate measures.
Severity is how bad the impact is. A crash that loses customer data is high severity. A misaligned icon is low severity.
Priority is how soon it should be fixed. This depends on the business, not only the impact. A spelling mistake in the company's name on the home page is low severity, since nothing breaks, but it may be high priority because thousands of people will see it on launch day. A crash in a feature nobody will use until next year may be high severity but lower priority right now.
Keeping the two separate leads to better decisions than a single "importance" label, and it gives testers a clear way to explain why a problem matters.
A quick example
A store's checkout page charges shipping twice when a customer applies a discount code.
- Error: the developer assumed the discount step and the shipping step never run together.
- Defect: the checkout code adds the shipping charge in both steps.
- Failure: a customer using a discount code sees shipping added twice to the total.
- Severity: high, because customers are overcharged.
- Priority: high, because a sale with discount codes starts this weekend.
- Root-cause fix: add the discount-plus-shipping combination to the requirements and to the regression tests that run on every change.
Try it yourself
Think of the last time an app or website misbehaved for you. Describe the failure in one sentence. Then guess at the defect that might have caused it, and the human error behind that. Finally, rate its severity and priority from the company's point of view.
The next step in this path turns this thinking into practice: writing test cases designed to find defects on purpose.