Weniger Bugs – Tipps zum Fehlermanagement im Softwarebereich

In IT-Unternehmen sehen sich die Mitarbeiter jeden Tag mit Softwarefehlern konfrontiert. Sobald ein Bug festgestellt wird, gilt es diesen schnellstmöglich zu beheben. Aber ist Bug gleich Bug? Je nachdem in welche Kategorie sich der jeweilige Fehler einordnen lässt und welche Auswirkung dieser auf die Programmierung beziehungsweise das System hat, gibt es unterschiedliche Lösungsmethoden zur Fehlerbehebung. In meinem Beitrag kategorisiere ich die unterschiedlichen Arten von Bugs. Anschließend gebe ich Tipps wie Fehler schon bei der Erstellung vermieden werden können.

Dafür bieten sich an:

• agile Projektframeworks wie Scrum oder Kanban
• mehr Sorgfalt bei der Planung
• bessere Projektmanagement-Methoden

Die Frage, warum Softwarefehler auch Software Bugs genannt werden, lässt sich mit einem Blick auf die Geschichte beantworten. Interessanterweise wurde der Begriff nämlich bereits vor der Computerzeit benutzt – und zwar zur Zeit von Thomas Alva Edison (1847 – 1931). Damals wurden kleine Fehler an elektrischen Bauteilen als Bugs bezeichnet. Denn das Knistern und Rauschen hörte sich so an, als ob kleine Wanzen und Käfer (englisch = bugs) an den Kabeln knabbern würden. Zusätzlich trägt eine amüsante Legende zur Begriffserklärung bei. Diese besagt, dass am 9. September 1945 eine Motte in einem Relais des Computers Mark II Aiken Relay Calculators zu einer Fehlfunktion führte. Die Motte wurde entfernt und in das Logbuch geklebt mit den Worten „Das erste Mal, dass tatsächlich ein Käfer (Bug) gefunden wurde.“

Bug ist nicht gleich Bug

Die wichtigste Tatsache in Bezug auf Softwarefehler lautet: Jedes Programm mit etwas Komplexität enthält Bugs. Ob Smartphone oder Computer, diese Aussage gilt für alle Betriebssysteme genauso wie für die auf diesen Geräten installierten E-Mail-Programme. Die Bugs sind nur noch nicht bekannt oder behoben. Möglicherweise ist ihre Auswirkung aber auch so gering, dass sie nicht auffallen und niemals bemerkt werden. Aber zu vermeiden sind sie nicht. Wie schwerwiegend solche Fehler tatsächlich sind, hängt immer von der Art der Bugs und von ihren auswirkenden Folgen ab.

Bugs ohne schlimme Auswirkungen

Solche Fehler haben lediglich Darstellungsprobleme oder einfache „Unschönheiten“ zur Folge, sie beeinträchtigen aber in der Regel die Hauptfunktionalität der Software nicht oder nur geringfügig. Häufig werden diese Bugs gar nicht erst beseitigt, da das Kosten-Nutzen-Verhältnis einer Behebung nicht angemessen ist.

Bugs, deren Auswirkung über lange Zeit unbemerkt bleiben

Hier handelt es sich um Fehler, die beispielsweise bei einer besonderen Nutzung oder nach Erstellung eines Jahresreports auffallen. Sie haben in der Regel eine aufwendige Behebungen oder Datennacherfassungen zur Folge (z.B. wenn über einen längeren Zeitraum hinweg Daten falsch gespeichert wurden).

Bugs, welche die Funktionalität der Software einschränken und deren Benutzung behindern

Diese Fehler sind am offensichtlichsten und werden im Allgemeinen schnell behoben, da bei ihnen meist ein direkter Zusammenhang zwischen dem fehlenden beziehungsweise nicht funktionierenden Feature und dem Fehler besteht. Wenn der Fehler so schwerwiegend ist, dass die Software nicht mehr sinnvoll benutzbar ist, kostet das im Unternehmenseinsatz viel Produktivität und damit Geld – selbst wenn die Fehler schnell behoben werden.

Bugs, die den stabilen Betrieb behindern oder unmöglich machen

Bei Stabilitätsproblemen, die nur unter bestimmten Bedingungen auftreten, ist die Behebung von Bugs schwierig. Das zeigt sich zum Beispiel bei Betriebssystemen, die immer mal wieder abstürzen und die wie bei älteren Windows-Versionen zu einem Blue Screen führen. Selbst Mac OS oder Linux-Systeme sind nicht vor einem Crash gefeit. In diesen Fällen ist es nicht immer einfach, die Problemstellung genau nachzubilden, um den Fehler zu finden und im Anschluss zu korrigieren. Wird jedoch die Fehlfunktionen nicht behoben, kann es zu schwerwiegenden Problemen kommen. Manchmal liegen die Probleme schon in der zu Grunde liegenden Konzeption – und diese ist im Nachhinein nur mit großem Aufwand oder gar nicht zu ändern. Im schlimmsten Fall scheitert ein ganzes IT-Projekt an einem Bug und muss neu aufgesetzt werden. Das passiert in der Praxis im Übrigen gar nicht so selten, wie man gemeinhin annehmen möchte.

