Introduction to Software Testing
Every app you have ever used — your banking app, a ride-hailing service, the website where you book flights — shipped only after someone asked, over and over, “but what happens if…?” That person is a software tester, and that question is the whole craft in a nutshell. This module lays the foundation: what testing really is, why it matters more than most people realise, and the mindset that separates someone who clicks buttons from someone who protects users and reputations.
Learning objectives
By the end of this lesson you will be able to:
- Explain what software testing is — and just as importantly, what it is not.
- Argue why testing matters using the rising cost of defects and real-world failures.
- Distinguish quality assurance from quality control, and verification from validation.
- Recite and apply the seven fundamental principles of testing.
- Use the vocabulary of a professional tester — error, defect and failure — precisely, and trace the chain between them.
- Decide, at a high level, when manual testing fits and when automation earns its place.
What software testing actually is
Software testing is the disciplined process of evaluating a piece of software to find out whether it behaves as expected — and to uncover the many ways it does not. It is an investigation, carried out to give stakeholders honest information about the quality and the risks of a product. Notice the word “information”. A tester’s core deliverable is not a pass or a fail stamp; it is knowledge that helps people decide whether to ship, what to fix first, and what they are risking if they do not.
It helps to be equally clear about what testing is not. Testing is not proof that software is perfect — no amount of testing can promise that. It is not the same as debugging: a tester finds and reports the symptom, a developer diagnoses and fixes the cause. And it is not a box-ticking formality bolted on at the end. Done well, testing is a continuous, thoughtful activity that shapes a product from its first requirement to its last release.
An analogy that will stick
Think of a tester as a building inspector, not the painter. The construction crew (developers) builds the house. The inspector does not pour concrete or hang doors — instead they walk the site asking pointed questions: Does the staircase hold weight? Do the fire exits actually open? Is the wiring safe behind the pretty walls? The inspector cannot guarantee the house will never have a single problem in fifty years, but they can catch the dangerous, expensive faults before a family moves in. A good inspector is valued precisely because they look for trouble on purpose — and so is a good tester.
Why testing matters: the rising cost of a bug
The single most important economic fact in testing is this: the later a defect is found, the more it costs to fix. A mistake caught while a requirement is still being written costs a conversation. The same mistake caught after release can cost a recall, a security breach, or a brand’s reputation. The cost does not rise gently — it multiplies at each phase.
| Phase where bug is found | Relative cost to fix | Why it grows |
|---|---|---|
| Requirements | 1× | Just reword a sentence — nothing has been built yet. |
| Design | ~5× | Rework a diagram before code depends on it. |
| Coding / unit test | ~10× | Change code and re-test one component. |
| System / integration test | ~20–50× | Trace the fault across many connected parts. |
| Production (live users) | ~100× or more | Emergency patch, data cleanup, support load, lost trust. |
This table is the business case for your whole profession. It is why “find it early” is not a slogan but a money-saving strategy, and why testers are increasingly invited into requirement reviews instead of waiting at the end of the line.
When software failures made history
Abstract numbers are easy to ignore, so remember these instead:
- Ariane 5 (1996). A European rocket self-destructed 37 seconds after launch. The cause was a reused piece of software from Ariane 4 that tried to fit a large 64-bit number into a 16-bit space — an overflow that was never re-tested for the faster new rocket. Cost: around US$370 million, gone in under a minute.
- Therac-25 (1985–87). A radiation-therapy machine delivered massive overdoses to patients because of a race condition — a timing bug that only appeared when an operator typed commands quickly. At least three people died. This is the sobering reminder that software quality can be a matter of life and death.
- Mars Climate Orbiter (1999). NASA lost a US$125 million spacecraft because one team used metric units (newtons) and another used imperial units (pound-force), and nobody tested the interface where the two met. The orbiter flew too close to Mars and was destroyed.
- Knight Capital (2012). A trading firm deployed new code to its servers but missed one of eight. Old, repurposed logic woke up on that one server and fired millions of unintended orders. In roughly 45 minutes the company lost about US$440 million and was effectively finished.
None of these were caused by lazy or foolish people. They were caused by untested assumptions — which is exactly what disciplined testing exists to hunt down.
QA vs QC, and verification vs validation
Four terms get thrown around as if they were the same thing. They are not, and interviewers love to check whether you know the difference.
Quality Assurance vs Quality Control
- Quality Assurance (QA)
- Process-oriented and preventive. QA asks, “Are we building the product the right way?” It is about defining good processes, standards, templates and reviews so that defects are less likely to be created in the first place. QA is proactive.
- Quality Control (QC)
- Product-oriented and detective. QC asks, “Did we actually build a good product?” It is the hands-on activity of inspecting and testing the finished work to find defects that slipped through. Testing is the heart of QC. QC is reactive.
A kitchen analogy: QA is writing the recipe, training the chefs, and keeping the kitchen clean so meals come out consistent. QC is tasting the dish before it leaves the kitchen. You need both — a perfect recipe can still be ruined by one bad plate.
Verification vs Validation
- Verification
- “Are we building the product right?” Does the software meet its written specifications? This is usually done through reviews, walkthroughs and inspections of documents and code — often without running the software.
- Validation
- “Are we building the right product?” Does the software actually meet the user’s real needs? This is done by executing the software and seeing it behave in realistic conditions.
A classic trap: you can build something that perfectly matches the specification (passes verification) yet is useless to the customer because the specification itself was wrong (fails validation). Both checks are essential.
The seven principles of testing
Decades of experience have been distilled into seven principles. They are not trivia — each one changes how you plan and defend your work.
1. Testing shows the presence of defects, not their absence
Finding bugs proves bugs exist. Finding none does not prove there are none — it may simply mean you have not looked in the right place. Testing reduces the probability of hidden defects; it can never prove a product is defect-free. Be humble in how you word your conclusions.
2. Exhaustive testing is impossible
You cannot test every possible input, path and combination — the numbers explode instantly. A single form with a few fields can have billions of combinations. Instead of trying to test everything, you use risk and priorities to choose the tests that matter most. Smart selection, not brute force, is the skill.
3. Early testing (shift-left)
Begin testing activities as early as possible — even reviewing requirements counts as testing. The earlier a defect is found, the cheaper it is (remember the cost table). “Shift-left” means moving testing toward the start of the timeline rather than cramming it at the end.
4. Defect clustering (the Pareto principle)
Defects are not spread evenly. Typically a small number of modules contain most of the bugs — often framed as “80% of defects come from 20% of the code.” When you find a cluster, dig deeper there; trouble tends to travel in packs.
5. The pesticide paradox
If you run the same tests over and over, they stop finding new bugs — just as insects grow resistant to a pesticide used too often. The cure is to regularly review and refresh your test cases, adding new ones that explore different angles.
6. Testing is context dependent
You do not test a banking app the way you test a mobile game. A medical device demands exhaustive safety checks; a marketing landing page does not. The context — risk, domain, users, regulations — shapes everything about how you test.
7. Absence-of-errors fallacy
Software that is 99% bug-free is still a failure if it solves the wrong problem or is unusable. A flawless product nobody wants is worthless. Testing must check that the software is both correct and genuinely useful — which ties straight back to validation.
Tutor tip: a memory aid for the seven principles
Try the sentence: “Defects show, Exhaustive no, Early go, Clusters grow, Pesticide slow, Context know, Absence-fallacy woe.” Silly rhymes stick far better than a plain list — and in an interview, being able to name all seven confidently signals that you learned the fundamentals properly.
The mindset and role of a tester
Technically, a tester designs and runs tests, reports defects, and tracks quality. But the mindset is what truly matters, and it is slightly unusual: a great tester is a professional, constructive pessimist. While everyone else is admiring the happy path — “the user types their name and it works!” — the tester is quietly asking, “What if the name is empty? What if it is 500 characters? What if two people submit at the exact same instant? What if the network drops halfway?”
This is often called the testing attitude: curiosity, attention to detail, a refusal to assume, and the courage to deliver bad news kindly. Crucially, the pessimism is never aimed at people. You are not trying to make developers look bad; you are trying to make the product better before a real user gets hurt. The best testers are seen as trusted partners, not gatekeepers — because they find problems early, explain them clearly, and help the team ship with confidence.
Error vs defect vs failure
These three words describe three different stages of the same problem, and using them precisely marks you as a professional. They form a chain.
- Error (mistake)
- A human action that produces an incorrect result — a developer misunderstands a requirement, or mistypes a formula. The error lives in someone’s head or keystrokes.
- Defect (bug / fault)
- The flaw in the software that the error introduced — the wrong line of code now sitting in the product, waiting. A defect can exist for months without anyone noticing.
- Failure
- What happens when the defect is executed and the software behaves wrongly in front of a user or tester. The failure is the visible symptom.
The chain in one concrete example
A developer is told that shipping is free over £50. They write the condition as if (total > 50) instead of if (total >= 50).
- Error: the human mistake — using
>where>=was meant. - Defect: the faulty code now living in the checkout logic.
- Failure: a customer whose basket totals exactly £50 is wrongly charged for shipping — the observable wrong behaviour.
Note that not every defect becomes a failure: if no customer ever spends exactly £50, the defect sits silent. This is precisely why principle #1 holds — the bug is there whether or not your tests happen to trigger it.
Manual vs automated testing: a first look
This course is about manual testing — a human thoughtfully exercising the software — but you should understand where it sits beside automation from day one. Neither is “better”; they solve different problems.
| Aspect | Manual testing | Automated testing |
|---|---|---|
| Best for | Exploratory, usability, ad-hoc, visual, and quickly-changing features. | Repetitive, stable, large-volume checks — regression, load, data-driven tests. |
| Human judgement | High — a person notices “this feels off”. | None — it only checks what it was told to check. |
| Up-front cost | Low to start. | High — scripts must be written and maintained. |
| Speed at scale | Slow and tiring for thousands of runs. | Very fast; runs overnight, every night. |
| Consistency | Humans tire and vary. | Perfectly repeatable every time. |
A healthy project uses both: automation guards the stable, boring regression checks so humans are freed to do what machines cannot — explore, empathise with users, and ask the creative “what if?” questions. Mastering manual testing first is the right order, because you cannot automate a test you do not yet understand how to perform.
Going deeper: “quality” is more than “no bugs”
Beginners equate quality with “it does not crash.” Professionals think in terms of quality attributes — often called non-functional requirements. A feature can be functionally correct yet still low quality if it is slow (performance), hard to use (usability), easily hacked (security), unusable to people with disabilities (accessibility), or falls over under load (reliability). As you grow, your “what if?” questions expand from “does it work?” to “is it fast, safe, clear and dependable?” Keep these attributes in the back of your mind even in this first module — they are the full definition of the thing you are protecting.
Common mistakes to avoid
- Treating “no bugs found” as “no bugs exist.” It usually means you need better tests, not that the product is flawless (principle #1).
- Using “error”, “defect” and “failure” interchangeably. Precise language makes your bug reports credible.
- Confusing QA with QC, or verification with validation. These pairs are not synonyms — mixing them up signals a shaky foundation.
- Testing only the happy path. The expensive bugs almost always hide in the edge cases and error paths.
- Aiming for “exhaustive” testing. It is impossible (principle #2); prioritise by risk instead.
- Reporting defects as personal criticism. Attack the problem, never the developer.
Hands-on exercise
Pick any everyday app you use — a notes app, a food-delivery app, or the login screen of a website. Then:
- List five happy-path actions (the way the app is meant to be used).
- For each, write at least two “what if…?” questions a tester would ask — empty inputs, extreme values, interruptions, wrong order of steps.
- Invent a plausible bug in the feature and describe it as a full chain: the error a developer might have made, the defect in the code, and the failure a user would see.
- For each of the seven principles, write one sentence explaining how it applies to this specific app.
- Decide which of your tests you would run manually and which you would eventually automate, and justify each choice in a few words.
Knowledge check
- In one sentence, what is the primary deliverable of software testing?
- Why does the cost of fixing a defect rise so sharply the later it is found?
- State the difference between verification and validation using the “right” phrasing for each.
- Which principle explains why re-running the same tests forever stops being useful, and what is its name?
- Give the error → defect → failure chain for a login form that crashes when the password field is left blank.
Show answers
- Information about the quality and risks of the product, so stakeholders can make informed decisions — not a simple pass/fail stamp.
- Because later phases have more work built on top of the flaw, so a fix means tracing and reworking across design, code, tests, data and sometimes live users — each layer multiplies the effort.
- Verification asks “are we building the product right?” (matches the spec, via reviews). Validation asks “are we building the right product?” (meets real user needs, by running it).
- The pesticide paradox — tests lose their power to find new defects unless they are regularly reviewed and refreshed.
- Error: the developer forgot to handle an empty password. Defect: code that uses the missing value with no guard. Failure: the app crashes when a user submits with the password blank.
Key takeaways
- Testing is an investigation that delivers information about quality and risk — it can show defects exist but never prove they are absent.
- Bugs get exponentially more expensive the later they are found; real disasters like Ariane 5, Therac-25 and Knight Capital show the stakes.
- QA is preventive and process-focused; QC is detective and product-focused. Verification checks against the spec; validation checks against real needs.
- Know the seven principles and be able to apply each to a real product.
- Use error, defect and failure precisely — they are three links in one chain.
- Manual and automated testing are partners; master manual first, because you cannot automate what you do not understand.
Go deeper
Three ideas sit just beyond this first module but will sharpen everything you do from here on.
- The oracle problem. Every test silently compares what happened against what should have happened — and that source of truth is called a test oracle. Sometimes the oracle is obvious (a requirement says “show £50”), but often it is fuzzy: is this search result “relevant enough”? Is this report “correct”? When you cannot state a clear oracle, you cannot really say a test passed — recognising a weak or missing oracle is a surprisingly senior skill.
- Static vs dynamic testing. The module said verification is often done “without running the software.” That activity has a name: static testing — reviews, walkthroughs, inspections and automated static analysis of documents and code. Dynamic testing is everything that executes the software. Static testing is the cheapest shift-left move there is, because it kills defects before they ever become running code.
- Positive vs negative testing. A positive test confirms the system does the right thing with valid input; a negative test deliberately feeds invalid or hostile input to confirm the system fails safely rather than crashing or corrupting data. Beginners write almost all positive tests; the expensive bugs usually live on the negative side.
A worked tie-back: take the free-shipping bug (if (total > 50) instead of if (total >= 50)). A positive test with a £60 basket passes and hides the bug. Only a test placed exactly on the £50 edge — a boundary, with a precise oracle (“shipping should be free”) — exposes it. That is why clear oracles and deliberate edge thinking matter even in Module 1.
