Eine Softwareänderung mit passenden Testfällen absichern

Eine kleine Änderung mit großer Wirkung

Die Lernwerk GmbH betreibt eine Software, mit der Beschäftigte interne Schulungsplätze buchen. Bisher durfte eine Buchung zwischen 1 und 8 Plätzen enthalten. Nun sollen Teamleitungen bis zu 12 Plätze in einer Buchung reservieren können. Für alle anderen Personen bleibt die Obergrenze bei 8.

Die neue Anforderung lautet:

Eine Buchung wird angenommen, wenn mindestens ein Platz angefragt wird und die Anzahl die Obergrenze der Rolle nicht überschreitet. Teamleitungen dürfen höchstens 12 Plätze buchen, andere Beschäftigte höchstens 8. Ungültige Rollen und nicht-ganzzahlige Platzangaben werden abgewiesen.

Eine Entwicklerin passt die Funktion an. Ein Test nur mit 3 Plätzen und der Rolle employee wird wahrscheinlich weiterhin erfolgreich sein. Er beantwortet aber nicht die entscheidenden Fragen: Gilt die neue Obergrenze wirklich nur für Teamleitungen? Werden 12 und 13 richtig unterschieden? Was passiert bei 0, einer Kommazahl oder einer unbekannten Rolle?

Genau hier beginnt systematisches Testen. Du leitest zuerst aus der Anforderung beobachtbare Bedingungen ab. Danach wählst du Daten, mit denen jede Bedingung sichtbar wird. Erst dann entscheidest du, welche Prüfungen du automatisierst.

Für die Codebeispiele solltest du Bedingungen, Funktionen und Rückgabewerte grundsätzlich lesen können. Die genaue Syntax wird an den entscheidenden Stellen erklärt.

Aus Text werden prüfbare Bedingungen

Eine Testbedingung beschreibt, welcher Teil einer Anforderung geprüft werden soll. Sie enthält noch nicht zwingend alle Eingabedaten. Für die Buchungsänderung lassen sich fünf Bedingungen ableiten:

1. Eine Teamleitung kann 1 bis einschließlich 12 Plätze buchen.
2. Eine andere beschäftigte Person kann 1 bis einschließlich 8 Plätze buchen.
3. Werte unter 1 werden abgewiesen.
4. Werte oberhalb der jeweiligen Rollenobergrenze werden abgewiesen.
5. Unbekannte Rollen und nicht-ganzzahlige Platzangaben werden abgewiesen.

Das Wort einschließlich ist wichtig. Es klärt, dass 12 noch erlaubt und erst 13 abzuweisen ist. Ohne diese Präzisierung könnten Entwicklung, Test und Auftraggeber unterschiedliche Erwartungen haben.

Aus einer Testbedingung entsteht ein Testfall. Er verbindet eine konkrete Ausgangslage und Eingabe mit einem erwarteten Ergebnis. Ein nachvollziehbarer Testfall beantwortet mindestens diese Fragen:

Das Soll-Ergebnis wird vor der Ausführung festgelegt. Wenn du es erst nach dem Test formulierst, besteht die Gefahr, dass du das beobachtete Verhalten nachträglich zur richtigen Lösung erklärst.

Normal-, Rand- und Fehlerfälle decken unterschiedliche Risiken ab

Ein Normalfall verwendet eine gewöhnliche, gültige Eingabe. Er zeigt, ob der erwartete Hauptweg funktioniert. Für employee und 3 Plätze muss die Buchung angenommen werden.

Ein Randfall liegt an oder direkt neben einer fachlichen Grenze. Hier entstehen häufig Fehler durch einen falschen Vergleichsoperator. Für die Teamleitung sind 11, 12 und 13 aussagekräftiger als drei beliebige Werte aus der Mitte. Besonders 12 und 13 trennen die beiden möglichen Ergebnisse.

Ein Fehlerfall verwendet eine Eingabe, die das System abweisen oder kontrolliert behandeln soll. Dazu gehören 0 Plätze, 2.5 Plätze oder die unbekannte Rolle admin. Ein guter Fehlerfall prüft nicht nur, dass etwas fehlschlägt. Er legt fest, wie das System den Fehler sichtbar macht.

Diese Kategorien sind keine starren Schubladen. Ein Wert kann zugleich Rand- und Fehlerfall sein. Die 0 liegt direkt unter der unteren gültigen Grenze und muss abgewiesen werden. Entscheidend ist, welches Risiko der Testfall sichtbar macht.

