Software Testing und Test Management nach ISTQB - International Software Testing Qualifications Board

Warum gutes Testen mehr ist als „Fehler finden“

Software wird heute in nahezu allen Produkten und Geschäftsprozessen eingesetzt. Gleichzeitig steigen die Anforderungen an Qualität, Sicherheit, Verfügbarkeit und Zuverlässigkeit.

Trotzdem wird Software Testing in vielen Projekten noch immer auf eine einfache Frage reduziert:

„Funktioniert die Software?“

Das reicht längst nicht mehr aus.

Die entscheidenden Fragen lauten vielmehr:

• Erfüllt die Software die definierten Anforderungen?
• Erfüllt sie die Erwartungen der Benutzer und Stakeholder?
• Ist sie unter realistischen Bedingungen zuverlässig?
• Ist sie ausreichend performant?
• Ist sie sicher?
• Was passiert bei Fehlbedienung oder ungewöhnlichen Eingaben?
• Wie verhält sie sich unter hoher Last?
• Was passiert nach Änderungen?
• Können wir objektiv nachweisen, dass die Anforderungen erfüllt sind?
• Und vor allem: Woher wissen wir, dass wir ausreichend getestet haben?

Genau hier setzt das International Software Testing Qualifications Board (ISTQB) an.

Der aktuelle ISTQB Certified Tester Foundation Level (CTFL) v4.0 vermittelt eine gemeinsame Terminologie und ein systematisches Verständnis von Software Testing. Der Ansatz ist dabei ausdrücklich unabhängig vom verwendeten Softwareentwicklungsmodell und kann beispielsweise in klassischen, agilen, DevOps- und Continuous-Delivery-Umgebungen eingesetzt werden.

1. Was bedeutet Software Testing eigentlich?

Testing ist wesentlich mehr als das Ausführen von Testfällen.

Aus Sicht des ISTQB umfasst Software Testing eine Reihe von Aktivitäten, die dazu dienen, Qualität zu bewerten und Fehler bzw. Defekte zu erkennen.

Dabei geht es nicht nur um die Frage:

„Gibt es Fehler?“

Sondern auch um:

„Welche Risiken bestehen, welche Qualitätsmerkmale sind relevant und welche Informationen benötigen wir für eine fundierte Entscheidung?“

Testing liefert damit Informationen für Entscheidungen.

Zum Beispiel:

• Kann eine Version freigegeben werden?
• Sind bestimmte Anforderungen erfüllt?
• Welche Risiken bestehen noch?
• Welche Defekte sind offen?
• Ist die Testabdeckung ausreichend?
• Welche Bereiche müssen weiter untersucht werden?

Damit wird Testing zu einem wichtigen Bestandteil des Qualitätsmanagements.

2. Testen ist nicht dasselbe wie Debugging

Ein wichtiger Unterschied:

Testing

Testing versucht, Fehler bzw. Defekte sichtbar zu machen und Informationen über die Qualität des Systems zu gewinnen.

Debugging

Debugging ist die Tätigkeit, mit der Entwickler die Ursache eines beobachteten Fehlverhaltens analysieren und beseitigen.

Vereinfacht:

Tester:
„Das System liefert bei dieser Eingabe ein falsches Ergebnis.“

Entwickler:
„Ich analysiere, warum das passiert und korrigiere die Ursache.“

Danach beginnt erneut der Test.

Diese Trennung ist wichtig, weil Testing nicht automatisch bedeutet, dass der Tester auch die Fehlerursache beheben muss.

3. Die sieben grundlegenden Testprinzipien

Die Testprinzipien gehören zu den wichtigsten Grundlagen des ISTQB.

Sie erklären, warum Testing anders funktioniert als viele andere Prüfprozesse.

Prinzip 1: Testing zeigt das Vorhandensein von Defekten

Der vielleicht wichtigste Grundsatz lautet:

Testing kann zeigen, dass Defekte vorhanden sind – es kann nicht beweisen, dass keine Defekte vorhanden sind.

Wenn ein Test einen Fehler findet, wissen wir:

Mindestens ein Defekt existiert.

Wenn 10.000 Tests erfolgreich sind, wissen wir dagegen nicht:

Es gibt keine weiteren Defekte.

Das ist ein fundamentaler Unterschied.

Ein erfolgreicher Test bedeutet:

Unter den geprüften Bedingungen wurde kein Fehlverhalten beobachtet.

Nicht:

Die Software ist fehlerfrei.

4. Prinzip 2: Vollständiges Testen ist unmöglich

Ein System kann eine nahezu unendliche Anzahl möglicher:

