WASTE-Alarm! 3 unverzichtbare Maßnahmen gegen Bugs in Softwareprojekten

Es gibt schätzungsweise 10^82 Atome im sichtbaren Universum.

Der Sourcecode meiner letzten API hatte etwa 3MB Größe (ohne Libraries/Frameworks versteht sich... ). Das sind 24 Millionen Bits, welche etwa 10^722772 verschiedene Zustände annehmen können. Das sind unvorstellbar viel mehr als Atome im Universum. Ist nur ein einziges Bit nicht richtig gesetzt, kann man schon davon ausgehen, dass wir es mit einem Bug zu tun haben. (Ja ich weiß, der Vergleich ist nicht ganz richtig, aber you get the point...)

Eines ist also klar: Software ist unglaublich komplex, und deshalb gibt es in jeder Software auch Bugs.

Ich gehe jede Wette um eine Kiste (Österreichisch für "Kasten" 😁 ) Bier ein, dass sogar die Taschenrechner-Software unter Windows, Linux und macOS verschiedene Ergebnisse ausspucken, wenn die durchgeführte Rechnung nur einigermaßen komplex ist.

Wir können also nicht verhindern, dass Bugs in Softwareprojekten auftauchen. Aber wir können versuchen, die Anzahl an (critical) Bugs zu minimieren. In diesem Artikel stelle ich drei zentrale Maßnahmen vor:

1. Aus der Sicht des Softwaretests

2. Aus der Sicht der Programmierung

3. Aus der Sicht des Projektmanagements und des Einkaufs

In weniger als 10 Minuten Lesezeit erfährst du hier also, wie du deine Softwareprojekte signifikant verbessern kannst, denn eines ist klar:

Bugs sind einer der schlimmsten WASTE-Typen überhaupt!

Die LEAN-Softwareentwicklungsmethode definiert sieben Typen von WASTE, also Ballast, Zeit-, Geld-, und Produktivitäts-Killer. "Defects" sind mitunter die schlimmsten Repräsentanten von WASTE, denn sie kosten eine Menge an Ressourcen an vielen verschiedenen Stellen:

• Die Endbenutzer:innen verlieren Zeit und Nerven, wenn die Software nicht korrekt funktioniert

• Softwareentwickler:innen müssen Fehlverhalten erst mal mühsam nachstellen, bevor an einer Korrektur gearbeitet werden kann

• Die komplette Projektmaschinerie wird zusätzlich belastet: Bugfixes müssen ebenso im Projektplan mit eingetaktet werden, ein neues Release wird benötigt, ein neuer Testzyklus muss durchgeführt werden, und eventuell müssen sogar Anforderungsbeschreibungen umgearbeitet werden

Dabei haben Bugs unterschiedlich starke Auswirkungen, je nachdem wann sie gefunden werden:

Um das schlimmste zu verhindern ist es also unabdingbar, Softwaretest-Phasen durchzuführen. Nicht zu vernachlässigen ist aber auch der Versuch, Bugs so gut es geht zu vermeiden - schon während der Anforderungserhebung und der Programmierung. In diesem Artikel werden wir auch Möglichkeiten besprechen, wie wir bereits in diesen Phasen aktiv gegen Bugs vorgehen können.

Es ist schnell klar, dass jede Initiative Bugs zu vermeiden mittelfristig massiv Zeit und Kosten spart. Um zu erfahren welche Schritte den meisten Wert stiften, müssen wir aber verstehen, welche Arten von Bugs es gibt:

Zwei Arten von Bugs

Für Bugs/Defects gibt es verschiedenste Kategorisierungen. Für diesen Artikel ist nur eine davon wirklich essenziell:

1. Kategorie 1: Alle Bugs, die es in einem Softwareprogramm gibt

2. Kategorie 2: "Gefundene" Bugs, also Bugs, die entweder durch (idealerweise) Softwaretester:innen oder (nicht so ideal) Endbenutzer:innen gefunden werden.