Eine kompakte Testfalltabelle

Eine Tabelle macht sichtbar, welche Bedingungen bereits abgedeckt sind. Sie ist außerdem verständlich, bevor ein Testframework feststeht.

Die Tabelle ist bewusst überschaubar. Sie behauptet keine vollständige Absicherung der gesamten Buchungssoftware. Sie prüft die Regeln, die für diese Änderung relevant sind.

Arrange, Act und Assert machen Tests lesbar

Der folgende JavaScript-Code bildet die Anforderung ab. roleLimits ordnet jeder bekannten Rolle ihre Obergrenze zu. Die Funktion gibt true zurück, wenn Rolle und Anzahl gültig sind.

const roleLimits = {
  employee: 8,
  lead: 12,
}

export function canBook(role, seats) {
  const limit = roleLimits[role]

  if (limit === undefined || !Number.isInteger(seats)) {
    return false
  }

  return seats >= 1 && seats <= limit
}

Ein automatisierter Test kann in drei gedankliche Schritte gegliedert werden:

• Arrange: Ausgangslage und Eingaben vorbereiten.
• Act: die zu prüfende Aktion ausführen.
• Assert: tatsächliches und erwartetes Ergebnis vergleichen.

Diese Struktur wird oft als AAA-Muster bezeichnet. Sie ist keine besondere JavaScript-Syntax. Sie hilft dabei, einen Test so zu schreiben, dass die Absicht schnell erkennbar bleibt.

import { canBook } from "./booking.js"

function assertEqual(actual, expected) {
  if (actual !== expected) {
    throw new Error(`Erwartet: ${expected}, erhalten: ${actual}`)
  }
}

// Arrange
const role = "lead"
const seats = 12

// Act
const actual = canBook(role, seats)

// Assert
assertEqual(actual, true)

In einem echten Projekt übernimmt meist ein Testframework das Ausführen, Vergleichen und Berichten. Die drei Schritte bleiben trotzdem dieselben. Ein sprechender Testname sollte Bedingung und Erwartung erkennen lassen, zum Beispiel accepts twelve seats for lead.

Aussagekräftige Tests scheitern aus einem erkennbaren Grund

Ein Test ist besonders nützlich, wenn sein Fehlschlag auf ein überschaubares Verhalten zeigt. Ein einzelner Test sollte deshalb nicht gleichzeitig die Rolle anlegen, eine Buchung über die Oberfläche absenden, eine E-Mail abrufen und eine Datenbanktabelle kontrollieren, wenn eigentlich nur die Grenzprüfung untersucht werden soll.

Auch der Vergleich braucht ein konkretes Soll-Ergebnis. assert(result) sagt weniger als assertEqual(result, false). Bei komplexeren Ergebnissen gehören die relevanten Werte in den Vergleich oder in eine verständliche Fehlermeldung.

Betrachte diesen fehlerhaften Test:

const actual = canBook("lead", 13)
assertEqual(actual, true)

Die Ausführung ist korrekt, aber die Erwartung widerspricht der Anforderung. Ein Test ist nicht automatisch richtig, nur weil er automatisiert ist. Testcode muss ebenso geprüft und verständlich gehalten werden wie Produktivcode.

Automatisiert und manuell erfüllen verschiedene Aufgaben

Automatisierte Tests sind besonders hilfreich, wenn eine Prüfung häufig und mit eindeutigem Soll-Ergebnis wiederholt werden soll. Die Buchungsgrenzen lassen sich schnell mit mehreren Datensätzen prüfen. Nach jeder Änderung kann derselbe Satz erneut laufen.

Manuelle Tests sind sinnvoll, wenn menschliche Wahrnehmung oder offene Erkundung wichtig ist. Ob eine Fehlermeldung in der Oberfläche verständlich wirkt, lässt sich nicht vollständig durch den Rückgabewert der Funktion beurteilen. Auch ein neuer, noch wenig verstandener Ablauf kann zunächst erkundend getestet werden.

Die Entscheidung ist daher nicht “automatisch oder manuell für alles”. Sie richtet sich nach dem Prüfziel:

Automatisierung spart Wiederholungsarbeit, beseitigt aber keine unklaren Anforderungen. Ein schnell ausgeführter Test mit falschem Soll-Ergebnis bleibt ein falscher Test.

Regression bedeutet: Bekanntes Verhalten erneut prüfen

