Module 1: Testing Foundations
Why Software Breaks
Every piece of software you have used has had bugs. Banking apps, mobile money menus, school portals and online shops all fail in some way at some point. Understanding why software breaks is the first step to finding problems before your users do. Testers who know where defects come from look in the right places, ask better questions and spend their limited time where it matters most.
Errors, defects and failures
Testing uses three related words precisely, and it helps to use them the same way:
- An error (or mistake) is a human action that produces a wrong result, such as a developer misreading a requirement or a business analyst writing an ambiguous rule.
- A defect (also called a bug or fault) is the flaw that the error leaves in the product: a wrong condition in the code, a missing validation, an incorrect requirement.
- A failure is what users see when the defect is triggered: the app crashes, the total is wrong, the payment is recorded twice.
A defect can sit unnoticed for months until the right conditions trigger it. A rounding defect may only cause a failure when an order has more than ten items, or a date defect may only fail on the 29th of February. This is why testing is about deliberately creating the conditions that expose defects.
Where defects come from
Defects are introduced at every stage of building software, not only in code:
| Source | Example |
|---|---|
| Unclear or wrong requirements | "Customers get a discount on large orders" without defining "large". Developers and testers each assume a different number. |
| Design gaps | Nobody decided what happens when a mobile money payment times out but the customer was actually charged. |
| Coding mistakes | Using > instead of >= at a threshold, forgetting to handle an empty list, or mixing up two similar variables. |
| Integration problems | Your system sends a phone number as 0712... while the partner's API expects 254712.... |
| Environment differences | The app works on a developer's laptop but fails on the server because of a different time zone, operating system or configuration. |
| Changes and regressions | A fix to the invoice layout accidentally breaks the totals on receipts. |
| Unexpected usage | Users double-tap a "Pay" button, use the back button mid-payment, or paste text with emojis into a name field. |
Research and industry experience broadly agree that defects found early, for example in a requirement review, are cheaper to fix than the same defects found after release, because less work has been built on top of them. You do not need a precise figure to apply the lesson: ask questions about requirements before code is written.
Worked example: one bug, traced to its root
Imagine a small Nairobi pharmacy chain launches a loyalty system. Customers earn one point for every KES 100 spent. A week after launch, a customer complains she earned no points on a KES 99,950 purchase made across several days.
Investigation reveals a chain of causes. The requirement said "one point per KES 100" but did not say whether points are calculated per receipt or per day. The developer calculated per receipt, rounding down, so a series of KES 99 purchases earned nothing. The tester checked only round amounts such as KES 500 and KES 1,000. And the requirement never stated that rounding should go down.
No single person "caused" the bug. An ambiguous requirement, an untested assumption and narrow test data combined. A tester asking "what happens with KES 99? With KES 199?" during the requirement review would have surfaced the question before any code existed. This pattern is common: most serious defects are found by asking about boundaries, unusual inputs and unclear rules.
Common mistakes to avoid
- Assuming bugs only come from code. Requirements and integrations are frequent sources.
- Testing only with "nice" data, such as round numbers and short names.
- Blaming individuals for defects. Look for the process gap that allowed the error through.
- Believing that testing can prove software has no defects. Testing reduces risk and finds defects, but it cannot show that none remain.
- Waiting for finished code before starting to think about testing.
Exercise
Choose an app you use regularly, such as a mobile banking, shopping or ride-hailing app. Write down three failures you have experienced or can imagine. For each, guess the likely defect and the human error behind it, and say which source from the table in this lesson it came from. Finally, write one question you would have asked during the requirement stage to prevent each one.
Key points
- An error causes a defect, and a triggered defect causes a failure.
- Defects come from requirements, design, code, integrations, environments and changes.
- Questions about boundaries and unclear rules prevent many defects early.
- Testing reduces risk but cannot prove the absence of defects.