Eine fehlerhafte Security-Lösung hat kürzlich Millionen von Computern lahmgelegt. Frank Krahl, Testing-Koordinator beim Chemnitzer IT-Unternehmen KIX Service Software, arbeitet daran, solche Pannen im Vorfeld zu vermeiden. Im Interview verrät er, warum es keinen fehlerfreien Code gibt und warum Tester Detektivarbeit leisten.
Codes schreiben und Programme entwickeln ist für viele ein Traumberuf. Aber wie wird man eigentlich Tester?
Da gibt es unterschiedliche Wege. Oft sind es Entwickler, die Informatik studiert haben und etwas Neues ausprobieren wollen. Die andere Möglichkeit, so war es bei mir, ist eine informatiknahe Ausbildung mit mehr oder weniger direktem Weg in den Testing-Bereich. Ich war zunächst im Support eines Software-Unternehmens, wo sich mein Aufgabenbereich aber immer mal wieder mit dem Testing überschnitten hat. 2017 bin ich dann zu KIX gewechselt und heute koordiniere ich diesen Bereich. Tester müssen eine Software nicht zwangsläufig bis ins Detail kennen, das ist eher der Job der Entwickler. Aber dafür müssen sie mit den Augen eines Kunden darauf schauen. Und häufig auch über den Tellerrand.
Wie sieht ihr typischer Berufsalltag aus?
Wir haben feste Strukturen, Abläufe und Einzelschritte. Sei es beim Test einer neuen Funktion, bei der Prüfung eines Fehlers oder beim Durchführen von Release Candidate- oder Regressionstests. Wir legen neu entwickelte Funktionen und behobene Fehler auf den Prüfstand und testen sie auf das jeweilige erwartete Verhalten hin. Erst wenn wir alle Schritte durchgeführt haben, erteilen wir eine Freigabe.
Wie gehen Sie dabei konkret vor?
Zuerst versuchen wir das Problem auf einem aktuellen System nach den gemeldeten Schritten nachzuvollziehen. Gelingt dies nicht, versuchen wir dies auf einem System mit der gleichen Version wie beim Kunden. Gibt es auch hier keinen Erfolg, schauen wir uns das Kundensystem genauer an. Oft haben spezifische Konfigurationen einen wichtigen Anteil, um den Fehler hervorzurufen. Es ist also eine Mischung aus genauer Abbildung der vom Kunden durchgeführten Schritte und analytischer Detektivarbeit. Manchmal komme ich mir wie ein Ermittler vor. Am liebsten schnappe ich einen Bug allerdings im Vorfeld. Schließlich gibt es genügend Beispiele, bei denen eine fehlerhafte Software Schäden in Millionenhöhe verursacht hat.
Anzeige | Kostenloses Webinar der Trovarit-Academy
|
A
|
Testmanagement in Business-Software Projekten
|
18.10.2024 |
| Thema: | Testmanagement, Software-Einführung, Implementierung |
| Referent: | Peter Treutlein, Trovarit AG |
Hinter jedem Ermittler steht ein findiges Team. Nutzen Sie als digitaler Detektiv eigentlich auch digitale Assistenz, um Software-Fehler zu finden?
Ja, klar. Wir nutzen eine Testautomatisierung. Ein Tool, das Testschritte durchführt, die sich regelmäßig wiederholen, nimmt uns einen Teil unserer Arbeit ab. Unser Job ist es vor allem, dieses Tool mit den richtigen Anforderungen zu füttern. Wir definieren die Testszenarien und -schritte je nach Anforderungen, und das System arbeitet diese meist einmal pro Tag ab. Findet das Tool einen Fehler, erhalten wir eine Nachricht. So kommen wir effizient voran.
Bei KIX arbeiten Sie mit einem IT Service Management Tool auf Open Source-Basis. Setzt es Sie unter Druck, dass alle Anwender den Quellcode einsehen und von Ihnen übersehene Fehler entdecken können?
Ganz im Gegenteil! Die Vorteile eines offenen Quellcodes überwiegen deutlich. Bei tausenden Anwendern offenbart sich ein Problem schneller als im internen Testing- und Entwicklungsbereich. So kann eine viel größeren Zahl an Personen mögliche Fehlerquellen erkennen und oft sogar direkt beheben. Hin und wieder kratzt es zwar etwas an der Berufsehre, aber eine komplett fehlerfreie Software ist auch einfach utopisch. Sogar die Software des Space Shuttles enthielt Fehler.
Wie kann es sein, dass Bugs immer wieder durchrutschen?
Die natürlichen Grenzen des Testings liegen in der Wirtschaftlichkeit. Es gilt, immer einen Kompromiss zu finden zwischen den Kosten eines Fehlers und den Kosten der Fehlerverhütung. Das heißt im Umkehrschluss, dass es immer eine Grauzone an möglichen Fehlern gibt, die in der Software enthalten sind. Vor einem Release testen wir alle Funktionen, bei denen ein Fehler gravierende Auswirkungen auf das Geschäft des Kunden haben kann. Bei KIX arbeiten wir mit fünf Fehlerklassen von A bis E. Ein Fehler der Klasse A wäre bei uns beispielsweise, dass die User keine Tickets erstellen können. Ein schwerwiegendes Problem, das wir direkt beheben müssen. In Klasse E gehören eher triviale Dinge. Ist ein Icon falsch ausgerichtet oder ein Rechtschreibfehler enthalten, dann ist die Wahrscheinlichkeit sehr gering, dass dies zu einem geschäftskritischen Zustand führt.
Die wichtigsten Funktionen sind Bestandteil der Regressionstests. Die weniger wichtigen Testfälle werden nur ausgeführt, wenn es der zeitliche Rahmen erlaubt. Um nochmal das Beispiel mit dem Space Shuttle aufzugreifen: Bei der NASA gab es auf 420.000 Codezeilen weniger als einen Fehler. Die NASA konnte so arbeiten, weil sie kein wirtschaftliches Unternehmen ist, sondern ein vom Staat getragenes Budget hat. Eine geschriebene, getestete und dokumentierte Codezeile kostete die NASA im Jahr 1973 rund 1.000 US-Dollar. Inflationsbedingt wären das heute etwa 7.000 Dollar pro Zeile. Würde das Projekt heute genauso umgesetzt, wären alleine für die Software knapp drei Milliarden Dollar nötig. Und dann wäre noch keine Rakete gebaut.
Ist es auch schon mal vorgekommen, dass ein Bug am Ende nützlich war?
Hin und wieder kommt das schon vor. Wenn wir eine Fehlermeldung bekommen, schauen wir immer erstmal nach, ob es sich tatsächlich um einen Bug handelt. Der Satz ‚Das ist kein Bug, das ist ein Feature‘ kommt auch bei uns gelegentlich vor. Durch unsere Feature-Liste können wir schnell feststellen, ob das jeweilige Verhalten so gewollt ist oder nicht. Selbst wenn es ein neuer Bug ist, muss das nicht zwangsläufig schlecht sein. Manchmal gibt es Momente, in denen wir ein vermeintliches Problem in unsere Lösung integrieren – ein glücklicher Unfall, sozusagen. Das kommt in der Branche immer wieder mal vor. Ein bekanntes Beispiel dafür ist etwa der fast 50 Jahre alte Bug im Spiel Space Invaders. Je mehr Raumschiffe ein Spieler abgeschossen hat, desto weniger Rechenleistung war nötig. Das sorgte dafür, dass sich die verbliebenen Gegner schneller auf den Spieler zubewegten. Die Entwickler hatten das nicht vorgesehen, ließen es aber im Spiel, um die Schwierigkeit zu erhöhen.
Hatten Sie auch schon so seltsame Bugs, dass Sie darüber lachen konnten?
Witzige Erlebnisse haben wir immer wieder mal. Wir können darüber lachen, wenn die Auswirkungen nicht zu gravierend waren. Ein Beispiel ist der von uns so getaufte Montagsbug. Bei einem Kunden gab es einen ganz seltsamen Fehler in der Zeiterfassung, der immer nur an Montagen auftrat. Es war eine Odyssee, das den Software-Fehler zu finden und zu beheben, weil wir es nur an diesem einen Wochentag beobachten konnten. Letztendlich war es ein Formatfehler in einem Datenbankfeld, der zu hunderten Fehlermeldungen geführt hat. Einen anderen lustigen Fehler hatten wir bei der Kontaktsynchronisation in einem LDAP-System (Lightweight Directory Access Protocol), bei dem zufällige Vor- und Nachnamen erstellt wurden. Hier haben wir relativ schnell gemerkt, dass das System anstatt der Kundendaten unsere Demo-Daten geladen hat. Jürgen Frisch
Im Interview
Frank Krahl ist Testing-Koordinator beim Chemnitzer IT-Unternehmen KIX Service Software.