Ein Regressionstest prüft nach einer Änderung, ob bereits vorhandenes Verhalten weiterhin funktioniert. Die neue Grenze für Teamleitungen darf die Grenze für employee nicht versehentlich verändern. Deshalb bleiben T01 bis T03 relevant, obwohl die Änderung hauptsächlich lead betrifft.

Regressionstests sind kein eigener Testfalltyp neben Normal-, Rand- und Fehlerfall. Der Begriff beschreibt den Zweck der Wiederholung. Ein vorhandener Randfall kann beim ersten Durchlauf die aktuelle Funktion prüfen und nach der nächsten Änderung als Regressionstest dienen.

Ein Befund muss für andere reproduzierbar sein

Ein fehlgeschlagener Test ist zunächst eine Beobachtung. Ein Befund macht daraus eine Information, mit der eine andere Person weiterarbeiten kann. Dafür braucht sie genug Kontext, um das Verhalten erneut auszulösen und Soll und Ist zu vergleichen.

Ein hilfreicher Befund enthält:

• eine kurze, konkrete Überschrift,
• betroffene Version oder Testumgebung,
• notwendige Vorbedingungen,
• nachvollziehbare Schritte und Eingaben,
• erwartetes Ergebnis,
• tatsächliches Ergebnis,
• bei Bedarf Protokolle oder Bildschirmaufnahmen ohne sensible Daten.

Wenig hilfreich wäre: “Buchung geht nicht.” Besser ist:

Teamleitung kann 12 Plätze nicht buchen Umgebung: Testsystem, Version 2.4.0 Schritte: Als Teamleitung anmelden, Schulung öffnen, 12 Plätze eintragen, Buchung bestätigen. Soll: Die Buchung wird angenommen. Ist: Die Oberfläche meldet “Maximal 8 Plätze” und lehnt die Buchung ab.

Diese Beschreibung enthält noch keine Behauptung über die technische Ursache. Die Ursache zu vermuten kann bei der Fehlersuche helfen, gehört aber getrennt von der beobachteten Wirkung dokumentiert.

Testen ist ein Teil der Qualitätssicherung

Testen vergleicht beobachtbares Verhalten mit einer Erwartung. Es kann Fehler sichtbar machen, beweist aber nicht, dass eine Anwendung unter allen Bedingungen fehlerfrei ist.

Qualitätssicherung ist weiter gefasst. Dazu gehören zum Beispiel klare Anforderungen, Reviews, Entwicklungsstandards, Versionsverwaltung, Tests, Auswertungen und Verbesserungen am Arbeitsprozess. Ein Code-Review kann einen Fehler finden, bevor das Programm ausgeführt wird. Ein Testprotokoll kann zeigen, welche Risiken geprüft wurden. Beides unterstützt Qualität, ist aber nicht dasselbe wie das Ausführen eines Testfalls.

Die Abgrenzung hilft bei der Planung. “Wir haben getestet” beantwortet noch nicht, ob Anforderungen verständlich waren, Änderungen nachvollziehbar versioniert wurden oder Befunde in den Prozess zurückfließen.

Transfer: Sichere eine Rabattänderung ab

Ein Bestellsystem berechnet einen Mengenrabatt. Bisher gab es ab 20 Stück 5 Prozent Rabatt. Künftig sollen registrierte Bildungseinrichtungen bereits ab 10 Stück 5 Prozent erhalten. Andere Kundengruppen behalten die Grenze von 20 Stück. Mengen müssen ganze Zahlen größer als 0 sein.

Was du jetzt mitnehmen kannst

Du beginnst nicht mit zufälligen Testdaten, sondern mit einer eindeutigen Anforderung. Daraus leitest du Testbedingungen und konkrete Soll-Ergebnisse ab. Normalfälle zeigen den Hauptweg. Randfälle prüfen Grenzen. Fehlerfälle machen die kontrollierte Behandlung ungültiger Eingaben sichtbar.

Arrange, Act und Assert strukturieren einen automatisierten Test. Manuelle Tests ergänzen ihn dort, wo Wahrnehmung und Erkundung wichtig sind. Nach einer Änderung schützen Regressionstests bereits vorhandenes Verhalten. Wenn etwas nicht passt, macht ein reproduzierbarer Befund aus der Beobachtung eine bearbeitbare Aufgabe.

Die Grenze bleibt wichtig: Ein guter Testsatz senkt bekannte Risiken. Er beweist nicht, dass die gesamte Software fehlerfrei ist. Tests sind ein Werkzeug innerhalb einer umfassenderen Qualitätssicherung.

Belegmatrix