Die gefundenen Bugs sind demnach eine Untermenge von allen Bugs der Software. Zum besseren Verständnis habe ich hier mal ein ziemlich professionelles Venn-Diagramm angefertigt:

Es ist wichtig zu verstehen, dass Softwaretests einfach die Menge der gefundenen Bugs vergrößern, während die anderen Maßnahmen direkt dabei ansetzen, die Anzahl aller Bugs zu verringern - bzw. nicht zu groß werden zu lassen.

Maßnahme 1: Softwaretest

Der Klassiker. Das Allheilmittel für viele (und doch leider oft nur halbherzig durchgeführt). Doch wie oben erwähnt ist es wichtig, genau zu verstehen, was Softwaretests machen:

• Softwaretests zeigt uns eine Teilmenge aller in der Software vorhandenen Bugs. Softwaretest verhindert nicht, dass Bugs in die Software kommen.

• Softwaretests trägt dazu bei, dass Bugs eher nicht von Endbenutzer:innen gefunden werden, sondern von den Tester:innen davor (bessere Customer Experience)

Softwaretester:innen leisten also Detektivarbeit, und gehen auf die Suche nach Bugs. Dazu gibt es mittlerweile viele Erfahrungswerte und Theorien. Idealerweise setzt man Softwaretest somit als strukturierten Prozess auf, der auf Best Practices aufgebaut ist. Ein guter Softwareprozess kann dahingehend optimiert werden, dass er:

• Jene Bugs findet, die die Programmbenutzung am massivsten stören würden

• Die wichtigsten Funktionen im Programm mit möglichst vielen Kombinationen von Daten und Benutzer:innenverhalten durchtestet, sodass ein reibungsloser Betrieb der wichtigsten Prozesse weitgehend sichergestellt werden kann

• Idealerweise automatisiert abläuft, sodass Re-Testing nach Erweiterung oder Abänderung der Software schnell durchgeführt werden kann

Welche Arten von Softwaretests gibt es?

Dabei gibt es verschiedene Arten von Softwaretests, welche in der Regel auch durch unterschiedlichen Engineers durchgeführt wird:

• Unit Tests - ja, liebe Programmier-Kolleg:innen .. das ist unsere Baustelle :)

• Integrationstests - je nach Projektgröße sinnvoll, um das Zusammenspiel einzelner Komponenten zu testen

• Systemtests / End-2-End-Tests: Die "klassischen" Softwaretests, die vom Testing-Team durchgeführt werden. Heutzutage wird auch in diesem Bereich viel automatisiert, und vor allem für webbasierte Technologien gibt es zahlreiche Frameworks hierzu.

• Abnahmetests: Endkund:innen sollten die Software, bevor sie released wird, ebenfalls kurz durchchecken. Etwaige Missverständnisse, die zB bereits im Requirements Engineering passiert sind, können hier noch vor Release aufgedeckt werden.

In der agilen Softwareentwicklung mit Scrum wird zB in 2-wöchigen Abständen der komplette Softwareentwicklungsprozess durchlaufen. Dies ist in der Regel nur möglich, wenn die Softwaretests stark automatisiert sind. Entsprechende Entwicklungskapazitäten müssen hierzu fix in den Projektplan miteinfließen.

Du bist Softwaretester:in oder interessiert an einem Quereinstieg in diese Thematik? Wir sind immer auf der Suche nach motivierten Techniker:innen - schreib uns einfach eine Email oder eine Nachricht auf LinkedIn, Twitter oder Instagram.

Maßnahme 2: Codequalität

Auch dieses Thema füllt Bücher, Vorträge, ja, ganze Studien. Ich möchte hier zwar schon ein paar Tipps geben, aber vor allem aufzeigen: Es lohnt sich massiv, in Codequalität zu investieren, denn damit kann die Anzahl der produzierten Bugs in Software massiv reduziert werden. Hier ein kurzer Überblick über konkrete Maßnahmen, die wir treffen können:

Clean Code

Pflichtlektüre für alle bei LEAN-Coders ist auf jeden Fall Clean Code von Robert "Uncle Bob" Martin - erhältlich auf so gut wie jeder Buchverkaufswebsite 😁

Die Grundprinzipien kann man sich auch auf Youtube aneignen.

Die Kernaussage von Clean Code ist: Code wird 1x geschrieben, aber 100x gelesen. Jedes Mal, wenn ein Softwareprogramm erweitert wird, muss Code gelesen werden. Guter Code ist dahingehend optimiert, gut gelesen werden zu können. Bereits einfachste Maßnahmen können schon dazu beitragen, Code wesentlich lesbarer zu machen:

• Sprechende Variablen- und Funktionsnamen

• Kurze Funktionen

• Wenig Code-Verzweigung innerhalb einzelner Funktionen

• Funktionen hierarchisch strukturieren. Soll eine Funktion zB den Inhalt einer Datei lesen und diesen Inhalt dann in einer Datenbank speichern so könnte man eine "High-Level"-Funktion schreiben, die in etwa so aussieht:
  
  const fileContent = await readFileContent(path)
const dbData = transformFileContentToDbModel(fileContent)
saveContentInDatabase(dbData)
  
  Selbst wenn du noch nie eine Zeile programmiert hast, kannst du vermutlich innerhalb weniger Sekunden erkennen, was hier abgeht. Stell dir nun vor, die Funktionalität dieser 3 Zeilen wäre hier einfach flach ausprogrammiert. Du müsstest dir erst mal dutzende Zeilen Code durchlesen und interpretieren, bevor du das "big Picture" erfassen kannst. Die Einführung dieser 3 zusätzlichen Hilfsfunktionen rentiert sich hier, weil sich die Lesbarkeit wesentlich erhöht. Zumal Funktionen ja auch wiederverwendet werden können - das kommt sozusagen als Bonus mit.

Wenn du mehr über Clean Code erfahren willst, kannst du dir auch mal die Vortragsreihe des Buchautors höchstpersönlich ansehen: Clean Code - Uncle Bob / Lesson 1

Software-Architektur

Software ist in der Regel (mehr oder weniger gut) aufgeteilt in einzelne Komponenten (Funktionen, Klassen, Module, ...). Wie man diese Aufteilung vornimmt, und wie die einzelnen Komponenten dann letztendlich wieder verdrahtet werden, um im Zusammenspiel ein großes Ganzes zu ergeben, wird durch die Softwarearchitektur bestimmt.

Auch dieses Thema kann ganze Bücher und Studien füllen. Für einen ersten Einstieg, und falls dir Clean Code gefällt, kann ich das Buch Clean Architecture empfehlen - ebenfalls von Robert Martin.

Wichtig zu verstehen ist, wie wichtig die Auswahl/Erstellung einer geeigneten Architektur für unsere Software ist. Oftmals wird enormer Fokus auf Design-Patterns gelegt, aber die Architektur beeinflusst die Struktur unserer Software noch wesentlich stärker.

Einen großen Benefit innerhalb kurzer Zeit kann man meist dadurch schon erzielen, indem man sich die gängigsten Architekturen mal ansieht - dazu reicht auch schon ein Blick in Wikipedia: Wikipedia-Architekturmuster

Dabei ist es, wie bei Design-Patterns, nicht ausschlaggebend, alle Architektur-Patterns auswendig zu lernen. Aber man sollte einen grundlegenden Überblick darüber haben, welche Architekturen es gibt, und welche Probleme durch "Standard-Architekturen" gelöst werden können. Die Details kann man bei Bedarf immer noch nachschlagen.