• Eingaben,
• Benutzerzustände,
• Datenkombinationen,
• Systemzustände,
• Schnittstellenzustände,
• Konfigurationen

besitzen.

Alle Kombinationen zu testen ist in der Praxis normalerweise unmöglich.

Deshalb muss Testing risikoorientiert priorisiert werden.

Beispiel:

Ein Online-Shop besitzt 50 Eingabefelder.

Man könnte versuchen, alle möglichen Kombinationen zu testen.

Das wäre praktisch nicht machbar.

Stattdessen konzentriert man sich beispielsweise auf:

• kritische Geschäftsfunktionen,
• Grenzwerte,
• häufige Nutzung,
• sicherheitsrelevante Funktionen,
• finanzielle Transaktionen,
• bekannte Fehlerbereiche,
• besonders komplexe Funktionen.

Damit wird aus:

„Wir testen alles.“

die realistische Aussage:

„Wir testen gezielt dort, wo Fehler die größten Auswirkungen haben oder besonders wahrscheinlich sind.“

5. Prinzip 3: Frühes Testen spart Zeit und Geld

Fehler werden teurer, je später sie entdeckt werden.

Ein Missverständnis in einer Anforderung kann beispielsweise entstehen, bevor überhaupt eine Zeile Code geschrieben wurde.

Wenn dieser Fehler bereits beim Requirements Review entdeckt wird, ist die Korrektur vergleichsweise einfach.

Wird derselbe Fehler erst nach:

• Architektur,
• Entwicklung,
• Integration,
• Systemtest

entdeckt, können erhebliche Nacharbeiten entstehen.

Deshalb gehört Testing nicht ans Ende des Projekts.

Testing beginnt bereits bei:

Anforderungen → Architektur → Design → Implementierung → Integration → System → Abnahme

Das wird häufig als Shift Left bezeichnet.

Dabei bedeutet Shift Left nicht lediglich:

„Tester sollen früher testen.“

Vielmehr geht es darum, Qualität und Testbarkeit bereits früh in den Entwicklungsprozess einzubauen.

6. Prinzip 4: Fehler treten häufig gehäuft auf

Defekte verteilen sich nicht unbedingt gleichmäßig über ein System.

Häufig konzentrieren sich viele Defekte auf relativ wenige Komponenten oder Bereiche.

Mögliche Ursachen:

• hohe Komplexität
• häufige Änderungen
• schlechte Wartbarkeit
• unklare Anforderungen
• hohe technische Verschuldung
• schwierige Schnittstellen
• fehlendes Wissen
• neue Technologien

Daraus folgt eine wichtige Konsequenz:

Tester sollten ihre Aufmerksamkeit nicht gleichmäßig über das gesamte System verteilen.

Wenn ein Modul bereits mehrfach schwerwiegende Fehler gezeigt hat, kann dies ein Hinweis auf ein erhöhtes Risiko sein.

7. Prinzip 5: Wiederholte Tests verlieren ihre Wirksamkeit

Das ISTQB bezeichnet dieses Phänomen als Pesticide Paradox.

Wenn immer wieder exakt dieselben Testfälle ausgeführt werden, finden sie irgendwann möglicherweise keine neuen Fehler mehr.

Nicht unbedingt deshalb, weil das System perfekt geworden ist.

Sondern weil die Tests immer dieselben Bereiche und Zustände prüfen.

Deshalb sollten Tests regelmäßig weiterentwickelt werden.

Zum Beispiel durch:

• neue Testdaten,
• andere Eingabekombinationen,
• neue Grenzwerte,
• negative Tests,
• exploratives Testen,
• neue Testtechniken,
• neue Risiken.

Testing ist daher kein statischer Prozess.

8. Prinzip 6: Testing ist kontextabhängig

Es gibt nicht die eine richtige Testmethode.

Die richtige Vorgehensweise hängt vom Kontext ab.

Ein medizinisches Gerät benötigt andere Tests als:

• ein Computerspiel,
• eine Banking-Anwendung,
• eine interne Zeiterfassung,
• eine Steuerungssoftware,
• ein Cloud-Service.

Relevant sind beispielsweise:

• Risiko
• Branche
• regulatorische Anforderungen
• Sicherheitsbedarf
• Kritikalität
• Benutzergruppe
• Systemkomplexität
• Entwicklungsmodell
• verfügbare Ressourcen

Deshalb ist die Aussage

„Wir testen genauso wie im letzten Projekt.“

grundsätzlich kritisch zu hinterfragen.

