Software-Testing: Auf der Jagd nach Bugs und Features

Software ist aus unserem Leben nicht mehr wegzudenken und steckt in nahezu allem, was einen Stecker oder einen Akku hat. Wenn mal etwas nicht funktioniert, reicht die Bandbreite von ‚ärgerlich‘ bis ‚Millionenschaden‘. Um Fehler so gering wie möglich zu halten, gibt es in ziemlich jedem IT-Unternehmen Tester. Warum rutschen Bugs trotzdem immer wieder durch? Was ist zu beachten? Und wie wird man eigentlich Software-Tester?

Auf den Satz „Irgendwas mit Medien“ stößt man immer wieder mal. Der Satz „Irgendwas mit IT“ ist dagegen noch nicht so populär. Eigentlich sollte er das aber sein. Entwickeln, Programme entwerfen, Codes schreiben – egal, erstmal für ein Informatikstudium einschreiben. Den Bereich Software-Testing hat dabei kaum jemand auf dem Zettel. Dabei ist er enorm wichtig.

Eine Software sollte einwandfrei funktionieren, so ist die Erwartungshaltung der User. Überwiegen Probleme und Fehlermeldungen, kann das schnell über den Erfolg oder Misserfolg eines Programms entscheiden. Es kommt auch immer wieder vor, dass fehlerhafte Software bei Unternehmen zu Schäden in Millionenhöhe führt. Durch eine ERP-Umstellung wollte ein Schokoladenhersteller beispielsweise eigentlich die Kosten senken, es lief aber etwas schief und es kam aber zu einer Überproduktion und zu einem Verlust von 14 Millionen Euro. Oder um etwas höher hinauszugehen: Bei der Ariane 5-Rakete wurde veraltete Software eingesetzt, die die Horizontalgeschwindigkeit zu niedrig berechnete. Schaden nach heutiger Kaufkraft: Fast 700 Millionen Euro.

Den einen richtigen und einzigen Weg, um Software-Tester zu werden, gibt es nicht. Aber oft sind Tester Menschen, die ganz klassisch Informatik studiert haben. Oder es wechseln erfahrene Entwickler zum Testing, um etwas Neues auszuprobieren. Auch mit einer informatiknahen Ausbildung kann der Schritt gelingen. Oder durch einen Abteilungswechsel – die Grenzen zum Testing sind meist nämlich nicht so streng festgelegt. Was den Job interessant macht: Tester müssen nicht unbedingt jedes Detail einer Software kennen, das ist eher der Bereich der Entwickler. Sie müssen dagegen vor allem den Blick des Kunden mitbringen. Und häufig auch über den Tellerrand schauen.

Bug-Suche bringt Wissenszuwachs

Auf der einen Seite gibt es feste Abläufe und Strukturen. Mal ist es der Test eines neuen Features, mal die Prüfung eines Fehlers. Oder die Durchführung von RC-, Release- oder Regressionstests. Besonders hilfreich ist der Einsatz einer Testautomatisierung, die sich regelmäßig wiederholende Testschritte durchführt. Ganz ohne menschliche Hilfe funktioniert so ein Tool aber eben nicht: Es muss regelmäßig mit Anforderungen und Testszenarien gefüttert werden, um einen wirklichen Mehrwert zu bieten.

Andererseits wird der Job trotz dieser Routinen und Hilfen nie langweilig. Abwechslung und Spannung gibt es täglich, weil man als Tester immer mit Aufgaben und Themen konfrontiert wird, die individuelle Herangehensweisen erfordern. Und das fachliche und technische Wissen wächst mit jeder Woche.

Grob lässt sich die Arbeit eines Testers in zwei Kategorien aufteilen: Die Bugsuche bei einem Launch bzw. vor dem Release eines Updates. Und die Fehlerbehebung, wenn ein User ein Problem gemeldet hat. Bei letzterer Variante beginnt die Suche meist damit, den Fehler auf einem aktuellen System nach den beschriebenen Reproduktionsschritten nachzuvollziehen. Wenn dies nicht gelingt, wiederholen wir das Prozedere auf einem System mit der gleichen Version wie die des Anwenders. Bringt auch das keinen Erfolg, lohnt sich ein genauer Blick auf das Kundensystem. Häufig werden Fehler durch spezifische Konfigurationen hervorgerufen. Diese Arbeit ist also oft eine Mischung aus analytischer Detektivarbeit und der genauen Abbildung der vom User durchgeführten Schritte.

Umso erfreulicher ist es aber, wenn wir die meisten schwerwiegenden Bugs schon im Vorfeld entdecken und beheben können. Dazu gibt es unterschiedliche Tests, die eine Software vor dem Release durchläuft. Eine komplett bug-freie Software ist aber utopisch. Fehler in einem Programm kommen aus unterschiedlichen Gründen immer wieder vor.