Es lohnt sich also zu Beginn eines Softwareprojekts, bzw. immer dann, wenn neue Subsysteme erstellt werden, über die Architektur nachzudenken. Dabei gibt es keine One-Solution-Fits-It-All-Lösung. Das wird leider oftmals implizit angenommen, weil durch moderne Frontend- und Backend-Frameworks Architekturen bereits vorgegeben werden. Diese machen auch massiv Sinn für ihre jeweiligen Anwendungszwecke. Eine MVC-Architektur hat sich im Backend für API's zum Beispiel über die Jahre hervorragend bewährt. Möchte man im Backend jedoch nun zB auch Daten-Integrationslösungen implementieren, lohnt sich ein Blick auf das Pipes-And-Filters-Pattern. Das Integrations-Subsystem darf nämlich ruhig eine eigene Architektur aufweisen, und kann in der (MVC-)API eingebettet sein - oder sogar komplett ausgelöst als eigenständiges System entwickelt werden ... you get the point, right?

Technologische Helferleins

Zusätzlich gibt es noch einige Tools, die uns das Leben potenziell erleichtern und unsere Codequalität erhöhen können, unter anderem:

• Linting, um Code-Smells automatisiert zu erkennen

• Sourcecodeverwaltung mit PR-Reviews, um den Code direkt nach Erstellung zu reviewen

• Automatisierte CI-Pipeline, um Linting und automatisierte Softwaretests strukturiert und beständig auszuführen, bevor Programmteile ausgespielt werden

Maßnahme 3: Projektmanagement & Sales

Wir programmieren ja nicht (nur) zum Spaß. In den allermeisten Fällen sind die zur Verfügung stehenden Ressourcen limitiert: Zeit, Geld und letztendlich pure Arbeitskraft. Der Erfolg eines Softwareprojektes hängt direkt mit der Anzahl an kritischen Bugs zusammen, die während des Programmierens produziert, und in der Testphase nicht abgefangen werden. Um gegen Projektende keine bösen (Kosten-)Überraschungen zu erleben, werden folgende Komponenten idealerweise von Anfang an fix in das Projekt eingeplant:

• Zeit zum Aufsetzen einer hochqualitativen Tooling-Umgebung

• Automatisierte CI-Pipeline

• Zeit für die Erstellung automatisierter Softwaretests

• Zeit für die Erstellung und Durchführung manueller Softwaretest-Fälle

• Zeit für das Fixen von kritischen Bugs

• Zeit für das genaue Analysieren und Erlernen der zu automatisierenden Prozesse. Je besser man ein Problem versteht, desto eher kann man eine digitale Umsetzung so programmieren, dass die Endkund:innen tatsächlich den größten Mehrwert von der zu erstellenden Software ziehen können

• Zeit für regelmäßige Feedbacks & Continuous Delivery - zB agil mit der Scrum-Methode

Wir können sie nicht alle finden

Wie viel Mühe wir uns auch geben: Bugs werden in Produktivsoftware immer auftreten. Ein gutes Handling von Bugs und entsprechender Kundenservice-Anfragen ist daher das A und O einer langfristigen Partnerschaft. Sich früh darüber Gedanken zu machen, wie man Fehlerbehandlungsprozesse abwickelt, sowie eine transparente Kommunikation darüber, haben sich in der Praxis auf jeden Fall bewährt.

A never ending story

Softwarebugs sind immens kostenintensiv, und werden uns immer begleiten, so viel ist klar. Es gibt aber Mittel und Wege, die Anzahl der Bugs in ausgelieferter Software zu reduzieren, und letztendlich mehr VALUE für Endkund:innen zu generieren.

Neben der Entwicklung von Individualsoftware bietet LEAN-Coders auch Consulting rund um den Softwareentwicklungs-Prozess - vom Review bestehender Prozesse bis hin zu Schulungen und Trainings, denn unsere Mission ist klar: Wir wollen den LEAN-Gedanken in die Welt hinaustragen - Step by Step :-)