Auf Entaggle hat mich vor einiger Zeit James Lyndsay mit einem Tag versehen: „has a problem with authority“ – hat ein Problem mit Autorität. Er versah dieses Kennzeichen mit dem Kommentar „healthily so“ – und das ist auch gut so.

Was veranlasst ihn dazu, mir diese Kennzeichnung zu verpassen? Die Antwort liefert ein Buch aus dem Jahr 2002: Lessons Learned in Software Testing. In diesem Buch erklären Cem Kaner, James Bach und Bret Pettichord in rund 300 Lektionen, welche Erfahrungen sie im Software Testen in den unterschiedlichsten Projekten gemacht haben. Mit ihren zusammen mehr als 60 Jahren Erfahrung (damals) sicherlich eine gute Quelle.

Doch aus der Arbeit für dieses Buch wuchs mehr. Der Untertitel lautet „A context-driven approach“ – ein kontextabhängiger Ansatz. Während sie ihr Wissen aufschrieben formulierten diese drei einen Testansatz, den in meinen Augen viel zu wenige Tester kennen. Ihnen war nämlich aufgefallen, dass es gröbere Kategorien dafür gibt, wie einige Tester, die sie getroffen haben, denken, und warum diese unterschiedlichen Denkrichtungen sich nicht untereinander verstehen, bzw. verschiedener Meinung sind. Hieraus entstanden die vier Denkrichtungen im Software Testen.

Über diese vier Denkrichtungen streiten sich die seitdem die Anhänger – oder auch nicht Anhänger. Ich persönlich glaube, dass es sinnvoll ist, sich darüber im Klaren zu sein, woher unsere Tätigkeit kommt, welche Schritte sie auf dem Weg in das Jetzt durchlebt hat, und unter welchen Voraussetzungen zu anderen Zeiten heute merkwürdig erscheinende Entscheidungen getroffen wurden. Die Vier Denkrichtungen helfen dabei.

Analytisches Testen

In den frühen Jahren ging es bei Fehlern in Software vor allem um Probleme, die auftraten, dadurch dass bei der Übersetzung der Software von der Assemblersprache (ADD EAX) in die Maschinensprache (0402 03219) Fehler mit Registern und Befehlen auftraten. Durch den Übersetzungsprozess konnten sich derlei Fehler einschleichen.

Außerdem konnte es sein, dass nach dem Anpassen von Software (zum Beispiel nach einem Bugfix) die Register neu geordnet werden mussten. Dann wurde ein Zwischenergebnis auf einmal durch ein weiteres Ergebnis überschrieben. Oder ein Zwischenergebnis war auf einmal ein ganz anderes Ergebnis.

Diese Fehler lassen sich analytisch finden, indem man den Quellcode immer und immer wieder analysiert und auf Fehler prüft. Sog. „Clerks“ machten in dieser Zeit diese Art von Tätigkeiten. Und die Softwareindustrie hatte eine Menge davon. Kein Wunder. Menschliche Arbeitskraft war damals im Verhältnis zu Maschinenkosten weitaus günstiger zu bekommen.

Standards

Während der Software Engineering Revolution entstand historisch dann ein Ansatz, der auf einen standardisierten Prozess legte. In den 70ern wurde viel Wert auf die Wiederholbarkeit von Ergebnissen gesetzt. Zu der damaligen Zeit glaubte man, dass Standards genau dabei helfen. Wenn alle das gleiche tun, dann kommt schließlich immer das gleiche am Ende raus – und – man verzeihe mir diesen kätzerischen Kommentar – die Fehler sind ebenfalls immer die gleichen.

Zur damaligen Zeit ging es vor allem darum, dass Tester aus den Bereichen kamen, die später durch Software weg rationalisiert werden sollten. Die damaligen Tester waren als Experten in der Domäne der Software, die sie testen sollten. Hier kam es vor allem darauf an, den Fortschritt hin zu fertigen Software zu messen – gerade im Wasserfall- und V-Modell zu der Zeit eine durchaus gängige Denkweise.

