Irren ist menschlich; Testing ist nötig, wenn eine Applikation Kunden begeistern und nicht ärgern soll. Dorian schreibt über die Anstrengungen bei Nektoon, möglichst viele Fehler zu eliminieren.
Von Dorian Selz, Nektoon
Es ist nur allzu menschlich nach Perfektion zu streben, aber dieses Ziel immer knapp zu verfehlen. Mit gemischten Gefühlen erinnere ich mich zurück an die Deutschstunden in meiner Schulzeit. Wir mussten recht häufig Aufsätze schreiben und ebenso häufig bekam ich gute Noten für meine Ideen und weniger gute Noten für meine (natürlich unbeabsichtigten) grammatikalischen Fehler.
Bei der Software-Entwicklung verhält es sich nicht unähnlich: Die elegantesten Code-Zeilen werden durch banale Fehler sabotiert.
Wie sagt man so schön: Fehler erkannt, Fehler behoben… Und doch, Studien zeigen, dass im Durchschnitt mit sechs behobenen Fehlern, ein neuer sich einschleicht. Dies erinnert an die Geschichte des mythischen Helden Achilles, der den Wettlauf gegen eine Schildkröte verliert.
Eine skalierbare Website ist ein komplexes Biest. Selbst in ihrer einfachsten Ausgestaltung besteht sie aus Tausenden von Code-Zeilen, mehreren Servern und Services.
Menschen funktionieren einigermassen gut, in einem Umfeld relativer Unsicherheit – Computer nicht. Während wir in der Lage sind, uns anzupassen, versagen Computer erbärmlich, wenn nicht völlig klar ist, was sie tun sollen, wenn sie mit fehlerhaften Code-Zeilen konfrontiert werden. Eine unerkennbare Zeichenfolge in einer get-Abfrage genügt und der empfangende Webservice liegt flach. Ein kleiner Fehler in einer Sub-Routine kann eine Transaktion lahm legen.
Deshalb ist Software-Testing wichtig
Es gibt verschiedene Möglichkeiten zu testen. Jeder Entwickler wird zustimmen, dass Code getestet werden muss. Testing eines individuellen Code-Fragments reicht aber bei weitem nicht aus. Besonders hart wird es, wenn man Code-Altlasten übernehmen muss, die bisher kaum getestet wurden. Mein Kollege Patrice zählt auf zwei einfache Regeln:
1. Kein Bugfix, ohne Testing
2. Neue Features werden nach einer testgetriebenen Methode entwickelt, Code muss möglichst testbar sein.
Bei Nektoon versuchen wir so viel Code wie möglich – und sinnvoll – zu testen. Wir können natürlich nicht 100% abdecken, aber gegen 98% sollten es schon sein. Wer wirklich 100% testen will, dreht durch: Viel Code wurde geschrieben, ohne dessen Testfähigkeit je bedacht zu haben. Das Testing solcher Zeilen ist wohl möglich, wird aber enorm viel Zeit kosten.
Eine gewisse Fehlerquote halten wir für tolerabel für ein System wie das unsrige. Um die Sache mit geringem Aufwand zu entschärfen, kann Redundanz eingebaut werden.
Testing erachten wir als integralen Bestandteil unserer Arbeit. Bevor die Applikation automatisch kompiliert wird (wir sprechen von kontinuierlicher Integration – vergleiche meinen Post über Automation), muss jedes Stückchen Code gründlich getestet werden.
Die Gleichung ist einfach: Wie viel Nutzen erwächst uns aus der zusätzlich investierten Zeit in Testing? Die Antwort: Sehr viel! Einfacherer Code, mehr Zuverlässigkeit, weniger lästiges Bugfixing und weniger enttäuschte Kunden, weil wieder einmal das System ausfiel.
Wir glauben an Testing. Auf seinem persönlichen Blog hat Patrice eine Serie nur zu diesem Thema begonnen. In den nächsten Wochen schreibt er über die Auswahl und das Aufsetzen eines Testing-Systems, Einheits- und funktionales Testing, Javascript-Testing, kontinuierliche Integration, Testing-orientierte Entwicklung, Testfähigkeit und den Abdeckungsgrad.
In dieser Serie erwartet Euch als nächstes: Schlussfolgerungen.
