Antwort.

Testen nach der "White-Box"-Methode basiert auf dem Wissen über die interne Struktur und den Code der Anwendung. Historisch gesehen war diese Methode das Vorrecht von Entwicklern, aber mit der Komplexität der Software begannen auch Tester, diese Ansätze zu verwenden. Im Gegensatz zur "Black-Box", bei der nur Eingangs- und Ausgangsdaten getestet werden, ist hier das Verständnis darüber wichtig, wie das System intern funktioniert.

Schlüsselfeatures:

Überprüfung der Logik, Bedingungen und Verzweigungen im Code
Hilft dabei, Fehler zu finden, die beim "Black-Box"-Testen nicht erkannt werden
Erfordert Analyse des Codes, Kommunikation mit Entwicklern und grundlegende Programmierkenntnisse

Problem

Manuelle Tester beschränken sich oft nur auf Benutzerszenarien und übersehen mögliche Defekte auf der Ebene der Implementierungslogik. Dies führt dazu, dass kritische Fehler in komplexen Systemen übersehen werden.

Lösung

Die Grundlagen der Code-Strukturierung lernen, einfache Funktionen und Flussdiagramme lesen können, lernen, Fragen an Entwickler zu stellen. Ein manueller Tester, der die Prinzipien der "White-Box"-Methode versteht, hebt sich deutlicher auf dem Markt ab.

Fangfragen.

Was ist der Fehler, wenn man denkt, dass manuelle Tester kein Testen nach der "White-Box"-Methode verwenden?

Es ist falsch zu glauben, dass dieser Ansatz ausschließlich für Automatisierer ist. In vielen Unternehmen überprüft der Tester manuell interne Berechnungen und Datenstrukturen – insbesondere bei komplexen Projekten.

Ist Unit-Testing ein Synonym für "White-Box"-Testen für manuelle Tester?

Nein. Unit-Tests sind ein Automatisierungswerkzeug. Manuelle Tester verwenden ähnliche Analyseprinzipien, schreiben aber keinen Code für diese Überprüfungen.

Kann man sich auf Benutzerszenarien beschränken, wenn der "White-Box"-Ansatz in der Entwicklungsphase angewendet wurde?

Nein. Benutzerszenarien können Fehler aufdecken, die auf Codeebene übersehen wurden. Nur die Kombination der Methoden aus der Nutzer- und Code-Perspektive bietet die größtmögliche Abdeckung.

Typische Fehler und Anti-Pattern

Unzureichendes Verständnis des Fachgebiets
Fehlende interne Kommunikation mit dem Entwicklungsteam
Oberflächliche Analyse von Änderungen im Code

Beispiel aus dem Leben

Negativer Fall

Der Tester überprüft das neue Modul anhand von Benutzerszenarien, sieht sich aber nicht an, wie komplexe Rabattlogiken berechnet werden. Ein Fehler in der Berechnung wurde übersehen.

Vorteile:

Schnelle Abdeckung der Schnittstelle
Einfache Dokumentation

Nachteile:

Kritischer Defekt auf der Ebene der Geschäftslogik übersehen
Unternehmensverluste aufgrund falscher Berechnungen

Positiver Fall

Der Tester analysierte das Flussdiagramm intern und forderte Erklärungen von den Entwicklern zur Berechnung der Rabatte an und überprüfte zusätzliche Fälle manuell neben den Benutzern.