9. Prinzip 7: Die Abwesenheit von Fehlern ist kein Qualitätsbeweis

Eine Software kann praktisch keine gefundenen Defekte aufweisen und trotzdem ungeeignet sein.

Beispielsweise kann sie:

• die falschen Anforderungen erfüllen,
• am Benutzer vorbei entwickelt worden sein,
• die falschen Geschäftsprozesse unterstützen,
• zu kompliziert sein,
• zu langsam sein,
• nicht ausreichend sicher sein.

Das ISTQB bezeichnet dies als Absence-of-Errors Fallacy.

Der entscheidende Gedanke lautet:

Eine Software ist nicht automatisch qualitativ hochwertig, nur weil wir keine Fehler gefunden haben.

Testing muss deshalb auch prüfen:

Bauen wir das richtige System?

und nicht nur:

Bauen wir das System richtig?

Damit entsteht eine direkte Verbindung zu Requirements Engineering.

10. Die Verbindung zwischen Requirements Engineering und Testing

Der Blog Artikel über Requirements Engineering führt direkt zu dieser Frage:

Wie wird aus einer Anforderung ein Test?

Beispiel:

Anforderung

Das System muss eine Standard-Suchanfrage bei bis zu 10 Millionen Datensätzen innerhalb von maximal 2 Sekunden beantworten.

Daraus können wir ableiten:

Akzeptanzkriterium

Mindestens 95 % der definierten Suchanfragen müssen innerhalb von 2 Sekunden beantwortet werden.

Testfall

Durchführung eines Performance-Tests mit 10 Millionen Datensätzen und definiertem Lastprofil.

Testergebnis

98 % der Suchanfragen ≤ 2 Sekunden.

Entscheidung

Anforderung erfüllt.

Damit entsteht eine Kette:

Anforderung → Akzeptanzkriterium → Testfall → Testergebnis → Entscheidung

Genau diese Verbindung macht Requirements Engineering und Testing zu zwei Seiten desselben Qualitätsprozesses.

11. Testlevels nach ISTQB

ISTQB unterscheidet Testlevels als Gruppen von Testaktivitäten, die gemeinsam organisiert und gesteuert werden. Im CTFL v4.0 werden fünf Testlevels beschrieben.

1. Component Testing

Hier werden einzelne Komponenten bzw. Einheiten getestet.

Beispielsweise:

• einzelne Funktionen
• Klassen
• Module
• Services

Ziel ist es, Fehler möglichst früh zu erkennen.

2. Component Integration Testing

Hier wird geprüft, ob Komponenten korrekt miteinander funktionieren.

Beispiele:

• API-Aufruf
• Datenübergabe
• Service-Kommunikation
• Schnittstellen
• Datenformate

Gerade Schnittstellen sind häufig risikoreich.

3. System Testing

Hier wird das gesamte System bzw. eine vollständige Systemlösung getestet.

System Testing ist besonders wichtig, weil sich Fehler häufig erst aus dem Zusammenspiel verschiedener Komponenten ergeben.

Beispielsweise:

Benutzer → Anwendung → API → Datenbank → externer Service

Jede einzelne Komponente kann für sich funktionieren.

Das Gesamtsystem kann trotzdem fehlerhaft sein.

4. System Integration Testing

Wenn mehrere Systeme miteinander verbunden sind, muss auch deren Zusammenspiel getestet werden.

Beispiele:

• ERP ↔ CRM
• Anwendung ↔ Payment Provider
• Cloud ↔ On-Premises-System
• IoT-Gerät ↔ Cloud
• Software ↔ externe API

5. Acceptance Testing

Acceptance Testing betrachtet das System aus Sicht der vorgesehenen Nutzung bzw. Abnahme.

Die zentrale Frage lautet:

Erfüllt das System die vereinbarten Anforderungen und den vorgesehenen Zweck?

Beteiligte können beispielsweise sein:

• Kunde
• Fachbereich
• Benutzer
• Product Owner
• Betreiber

12. Testlevels sind nicht dasselbe wie Testarten

Eine häufige Verwechslung:

Testlevel beschreibt:

Wo bzw. auf welcher Systemebene testen wir?

Testart / Testtyp beschreibt:

Was untersuchen wir?

Beispielsweise kann ein Systemtest gleichzeitig sein:

• funktionaler Test
• Performance-Test
• Security-Test
• Usability-Test
• Reliability-Test

ISTQB unterscheidet Testlevels und Testtypes ausdrücklich. Testtypes beziehen sich auf bestimmte Qualitätsmerkmale und können grundsätzlich auf verschiedenen Testlevels eingesetzt werden.