Aber es ging auch darum, dass Tester möglichst wenig Fähigkeiten benötigen sollten. Die Kosteneffizienz der frühen Jahre war das Ziel. Dafür sollten jetzt Studenten Tests durchführen. Einige davon blieben später bei dieser Tätigkeit.

Der Nachteil hierbei ist natürlich, dass Standards nichts über Fähigkeiten einzelner Entwickler aussagen, und ein wiederholbarer Prozess nicht unbedingt wiederholbare Ergebnisse liefert. Aus diesem Grund musste die nächste Denkrichtung her.

Qualität, Qualität, Qualität

Das Problem war klar: die Tester müssen mehr Macht bekommen. Ab sofort geht nur noch Software in Richtung Produktion, wenn diese durch die Tester frei gegeben wurde. Tester sind ab sofort eine Schranke. Die Software geht erst raus, wenn die Tester das ok dazu geben.

Das Problem mit dieser Herangehensweise ist nach meiner Erfahrung, dass dieser Mechanismus nie funktionieren konnte. Wenn man Testern mit standardisierten Fähigkeiten die Macht gibt, über Go oder No-Go der Software zu entscheiden, dann werden diese zwangsläufig bei kritischen Entscheidungen von der nächst höheren Instanz einfach übergangen. Schließlich können Tester ja nicht alle Faktoren, die hinter der Entscheidung stehen, kennen. Richtig?

Absolut richtig. Aber dann kann ich mir diese ganze Zeremoniell mit den Freigaben auch von vornherein sparen. Aber das bringt mich zu dem anderen Problem zurück: Unsere Software hat bei der Auslieferung keine gute Qualität. Wie bekommen wir die denn dann?

Kontextabhängiges Testen

Nun, die drei zuvor genannten Personen – Kaner, Bach und Pettichord – kamen zu dem Schluss, dass manche Praktiken in manchen Projekten Sinn machen, in anderen wiederum nicht. Abhängig davon, in welchem Projekt man sich befindet, macht es beispielsweise Sinn, den IEEE Standard für Testdokumentation zu verwenden – Atomkraftwerke, ferngesteuerte Militärwaffen, Autosteuerung – oder gar leichtgewichtige Testdokumentation wie Tests als Spezifikation – Agile Softwareentwicklung einer Webanwendung – zu verwenden. Das gleiche gilt für Methoden wie Testfallerstellung durch Entscheidungstabellen, Grenzwerte (redaktionelle Anmerkung: zu einer Zahl +1 und -1 zu rechnen ist keine Form der Analyse) oder auch paarweises Testen.

Hieraus wuchs die Kontxtabhängig Denkrichtung. Diese setzt vor allem auf die Zusammenarbeit zwischen Projektbeteiligten, aber auch darauf, dass es keine beste Möglichkeit – sog. „best practices“ – gibt. Es gibt höchstens Praktiken, die in einem gewissen Zusammenhang – dessen Kontext – Sinn gemacht haben – einmal. Ein Ansatz, der vor allem Wert auf die kritischen Denkfähigkeiten eines Testers setzt.

Diese Denkweise macht also deutlich, dass ein gesundes Misstrauen einen guten Tester auszeichnet. Und genau das gilt auch für mein Problem mit sog. Autoritäten. Nur weil es sie gibt, muss ich ihnen nicht trauen. Ganz im Gegenteil: durch kritisches Hinterfragen finde ich heraus, wann eine Denkweise einer sog. oder auch selbst-ernannten (woran merkt man den Unterschied?) Autorität Sinn ergibt, wann nicht und welche dieser Situationen ich bereits erlebt habe, bzw. in welchen Situationen ich dieses gezielt nicht ausprobieren wollte.

Wenn also das nächste Mal ein Berater Ihre Frage mit „kommt drauf beantwortet“, bedeutet das nichts anderes, als „ich verstehe Ihre Situation noch nicht völlig.“ Bei guten Beratern wird diese Antwort allerdings auch mit „Hier sind ein paar der Situationen, die ich bisher erlebt habe. Welche macht in Ihrer Situation am meisten Sinn?“ zu einem Gesamtbild ergänzt.