Testmanagement & ISTQB-Begriffe

Richtig: Komponententest → Integrationstest → Systemtest → Abnahmetest

Von klein nach groß: einzelne Bausteine, ihr Zusammenspiel, das Gesamtsystem, schließlich die Abnahme durch Fachbereich oder Kunden. In agilen Teams laufen die Stufen oft parallel, die Unterscheidung hilft trotzdem bei der Frage „Was prüfen wir wo?“.

Richtig: „Bauen wir das richtige Produkt?“ – erfüllt es den tatsächlichen Bedarf der Nutzer

Verifikation prüft gegen die Spezifikation, Validierung gegen den echten Bedarf. Ein Produkt kann perfekt verifiziert und trotzdem nutzlos sein, wenn die Spezifikation am Bedarf vorbeigeht.

Richtig: In der Anforderung, bevor eine Zeile Code geschrieben ist

Je später ein Fehler gefunden wird, desto mehr hängt schon daran: Code, Tests, Dokumentation, im schlimmsten Fall Kunden. Deshalb lohnen sich Reviews von Anforderungen und frühe Tests („Shift Left“) so sehr.

Richtig: 2 Fehler pro 1.000 Zeilen

30 / 15 = 2. Die Kennzahl hilft beim Vergleich von Modulen: Ein Modul mit auffällig hoher Dichte ist ein Kandidat für mehr Tests oder eine Überarbeitung. Allein bewertet sagt sie wenig, denn wer nicht testet, findet auch keine Fehler.

Richtig: 90 %

90 / (90 + 10) = 90 %. Die Kennzahl misst, wie wirksam der Test war. Wichtig ist, sie über mehrere Releases zu verfolgen: Ein Absinken deutet darauf hin, dass sich der Test nicht mit dem Produkt weiterentwickelt hat.

Richtig: Der Fehlernachtest prüft, ob dieser Fehler behoben ist; der Regressionstest, ob die Änderung anderswo etwas kaputt gemacht hat

Beides gehört nach jeder Korrektur dazu. Gerade schnell gemachte Korrekturen verursachen gern Folgefehler an anderer Stelle. Den Fehlernachtest übernimmt man idealerweise gleich als neuen automatisierten Regressionstest.

Richtig: Jede Anweisung wurde mindestens einmal ausgeführt; das Modul kann trotzdem Fehler enthalten

Überdeckung zeigt, was ausgeführt wurde, nicht, ob das Ergebnis geprüft wurde. Tests ganz ohne Assertions können 100 % erreichen. Fehlende Funktionen (die gar nicht im Code stehen) findet Überdeckung nie.

Richtig: Keine offenen Fehler der höchsten Schwere und alle Tests mit hohem Risiko durchgeführt

Eingangskriterien sagen, wann man sinnvoll mit Testen beginnen kann (Umgebung steht, Build läuft). Ausgangskriterien sagen, wann man aufhören darf. Ohne sie endet der Test meist dann, wenn die Zeit vorbei ist.

Richtig: Ein statischer Test: Arbeitsergebnisse werden geprüft, ohne Software auszuführen

Statische Tests (Reviews, statische Codeanalyse) finden Fehler, bevor es lauffähige Software gibt, und damit sehr günstig. Unklare Anforderungen zählen ausdrücklich als Fehler.

Richtig: Pestizid-Paradoxon: Immer gleiche Tests verlieren mit der Zeit ihre Wirkung

Wie Schädlinge gegen dasselbe Gift unempfindlich werden, finden dieselben Tests keine neuen Fehler. Tests müssen regelmäßig überarbeitet und um neue Fälle ergänzt werden, etwa aus Kundenmeldungen.

Richtig: Fehlhandlung (Vertippen) → Fehlerzustand (> im Code) → Fehlwirkung (Ablehnung im Betrieb)

Menschen machen Fehlhandlungen (error), die führen zu Fehlerzuständen im Produkt (defect, bug), und die können im Betrieb Fehlwirkungen (failure) auslösen. Nicht jeder Fehlerzustand wird sichtbar; tritt die Bedingung nie auf, schlummert er unbemerkt.

Richtig: Zahlung

Zahlung: 4 × 5 = 20. Produktsuche 9, Newsletter 3, Impressum 2. Risikobasiertes Testen verteilt die knappe Testzeit nach diesem Produkt, statt alles gleich intensiv zu prüfen.

Richtig: Ob die wichtigsten Grundfunktionen überhaupt laufen, sodass weiteres Testen sinnvoll ist

Der Name kommt aus der Elektronik: einschalten und schauen, ob es raucht. Startet die Anwendung, klappt die Anmeldung, lädt die Hauptseite? Wenn nicht, spart man sich den stundenlangen Gesamttest.

Richtig: Der Quellcode der zu testenden Anwendung

Ein Testkonzept beschreibt das Was, Wie, Wer und Wann des Testens. Es soll Entscheidungen festhalten und abstimmbar machen. Ein gutes Konzept ist kurz und wird gelesen, ein schlechtes ist lang und liegt in der Schublade.

Richtig: Testaktivitäten früher im Ablauf beginnen, z. B. Anforderungen prüfen und Tests vor dem Code entwerfen

Auf einer Zeitachse von links (Idee) nach rechts (Betrieb) wandert das Testen nach vorn. Tester sind bei der Formulierung der Anforderungen dabei, Akzeptanzkriterien entstehen vor dem Code. Das Gegenstück „Shift Right“ meint Beobachten und Testen im Betrieb.

Richtig: Es sagt nichts über Ergebnisse, Risiko und offene schwere Fehler; die fehlenden 20 % könnten die wichtigsten sein

Ein guter Bericht sagt: Welche Risiken sind abgedeckt, welche nicht? Wie viele schwere Fehler sind offen? Was bedeutet das für das Release? Die Anzahl ausgeführter Testfälle misst Fleiß, nicht Qualität.

Richtig: Äquivalenzklassenbildung

Black-Box-Verfahren leiten Tests aus der Spezifikation ab, ohne den Code zu kennen: Äquivalenzklassen, Grenzwerte, Entscheidungstabellen, Zustandsübergänge. Überdeckungsverfahren brauchen den Code und sind White-Box.

Richtig: Das erwartete Ergebnis

Ohne erwartetes Ergebnis kann man nicht entscheiden, ob der Test bestanden ist. Dann prüft jeder nach Gefühl. Ein vollständiger Testfall hat Vorbedingungen, Schritte, Testdaten und das erwartete Ergebnis.

Richtig: Abnahmetest: Vertrauen gewinnen, dass das System für den Einsatz taugt

Beim Abnahmetest geht es weniger ums Fehlerfinden als um die Frage: Können wir damit arbeiten? Werden hier noch viele Fehler gefunden, ist in den Stufen davor etwas schiefgelaufen.

Richtig: Wenn die vereinbarten Ausgangskriterien erfüllt sind und das verbleibende Risiko für die Beteiligten akzeptabel ist

Fehlerfreiheit lässt sich nicht beweisen, und vollständiges Testen ist unmöglich. Testen liefert Informationen über das Risiko, die Entscheidung zum Release treffen die Verantwortlichen auf dieser Grundlage. Ist das Budget erschöpft, sollte man das verbleibende Risiko ausdrücklich benennen.