Thought Leadership
Die Meisten haben es schon erlebt: Ein Computer-Programm, eine Handy-App oder ein Videospiel tut einfach nicht das, was es tun soll. Stattdessen erscheint ein Fehlercode auf dem Display, oder es geht einfach gar nichts mehr. Ärgerlich, und häufig mit der Frage verbunden: Wie kann das eigentlich sein?
Um solche Probleme im Vorfeld zu erkennen und zu minimieren, gibt es Menschen wie Frank Krahl. Der 39-jährige ist Testing-Koordinator beim Chemnitzer IT-Unternehmen KIX Service Software. Mit seinem Team spielt er täglich die unterschiedlichsten Testszenarien durch – von automatisierten Abläufen bis zu Regressionstests.
Im Interview verrät er, wieso es fehlerfreie Software nicht gibt, warum Tester oft Detektivarbeit leisten und wie ein Bug auch mal zu einem Feature werden kann.
Lieber Herr Krahl, Codes schreiben und Programme entwickeln ist sicherlich für viele ein Traumberuf. Aber wie wird man eigentlich Tester?
Da gibt es unterschiedliche Wege. Oft sind es Entwickler, die ganz klassisch 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.
Den typischen Alltag gibt es bei Ihnen also gar nicht?
Wir haben schon feste Strukturen, Abläufe und Einzelschritte. Sei es beim Test einer neuen Funktion, bei der Prüfung eines Fehlers oder der Durchführung von RC-, Release- oder Regressionstests. Der gewöhnliche Alltag besteht darin, neu entwickelte Funktionen und behobene Fehler auf den Prüfstand zu bringen und auf das jeweilige erwartete Verhalten hin zu checken. Spannend und abwechslungsreich ist aber, dass wir täglich mit neuen Themen und Aufgaben konfrontiert werden und wir unser technisches und fachliches Wissen so andauernd erweitern. Langweilig wird es bei uns jedenfalls nie. Und 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 Reproduktionsschritten nachzuvollziehen. Gelingt dies nicht, versuchen wir dies auf einem System mit der gleichen Version wie die des Kunden. Gibt es auch hier keinen Erfolg, schauen wir uns das Kundensystem genauer an. Nicht selten sind die spezifischen Konfigurationen ein wichtiger Teil, 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 (lacht). Am liebsten schnappe ich den Täter bzw. den Bug aber natürlich im Vorfeld. Es gibt bereits genügend Beispiele, bei denen ein fehlerhaftes Programm Schäden in Millionenhöhe verursacht hat.
Hinter jedem Ermittler steht ein findiges Team. Nutzen Sie als digitaler Detektiv eigentlich auch digitale Assistenz?
Ja, klar. Wir nutzen dafür, und das kann ich allen Kolleginnen und Kollegen nur empfehlen, eine Testautomatisierung. Also ein Tool, das Testschritte durchführt, die sich regelmäßig wiederholen. Das nimmt uns einen Teil unserer Arbeit ab, unser Job dabei ist es vor allem, dieses Tool mit Anforderungen zu füttern. Das bedeutet: Wir definieren die Testszenarien und -schritte je nach Anforderungen und es arbeitet diese in der Regel einmal pro Tag ab. Findet das Tool einen Fehler, werden wir automatisch benachrichtigt. So kommen wir deutlich effizienter voran.
Mit KIX arbeiten Sie mit einem ITSM-System auf Open Source-Basis. Setzt es Sie besonders unter Druck, dass alle User den Quellcode einsehen und von Ihnen übersehene Fehler entdecken können?
Ganz im Gegenteil, dafür überwiegen die Vorteile eines offenen Quellcodes einfach. Mögliche Fehlerquellen können von einer viel größeren Zahl an Personen erkannt und häufig sogar direkt behoben werden. Bei tausenden Anwendern offenbart sich ein Problem einfach schneller als im internen Testing- und Entwicklungsbereich. Hin und wieder kratzt es zwar schon 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 meist in der Wirtschaftlichkeit. Es gilt immer einen Kompromiss zwischen Fehlerkosten und Fehlerverhütungskosten zu finden. Das heißt im Umkehrschluss, dass es immer eine sogenannte Grauzone an möglichen Fehlern gibt, die in der Software noch enthalten sind. Vor einem Release werden die Tests ausgeführt, die alle wichtigen Funktionen abdecken, deren Fehlfunktion gravierende Auswirkungen auf das Geschäft des Kunden haben könnten.
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. Also ein schwerwiegendes Problem, das wir direkt beheben müssen. In Klasse E gehören dagegen eher triviale Dinge. Wenn ein Icon falsch ausgerichtet oder ein Rechtschreibfehler enthalten ist, dann ist die Wahrscheinlichkeit, dass dies zu einem geschäftskritischen Zustand führt, sehr gering. Die wichtigsten Funktionen sind dann Bestandteil des Regressionstests. Die geringfügig 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. Das ist ihnen gelungen, weil sie kein wirtschaftliches Unternehmen sind, sondern ein großes, vom Staat getragenes Budget haben. Eine geschriebene, getestete und dokumentierte Codezeile kostete die NASA im Jahr 1973 rund 1.000 US-Dollar. Inflationsbedingt wären wir dafür heute bei etwa 7.000 Dollar pro Zeile. Oder anders ausgedrückt: Würde das Projekt heute genauso umgesetzt werden, wären alleine knapp drei Milliarden Dollar für die Software nötig. Und dann wäre noch keine Rakete gebaut.
Ist es auch schon mal vorgekommen, dass ein Bug am Ende nützlich war?
Klar, hin und wieder kommt das schon vor. Wenn wir eine Fehlermeldung bekommen, schauen wir immer erstmal nach, ob es sich wirklich um einen Bug handelt. Der Satz ‚Das ist kein Bug, das ist ein Feature‘ kommt bei uns gelegentlich vor (lacht). Durch unsere Feature-Liste können wir schnell feststellen, ob das so gewollt ist oder nicht. Und 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 Space Invaders-Bug. In Kurzfassung: Je mehr Raumschiffe der Spieler abschoss, desto weniger Rechenleistung wurde benötigt. 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.
Und hatten Sie auch schon so seltsame Bugs, dass Sie darüber nur lachen konnten?
Witzige Erlebnisse haben wir immer wieder mal. Zumindest können wir dann im Anschluss öfter darüber lachen, wenn die Auswirkungen nicht zu gravierend waren.
Ein Beispiel wäre etwa der von uns so getaufte Montagsbug. Bei einem unserer Kunden gab es einen ganz seltsamen Fehler in der Zeiterfassung, der immer nur an Montagen auftrat. Es war eine Odyssee, das Problem zu finden und zu beheben, eben 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, bei dem zufällige Vor- und Nachnamen erstellt wurden. Hier haben wir aber relativ schnell gemerkt, dass das System anstatt der Kundendaten unsere Demo-Daten geladen hat.
Bei uns im Softwaretesting ist jedenfalls von allem etwas dabei – mal was zum Lachen, mal etwas Neues und mal sind wir Detektive. Spannend bleibt es immer, und früher oder später kommen wir allen Bugs auf die Schliche.
(ds/KIX Service Software)
