Qualität stinkt. Manchmal.

Torsten Franz und ich hatten das Glück dieses Jahr mit einem recht provokativen Thema gleich bei zwei Konferenzen (dc, wdc) eingeladen zu werden. Beide in Hamburg und beide nur drei Tage auseinander. Wir haben über die Evolution der Qualitätssicherung in den letzten Jahren geredet. Leider gibt es kein Video oder ähnliches. Ihr müsst euch also mit den Folien begnügen. Ich werde aber trotzdem versuchen hier ein wenig die Richtung zu beschreiben, in die der Vortrag ging.

Angefangen haben wir mit dem Homo Testnix. Diese Spezies existierte überwiegend in den 90er Jahren und hatte nichts am Hut mit Qualitätssicherung. Software wurde nach Anforderungen runtergeklöppelt. Danach hat noch mal jemand ein wenig auf der Webseite rumgeklickt, um dann per FTP alles live zu stellen. Wir waren die Rambos der Softwareentwicklung, alles ging schnell und Fehler wurden direkt auf der Konsole des Produktionssystems gemacht. Keine Prozesse oder andere Aktivitäten, die uns entschleunigt haben. Eine geile Zeit. Einziges Manko daran war, dass uns die Software früher oder später um die Ohren geflogen ist. Softwareerosion ist in solchen Prozessen meist ein ständiger Begleiter.

Keine Tests zu haben ist also nicht wirklich das Wahre. Also auf zur nächsten Evolutionsstufe. Der Homo Testus war geboren. Die Idee in diesem Zeitalter war einfach. Wenn keine Tests nicht gut sind, dann müssen wir einfach ganz viel testen. Los geht’s. Das war die Zeit Sebastian Bergmanns, Manuel Pichlers und ganz vielen anderen Testgurus. Vielleicht aber auch von mir, dann in der Zeit habe ich auch ganz viel über Qualität  geschrieben. Was haben wir nicht alles getestet? Angefangen bei Unit Tests, gefolgt von statischer Code-Analyse, Lasttests, Stresstests, manuelle funktionale Tests, Testivals, Selenium-Tests, Code-Reviews und so weiter. Das ganze wurde dann über die Continuous-Integration-Lösung der Wahl permanent ausgeführt. Auch irgendwie eine geile Zeit. Viel gelernt, viel ausprobiert und eine wirklich hochwertige Software gebaut. Dummerweise wurden wir immer später fertig und die kosten sind gestiegen.

Den heiligen Gral des Testens haben wir also noch nicht gefunden. Bisher. Aber auch wir können uns weiterentwickeln und steigen in die nächste Epoche ein. Der Homo Qualitätus. Gelernt haben wir, dass zu viel Testen auch nicht das beste ist. Aber wie wollen wir sonst Qualität schaffen? Ganz einfach. Aber zuerst einmal vorne weg, möchte ich einen Test machen. Ich hoffe ihr spielt alle mit und kommentiert auch brav euer Ergebnis. Wem von euch ist Qualität in der Software, die er entwickelt wichtig? Mein Informant bei der NSA, hat mir gerade bestätigt, dass die meisten Hände nach oben gegangen sind. Und jetzt gleich die nächste Frage: „Was ist eigentlich Qualität?“. Gar nicht so einfach, zumindest haben wir das empirisch bei unseren Vorträgen rausgefunden. Ich hatte mit damit in meinem phphatesme-Leben beschäftigt. Ihr könnt da also alles nachlesen. Wichtiges Ergebnis ist aber, dass wir fast alle nicht wissen, was Qualität ist, wir aber den Begriff tagtäglich verwenden.

Qualität ist die Übereinstimmung von Leistungen mit Ansprüchen

Wir definieren also, was für unser Produkt wichtig ist und nur das testen wir. Wartbarkeit ist wohl in einem Wegwerfskript nicht relevant, also keine Code-Reviews. Das Skript läuft ein Mal in 24 Stunden? Naja, Performancetest sind wohl nicht angebracht. Ich übertreibe jetzt ein wenig, aber der Punkt sollte klar sein. Manchmal haben wir gar nicht den Anspruch perfekt zu sein und dann sollten wir dort auch nicht von schlechter Qualität sprechen.

In diesem Zeitalter hat man auch verstanden, was Risiken sind. Ein Leitsatz, der mich die letzten zwei Jahre begleitet ist „no risk, no test“. Risiko ist definiert als Eintrittswahrscheinlichkeit x Schaden. Ist der Schaden nicht hoch, wenn etwas kaputt geht, dann muss ich es vielleicht vorher auch nicht testen. Genau so ist es bei der Eintrittswahrscheinlichkeit. Ein Facebook-Kommentarsystem, welches ich bei mir eingebaut habe wird wohl nicht so schnell den Geist aufgeben. Trotzdem müssen wir testen, was riskant ist oder was unseren Ansprüchen entspricht.

Das schöne ist, dass wir alle Werkzeuge aus der vorhergegangenen Epoche weiterhin einsetzen können. Nur ein wenig gezielter. In diesem Zeitalter befinde ich mich gerade. Wir machen vor einem Projekt eine Risikoanalyse und erstellen dann ein Testkonzept. Alles zusammen mit dem Produktverantwortlichen.

Damit sind wir also in der Gegenwart angekommen. Trotzdem gab es bei unserer Präsentation noch eine weitere Evolutionsstufe. Den Homo Futuris. Über ihn haben wir beschrieben, wie wir uns das Testen in unserer Domäne in Zukunft vorstellen.Hier müssen wir aber auch wieder ein wenig ausholen. Es gibt Studien darüber, wie viele Features einer Software wirklich verwendet werden. Und was soll ich sagen? Es sind erstaunlich wenige.

Laut der Standish Group sind es nämlich nur knapp 30 Prozent. Über die Zahlen lässt sich natürlich bestens streiten. Die Idee dahinter sollte aber klar sein. Besonders im Netz ist das meiste was man anfasst kein Erfolg. Traurig aber wahr. Wie viele der Webseiten da draußen werden kaum oder gar nicht angesehen. Das sind sicher mehr als 30 Prozent. Aber so grausam ist das Leben nun mal.

Was wir auf jeden Fall aus diesem Fakt mitnehmen können, ist, dass man nicht immer zu den Gewinnern gehört. Und eine Frage sollte man sich ernsthaft stellen: „Wenn mein Feature zu 70% kein Erfolg ist, muss ich es dann überhaupt im vollen Umfang testen?“. Unserer Meinung nach nicht.

Hier fängt aber schon gleich das Umdenken an. Ob etwas ein Erfolg wird, kann ich im Vorfeld nicht sagen und wenn ich es könnte, würde ich irgendwo auf Hawaii liegen mit einem Schirmchen in meinem Cocktail. Wir würden also Software immer in einer „schlechten“ Variante livestellen. Jetzt kommt aber der wichtige Punkt. Wenn der Erfolg kommt und das Feature vom User angenommen wird, muss ich wieder zurück ans Reißbrett. Jetzt muss ich das Feature neu machen und auch testen. Wir haben also in unserem Entwicklungsprozess das Aufeinandertreffen zweier Welten. Homo Testnix trifft Homo Qualitäts. Und die zwei scheinen sich ganz gut zu verstehen. Wie man das Vorgehen den Produktverantwortlichen klar macht muss man erst noch rausfinden. Einfach ist es sicherlich nicht.

Das war auch schon unser Vortrag. Ich denke, dass er gut ankam und sehr viele Diskussionen ins Leben gerufen hat. Ihr dürft hier also auch loslegen.

Ach ja … hier noch die Folien: