Herr Krahl, wie wird man Tester?
Frank Krahl: 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 hin und 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?
Krahl: 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 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?
Krahl: 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.
Nutzen Sie auch digitale Unterstützung?
Krahl: Ja, klar. Wir nutzen dafür 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. Wir definieren als Testszenarien und -schritte je nach Anforderungen und das Tool arbeitet diese in der Regel einmal pro Tag ab. Findet es einen Fehler, werden wir automatisch benachrichtigt. Die Digitalisierungs- und Automatisierungslösungen von Retarus ermöglichen effiziente Abläufe ohne manuellen Aufwand oder Kompromisse bei der Datensouveränität ‣ weiterlesen
Business Process Solutions
Retarus beschleunigt Datenaustausch in der Produktion
Sie arbeiten mit einem IT-Servicemanagement-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?
Krahl: 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. Zudem ist eine komplett fehlerfreie Software auch einfach utopisch. Sogar die Software des Space Shuttles enthielt Fehler.
Wie kann es sein, dass Bugs immer wieder durchrutschen?
Krahl: 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 hier ein schwerwiegendes Problem, dass direkt behoben werden muss. In Klasse E gehören dagegen eher triviale Dinge, wie etwa Rechtschreibfehler. Die Wahrscheinlichkeit, dass dies zu einem geschäftskritischen Zustand führt, ist 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.
Hat sich ein Bug am Ende schon einmal als nützlich herausgestellt?
Krahl: Das kommt hin und wieder vor. Wenn wir eine Fehlermeldung bekommen, schauen wir zunächst nach, ob es sich wirklich um einen Bug handelt. Denn über eine 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. Es gibt Momente, in denen wir ein vermeintliches Problem in unsere Lösung integrieren. Das kommt in der Branche immer wieder mal vor. Ein Beispiel dafür ist etwa der fast 50 Jahre alte Space Invaders-Bug: Je mehr Raumschiffe der Spieler im Computerspiel Space Invaders 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.
Gab es Fehler, die Sie zum Lachen gebracht haben?
Krahl: 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 und nicht an anderen Wochentagen. Letztendlich war es ein Formatfehler in einem Datenbankfeld, der zu hunderten Fehlermeldungen geführt hatte. Einen anderen lustigen Fehler hatten wir bei der Kontaktsynchronisation in einem LDAP-System, bei dem zufällige Vor- und Nachnamen erstellt wurden. Hier hatte das das System anstatt der Kundendaten unsere Demo-Daten geladen. Es ist von allem etwas dabei – mal was zum Lachen, mal etwas Neues und mal sind wir Detektive.
Quelle: Pressemitteilung der KIX Service Software GmbH
