Was ist ein Bug?
Ein sogenannter Bug ist ein Fehler innerhalb eines Programms, der dazu führt, dass das Programm nicht wie erwartet funktioniert. Man kann davon ausgehen, dass in jedem Programm und in jeder Software Bugs zu finden sind, viele davon aber gar nicht bekannt sind, weil sie keine Fehlerwirkung zeigen, also niemandem (als Bug) auffallen.
Werde jetzt in 6-12 Monaten Software-Tester!
In jedem Fall ist ein Bug die „Nichterfüllung einer Anforderung“ und kann je nach Wirkung und Ausmaß unterschiedlich eingeordnet werden, was Schwere (Severity) und Bearbeitungspriorität (Priority) angeht.
Fehlerkosten und wie sie mit der Zeit steigen
Fehlerkosten und wie sie mit der Zeit steigenDie Entwicklung und das Programmieren einer Software verursachen natürlicherweise Kosten, beispielsweise in Form von Gehältern, Marketingkampagnen, Produktion etc. Auf die gleiche Weise wirken sich auch Fehler, deren Auffinden, ihre Behebung und ggf. Folgeaktionen finanziell aus. Denn dieser Prozess benötigt in der Regel nicht nur Zeit, sondern auch Ressourcen, zum Beispiel in Form von Arbeitskraft.
Fehler können in jeder Phase der Entwicklung entstehen, meistens jedoch während des Produktdesigns und der programmatischen Umsetzung. Finden sich Fehler, muss das Entwicklungsteam in den meisten Fällen den Code anpassen. Je später dies passiert, je mehr Code also geschrieben und je mehr funktionale Verknüpfungen in der Software entstanden sind, desto aufwändiger kann die Fehlerbehebung werden – und desto teurer.
Geht man beispielsweise davon aus, dass bereits in der anfänglichen Analyse oder beim initialen Design der Software Fehler auffalle, so können die Entwürfe überwiegend noch recht schnell und einfach angepasst werden. Ist bereits Code geschrieben, muss dieser korrigiert werden, wobei auf die stetige Kompatibilität mit dem restlichen Programm zu achten ist. Fällt eine Fehlerwirkung jedoch erst im Produktivsystem auf, so fällt nicht nur die Behebung dieses Fehlers an, sondern ggf. auch die Korrektur daraus resultierender Folgefehler – und die entsprechende Kommunikation an Betroffene und Beteiligte.
Die Faustformel – auch Zehnerregel genannt – geht von einer exponentiellen Steigerung der Kosten einer Fehlerbehebung von 10 aus. Das heißt: Wird der Fehler noch während der Analysephase gefunden, ist die Fehlerbehebung nicht mit großem Aufwand verbunden und kostet beispielhaft gesprochen 10,00 Euro. Wird der Fehler hingegen erst in der folgenden Designphase entdeckt, kommen bereits 100,00 Euro Behebungskosten auf, also das Zehnfache. Während des Programmierens selber wären es der Faustformel nach dann schon 1.000,00 Euro, während der Testphase 10.000,00 Euro und letztlich auf Produktionsebene 100.000 Euro.
Diese Zahlen sind zwar nur Richtwerte, nichtsdestotrotz verbildlichen sie, wie wichtig frühes Testen und Fehlerbeheben sind. Andernfalls kann ein zu spät gefundener Fehler große Kosten nach sich ziehen, zum Beispiel, wenn eine Vielzahl von Nutzenden informiert, Transaktionen rückgängig oder korrigiert und ggf. temporär Workarounds einge- und vielleicht sogar Entschädigungen entrichtet werden müssen.
Form eines guten Fehlerberichts
Auf die Entdeckung eines Bugs folgt in der Regel die detaillierte Dokumentation des Bugs, damit das Entwicklungsteam bestmöglich über die Fehlerwirkung informiert werden und möglichst zielgerichtet mit der Ursachenforschung und -behebung beginnen kann. Zu diesem Zweck sollte für jeden neu gefundenen Bug ein genauer Fehlerbericht erstellt werden.
Ein guter Fehlerbericht ist eindeutig zuordenbar, so kurz wie möglich und so umfangreich wie nötig. Eine eindeutige Berichts-ID dient als Erkennungsmerkmal, außerdem hilft auch ein prägnanter Titel. Inhaltlich muss ein guter Fehlerbericht genaue Informationen darüber enthalten, was von wem wann mit welchen Daten auf welchem System oder in welcher Umgebung, mit welchen Resultaten getan hat.
Eine detaillierte Schritt-für-Schritt-Anleitung ist hier von Nutzen, damit das Entwicklungsteam nachvollziehen kann, was geschehen ist, und den Fehler ggf. sogar nachstellen kann, falls er reproduzierbar ist. Ebenso wichtig ist das Aufführen des eigentlich erwarteten Verhaltens der Software – also eine Gegenüberstellung des Soll-Zustands mit dem Ist-Zustand.
Eine weitere wichtige Information, die in einem guten Fehlerbericht enthalten sein sollte, ist die Einschätzung einerseits bezüglich der Schwere des Fehlers, hinsichtlich der Nutzbarkeit der Software und andererseits bezüglich der Priorität, mit der der Bug behoben werden sollt.
Je wichtiger die betroffene Funktion der Software ist und je stärker sie beeinträchtigt ist, desto schwerer wiegt der Bug und desto schneller sollte er behoben werden. Gleiches gilt, wenn eine große Anzahl von Nutzenden betroffen ist oder Zeitdruck hinsichtlich der Fehlerbehebung besteht.
Mögliche Gründe für Softwarebugs
Ein Bug ist stets ein Fehlerzustand in der Software oder dem System. Viele bleiben unbemerkt, andere zeigen sich jedoch in Form einer Fehlerwirkung und haben somit sichtbare Auswirkungen auf die Nutzung des Programms.
Festzuhalten ist, dass Bugs auf vielfache Weise entstehen können, meist jedoch auf menschliches Versagen zurückzuführen sind – beispielsweise, wenn das Entwicklungsteam Tipp- oder Logikfehler in den Code eingebaut hat. Die Softwareanforderungen lückenhaft oder missverständlich waren und somit die Umsetzung auf Grundlage eines falschen Verständnisses erfolgt ist. Fehler können aber auch auf Probleme bei Hardware oder System zurückzuführen sein.
Oft sind Zeitdruck, Unachtsamkeit, mangelnde Kommunikation, Änderungen der Anforderungen oder geänderte technologische Gegebenheiten der Grund für die Entstehung von Fehlerzuständen in einem Programm. Je genauer die Erfordernisse für die gewünschte Software definiert sind und allen Beteiligten kommuniziert werden, inkl. aller Grenzfälle und möglicher Probleme, desto geringer ist die Wahrscheinlichkeit, dass (schwerwiegende) Fehler produziert werden.
