Black Box White Box Test

Okay, mal ehrlich. Haben wir uns nicht alle schon mal gefragt: Was zum Kuckuck ist eigentlich der Unterschied zwischen Black Box und White Box Test? Und warum klingt das so nach Magie?

Es geht ums Testen von Software. Das ist klar. Aber dann wird's kompliziert. Da ist die eine Box schwarz, die andere weiß. Und wir sollen raten, was drin passiert. Klingt nach 'nem Denkspiel für Informatiker, oder?

Meine ketzerische Meinung: Im Grunde ist es doch gar nicht so wichtig, wie wir es nennen. Hauptsache, die Software funktioniert am Ende, oder?

Black Box: Der Test für Normalsterbliche

Stellt euch vor, ihr kauft einen Toaster. Ihr wisst nicht, wie er funktioniert. Ihr schmeißt einfach Brot rein und drückt den Hebel. Funktioniert? Super! Brot verbrannt? Zurück damit! Das ist Black Box Testing in Reinform.

Ihr seht den Code nicht. Ihr wisst nichts über die inneren Abläufe. Ihr testet nur, was reingeht und was rauskommt. Input -> Output. Simpel, oder? (Okay, meistens...)

Ein Black Box Tester braucht keine Programmierkenntnisse. Er muss nur wissen, was die Software tun soll. Und er muss kreativ sein, um alle möglichen Szenarien durchzuspielen. Was passiert, wenn ich eine negative Zahl eingebe? Was passiert, wenn ich gar nichts eingebe?

Ich behaupte mal, jeder von uns testet Software auf diese Weise. Wir benutzen Apps, Websites, Programme. Und wenn etwas nicht so funktioniert, wie es soll, beschweren wir uns. Zack, unbewusster Black Box Test.

"Black Box Testing ist wie ein Blind Date. Du weißt nicht, was dich erwartet."

White Box: Der Blick hinter die Kulissen

Jetzt wird's nerdiger. White Box Testing bedeutet, ihr kennt den Code. Ihr wisst genau, wie die Software aufgebaut ist. Ihr seht alle Schleifen, Funktionen und Variablen.

Stellt euch vor, ihr seid der Toaster-Hersteller. Ihr wisst, wie die Heizdrähte funktionieren. Ihr wisst, wie der Timer eingestellt ist. Ihr könnt jeden einzelnen Baustein testen.

White Box Tester sind meistens Entwickler. Sie testen ihren eigenen Code (oder den von anderen). Sie suchen nach Fehlern, die im Code versteckt sind. Nach Logikfehlern, Dead Code, Sicherheitslücken.

Das ist natürlich viel aufwendiger als Black Box Testing. Aber es kann auch viel effektiver sein. Denn ihr testet nicht nur, ob die Software funktioniert, sondern auch, warum sie funktioniert (oder eben nicht).

Unpopuläre Meinung Nummer 2: Manchmal ist White Box Testing überbewertet. Perfekter Code existiert nicht. Und selbst wenn der Code perfekt ist, kann die Software trotzdem Fehler haben (z.B. wegen falscher Anforderungen).

Graubereich: Gibt's eigentlich auch Grey Box?

Ja, gibt's. Aber lass uns ehrlich sein: Brauchen wir noch mehr Kategorien? Im Grunde ist Grey Box Testing eine Mischung aus beidem. Man hat ein bisschen Ahnung vom Code, aber nicht alles.

Wie wenn ihr den Schaltplan vom Toaster habt, aber keine Ahnung, welche Art von Draht verwendet wurde.

Ich finde ja, wir sollten uns lieber auf die Ergebnisse konzentrieren. Ob Black Box, White Box oder Pink Box – Hauptsache, die Software ist gut!

Meine abschließende, möglicherweise kontroverse Aussage: Am Ende des Tages ist es doch egal, wie wir testen. Wichtig ist, dass wir testen. Und dass wir uns Mühe geben, gute Software zu entwickeln.

Und wenn der Toaster das Brot verbrennt, egal wie viel White Box Tests gemacht wurden, dann war's das halt. Dann gibt's halt Knäckebrot. (Oder wir schreiben 'ne wütende Rezension.)

Also, entspannt euch, liebe Tester. Macht euren Job gut. Und nehmt das Ganze nicht zu ernst. Schließlich ist es "nur" Software.

Außer es geht um die Software für Atomkraftwerke. Dann vielleicht doch ein bisschen ernster nehmen. Nur so als Tipp.