Why a tester needs theory
Theory gives you a shared language. When someone in the team says “let’s run regression after this fix” or “it’s a low-severity, high-priority defect”, everyone should understand the same thing. It also helps you choose tests deliberately instead of testing a little of everything.
This guide is based on the ISTQB Foundation Level syllabus (v4.0), the standard behind most training courses and interviews. It is the second part of the “Testing from scratch” series.
Error, defect, failure
Three words that all mean “bug” in everyday speech, but describe three different things in testing:
- Error (mistake): a person does something wrong, e.g. a developer misunderstands the discount rule.
- Defect: the result of the error, written into the code, the requirements or the documentation.
- Failure: the moment the defect shows up while the system runs, e.g. a customer pays the full price despite a discount code.
The distinction matters in practice. Dynamic testing (running the application) finds failures, and the cause, the defect, still has to be found. A requirements review can find a defect before anyone writes code.
The 7 testing principles in practice
| principle | what it means at work |
|---|---|
| Testing shows the presence, not the absence of defects | “I found no bugs” is not the same as “there are no bugs”. Report what you checked. |
| Exhaustive testing is impossible | You can’t test every combination, so you choose by risk. |
| Early testing saves time and money | A question about a requirement before implementation costs a minute, a fix after release costs days. |
| Defects cluster together | Most bugs sit in a few modules. Test those more thoroughly. |
| Tests wear out | The same tests stop finding new bugs over time. Vary data and scenarios. |
| Testing is context dependent | A banking app and a brochure website need different approaches. |
| Absence-of-defects fallacy | A bug-free system that doesn’t solve the user’s problem is still useless. |
The test process
Testing is more than running tests. ISTQB defines groups of activities that overlap in practice:
- Test planning: objectives, scope, approach, schedule.
- Test monitoring and control: comparing progress with the plan and reacting to deviations.
- Test analysis: what to test, i.e. test conditions based on requirements and risk.
- Test design: how to test, i.e. test cases and the data they need.
- Test implementation: preparing the environment, data and scripts.
- Test execution: running tests, comparing results, reporting defects.
- Test completion: report, lessons learned, archiving the testware.
In a small team one person does all of this within one sprint. In a large project each activity can have its own document.
Test levels
| level | what it checks | who usually does it |
|---|---|---|
| component testing | individual functions and classes | developers |
| component integration testing | how modules work together within one system | developers, testers |
| system testing | the whole system against requirements | testers |
| system integration testing | how the system works with external systems, e.g. payments | testers |
| acceptance testing | whether the system meets user and business needs | the client, users, the product owner |
Early in their career, testers most often work at the system level and on acceptance testing.
Test types
A test type tells you which characteristic you are checking, whatever the level.
- Functional: does the system do what it should.
- Non-functional: how it does it: performance, security, usability, accessibility, compatibility.
- Black-box: based on the specification and behaviour, without looking at the code.
- White-box: based on the structure of the code, e.g. whether every branch of a condition was executed.
Then there are two kinds of testing related to change:
- Confirmation testing (retesting): has a specific defect been fixed.
- Regression testing: has the change broken something that worked before.
Regression is the best candidate for automation, because it repeats with every release. More on that in the guide to regression in CI.
Static and dynamic testing
Dynamic testing requires running the application. Static testing means checking without running it: reviewing requirements, user stories, designs and code, as well as analysis with tools.
An example from practice: a user story says “the user can cancel an order”. The review question: until when? After shipping too? The answer takes a minute, and without it the developer guesses, and the tester later reports a defect that isn’t really the developer’s mistake but a gap in the requirement.
How to keep learning
The ISTQB Foundation Level syllabus is free and available in many languages. You don’t need to learn it by heart, but it is worth reading once in full and coming back to chapters when you hit a specific problem. You can test the vocabulary from this guide in practice with 50 QA tester interview questions.
The next part of the series shows how to turn this theory into concrete test cases.
The “Testing from scratch” series
- What does a software tester do, and how to get started
- Testing theory in a nutshell (this guide)
- How to write a test case
- How to report defects
- API testing basics
- First steps in test automation