Welcome
In short: Verification asks "did we build it right", validation asks "did we build the right thing". The course teaches both, with requirements, stories, examples and tests on one shop.
Problem
Built exactly to the requirement. And still wrong
The shop owner writes in the brief: "Free delivery over 50 €". The developer builds exactly that: an order of 50.00 € pays 4.90 € for delivery, and 50.01 € gets it free. The tester checks 50.00 € against what is written. Everything matches.
The ad goes out: "Free delivery from 50 €". The first customers with a cart of exactly 50 € send angry emails. The owner meant "from 50 €" and wrote "over".
The program did nothing wrong. The requirement was wrong, and nobody saw it, because everybody checked against it.
The idea
Two questions
The story holds two separate questions:
- Did we build it right? Does the program do what the requirement says? That is verification. In the story it passed.
- Did we build the right thing? Is the requirement what the client really wants? That is validation. In the story nobody did it.
The two get mixed up because both sound like "checking". The difference is the yardstick: for verification it is what is written, for validation it is the real need.
The opposite case happens too. The requirement says "from 50 €" and the program does "over 50 €". Then the requirement is right and the program does not meet it. Verification catches that.
More precisely, if you are curious
The ISTQB glossary takes the definitions from ISO 9000. Verification: confirmation by examination and through objective evidence that specified requirements have been fulfilled. Validation: the same, for the requirements of a specific intended use, that is, whether the product does the job it was asked for.
IEEE 1012 (the V&V standard, latest edition from 2024) sets both out as activities across the whole life of a system, not only at the end. It also brings in the integrity level: the heavier the consequences of a failure, the more and the stricter the checking. The shop is a low level. The software of a medical device is high, and there it goes as far as formal verification: a mathematical proof that the model of the system cannot reach a forbidden state. We will not go that far here.
The idea
The example catches both
How could the mistake have been caught in time? With one question, before any code: "And at exactly 50.00 €?"
A concrete example brings the two checks together. The owner answers "free, of course", and the requirement is fixed (validation). Then the same example becomes a test that checks the program (verification).
This is how the example will look in the scenarios module. The language is called Gherkin and it reads like a sentence:
Feature: Free delivery
Scenario: An order of exactly 50 € Given a cart of 50.00 € When I place the order Then delivery is 0.00 €That is why the course keeps business analysis and testing together: the requirement and the test meet in the example. The rule we work with from here on is the fixed one: delivery is free for an order from 50 € inclusive, otherwise it is 4.90 €.
Try it
Which of the two?
The idea
Who does what
Four roles stand around one requirement. In a small team one person may hold two of them, but their questions are different.
- The product owner decides what gets built and in what order. They are responsible for value: why this and not something else.
- The business analyst works out what is really needed. They ask, listen to the stakeholders, and write the requirements, the stories and the examples. Their question is "what problem are we solving".
- The developer builds the solution. Their question is "how".
- QA (quality assurance) checks, and not only at the end. A good tester asks "and at exactly 50 €?" while the requirement is still being written.
Validation is mostly the work of the analyst and the owner, verification of QA and the developer. The line is not a wall: in the delivery story the tester would have saved validation with one question.
More precisely, if you are curious
ISTQB separates quality assurance from testing. Assurance is about the process: how we work so that defects do not appear (reviews, standards, training). Testing is about the product: it finds the defects that are there anyway, and it is a kind of quality control. At work "QA" often means "tester". The course teaches both.
The idea
The path of the course
The course follows the path of one request, from the talk with the client to release:
- Welcome: validation and verification, why programs fail, what quality is.
- Requirements: whom to ask, how to ask, the kinds of requirements and what makes one good.
- Stories and acceptance criteria: "As a … I want … so that …", splitting big stories, rules and examples.
- Scenarios in Gherkin: Given, When, Then; scenarios the business reads.
- Traceability: which requirement is covered by what, and what changes when a requirement changes.
- Static testing: a defect found in the text, before there is a program.
- Test design techniques: partitions, boundaries, decision tables, states. Why 49.99 €, 50.00 € and 50.01 € are three different tests, and 30 € and 40 € are one.
- Levels, types and process: from the test of one component to acceptance, the plan, risk and the defect report.
- Non-functional: usability, performance and security as requirements you measure.
- Automation: scenarios become tests that run on their own.
- Validating with the client: acceptance testing and measuring after release.
- Project: promo codes from the request to release.
Tasks are checked straight away. Later you will write scenarios and test cases that run against the correct shop and against versions with real bugs.
The idea
The course and the certifications
The course is aligned with the syllabi of the largest institutions in the field and covers their topics. It is not accredited by any of them and does not award a certificate. If you are preparing for an exam, this table tells you where each topic is. It is a guide, not a promise about the exam.
| Programme | What it is | Modules |
|---|---|---|
| ISTQB CTFL v4.0.1 | the foundation level for testers | 0, 2, 3, 4, 5, 6, 7, 9 |
| ISTQB CT-AcT v1.0 | acceptance testing | 2, 3, 8, 10 |
| IIBA BABOK Guide v3 | business analysis | 1, 2, 4, 5, 10 |
| IREB CPRE Foundation Level 3.3.0 | requirements engineering | 0, 1, 2, 4 |
| ISO/IEC 25010:2023 | the quality model | 0, 8 |
| IEEE 1012-2024 | the V&V framework | 0 |
The idea
What you need to know
You do not need programming. Almost the whole course is in the language of requirements: sentences, examples, tables and scenarios.
The exception is the Automation module. There scenarios become code, and you need one of the languages on the site up to the module "Real-world programs", where the component tests are. The course map says so at the module.
The shop is the same as in the other courses, in euros: products, cart, promo codes, orders, delivery and returns. Its rules are real, and people get them wrong.
Test