Bugs, die eine Sicherheitslücke darstellen und einen Angriff auf das System oder die gespeicherten Daten erlauben

Diese Fehlerkategorie ist am problematischsten – und zwar nicht zuletzt deshalb, weil Sicherheitslücken häufig erst nach Jahren entdeckt werden. Jedes komplexe System enthält hunderte oder tausende Bugs, dementsprechend gibt es viele potenzielle Sicherheitslücken. Zu einem Problem werden solche Lücken immer dann, wenn sie zwar jemand entdeckt, sie aber geheim hält, weil er keine guten Absichten hat oder sie zu kriminellen Zwecken nutzen will. Gerüchten zufolge bezahlen sogar Geheimdienste Hacker dafür in bestimmten IT-Systemen nach unbekannten Sicherheitslücken zu suchen. Aber nicht, um diese öffentlich zu machen, sondern um sich darüber unbemerkt Zugriff auf Daten zu verschaffen. Die Krux an dieser Sache: In solchen Fällen erfahren die Hersteller oder die Open Source Community gar nicht oder erst sehr spät von der Lücke und können diese auch nicht zeitgerecht schließen. Nur wenn die Sicherheitslücke bekannt wird, kann der Hersteller Gegenmaßnahmen ergreifen und sie schließen. In der Realität dauert dieser Vorgang vielfach Wochen oder Monate.

Je bekannter eine Lücke wird, desto mehr Informationen erhalten potenzielle Angreifer im Internet über die Schwachstelle. Ab einem gewissen Bekanntheitsgrad sind selbst Hobby-Hacker in der Lage eine Sicherheitslücke zu überwinden und Schaden anzurichten. Positiv ist auf der anderen Seite, dass immer mehr Nutzer informiert werden. Sie können sich anschließend gegen mögliche Angriffe schützen oder die betroffene Software temporär nicht benutzen. In diesen Fällen spielt der Hersteller in der Regel kurzfristig einen Patch ein, wobei es trotzdem oft sehr lange dauert, bis die Gefahr gebannt und eine Sicherheitslücke komplett geschlossen wird.

Der bestmögliche Schutz vor Problemen im Zusammenhang von Softwarefehlern steht in jeder Unternehmens-IT im Mittelpunkt.

Software Bugs – alles Definitionssache?

Neben der korrekten Einteilung von Bugs in verschiedene Kategorien, besteht eine weitere Herausforderung in der Definition eines Softwarefehlers. Über die korrekte Begriffsbestimmung herrschen unterschiedliche Meinungen. Sebastian Krack, Leiter der Softwareentwicklung bei Adacor, definiert einen Bug zum Beispiel wie folgt:

„Wenn der Quellcode nicht genauso abläuft, wie der Entwickler es sich gedacht hat oder entscheidende Gegebenheiten bei der Programmierung nicht bedacht wurden, ist es ein Bug“.

Neben der Programmierersicht lautet eine Definition aus der Businessperspektive so: „Um einen Softwarefehler als solchen zu definieren, bedarf es einer genauen Spezifikation der gewünschten Funktionsweise der Software und erst eine Abweichung von dieser stellt einen Fehler dar.“

Ein typisches Beispiel für Probleme, die aus einer fehlenden Spezifikation entstehen können, ist die ungeplante Skalierung der Software. So wird etwa eine Software für einen kleinen Personenkreis mit überschaubarem Budget entwickelt und implementiert. Für diese Nutzergruppe funktioniert das Programm einwandfrei. Die Software begeistert nach und nach immer mehr Nutzer, sodass deren Anzahl steigt. Nachdem nicht mehr nur 15, sondern 200 Personen die Software regelmäßig nutzen, kommt es laufend zu Problemen und Abstürzen. Die dafür ursächlichen Softwarefehler sind dann eigentlich keine richtigen Fehler, sondern Teil der ursprünglichen Konzeption. Denn diese basiert auf einer kleinen Nutzergruppe, für die es weder die Anforderung noch das Budget für eine Skalierbarkeit gab. Folgerichtig wurde auf jeden Mehraufwand für Skalierbarkeit und entsprechende Performance-Optimierung verzichtet.

Daraus lässt sich schlussfolgern, dass theoretisch bei jeder Softwarekonzeption von Anfang an genau klar sein müsste, wie die genauen Anforderungen an das Programm in Zukunft aussehen werden. In der Praxis ist diese Voraussicht in vielen Fällen nicht möglich. Es ist im Gegenteil sogar extrem schwierig, die genauen Vorgaben an eine Software vor Projektbeginn zu definieren. Diese Erkenntnisse berücksichtigen jedoch moderne agile Projektframeworks wie Scrum oder Kanban, die auch bei uns zum Einsatz kommen.

Je mehr Planung also in die Definition von Anforderungen oder in deren Unschärfe in der Konzeptionsphase fließen und je besser die Projektmanagement-Methoden sind, desto weniger Probleme gibt es hinterher bei der Entwicklung.

Kombinierte Testverfahren stellen Softwarequalität sicher

Grundsätzlich ist das ausgiebige Testen einer Software die offensichtlichste Methode, um Fehler möglichst frühzeitig zu erkennen. Neben verschiedenen anderen Prüfmethoden ist der manuelle Test am bekanntesten. Dabei handelt es sich um eine Variante des sogenannten Black-Box-Testings, bei dem ohne Kenntnis des Softwarecodes (wie in einer Black Box) gegen die Spezifikation getestet wird. Die Tester gehen die Anwendung Schritt für Schritt durch und überprüfen, ob alle Features wie erwartet funktionieren. Damit der Tester aufgrund seiner eigenen Entwicklung nicht unbewusst Annahmen über die Nutzung der Software trifft, sollte ein Entwickler nicht gleichzeitig auch Tester sein. Der Nachteil dieser Testmöglichkeit besteht darin, dass nur Fehlerbilder geliefert werden, aber keine Ursachen.

Um Fehler in größeren Projekten einer bestimmten Komponente zuweisen zu können, benötigt man sogenannte White-Box-Tests, bei denen der Quellcode selbst getestet wird. Da es bei größeren Projekten immer aufwendiger wird, den Code manuell zu testen, kommen in einem solchen Fall immer häufiger automatisierte Tests zum Einsatz. Ein weit verbreitetes Verfahren ist dabei der Unit-Test bzw. Modultest, bei dem jedes Softwaremodul einzeln getestet wird, um die Komplexität zu reduzieren. Das bedeutet konkret, dass für jedes Modul ein eigenes Testprogramm, welches die Funktionen des Moduls gegen die Spezifikation testet, geschrieben wird.

Automatisierte Tests, die in der Regel vom selben Softwareentwickler geschrieben werden wie der Code, finden jedoch nur solche Fehler, die bereits bei der Testkonzeption berücksichtigt wurden. Ein grundlegender Denkfehler bezogen auf die Implementierung könnte sich hingegen in den Tests fortsetzen. Um diesen Nachteil auszugleichen, werden in der Praxis manuelle Black-Box-Tests mit einem unabhängigen Team mit automatisierten White-Box-Tests zur Fehlersuche kombiniert.

Komplexe Konstellationen mithilfe von Betaphasen checken

Die nächste Stufe des Softwaretests umfasst die Betaphase, welche die meisten Nutzer schon einmal bei einem Webdienst erlebt haben. In diesem Stadium wurde die Software hinter einem Dienst bereits intern getestet und das Programm arbeitet im besten Fall weitgehend fehlerfrei. In seltenen Konstellationen, die vielleicht in den Tests nicht berücksichtigt wurden, werden jedoch noch Fehler erwartet. Um diese Bugs zu finden, wird die Software bzw. der Dienst mit dem Hinweis auf die Betaphase veröffentlicht und in der Regel bis zum Abschluss dieser Stufe kostenlos angeboten. In diesem Zeitraum sind die Nutzer aufgerufen, Fehler zu melden. Damit kann der Anbieter auch Fehler finden, die nur in speziellen Situationen auftreten oder die beim internen Testen übersehen wurden. Dieses Vorgehen ist allerdings nur bei Software möglich, die eine breite Nutzerbasis hat. Typisch ist das bei großen Internetunternehmen. Wenn man eine kleine oder mittlere Auftragsentwicklung mit einem neuen Google-Dienst vergleicht, ist das natürlich nicht fair, da man nicht immer 20.000 Betatester parat hat.

Fazit: Fehler gehören zur Softwareentwicklung dazu

Ein wichtiger Bewertungsmaßstab für die Qualität einer Software ist immer die ursprünglich und individuell zu Grunde gelegte Konzeption. Deckt sich bei der Einführung die Grundkonzeption nicht mit den tatsächlichen Gegebenheiten im Unternehmen (zum Beispiel im Hinblick auf die Skalierbarkeit der User-Anzahl), kann es bei der Implementierung der Software zu Problemen kommen. Diese sind dann weniger einer fehlerhaften Programmierung geschuldet, als vielmehr der Diskrepanz zwischen den vom Hersteller für die Programmierung festgelegten Spezifikationen und den tatsächlichen Einsatzbedingungen vor Ort beim Kunden.

Hiervon abgesehen existiert eine Menge rein objektiver Kategorien von Softwarefehlern, die bei der Programmierung selbst entstehen. In diesem Kontext ist es wichtig, sich vor Augen zu führen, dass Fehler zur Softwareentwicklung dazugehören. Komplexe Systeme beinhalten immer Fehler – und zwar unabhängig davon, welches Programm oder Endgerät genutzt wird. Trotz der diversen Konzepte zur Fehlervermeidung werden Software Bugs die IT auch in Zukunft begleiten. Es gibt in dieser Hinsicht keine absolute Sicherheit.