Introduction to Software Testing

Every piece of software you have used was tested by someone, even if that someone was the first unlucky customer. Testing is how a team finds out what the product actually does, as opposed to what everyone believes it does, before the people paying for it find out the hard way.

This lesson sets up the mental model the rest of the path builds on. You will learn what testing is for, what it cannot do, the vocabulary interviewers expect you to use precisely, and the seven principles that explain why testers make the choices they do.

What software testing actually is

A practical definition: software testing is the process of evaluating a product to find information about its quality, so that people can make better decisions about it. That information might be “this checkout flow loses the discount code when you go back a page” or “the search page is fine on every browser we support”.

The ISTQB glossary defines testing as the process within the software development lifecycle that evaluates the quality of a component or system and related work products. The ISTQB Foundation syllabus then lists the objectives of testing, which include evaluating work products such as requirements and code, finding defects, checking that specified requirements are met, building confidence, and providing information so stakeholders can make decisions. Notice three things:

1. Testing happens across the lifecycle, not only by clicking through a finished build. Reviewing a requirements document is testing.
2. It evaluates work products, not just running code.
3. It has more than one goal: finding defects is one, but so are checking requirements, checking fitness for purpose and informing decisions.

Testing produces information, not quality

Testers do not “add quality” to a product any more than a thermometer adds heat to a room. Quality is built by everyone: product managers writing clear requirements, developers writing careful code, designers removing confusing flows. Testing measures and reveals. A good tester’s output is a clear, trustworthy picture of risk: what works, what is broken, what has not been checked, and how confident the team can be.

This matters in practice. When a release slips because a critical bug was found, testing did its job. The bug was already there; testing just made it visible while it was still cheap to fix.

Error, defect, failure: get the words right

These three terms are often used interchangeably in casual conversation, but they mean different things, and interviewers notice when you use them correctly.

Term	What it is	Example
Error (mistake)	A human action that produces an incorrect result	A developer misreads the spec and thinks a discount applies to orders over 100 instead of 100 or more
Defect (bug, fault)	An imperfection in a work product: code, requirement, design	The code says total > 100 where it should say total >= 100
Failure	An event where the system does not do what it should when executed	A customer with a cart of exactly 100 does not get the discount

The chain is: a person makes an error, which introduces a defect into the product, which may cause a failure when that code runs under the right conditions.

Two consequences follow:

• A defect does not always cause a failure. If no customer ever has a cart of exactly 100, the defect sits there silently. This is why some bugs survive for years.
• Failures can also come from the environment, not only defects: a full disk, a network timeout or a misconfigured server can make correct code fail.

Why testing is necessary

Software is built by people working from incomplete information under time pressure. Mistakes are guaranteed. Testing exists because:

• Defects are cheaper to fix early. A wrong requirement caught in a review costs a conversation. The same mistake found in production can cost a hotfix, a data clean-up, support time and customer trust.
• Some failures have serious consequences. Payment systems, medical devices, aviation software and anything handling personal data carry legal and safety obligations.
• Stakeholders need evidence. “We think it works” is not a release criterion. Test results give product owners something concrete to decide on.
• Contracts and regulations may require it. Many industries mandate documented testing as part of compliance.

The seven testing principles

The ISTQB Foundation syllabus lists seven principles. They are not rules to memorise for a certificate; each one explains a decision you will make on a real project.

1. Testing shows the presence, not the absence, of defects

Testing can prove that defects exist. It cannot prove that none exist. If 500 tests pass, you know those 500 scenarios behaved as expected, nothing more. This is why testers report “no known critical defects in the tested scope” rather than “the product is bug-free”.

2. Exhaustive testing is impossible

A common myth is that with enough automation you can test everything. You cannot. Consider a single form with a 10-character text field that accepts letters and digits. That is 62 possible characters in each of 10 positions: 62 to the power of 10, roughly 8.4 × 10^17 combinations, for one field. Add more fields, browsers, devices, network conditions and timing, and the input space is effectively infinite.

Instead of trying to test everything, testers use risk analysis and test design techniques (equivalence partitioning, boundary value analysis, decision tables, pairwise testing) to choose a small set of tests that are most likely to find defects. You will learn these in Test Case Design Techniques.

3. Early testing saves time and money

