Software, die das Leben erleichtern oder unterhalten soll, führt oft zu Problemen. Bugs sorgen regelmäßig für Frust bei den Usern, doch die Ursachen sind meist komplex. Trotz automatisierter Tests sind Fehler nie vollständig vermeidbar. Frank Krahl, Testing-Koordinator bei KIX Service Software, berichtet im Interview mit IT WELT.at aus seinem Alltag. [...]
Viele Menschen möchten in der IT arbeiten. Den Testing-Bereich haben dabei nur wenige auf dem Schirm. Wie sind Sie hier gelandet?
Eine gerade Linie war es zumindest nicht. Eigentlich wollte ich mal Astronaut werden, aber dann habe ich doch eine Ausbildung zum technischen Assistenten für Qualitätssicherung gemacht und einige Jahre im Support eines IT-Unternehmens gearbeitet. Dort kam ich auch schon hin und wieder mit dem Testing in Kontakt. 2017 bin ich zu KIX gewechselt, wo ich seitdem die Testing-Abteilung koordiniere. Bei meinen Kollegen war es ähnlich, sie kommen auch aus allen Himmelsrichtungen – aus dem Support, dem Sales-Bereich oder der Entwicklung. Das finde ich so toll an dem Job: Wir Tester müssen nicht unbedingt jedes Detail einer Software kennen, dafür aber offen für ungewöhnliche Herangehensweisen sein. Genau wie Detektive, und so komme ich mir manchmal vor.
Routine ist für Sie also ein Fremdwort?
Nicht ganz. Einerseits haben wir feste Strukturen und Abläufe. Die Routine besteht meist darin, neue Funktionen und behobene Fehler zu prüfen und auf das erwartete Verhalten hin zu checken. Andererseits landen auch jeden Tag neue Themen und Aufgaben auf unseren Tischen, wodurch wir unser fachliches und technisches Wissen regelmäßig erweitern. Ich würde es also als eine spannende Mischung beschreiben. Das kann etwa die Prüfung eines Fehlers sein, der Test einer neuen Funktion, oder dass wir beispielsweise RC-, Release- und Regressionstests durchführen. Über Langeweile und einen drögen Alltag können wir uns jedenfalls nicht beschweren.
Was passiert genau, wenn ein Kunde Ihnen ein Problem meldet?
Zuallererst müssen wir das Problem verstehen. Dazu nehmen wir die Informationen des Kunden und versuchen den Fehler auf einem aktuellen System zu reproduzieren. Wenn wir damit keinen Erfolg haben, wiederholen wir das Szenario, diesmal aber auf einem System mit der gleichen Version wie beim Kunden. Kommen wir auch hier nicht weiter, nehmen wir das Kundensystem genau unter die Lupe. Das ist dann der Punkt, an dem die Detektivarbeit beginnt. Da unsere ITSM-Software viele Konfigurationsmöglichkeiten bietet, liegt das Problem oft in den individuellen Einstellungen. Am liebsten ist es uns aber natürlich, wenn wir alle Fehlerquellen schon vorher aus dem Weg räumen. Manchmal sind Bugs einfach nur nervig, sie können auch schnell teuer werden. Vor ein paar Jahren wollte ein Schokoladenhersteller beispielsweise seine Kosten durch eine ERP-Umstellung senken. Durch einen Fehler im System kam es aber zu einer Überproduktion und einem Verlust von 14 Millionen Euro.
Sind bei Ihnen auch digitale Helfer im Einsatz?
Klar, und das kann ich allen Kolleginnen und Kollegen aus dem Testing auch nur empfehlen, weil man damit einfach deutlich effizienter vorankommt. Wir setzen beispielsweise ein Tool zur Testautomatisierung ein. Es führt Testschritte, die immer wieder vorkommen, von alleine durch und informiert uns, sobald etwas an irgendeiner Stelle nicht rundläuft. Die Beine hochlegen können wir dadurch zwar nicht, weil wir es regelmäßig mit Anforderungen und Testszenarien füttern müssen. Eine enorme Hilfe ist es aber trotzdem, da es uns viel zeitraubende Arbeit abnimmt.
Das IT-Service-Management-System KIX beruht auf Open Source. Haben Sie manchmal ein mulmiges Gefühl, dass alle User den Quellcode einsehen und von Ihnen übersehene Fehler entdecken können?
Eher nicht, dafür bin ich einfach ein viel zu großer Fan von Open Source. Ich finde es super, dass so viele Menschen zusammen an einem Code arbeiten, Fehler entdecken und oft sogar direkt beheben. Es ist ganz natürlich, dass ein Fehler bei tausenden Anwendern schneller auffällt als in einem überschaubaren Testing-Team. Klar wäre es uns lieber, das perfekte System auszuliefern, aber eine komplett fehlerlose Software ist und bleibt einfach utopisch. Sogar in der Software des Space-Shuttles hat es Fehler gegeben.
Wieso schaffen es eigentlich Bugs immer wieder in die Software?
Wie gesagt – eine perfekte Software wird es nie geben. Wir müssen immer eine Balance zwischen Fehlerkosten und Fehlerverhütungskosten finden, wodurch eine Grauzone mit möglichen Fehlern in einer Software entsteht. Vor einem Release achten wir vor allem darauf, dass es keine Bugs mehr gibt, die sich geschäftsschädigend beim Kunden auswirken. Bei KIX arbeiten wir dafür beispielsweise mit den Fehlerklassen A bis E. Ein Fehler der Klasse A wäre etwa, dass die User keine Tickets mehr erstellen können. Die Lösung eines solch massiven Problems hat für uns dann die höchste Priorität. In Kategorie E fallen dagegen eher banale Dinge wie Rechtschreibfehler oder schief sitzende Icons. Also Dinge, die sich sehr wahrscheinlich nicht negativ auf das Geschäft des Kunden auswirken, falls sie ihm überhaupt auffallen.
Der Vergleich mit dem Space Shuttle macht es vielleicht anschaulicher: Es gab hier zwar Bugs in der Software, auf 420.000 Codezeilen allerdings weniger als einen. Der NASA ist das gelungen, weil sie bei diesem Prestigeprojekt ein nahezu unbegrenztes Budget vom Staat zur Verfügung hatte. Damals, in den 1970er Jahren, hat eine geschriebene, getestete und dokumentierte Codezeile rund 1.000 Dollar gekostet. Das entspricht einem heutigen Wert von etwa 7.000 Dollar. Oder insgesamt knapp drei Milliarden Dollar alleine für die Software. Ohne Hardware: Shuttle, Rampe und Rakete
Dass Bugs schnell teuer werden können, haben Sie schon erwähnt. Ist Ihnen aber auch schon mal ein hilfreicher Fehler untergekommen?
Oh ja, auch das gibt es hin und wieder. Wenn bei uns eine Fehlermeldung landet, schauen wir zunächst erstmal nach, ob es sich um einen Bug oder vielleicht um ein vom Anwender falsch genutztes Feature handelt. Und auch wenn es wirklich ein Bug ist, muss das nicht unbedingt schlecht sein. Manchmal sorgt ein Fehler dafür, dass das System runder läuft oder die User sich ein paar Klicks sparen. Und solche hilfreichen Unfälle werden dann manchmal auch zu einem festen Bestandteil unserer Lösung. Das ist übrigens auch nicht ungewöhnlich in der Software-Branche. Schon vor fast 50 Jahren hat es in dem Spiel Space Invaders einen Bug gegeben, der womöglich sogar zum Erfolg des Titels beigetragen hat. Immer wenn der Spieler eins der feindlichen Raumschiffe abschoss, wurde weniger Rechenleistung benötigt und die verbliebenen Gegner bewegten sich schneller voran. Gewollt war das nicht, aber da es die Spannung erhöhte, haben die Entwickler den Bug nie gefixt.
Und was sind die seltsamsten Bugs, mit denen Sie bisher zu tun hatten?
Wir mussten schon einige komische Bugs in den Griff bekommen. Meist können wir aber erst im Anschluss darüber lachen, wenn die Auswirkungen und die Lösung nicht zu kompliziert waren. Bei einem Fall wurden etwa in der Kontaktsynchronisation eines LDAP-Systems willkürliche und teils skurille Vor- und Nachnamen erstellt. Das Problem hatten wir aber schnell gefunden: Anstatt der Kundendaten wurden unsere Demo-Daten in das System geladen. Ein anderes Mal hatten wir einen Bug, der bei uns schon fast einen legendären Status erreicht hat – wir haben ihn den Montagsbug getauft. Ein Kunde hatte uns gemeldet, dass bei ihm jeden Montag hunderte Fehlermeldungen auftreten. Hier mussten wir wieder unsere Sherlock Holmes-Mützen aufsetzen, bevor wir das Problem lösen konnten. Letztendlich lag es an einem kleinen Formatfehler in einem Datenbankfeld. Solche Fälle machen den Job für mich aber aus: Es passiert immer was Neues, wir sind Jäger und Detektive, und manchmal treffen wir auf sehr skurrile Probleme. Aufregend ist es im Testing jedenfalls immer.
Be the first to comment