13. Funktionales Testing

Funktionales Testing untersucht, ob das System die erwarteten Funktionen korrekt ausführt.

Beispiele:

• Login
• Bestellung
• Rechnungserstellung
• Suche
• Datenimport
• Datenexport
• Benutzerverwaltung

Die Frage lautet:

Tut das System das Richtige?

14. Nichtfunktionales Testing

Nichtfunktionales Testing untersucht Qualitätsmerkmale.

Dazu gehören beispielsweise:

• Performance
• Sicherheit
• Usability
• Zuverlässigkeit
• Kompatibilität
• Wartbarkeit
• Skalierbarkeit

Beispiel:

Funktional:

„Der Benutzer kann einen Auftrag speichern.“

Nichtfunktional:

„Der Auftrag muss innerhalb von maximal 2 Sekunden gespeichert werden.“

Oder:

„Nur berechtigte Benutzer dürfen den Auftrag ändern.“

Damit wird deutlich:

Funktionale Anforderungen und Qualitätsanforderungen benötigen unterschiedliche Testperspektiven.

15. Black-Box- und White-Box-Testing

Eine weitere wichtige Unterscheidung betrifft den Blickwinkel.

Black Box

Der Tester betrachtet das System von außen.

Er kennt möglicherweise nicht die interne Implementierung.

Er prüft beispielsweise:

Eingabe → System → Ergebnis

Typische Techniken:

• Äquivalenzklassen
• Grenzwertanalyse
• Entscheidungstabellen
• Zustandsübergangstests
• Use-Case-Tests

White Box

Hier wird die interne Struktur berücksichtigt.

Beispielsweise:

• Code
• Kontrollfluss
• Bedingungen
• Pfade
• Anweisungen

White-Box-Techniken können insbesondere für Entwickler und technische Tester relevant sein.

16. Testen beginnt nicht erst mit Testfällen

Ein professioneller Testprozess beginnt wesentlich früher.

Ein typischer Ablauf ist:

·      Testplanung

·      Testanalyse

·      Testentwurf

·      Testimplementierung

·      Testausführung

·      Bewertung

·      Testabschluss

·     

Dabei werden beispielsweise folgende Fragen beantwortet:

• Was soll getestet werden?
• Warum?
• Mit welchem Risiko?
• Welche Testbedingungen gibt es?
• Welche Testdaten benötigen wir?
• Welche Testumgebung ist erforderlich?
• Welche Testfälle werden benötigt?
• Welche Ergebnisse erwarten wir?
• Wann gilt der Test als erfolgreich?
• Wann darf der Test abgeschlossen werden?

17. Test Management

Test Management sorgt dafür, dass Testing nicht zu einer Ansammlung einzelner Testfälle wird.

Das ISTQB CTFL v4.0 behandelt ausdrücklich:

• Testplanung
• Risikomanagement
• Testmonitoring
• Teststeuerung
• Testabschluss.

Ein Testmanager bzw. Testverantwortlicher muss beispielsweise entscheiden:

Was wird getestet?

Testumfang und Testobjekte.

Wie wird getestet?

Teststrategie und Testansatz.

Mit welchem Risiko?

Priorisierung nach Produkt- und Projektrisiken.

Wer testet?

Rollen und Verantwortlichkeiten.

Wann?

Zeitplanung und Abhängigkeiten.

Womit?

Testumgebung, Tools und Testdaten.

Wann sind wir fertig?

Exit-Kriterien.

18. Risikobasiertes Testing

Ein besonders wichtiger Grundsatz lautet:

Nicht jede Funktion verdient denselben Testaufwand.

Beispiel:

Eine Software besitzt:

• eine selten verwendete Hilfefunktion,
• eine Zahlungsfunktion,
• eine Benutzerverwaltung,
• eine Datenlöschfunktion.

Es wäre kaum sinnvoll, allen vier Bereichen exakt denselben Testaufwand zuzuweisen.

Bei der Priorisierung können beispielsweise betrachtet werden:

Wahrscheinlichkeit × Auswirkung

Zusätzlich können berücksichtigt werden:

• Sicherheitsrisiko
• regulatorisches Risiko
• wirtschaftlicher Schaden
• Benutzeranzahl
• Komplexität
• Änderungsumfang
• bisherige Defekte

Damit wird Testing zu einer risikoorientierten Qualitätsmaßnahme.

19. Testfälle müssen nicht nur „happy path“ prüfen

Ein häufiger Fehler in Softwareprojekten:

Es wird hauptsächlich der erwartete Normalfall getestet.