Start testing activities as early as possible. Review requirements before code is written; ask “how would I test this?” during refinement. Teams sometimes call this shift-left. A tester who spots an ambiguous acceptance criterion in a planning meeting prevents a whole class of defects.

4. Defects cluster together

A small number of modules usually contain most of the defects. Complex areas, frequently changed code and parts written under time pressure tend to be where problems live. Use your bug history: if the pricing engine produced most of last quarter’s bugs, it deserves more testing this quarter.

5. Tests wear out (the pesticide paradox)

Running the same tests repeatedly eventually stops finding new defects, in the same way pests become resistant to a pesticide that is used over and over. Existing tests remain valuable as regression checks, but you need to review and add new tests, vary data and do exploratory testing to keep finding new problems. The current syllabus phrases this principle as “tests wear out”.

6. Testing is context dependent

There is no single correct way to test. A banking API, a mobile game and an internal admin tool need very different approaches, levels of rigour and documentation. Safety-critical software may need formal traceability for every requirement; a two-week prototype may need a quick exploratory session.

7. Absence-of-defects fallacy

Finding and fixing lots of defects does not guarantee success. A system can be nearly bug-free and still fail because it solves the wrong problem, is too slow, or confuses its users. This is why testing includes validation, not only verification.

Verification vs validation

	Verification	Validation
Question	Are we building the product right?	Are we building the right product?
Checks against	Specifications, designs, standards	User needs and intended use
Typical activities	Reviews, static analysis, testing against acceptance criteria	User acceptance testing, usability testing, beta programmes
Example	The password rule “8+ characters” is enforced exactly	Users can actually create an account without giving up

Both matter. A feature that perfectly matches a flawed spec passes verification and fails validation.

Static and dynamic testing

Testing is not only running software.

• Static testing examines work products without executing them: reviewing requirements, walking through designs, code reviews, and static analysis tools such as linters and type checkers.
• Dynamic testing executes the software and observes its behaviour: manual test cases, exploratory sessions, and automated test suites.

Static testing is often the cheapest way to find defects, because the defect is caught before anyone builds on top of it.

Where testers add value

A modern QA engineer or SDET contributes across the whole cycle:

• Before code: questioning requirements, writing acceptance criteria with the team, identifying risks.
• During development: pairing with developers, writing automated checks, testing early builds.
• Before release: regression testing, exploratory testing, reporting clear status to stakeholders.
• After release: analysing production incidents, adding tests for escaped defects, improving the process.

The next two lessons show where these activities sit in the Software Development Life Cycle and the Software Testing Life Cycle.

Practice exercise

Take a simple feature you can picture clearly: a login form with an email field, a password field, a “Remember me” checkbox and a “Sign in” button. The rule is that accounts lock after five consecutive failed attempts.

1. Write down one example each of an error, a defect and a failure that could plausibly occur in this feature.
2. Pick three of the seven principles and write one sentence each on how it changes what you would test here.
3. List two verification checks and two validation checks.

A good result uses each term precisely, ties every principle to a concrete decision rather than restating it, and separates “matches the spec” from “works for real users”. You can turn your ideas into structured cases with the Test Case Generator.

Show a model answer

Error, defect, failure

• Error: the developer assumes the lockout counter resets on page refresh.
• Defect: the counter is stored in page state instead of on the server.
• Failure: an attacker refreshes the page between attempts and gets unlimited password guesses.

Principles

• Exhaustive testing is impossible: I will not try every password; I will test boundaries of the lockout rule (4, 5 and 6 failed attempts) and representative invalid inputs.
• Defects cluster: authentication and session handling are high-risk, so I will spend more time on lockout, session expiry and “Remember me” than on button styling.
• Absence-of-defects fallacy: even if lockout works perfectly, I will check that a locked-out user is told clearly what happened and how to recover.

Verification

• After exactly five failed attempts the account is locked, as specified.
• The password field masks input.

Validation

• A real user who forgot their password can recover access without contacting support.
• The error messages are understandable and do not reveal whether the email exists.

Key takeaways

• Testing produces information about quality so people can make decisions; it does not add quality by itself.
• An error (human mistake) introduces a defect (in a work product), which may cause a failure (observed incorrect behaviour) when executed.
• Exhaustive testing is impossible, so testers rely on risk and test design techniques to choose what to test.
• Verification checks against the spec; validation checks against real user needs. You need both.
• Testing starts early and includes static activities such as reviews, not only running the software.