Chapter 01
Testing fundamentals
What testing is for, where it sits in how software is built, and the vocabulary every QA conversation uses.
Why we test
Also called purpose of testing, quality assurance
- What
- Testing is running software, or examining its artefacts, to find defects and to give people evidence about its quality so they can decide whether to release it.
- Why
- Defects found before release are cheaper to fix and do not reach users. Testing reduces risk and informs decisions; it does not prove the software has no bugs.
Watch out
Believing that passing tests prove the software is correct, when they only show the cases you checked worked.
SDLC and STLC
Also called software development life cycle, software testing life cycle, SDLC, STLC
- What
- The SDLC is how a team takes a product from idea to release (plan, design, build, test, release, maintain). The STLC is the testing work inside it: analysis, planning, design, environment set-up, execution and closure.
- Why
- Knowing where you are in the cycle tells you what testing work is useful now: reviewing requirements early, designing cases before code lands, running regression before release.
- Example
- In a two-week sprint, a tester reviews stories on day one, writes test ideas while developers build, tests each story as it lands and runs a regression pass before the release.
Verification and validation
Also called verification, validation
- What
- Verification asks whether the product was built as specified. Validation asks whether it meets the user's real need in real use.
- Why
- A feature can match its specification perfectly and still be useless to users. Good testers check both, and raise it when the specification itself looks wrong.
- Example
- A search box that returns exact matches passes verification against a spec saying "exact match", but fails validation if users expect typos to be tolerated.
Test levels
Also called unit testing, integration testing, system testing, acceptance testing, UAT, unit test, integration test, acceptance test
- What
- Unit tests check one small piece of code. Integration tests check pieces working together. System tests check the whole product end to end. Acceptance tests check it meets the business or user need.
- Why
- Each level catches different bugs at a different cost. Knowing the levels lets you put each check where it is fastest and most reliable.
Watch out
Testing everything through the user interface, which makes a slow, fragile suite for bugs a unit or API test would catch in milliseconds.
Functional and non-functional testing
Also called test types, functional testing, non-functional testing
- What
- Functional testing checks what the system does: features, rules and outputs. Non-functional testing checks how well it does it: performance, accessibility, security, usability and reliability.
- Why
- Users judge both. A checkout that calculates totals correctly but takes 20 seconds, or cannot be used with a keyboard, still fails them.
Test pyramid
- What
- A model for balancing a suite: many fast unit tests at the bottom, fewer integration and API tests in the middle, and a small number of end-to-end UI tests at the top.
- Why
- Lower tests are faster, cheaper and less flaky. Keeping UI tests to the critical journeys keeps the suite quick enough to run on every change.
Watch out
The ice cream cone: hundreds of UI tests and almost no unit or API tests, so the suite is slow and fails for reasons unrelated to bugs.
Risk-based testing
- What
- Choosing what to test, and how deeply, by the likelihood that an area fails and the impact if it does.
- Why
- You never have time to test everything. Ranking by risk puts your effort on payments, sign-in and data loss before cosmetic pages.
- Example
- A banking app release: transfers and login get deep testing and automation, the help page gets a quick check.
Seven testing principles
- What
- Widely taught principles: testing shows the presence of defects, not their absence; exhaustive testing is impossible; test early; defects cluster; tests wear out; testing depends on context; and a lack of bugs does not mean the product is useful.
- Why
- They explain everyday QA decisions, such as why you vary regression tests over time and why you look harder at modules that already had many bugs.