Beispiel:

Benutzer gibt korrekte Zugangsdaten ein → Login erfolgreich.

Aber was passiert bei:

• falschem Passwort?
• leerem Passwort?
• gesperrtem Benutzer?
• abgelaufener Session?
• manipuliertem Request?
• fehlendem Netzwerk?
• überlastetem System?

Gutes Testing untersucht deshalb auch:

Was passiert, wenn etwas nicht so läuft wie vorgesehen?

Gerade hier treffen sich Software Testing und Informationssicherheit.

20. Testdesign: Wie entstehen gute Testfälle?

ISTQB behandelt verschiedene Testtechniken.

Besonders bekannt sind:

Äquivalenzklassen

Eingaben werden in Klassen aufgeteilt, die sich hinsichtlich ihres erwarteten Verhaltens ähnlich verhalten.

Grenzwertanalyse

Besonders interessant sind die Grenzen.

Beispiel:

Zulässiger Wert: 1–100

Dann sind beispielsweise besonders relevant:

• 0
• 1
• 2
• 99
• 100
• 101

Entscheidungstabellen

Geeignet für komplexe Kombinationen von Bedingungen.

Zustandsübergangstests

Geeignet, wenn sich das Verhalten abhängig vom aktuellen Zustand verändert.

Use-Case-Testing

Testen aus Sicht konkreter Anwendungsszenarien.

Erfahrungsbasierte Verfahren

Beispielsweise:

• Error Guessing
• Exploratory Testing

Die Auswahl der Technik sollte zum Risiko und zum Testziel passen.

21. System Testing: Die Realität entscheidet

System Testing ist besonders interessant, weil hier das Zusammenspiel des Systems sichtbar wird.

Ein System kann aus einzelnen Komponenten bestehen, die jeweils erfolgreich getestet wurden:

Komponente A – OK

Komponente B – OK

Komponente C – OK

Trotzdem kann gelten:

Gesamtsystem – NICHT OK

Warum?

Weil beispielsweise:

• Schnittstellen nicht zusammenpassen,
• Datenformate unterschiedlich interpretiert werden,
• Timing-Probleme auftreten,
• Berechtigungen falsch zusammenspielen,
• Fehlerzustände nicht korrekt behandelt werden.

Deshalb ist System Testing keine einfache Addition von Component Tests.

22. Regression Testing

Eine Änderung kann funktionieren und trotzdem bestehende Funktionen beschädigen.

Beispiel:

Ein Entwickler ändert die Benutzerverwaltung.

Der Login funktioniert weiterhin.

Aber plötzlich funktioniert der Export nicht mehr.

Deshalb muss nach Änderungen geprüft werden:

Was könnte durch diese Änderung unbeabsichtigt beeinflusst worden sein?

Regression Testing ist deshalb ein wesentlicher Bestandteil eines kontrollierten Änderungsprozesses.

Besonders relevant ist dies bei:

• Releases
• Patches
• Security Updates
• Refactoring
• Architekturänderungen
• Datenbankänderungen
• API-Änderungen

23. Testautomatisierung ist kein Ersatz für Testmanagement

„Wir haben 10.000 automatisierte Tests.“

Das klingt zunächst beeindruckend.

Aber die Anzahl der Tests sagt allein wenig über die Testqualität aus.

Entscheidend ist:

• Was wird getestet?
• Welche Risiken werden abgedeckt?
• Sind die Tests aktuell?
• Sind die erwarteten Ergebnisse korrekt?
• Werden kritische Randbedingungen geprüft?
• Welche Anforderungen sind abgedeckt?
• Welche Tests schlagen tatsächlich fehl, wenn etwas kaputtgeht?

Ein automatisierter Test kann sehr effizient sein.

Er kann aber auch sehr effizient das Falsche testen.

Deshalb gilt:

Automatisierung verbessert die Effizienz des Testens – sie ersetzt nicht die Teststrategie.

24. Testbarkeit beginnt bereits bei den Anforderungen

Hier schließt sich der Kreis zum Requirements Engineering.

Eine gute Anforderung sollte testbar sein.

Beispiel:

„Das System muss benutzerfreundlich sein.“

Wie testen wir das?

Schwierig.

Besser:

„Ein Benutzer mit definierter Vorerfahrung muss einen Standardauftrag innerhalb von maximal fünf Minuten ohne Unterstützung erfassen können.“

Jetzt können wir einen Test entwerfen.

Damit entsteht:

·      Gute Anforderung

·      Gutes Akzeptanzkriterium

·      Guter Testfall

