Kategorien
Die Schönheit des Durchschnitts
Heute ist der Tag an dem ich eine neue Kolumne einführen möchte. Lean Testing soll sie heißen und sich damit beschäftigen, wie man Software am besten im heutigen agilen, schlanken und Start-Up-Umfeld testen sollte. Ich werde aber ganz sicher bald eine genaue Definition des Begriffs online stellen.
Fangen wir aber mal mit einem einfachen Thema an. Grenzwertanalyse. Nehmen wir uns eine Methode, die z.B. E-Mail-Adressen validiert. Wenn ich diese Methode mit Unit Tests abdecken will, dann haben wahrscheinlich einige Tests. Kann man ja mal im Kopf durchspielen: was wäre wenn man eine E-Mail-Adresse wie langner@nils@example.de eingibt oder langner.example.de oder @example. Uns fallen sicher noch viele Dinge ein, die man testen könnte. Wenn man jetzt für jede der möglichen Äquivalenzklassen ein Beispiel durchtestet, dann müsste man eine sehr gute Unit-Test-Abdeckung haben und alles ist gut. Wahrscheinlich wird man es so auch in vielen Lehrbüchern so finden. Sicherlich hat man ein wirklich robustes Stück Software, wenn man so vorgeht.
Aber wir wollen ja heute den Lean-Testing-Ansatz anwenden und da würde ich sagen, dass das viel zu viel ist, was man testet. Mir geht es hauptsächlich darum, vor dem Testen den Businesswert von dem was man da gerade macht zu betrachten. Klar ist es toll jede Eventualität abgedeckt zu haben, aber mal ganz ehrlich, war würde es kosten, wenn ein Anmeldeformular E-Mail-Adressen annehmen würde, die zwei @-Zeichen drinnen haben? Nichts? Wäre relativ egal. Dann hat man eben da eine ungültige Adresse im System. Das Beispiel mag vielleicht nicht immer passen, aber ich hoffe ihr versteht die Idee.
Jetzt einfach mein Gedankenexperiment. Was wäre, wenn ihr einfach eine durchschnittliche E-Mail-Adresse nehme und sicherstellt, dass diese erkannt wird. Aus Businesssicht hätte ich damit wahrscheinlich 99% der Fälle bereits abgedeckt. Alles was jetzt noch kommt ist Kür und hat nicht wirklich einen Mehrwert.
Die Frage, die ich in den Raum stellen will ist folgende: Ist es nicht meistens aus Businesssicht ausreichend, wenn man nur den Durchschnittswert durchtestet? Würde man nicht sehr viel Zeit und Kosten sparen, wenn man sich darauf konzentriert? Ich glaube schon, denn es ist erstmal wichtig rauszufinden, ob ein Produkt am Markt überhaupt angenommen wird, bevor man das „perfekte“ Produkt baut.
PS: Ja ich weiß, dass man mit Unit Tests auch schöneren/sauberen Code hinbekommt, aber das klammer ich hier mal aus.
Die grundsätzliche Haltung, nur so viel zu testen, wie für den business case sinnvoll ist, finde ich gut. Das Beispiel E-Mail zeigt aber auch, dass die Antwort in einigen Fällen von vielen verschiedenen Business-Faktoren abhängt: zum einen der reine Use-Case („Um die Anwendung nutzen zu können, muss ich der Benutzer mit einer E-Mail-Adresse anmelden können“). Aber es sind auch Faktoren wie Sicherheit und Usability betroffen. Wie viel Geld verliere ich, wenn ich das Format der Mailadresse abfrage, aber nicht teste, ob die Mailadresse wirklich dem Benutzer gehört (per opt.in Verfahren) und ich Opfer von Betrug werde? Wie viel Geld verliere ich, wenn sich Benutzer bei der Anmeldung vertippen, keine Rückmeldung bekommen und frustriert aufgeben? Und wie wäge ich diese Kosten ab gegen die Kosten, die durch umfangreichere Unit-Tests entstehen?