Black-Box-Testing in der Softwareentwicklung prüft ein Produkt von außen, ohne Einblick in den Quellcode, also genau so, wie Ihre Kunden es nutzen. Diese Einschränkung ist Absicht, denn wer für das Produkt bezahlt, sieht ebenfalls nicht hinein. Trotzdem findet er die kaputten Stellen schon wenige Tage nach einem Launch.
Es gibt auch einen geschäftlichen Grund, sich dafür zu interessieren. Tester, die Ihren Code nie erhalten, können ihn auch nicht weitergeben. Deshalb beauftragen viele Unternehmen für manuelle Tests einen externen Partner, statt ihre Systeme zu öffnen.
In diesem Leitfaden führen wir Sie ausführlich durch das Black-Box-Testing und seine vier wichtigsten Verfahren. Außerdem sprechen wir darüber, wann Sie in realen Projekten Black-Box- oder White-Box-Testing einsetzen sollten.
Was Black-Box-Testing in der Softwareentwicklung wirklich ist
Der Name stammt aus der Ingenieurstechnik, wo eine Black Box jedes System ist, das ausschließlich danach beurteilt wird, was hineingeht und was herauskommt. Tester arbeiten genauso. Einige haben keinen Zugang zum Code, die anderen entscheiden sich bewusst dagegen, hineinzusehen.
Die Branche hat dafür einen zweiten Begriff, den spezifikationsbasierten Test, und der beschreibt die Aufgabe ehrlicher. ISTQB, das Gremium, das die Standardterminologie für Tester weltweit pflegt, definiert ihn als einen Testansatz, der auf der Spezifikation einer Komponente oder eines Systems beruht. Schlicht gesagt: jemand schreibt auf, was das Produkt tun soll, und ein Tester prüft, ob es genau das tut.
Ein Tester muss nicht wissen, wie die Software gebaut wurde. Er arbeitet mit Anforderungen, Funktionsbeschreibungen und den Bildschirmen vor sich und vergleicht dann, was passiert, mit dem, was versprochen wurde.
White-Box-Testing setzt dagegen am entgegengesetzten Ende an. Die Entwicklerin liest den Quellcode und zeichnet jede Entscheidung nach, die er trifft, etwa zahlende Kunden auf den einen und kostenlose Nutzer auf den anderen Weg zu schicken. Jede dieser Verzweigungen erhält dann ihren eigenen Test, damit im Inneren nichts ungeprüft bleibt.
Was der Tester sieht
Das Produkt so, wie ein Kunde es sieht
Den Quellcode und jede Entscheidung darin
Worauf die Tests beruhen
Anforderungen und Spezifikationen
Codestruktur und Logik
Wer sie üblicherweise durchführt
QA-Ingenieure, externe Partner, echte Nutzer
Entwickler und alle mit Zugriff auf den Code
Was sie am besten finden
Kaputte Funktionen, verwirrende Abläufe, fehlende Regeln
Ungetestete Zweige, toter Code, fehlerhafte Logik
Welche Fähigkeiten sie verlangen
Produkt- und Fachwissen
Programmierkenntnisse
Zugriff auf den Quellcode
Nicht nötig
Unverzichtbar
Keiner der beiden Ansätze gewinnt für sich genommen, denn sie beantworten unterschiedliche Fragen. Der eine sagt Ihnen, ob das Produkt seine Aufgabe erfüllt. Der andere zeigt, ob der Code darunter solide ist. Die meisten gesunden Teams setzen beide ein, zu unterschiedlichen Zeitpunkten und meist mit getrennten Personen.
Die vier zentralen Black-Box-Testverfahren
Sie können nicht alles testen. Ein Buchungsformular mit nur fünf Fragen, von denen jede zehn verschiedene Antworten zulässt, ergibt bereits 100.000 Kombinationen. Da niemand Zeit hat, sie einzeln durchzugehen, nutzen Fachleute stattdessen vier Black-Box-Testverfahren, die die Liste auf die Prüfungen eingrenzen, die am ehesten echte Fehler finden.
Äquivalenzklassenbildung: einen Wert pro Gruppe testen
Software behandelt selten jede Eingabe als einzigartig. Sie sortiert sie in Gruppen und wendet auf jede dieselbe Regel an.
Stellen Sie sich ein Anmeldeformular vor, das Bewerber im Alter von 18 bis 65 Jahren akzeptiert. Alle innerhalb dieser Spanne werden identisch behandelt, also bringt es nichts, erst 34 und dann 47 auszuprobieren. Tatsächlich gibt es hier drei Ergebnisse: zu jung, akzeptiert und zu alt. Äquivalenzklassenbildung bedeutet, aus jeder Gruppe einen Wert zu wählen und darauf zu vertrauen, dass er für den Rest steht.
Diese 48 akzeptierten Altersangaben brauchen zusammen nur einen einzigen Test, während die beiden abgelehnten Gruppen je einen erfordern. Das Verfahren deckt auch Eingaben ab, die fehlschlagen sollen, etwa Buchstaben in einem Zahlenfeld oder ein leer gelassenes Feld. Diese gezielt zu prüfen nennt man Negativtests.
Grenzwertanalyse: die Ränder jeder Gruppe testen
Fehler sammeln sich an den Rändern jeder Gruppe, also genau an den Punkten, an denen die Antwort von akzeptiert auf abgelehnt umschlägt. Das Anmeldeformular aus unserem Beispiel hat zwei davon: den Schritt von 17 auf 18 und den Schritt von 65 auf 66.
Und hier geht es schief. Die Regel sagt, Bewerber müssen 18 oder älter sein, aber wer das Formular baut, schreibt stattdessen „über 18“. Diese beiden Formulierungen sehen identisch aus, bis sich eine 18-Jährige anmelden will und abgewiesen wird.
Also testen Sie die Werte auf beiden Seiten jedes Randes: 17 und 18 unten, 65 und 66 oben. Das sind vier Prüfungen, und sie fangen einen Fehler ab, der sich ständig in Software einschleicht. Unser Leitfaden zur Grenzwertanalyse geht weiter und zeigt, wie dieselbe Idee für Datumsangaben, Dateigrößen und die Anzahl der Datensätze gilt, die ein System auf einmal annimmt.
Entscheidungstabellentest: jede Regelkombination abbilden
Manches Verhalten hängt von mehreren Bedingungen gleichzeitig ab, und genau da verlieren Teams den Überblick. Eine Entscheidungstabelle listet jede einzelne auf und legt dann fest, was bei jeder Kombination passieren soll.
Angenommen, Ihr Checkout bietet kostenlosen Versand ab einem Bestellwert von 50 Dollar, und Mitglieder des Treueprogramms sammeln Punkte für alles, was sie kaufen. Zwei Bedingungen ergeben vier Ergebnisse:
Nein
Nein
Versandgebühr von 5 Dollar
Nein
Ja
Versandgebühr von 5 Dollar, Punkte gutgeschrieben
Ja
Nein
Kostenloser Versand
Ja
Ja
Kostenloser Versand, Punkte gutgeschrieben
So ausgeschrieben werden die Lücken offensichtlich. Teams prüfen routinemäßig die erste und die letzte Zeile und liefern dann aus, ohne die beiden dazwischen ausprobiert zu haben. Genau dort zahlt ein Mitglied, das 40 Dollar ausgibt, die richtige Gebühr und erhält seine Punkte nie.
Fügen Sie eine dritte Bedingung hinzu, etwa einen Rabattcode, und die Tabelle verdoppelt sich auf acht Zeilen. Dieses Wachstum ist der eigentliche Punkt, denn jede neue Zeile ist eine Kombination, auf die Ihre Kunden irgendwann stoßen werden, ob sie vorher jemand ausprobiert hat oder nicht.
Zustandsübergangstest: dem Weg der Nutzer folgen
Bestimmte Funktionen verhalten sich je nach Vorgeschichte unterschiedlich, und genau diese Vorgeschichte untersucht dieses Verfahren. Die Software befindet sich in einem Zustand, ein Ereignis überführt sie in einen anderen, und der Tester folgt der Route.
Die Kontosperrung ist das klarste Beispiel. Zu Beginn ist jeder in gutem Stand. Dann bringt ein falsches Passwort einen Strike, ein zweites einen weiteren, und beim dritten wird der Login für 15 Minuten gesperrt. Ein richtiger Versuch zu einem beliebigen Zeitpunkt sollte diesen Zähler jedoch löschen und die Person einlassen.
Wer diesen Weg abgeht, findet die Prüfungen, die sich lohnen:
- Der Zähler sollte vollständig zurückgesetzt werden, sodass nichts vom Dienstag übrig bleibt, das sich am Freitag mit zwei weiteren addiert.
- Die Sperre sollte sich nach 15 Minuten von selbst lösen, statt zu bestehen, bis der Support eingreift.
- Ein gesperrtes Konto sollte während der Wartezeit keine neuen Versuche annehmen.
Keine dieser Prüfungen setzt Zugriff auf den Quellcode voraus. Sie brauchen nur jemanden, der bereit ist, die gesamte Abfolge zu durchlaufen, statt jeden Bildschirm für sich zu testen.
Wo Black-Box-Testing in Ihren Entwicklungsprozess passt
Black-Box-Arbeit kann beginnen, sobald schriftliche Anforderungen vorliegen, und das ist früher, als die meisten Teams annehmen. Tester entwerfen Fälle direkt aus der Spezifikation, die Vorbereitung startet also, während die Entwickler noch bauen.
Zur wichtigsten Methode wird es in zwei späteren Phasen:
- Systemtesten prüft das zusammengesetzte Produkt gegen das Spezifizierte und deckt das Ganze ab statt seiner Teile.
- Benutzerakzeptanztests fragt die Menschen, die die Software beauftragt haben, ob sie ihr Problem löst. Diese Prüfer haben den Code nie gesehen, und sie müssen es auch nicht. Das ist Black-Box-Testing in seiner reinsten Form.
Alpha- und Betatests gehören zur selben Familie. Beide geben einen Build an echte Nutzer und beobachten, was kaputtgeht, eine Gruppe innerhalb des Unternehmens und eine außerhalb. Unser Vergleich von Alpha- und Betatests zeigt, worin sie sich in der Praxis unterscheiden.
Diese Methode kann allerdings nicht belegen, dass jede Zeile Ihres Codes ausgeführt wurde. Eine Funktion kann alle Prüfungen von außen bestehen, während ein ganzer Logikzweig dahinter unberührt liegt und auf eine ungewöhnliche Eingabe wartet. Entwickler schließen diese Lücke mit Unit-Tests, kleinen Programmen, die den Code direkt untersuchen. Automatisierungstests führt die nutzerseitigen Szenarien dann bei jedem Build erneut aus, sodass Sie sofort erfahren, wenn etwas, das funktioniert hat, nicht mehr funktioniert. Diese Maßnahmen ergänzen einander, statt zu konkurrieren.
Warum Black-Box-Testing beim Auslagern der QA zählt
Den eigenen Quellcode an ein fremdes Unternehmen zu geben, ist eine Entscheidung mit rechtlichem Gewicht. Verträge werden länger, Sicherheitsprüfungen kommen ins Spiel, und manche Organisationen lehnen schlicht ab.
Black-Box-Testing umgeht diese Entscheidung vollständig. Ein Partner, der diese Verfahren anwendet, braucht nur Ihre Anforderungen, einen lauffähigen Build und ein paar Konten zum Anmelden. Weil Ihr Code Ihr Unternehmen nie verlässt, haben Ihre Juristen deutlich weniger zu prüfen. Die Tests können in Tagen starten, statt auf eine Freigabe zu warten.
Das bedeutet auch, dass ein externer Partner in jeder Projektphase einsteigen kann, ohne fertigen Build und ohne Code-Übergabe. Ein engagiertes QA-Team kann mit der Hälfte des Produkts beginnen, die bereits funktioniert, während Ihre Entwickler den Rest fertigstellen.
So sieht das in der Praxis aus: Escuela Coaching mit Sitz in Madrid bat vor dem Launch um eine unabhängige Prüfung der Online-Plattform. Unsere Ingenieure testeten das Coach- und das Kundenportal auf 7 Geräten in rund einem Monat und meldeten mehr als 100 Defekte. Heute bedient die Plattform über 300 Organisationen.
Dieselbe Logik gilt für die Sicherheit. Dynamisches Sicherheitstesten von Anwendungen sondiert ein laufendes System von außen und sucht nach Schwachstellen, ohne eine Zeile Quellcode zu lesen. Damit gehört das Sicherheitstesten von Webanwendungen zur selben Familie und ist eine weitere Aufgabe, die ein externer Spezialist ohne Ihren Code übernehmen kann.
Black-Box-Testing ist eine Entscheidung, kein Kompromiss
Ohne Quellcode zu arbeiten wirkt wie eine Lücke im Verfahren, bis man sieht, was es einbringt. Die Prüfungen bilden ab, wie echte Kunden das Produkt nutzen, und wer sie durchführt, braucht nie Zugang zu Ihrem Code. Zusammen erklären diese beiden Tatsachen, warum so viel Testarbeit an ein externes Team geht.
QAwerk wendet diese Verfahren über unsere manuellen Tests, Systemtests und Abnahmetests hinweg an. Um herauszufinden, welche davon Ihr nächstes Release wirklich braucht, sprechen Sie mit unseren QA-Ingenieuren.
Was ist Black-Box-Testing in der Softwareentwicklung?
Black-Box-Testing in der Softwareentwicklung bedeutet, ein Produkt danach zu beurteilen, was es tut, und nicht danach, wie es gebaut wurde. Ein Tester arbeitet mit den Anforderungen und den Bildschirmen, nie mit dem Quellcode. Man nennt es auch spezifikationsbasiertes Testen, den Standardansatz für Systemtests, Abnahmetests und den größten Teil der manuellen QA.
Was sind die wichtigsten Black-Box-Testverfahren?
Vier Verfahren decken die meisten Situationen ab. Die Äquivalenzklassenbildung teilt Eingaben in Gruppen, die sich gleich verhalten, und testet dann ein Mitglied je Gruppe. Die Grenzwertanalyse zielt auf die Werte genau dort, wo eine Regel zu greifen beginnt oder aufhört. Der Entscheidungstabellentest arbeitet jede Kombination von Bedingungen durch. Der Zustandsübergangstest prüft, wie eine Funktion reagiert, wenn sich ihr Status ändert.
Lässt sich Black-Box-Testing automatisieren?
Ja, und die meisten Teams automatisieren die sich wiederholenden Teile. Ein Skript kann ein Formular ausfüllen, absenden und die Antwort prüfen, ohne dass jemand zusieht, was sich für alles eignet, das Sie bei jedem Build wiederholen. Exploratives Arbeiten und die Einschätzung, ob ein Bildschirm tatsächlich Sinn ergibt, bleiben Handarbeit. Die meisten Produkte landen bei einer Mischung aus beidem.
Müssen Black-Box-Tester programmieren können?
Nein. Diese Verfahren beruhen darauf, das Produkt, seine Nutzer und die schriftlichen Anforderungen zu verstehen, nicht darauf, Code zu lesen. Viele QA-Ingenieure eignen sich mit der Zeit Skripting an, und das erweitert ihren Aufgabenbereich. Testfälle aus einer Spezifikation zu entwerfen erfordert allerdings überhaupt keinen Entwicklungshintergrund.
Wann sollten Sie Black-Box-Testing einsetzen?
Greifen Sie dazu, wann immer die Frage lautet, ob das Produkt für seine Nutzer funktioniert. Es passt zu System- und Abnahmetests, zu Releases unter Termindruck und zu jeder Konstellation, in der ein Dienstleister Ihren Quellcode nicht bekommen sollte. Kombinieren Sie es mit den Unit-Tests der Entwickler, denn keiner der beiden Ansätze erzählt für sich allein die ganze Geschichte.
Sehen Sie, wie Escuela Coaching seine Online-Coaching-Plattform termingerecht gestartet hat, nachdem wir beide Portale auf 7 Geräten getestet und mehr als 100 Defekte gemeldet haben.