·      Objektiver Nachweis

·     

Die Qualität des Tests hängt deshalb bereits von der Qualität der Anforderungen ab.

25. Testing und Security Testing

Bei modernen Softwareprodukten darf Informationssicherheit nicht als separates Thema betrachtet werden.

Security Testing kann beispielsweise untersuchen:

• Authentifizierung
• Autorisierung
• Session Management
• Eingabevalidierung
• Verschlüsselung
• Logging
• Fehlerbehandlung
• Schnittstellen
• Schwachstellen
• Konfiguration
• Berechtigungen

Besonders wichtig:

Security Testing darf nicht erst kurz vor dem Release beginnen.

Sicherheitsanforderungen müssen bereits bei der Anforderungsanalyse berücksichtigt werden.

Danach folgen:

Security Requirement → Security Design → Secure Implementation → Security Test → Nachweis

26. Testing und Cyber Resilience

Für Software und Produkte mit digitalen Elementen wird Testing auch aus regulatorischer Sicht immer wichtiger.

Beispielsweise müssen bei sicherheitsrelevanten Produkten nicht nur Funktionen nachgewiesen werden.

Es geht auch um:

• Cybersecurity-Anforderungen
• Schwachstellen
• sichere Updates
• Schutzmechanismen
• technische Dokumentation
• Nachweise

Damit entsteht eine Verbindung zwischen:

Requirements Engineering

Software Testing

Security Testing

Vulnerability Management

Compliance

Testing ist damit nicht nur eine technische Entwicklungsaktivität.

Es wird Teil der Nachweisführung über die Qualität und Sicherheit eines Produkts.

27. Testmanagement und Qualitätssicherung

Testen und Qualitätssicherung sind nicht identisch.

Testing ist eine wichtige Qualitätsbewertungsaktivität.

Quality Assurance geht darüber hinaus.

Sie fragt beispielsweise:

Sind unsere Prozesse geeignet, um systematisch gute Software zu entwickeln?

Beispiele:

• Sind Anforderungen klar definiert?
• Werden Reviews durchgeführt?
• Gibt es definierte Testprozesse?
• Werden Testergebnisse dokumentiert?
• Werden Defekte analysiert?
• Werden Ursachen betrachtet?
• Werden Prozesse verbessert?

Testing liefert also Informationen über das Produkt.

Quality Assurance betrachtet zusätzlich die Prozesse, die dieses Produkt hervorbringen.

28. Defect Management

Ein gefundenes Problem ist noch kein gelöster Fehler.

Ein professioneller Defect-Prozess sollte beispielsweise enthalten:

·      Defect entdeckt

·      Dokumentation

·      Klassifikation

·      Priorisierung

·      Analyse

·      Korrektur

·      Retest

·      Regressionstest

·      Abschluss

Dabei sollten zumindest folgende Informationen nachvollziehbar sein:

• Was ist passiert?
• Unter welchen Bedingungen?
• Wie lässt sich der Fehler reproduzieren?
• Welche Version ist betroffen?
• Welche Auswirkungen hat der Fehler?
• Wie kritisch ist er?
• Wer ist verantwortlich?
• Wie wurde er behoben?
• Wurde die Korrektur getestet?

29. Testabschluss bedeutet nicht einfach „alle Tests sind grün“

Auch das ist ein wichtiger Punkt.

Ein Projekt kann beispielsweise 98 % erfolgreiche Tests haben.

Die entscheidende Frage lautet:

Welche 2 % sind fehlgeschlagen?

Wenn darunter ein kritischer Security Test ist, kann das wesentlich relevanter sein als 500 erfolgreiche Tests einer unwichtigen Funktion.

Deshalb braucht Test Management definierte Exit-Kriterien.

Zum Beispiel:

• alle kritischen Tests erfolgreich,
• keine offenen kritischen Defekte,
• definierte Testabdeckung erreicht,
• Security Tests abgeschlossen,
• Performance-Ziele erreicht,
• Akzeptanzkriterien erfüllt.

Die konkreten Kriterien müssen natürlich zum Projekt und Risiko passen.

30. Welche Testmetriken sind sinnvoll?

Metriken können helfen, den Testfortschritt zu steuern.

Beispiele:

• Anzahl geplanter Testfälle
• ausgeführte Testfälle
• erfolgreiche Tests
• fehlgeschlagene Tests
• offene Defekte
• Defekte nach Kritikalität
• Defekttrend
• Testabdeckung
• Anforderungsabdeckung
• Regressionsergebnisse
• Automatisierungsgrad

Aber auch hier gilt:

Eine Metrik ist kein Qualitätsbeweis.

Ein hoher Automatisierungsgrad bedeutet beispielsweise nicht automatisch hohe Qualität.

Metriken müssen immer im Kontext interpretiert werden.

31. Unabhängigkeit beim Testen

ISTQB berücksichtigt auch die Frage der Unabhängigkeit.

Je nach Situation kann es sinnvoll sein, dass Tests von Personen durchgeführt werden, die nicht selbst für die Entwicklung des getesteten Ergebnisses verantwortlich waren.

Dabei geht es nicht darum, Entwicklern das Testen zu verbieten.

Im Gegenteil:

Entwickler sollten selbstverständlich testen.

Aber eine zusätzliche unabhängige Perspektive kann wertvoll sein.

Insbesondere bei:

• kritischen Systemen
• regulierten Produkten
• sicherheitsrelevanten Funktionen
• Abnahmetests
• unabhängigen Reviews

kann eine gewisse Unabhängigkeit die Wahrscheinlichkeit erhöhen, dass andere Fehlerarten erkannt werden.

32. Der „Whole Team“-Gedanke

ISTQB CTFL 4.0 legt einen starken Schwerpunkt auf Zusammenarbeit und ein gemeinsames Qualitätsverständnis.

Testing ist nicht mehr ausschließlich:

„Aufgabe des Testers.“

Qualität betrifft das gesamte Team.

Dazu gehören beispielsweise:

• Product Owner
• Business Analyst
• Requirements Engineer
• Entwickler
• Tester
• Security
• Operations
• Fachbereich
• Management

ISTQB beschreibt CTFL 4.0 ausdrücklich als Grundlage für ein gemeinsames Verständnis von Qualität und Testing und hebt den „whole team approach“ hervor.

Das ist besonders wichtig in agilen und DevOps-orientierten Entwicklungsmodellen.

33. Testing als Informationsgewinn

Eine interessante Perspektive auf Testing lautet:

Testing produziert Informationen.

Zum Beispiel:

• Welche Anforderungen sind erfüllt?
• Welche Risiken bestehen?
• Wo liegen Defekte?
• Welche Komponenten sind instabil?
• Welche Qualitätsziele werden erreicht?
• Welche Risiken bleiben offen?

Der Testmanager ist damit nicht nur Organisator von Testfällen.

Er unterstützt Management und Projektverantwortliche bei Entscheidungen.

Zum Beispiel:

„Kann diese Version freigegeben werden?“

Die Antwort sollte nicht allein auf einem Bauchgefühl beruhen.

Sie sollte auf nachvollziehbaren Informationen basieren.

34. Die Verbindung von Requirements Engineering und Testing

Damit lässt sich die gesamte Kette aus dem vorherigen Artikel erweitern:

·      Stakeholder-Bedürfnis

·      Anforderung

·      Qualitätsanforderung / Security Requirement

·      Risiko

·      Architektur / Design

·      Implementierung

·      Testanalyse

·      Testfall

·      Testausführung

·      Testergebnis

·      Defect / Korrektur

·      Regressionstest

·      Abnahme

·      Release

·      Betrieb

·      Änderung

·      erneutes Testing

Das ist der eigentliche Lebenszyklus einer Anforderung.

35. Was sollte ein guter Testnachweis enthalten?

Für einen nachvollziehbaren Nachweis sollten beispielsweise folgende Informationen vorhanden sein:

Element  - Frage

• Test-ID   - Welcher Test ist gemeint?
• Anforderung- Was soll nachgewiesen werden?
• Testziel -Was soll geprüft werden?
• Testbedingungen -Unter welchen Bedingungen?
• Testdaten -Mit welchen Daten?
• Testumgebung -Wo wurde getestet?
• Testschritte -Was wurde durchgeführt?
• Erwartetes Ergebnis -Was sollte passieren?
• Tatsächliches Ergebnis -Was ist passiert?
• Status -Passed / Failed etc.
• Defect - Gibt es eine Abweichung?
• Tester - Wer hat getestet?
• Datum- Wann wurde getestet?
• Version- Welche Softwareversion?

Damit wird aus: „Wir haben getestet.“ ein belastbarer Nachweis:

„Wir haben diese Anforderung unter definierten Bedingungen mit diesem Test geprüft und dieses Ergebnis erhalten.“

36. Was bedeutet „ausreichend getestet“?

Eine der schwierigsten Fragen im Testmanagement.

Die Antwort lautet:

Nicht alle möglichen Fälle wurden getestet – sondern die definierten Testziele und risikobasierten Kriterien wurden ausreichend erfüllt.

