Willkommen
Kurz gesagt: Die Verifizierung fragt „Haben wir es richtig gebaut?“, die Validierung fragt „Haben wir das Richtige gebaut?“. Der Kurs lehrt beides, mit Anforderungen, Stories, Beispielen und Tests an einem Shop.
Problem
Genau nach der Anforderung gebaut. Und trotzdem falsch
Der Shop-Inhaber schreibt in die Aufgabenstellung: „Kostenlose Lieferung über 50 €“. Der Entwickler baut genau das: Eine Bestellung über 50,00 € zahlt 4,90 € Lieferkosten, und bei 50,01 € ist die Lieferung kostenlos. Der Tester prüft 50,00 € gegen das Geschriebene. Alles stimmt überein.
Die Werbung geht raus: „Kostenlose Lieferung ab 50 €“. Die ersten Kunden mit einem Warenkorb von genau 50 € schreiben wütende E-Mails. Der Inhaber hat „ab 50 €“ gemeint und „über“ geschrieben.
Das Programm hat nichts falsch gemacht. Falsch war die Anforderung, und niemand hat es gesehen, weil alle gegen sie geprüft haben.
Die Idee
Zwei Fragen
Die Geschichte enthält zwei getrennte Fragen:
- Haben wir es richtig gebaut? Tut das Programm, was in der Anforderung steht? Das ist Verifizierung (verification). In der Geschichte hat sie bestanden.
- Haben wir das Richtige gebaut? Ist die Anforderung das, was der Kunde wirklich will? Das ist Validierung (validation). In der Geschichte hat sie niemand gemacht.
Die beiden werden verwechselt, weil beide wie „prüfen“ klingen. Der Unterschied liegt im Maßstab: Bei der Verifizierung ist es das Geschriebene, bei der Validierung der tatsächliche Bedarf.
Der umgekehrte Fall kommt auch vor. Die Anforderung sagt „ab 50 €“, und das Programm macht „über 50 €“. Dann ist die Anforderung richtig, und das Programm erfüllt sie nicht. Das fängt die Verifizierung ab.
Genauer, für Neugierige
Das ISTQB-Glossar übernimmt die Definitionen aus ISO 9000. Verifizierung: Bestätigung durch Untersuchung und objektive Nachweise, dass festgelegte Anforderungen erfüllt wurden. Validierung: dasselbe, aber für die Anforderungen an einen bestimmten Verwendungszweck, also ob das Produkt die Aufgabe erfüllt, für die es bestellt wurde.
IEEE 1012 (der Standard für V&V, jüngste Ausgabe von 2024) ordnet beides als Tätigkeiten über die gesamte Lebensdauer eines Systems ein, nicht nur am Ende. Er führt auch die Integritätsstufe (integrity level) ein: Je schwerer die Folgen eines Ausfalls, desto mehr und desto strenger wird geprüft. Der Shop ist eine niedrige Stufe. Die Software eines Medizinprodukts ist eine hohe, und dort geht es bis zur formalen Verifizierung: einem mathematischen Beweis, dass das Modell des Systems nie in einen verbotenen Zustand geraten kann. So weit gehen wir hier nicht.
Die Idee
Das Beispiel fängt beides ab
Wie hätte man den Fehler rechtzeitig gefunden? Mit einer Frage, bevor Code geschrieben wird: „Und bei genau 50,00 €?“
Ein konkretes Beispiel bringt die beiden Prüfungen zusammen. Der Inhaber antwortet „kostenlos, natürlich“, und die Anforderung wird korrigiert (Validierung). Danach wird dasselbe Beispiel zu einem Test, der das Programm prüft (Verifizierung).
So sieht dieses Beispiel im Modul über Szenarien aus. Die Sprache heißt Gherkin und liest sich wie ein Satz:
# language: deFunktionalität: Kostenlose Lieferung
Szenario: Bestellung über genau 50 € Angenommen ein Warenkorb von 50,00 € Wenn ich bestelle Dann beträgt die Lieferung 0,00 €Deshalb hält der Kurs Business-Analyse und Testen zusammen: Die Anforderung und der Test treffen sich im Beispiel. Die Regel, mit der wir ab jetzt arbeiten, ist die korrigierte: Die Lieferung ist bei einer Bestellung ab 50 € einschließlich kostenlos, sonst kostet sie 4,90 €.
Probier es aus
Welches von beiden?
Die Idee
Wer was tut
Rund um eine Anforderung stehen vier Rollen. In einem kleinen Team kann eine Person zwei davon haben, aber ihre Fragen sind verschieden.
- Der Product Owner entscheidet, was gebaut wird und in welcher Reihenfolge. Er ist für den Wert verantwortlich: warum das und nicht etwas anderes.
- Die Business-Analystin (business analyst) findet heraus, was wirklich gebraucht wird. Sie fragt, hört den Interessengruppen zu und schreibt die Anforderungen, die Stories und die Beispiele. Ihre Frage ist „Welches Problem lösen wir?“.
- Der Entwickler baut die Lösung. Seine Frage ist „Wie?“.
- QA (quality assurance) prüft, und nicht nur am Ende. Ein guter Tester fragt „Und bei genau 50 €?“, noch während die Anforderung geschrieben wird.
Die Validierung ist vor allem die Arbeit der Analystin und des Product Owners, die Verifizierung die von QA und Entwickler. Die Grenze ist keine Mauer: In der Geschichte mit der Lieferung hätte der Tester die Validierung mit einer einzigen Frage gerettet.
Genauer, für Neugierige
ISTQB trennt die Qualitätssicherung (quality assurance) vom Testen. Die Sicherung betrifft den Prozess: wie wir arbeiten, damit Fehler gar nicht erst entstehen (Reviews, Standards, Schulungen). Das Testen betrifft das Produkt: Es findet die Fehler, die trotzdem da sind, und ist eine Art der Qualitätskontrolle (quality control). Im Beruf heißt „QA“ oft „Tester“. Der Kurs lehrt beides.
Die Idee
Der Weg durch den Kurs
Der Kurs folgt dem Weg einer Anfrage, vom Gespräch mit dem Kunden bis zur Freigabe:
- Willkommen: Validierung und Verifizierung, warum Programme versagen, was Qualität ist.
- Anforderungen: wen du fragst, wie du fragst, die Arten von Anforderungen und woran eine gute zu erkennen ist.
- Stories und Akzeptanzkriterien: „Als … möchte ich … damit …“, große Stories aufteilen, Regeln und Beispiele.
- Szenarien mit Gherkin: Angenommen, Wenn, Dann; Szenarien, die das Geschäft liest.
- Rückverfolgbarkeit: welche Anforderung wodurch abgedeckt ist und was man anfasst, wenn sich eine Anforderung ändert.
- Statisches Testen: ein Fehler, der im Text gefunden wird, bevor es ein Programm gibt.
- Testentwurfsverfahren: Klassen, Grenzen, Entscheidungstabellen, Zustände. Warum 49,99 €, 50,00 € und 50,01 € drei verschiedene Tests sind und 30 € und 40 € nur einer.
- Stufen, Arten und Prozess: vom Test einer einzelnen Komponente bis zur Abnahme, der Plan, das Risiko und der Fehlerbericht.
- Nichtfunktional: Gebrauchstauglichkeit, Leistung und Informationssicherheit als Anforderungen, die man misst.
- Automatisierung: Szenarien werden zu Tests, die von allein laufen.
- Validieren mit dem Kunden: Abnahmetest und Messen nach der Freigabe.
- Projekt: Gutscheincodes von der Anfrage bis zur Freigabe.
Die Aufgaben werden sofort geprüft. Später schreibst du Szenarien und Testfälle, die gegen den richtigen Shop und gegen Versionen mit echten Fehlern laufen.
Die Idee
Der Kurs und die Zertifizierungen
Der Kurs orientiert sich an den Lehrplänen der größten Institutionen auf dem Gebiet und deckt ihre Themen ab. Er ist von keiner von ihnen akkreditiert und vergibt kein Zertifikat. Wenn du dich auf eine Prüfung vorbereitest, sagt dir diese Tabelle, wo das Thema steht. Sie ist ein Wegweiser, kein Versprechen für die Prüfung.
| Programm | Was es ist | Module |
|---|---|---|
| ISTQB CTFL v4.0.1 | die Grundstufe für Tester | 0, 2, 3, 4, 5, 6, 7, 9 |
| ISTQB CT-AcT v1.0 | Abnahmetest | 2, 3, 8, 10 |
| IIBA BABOK Guide v3 | Business-Analyse | 1, 2, 4, 5, 10 |
| IREB CPRE Foundation Level 3.3.0 | Requirements Engineering | 0, 1, 2, 4 |
| ISO/IEC 25010:2023 | das Qualitätsmodell | 0, 8 |
| IEEE 1012-2024 | der Rahmen für V&V | 0 |
Die Begriffe stehen auf Deutsch und beim ersten Auftreten in Klammern auf Englisch, weil du ihnen im Beruf und in der Prüfung auf Englisch begegnen wirst.
Die Idee
Was du wissen musst
Programmieren brauchst du nicht. Fast der ganze Kurs ist in der Sprache der Anforderungen: Sätze, Beispiele, Tabellen und Szenarien.
Die Ausnahme ist das Modul „Automatisierung“. Dort werden Szenarien zu Code, und du brauchst eine der Sprachen der Website bis zum Modul „Programme in der echten Welt“, wo die Komponententests stehen. Die Kursübersicht sagt es beim Modul.
Der Shop ist derselbe wie in den anderen Kursen, in Euro: Produkte, Warenkorb, Gutscheincodes, Bestellungen, Lieferung und Rückgabe. Seine Regeln sind echt, und Menschen machen dabei Fehler.
Test