Bugs wird es immer geben

Sogar wer Chat GPT oder eine andere KI fragt, ob fehlerfreie Software möglich ist, bekommt als Antwort: Fehlerarm ja, fehlerfrei ist aber nahezu unmöglich. Dafür kommen einfach zu viele Variablen zusammen. Es beginnt schon beim Quellcode. Bei oft hunderttausenden Codezeilen, die miteinander interagieren, können selbst bei minimalen Änderungen plötzlich Fehler auftreten, die es am Tag zuvor noch nicht gab. Und auch, wenn ein Programm beim Entwickler rundläuft, muss es das nicht beim Kunden tun. Individuelle Konfigurationen und Hardware können ganz neue Probleme verursachen. Zudem kommen Bugs häufig erst nach einem Release zu Tage, weil etliche Anwender schneller auf einen Fehler stoßen als ein überschaubares Testing-Team.

Testerinnen und Tester müssen sich deshalb aber nicht in der Berufsehre verletzt sehen. Das Testing hat nun mal natürlich Grenzen, und diese liegen meist in der Wirtschaftlichkeit. Es wird immer eine gewisse Grauzone an Fehlern geben, die noch in der Software enthalten ist. Unternehmen müssen immer einen Kompromiss zwischen Fehlerkosten und Fehlerverhütungskosten finden. Und das tun sie, indem sie die Tragweite der Bugs abwiegen.

Bei unserem Unternehmen arbeiten wir mit fünf Fehlerklassen, kategorisiert von A bis E. Bei einem IT-Management-System wäre ein Fehler der Klasse A beispielsweise, dass unsere Partner und Kunden keine Tickets erstellen können. Ein schwerwiegendes Problem also, dass wir sofort beheben müssen. In Klasse E fallen dagegen vor allem triviale Probleme, wie etwa ein Rechtschreibfehler oder ein falsch ausgerichtetes Icon. Also Dinge, die sich höchstwahrscheinlich nicht geschäftsschädigend auswirken.

Um es etwas anschaulicher zu beschreiben: Selbst die Software des Space Shuttles enthielt Fehler, wenn auch nicht viele. Bei rund 420.000 Codezeilen hatte die NASA weniger als einen Fehler. Das haben sie geschafft, weil sie kein wirtschaftliches Unternehmen sind, sondern auf ein enormes, vom Staat getragenes Budget zurückgreifen konnten. Im Jahr 1973 kostete eine geschriebene, getestete und dokumentierte Codezeile etwa 1.000 Dollar. Durch die Inflation wären wir dafür heute bei 7.000 Dollar pro Zeile, oder insgesamt bei knapp drei Milliarden Dollar. Und das nur für die Software, eine Rakete wäre damit noch nicht gebaut.

Nicht jeder Bug ist schlecht

In den meisten Fällen sind Bugs nervig und mitunter teuer. Aber auch nicht immer. Nach einer Fehlermeldung schauen Tester meist, ob es sich wirklich um einen Bug handelt, oder nicht doch um ein Feature. Wenn es sich wirklich um einen neuen Fehler handelt, kommt es hin und wieder vor, dass er in die nächste Version des Systems integriert wird. Auch wenn er nicht vorgesehen war, sorgt ein Bug manchmal dafür, dass ein Programm etwa effektiver läuft oder dem User ein paar Zwischenschritte abnimmt.

Ein interessantes Beispiel für einen positiven Bug gab es schon vor fast 50 Jahren in dem Videospiel Space Invaders – vielleicht hat dieser sogar zum Erfolg des Titels beigetragen. Bei Space Invaders müssen die Spieler feindliche Raumschiffe abschießen. Was die Entwickler nicht geplant hatten: Je mehr Raumschiffe die Spieler erwischten, desto weniger Rechenleistung wurde benötigt. Das sorgte dafür, dass sich die verbliebenen Gegner schneller bewegten. Die Entwickler machten diesen Bug zum Feature, um den Schwierigkeitsgrad zu erhöhen.

Solche kuriosen Beispiele kommen immer wieder vor. Auch bei uns. Wir haben zum Beispiel einen Bug zum Montagsbug erklärt, weil er bei einem unserer Kunden immer nur an diesem einen Wochentag auftrat. Das Problem lag an einem Formatfehler in einem Datenbankfeld, wodurch es zu hunderten Fehlermeldungen kam. Es war eine wahre Odyssee, dieses Problem zu beheben. Aber auch das macht das Testing aus: Mal geht es um eine Herausforderung, mal um Detektivarbeit, und mal gibt es auch etwas zum Schmunzeln.