Dafür braucht ein Projekt beispielsweise:

• Teststrategie
• Risikobewertung
• Testziele
• Testumfang
• Testkriterien
• Exit-Kriterien
• Testmetriken
• dokumentierte Testergebnisse

Die Aussage

„Wir haben keine Zeit mehr, aber die Tests sehen gut aus.“

ist dagegen kein belastbares Testabschlusskriterium.

37. Die zehn wichtigsten Prinzipien für die Praxis

Aus dem ISTQB-Ansatz lassen sich für die Praxis zehn besonders wichtige Regeln ableiten:

1. Testen beginnt früh.

Nicht erst nach der Entwicklung.

2. Anforderungen müssen testbar sein.

Unklare Anforderungen führen zu unklaren Tests.

3. Testen ist risikobasiert.

Nicht alles ist gleich wichtig.

4. Testen kann Fehler finden, aber Fehlerfreiheit nicht beweisen.

5. Tests müssen weiterentwickelt werden.

Immer dieselben Tests reichen nicht.

6. Normalfälle reichen nicht.

Grenzwerte, Fehlerfälle und Missbrauchsszenarien sind wichtig.

7. Systemtests testen das Zusammenspiel.

Nicht nur einzelne Komponenten.

8. Änderungen erfordern Regressionstests.

Ein Fix kann neue Fehler verursachen.

9. Testmanagement braucht klare Kriterien.

Wann beginnen wir? Was testen wir? Wann sind wir fertig?

10. Qualität ist Teamarbeit.

Testing ist keine isolierte Tätigkeit.

38. Die wichtigste Verbindung zu gutem Requirements Engineering

Der vielleicht wichtigste gemeinsame Nenner von IREB und ISTQB lautet:

Eine Anforderung sollte so beschrieben sein, dass ihre Erfüllung überprüft werden kann.

IREB hilft dabei, Anforderungen:

• eindeutig,
• verständlich,
• vollständig,
• notwendig,
• angemessen und
• verifizierbar

zu formulieren.

ISTQB zeigt anschließend, wie daraus:

• Testbedingungen,
• Testfälle,
• Testdaten,
• Testverfahren und
• Testnachweise

entstehen können.

Damit ergänzen sich beide Ansätze hervorragend.

39. Ein praktisches Gesamtbild

Man kann Requirements Engineering und Testing auf eine gemeinsame Kette reduzieren:

IREB

·      Was brauchen wir?

·      Warum brauchen wir es?

·      Wie formulieren wir es eindeutig?

·      Woran erkennen wir die Erfüllung?

ISTQB

·      Wie prüfen wir die Erfüllung?

·      Welche Risiken müssen wir berücksichtigen?

·      Welche Testfälle benötigen wir?

·      Was ist das Testergebnis?

·      Welche Entscheidung treffen wir?

Das Ergebnis ist:

Anforderung → Test → Nachweis → Entscheidung

Und genau diese Verbindung ist eine der wichtigsten Grundlagen für belastbare Softwarequalität.

40. Fazit

Software Testing nach ISTQB ist weit mehr als das Suchen nach Fehlern.

Es ist ein systematischer Prozess zur Bewertung von Qualität, zur Reduzierung von Risiken und zur Gewinnung belastbarer Informationen über ein System.

Die sieben Testprinzipien zeigen dabei sehr deutlich die Grenzen und Möglichkeiten des Testens:

Testing findet Defekte – es beweist keine Fehlerfreiheit.

Vollständiges Testen ist nicht möglich – deshalb muss risikobasiert priorisiert werden.

Frühes Testen reduziert spätere Kosten.

Fehler konzentrieren sich häufig auf bestimmte Bereiche.

Tests müssen weiterentwickelt werden.

Testing muss zum Kontext passen.

Und ein fehlerfreies Testergebnis bedeutet noch nicht, dass das richtige Produkt gebaut wurde.

Der aktuelle ISTQB CTFL v4.0 verbindet diese Grundlagen mit Testlevels, Testarten, Testtechniken, Testmanagement, Risikomanagement, Monitoring und Testabschluss.

Für die Praxis ergibt sich daraus eine einfache, aber wirkungsvolle Kette:

Gute Anforderungen → gute Testbarkeit → risikoorientiertes Testing → belastbare Testergebnisse → fundierte Freigabeentscheidung.

Und genau deshalb beginnt gutes Software Testing nicht erst beim ersten Testfall.

Es beginnt bei der Anforderung.

Ihr Konstantin Ziouras