Software-Qualität dank Individualsoftware

Als User sind wir es gewohnt, Software zu verwenden, die keine groben Fehler hat, und machen uns daher über Software-Qualität meist keine großen Gedanken: Zwar kennen (und tolerieren wohl auch) die meisten von uns kleinere Bugs und gelegentliche Fehlermeldungen auch in weitverbreiteter Standardsoftware wie Betriebssystemen, Browsern, typischen Büroanwendungen und mobilen Apps. Aber im Großen und Ganzen erwarten wir, dass diese Anwendungen stabil laufen und eine ihrem Einsatzzweck angemessene Qualität aufweisen. Individualsoftware für eine hohe Software-Qualität.

1.1 Eine verzerrte Wahrnehmung

Diese meist hohe Software-Qualität nehmen Anwender:innen oft als selbstverständlich hin: Für den User bleibt verborgen, was alles nötig ist, um eine Software stabil und annähernd fehlerfrei hin zu bekommen. In Wirklichkeit haben die großen Unternehmen, die die eingangs genannten Softwareprodukte herstellen, meist hunderte oder tausende Software-Engineers, Tester und Testuser im Einsatz, die Tag für Tag dafür Sorge tragen, dass die Software annähernd fehlerfrei läuft. Also ein enormer Aufwand, der – wie alle anderen Bereiche der Produktentwicklung auch - meist über den Verkauf von Lizenzen bezahlt werden muss. Und trotzdem kann eine hundertprozentige Fehlerfreiheit, wie sich zeigt, in den meisten Fällen nicht garantiert werden.

1.2 Unterschied zwischen Standardsoftware und Individualentwicklung

Denken wir nun nicht an weit verbreitete Softwareprodukte mit Tausenden oder Millionen von Nutzer:innen, sondern an Individualsoftware. Im Gegensatz zu Standardsoftware die „von der Stange“ gekauft werden kann, löst Individualsoftware ganz spezifische Probleme, oft für einen vergleichsweise überschaubaren Nutzerkreis. Software-Qualität dank Individualsoftware. Diese Spezialisierung ist auch der Grund dafür, dass die Software individuell und maßgeschneidert entwickelt werden muss. Bei diesem ingenieursmäßigen Entwicklungsprozess wird die Software von Null weg gemeinsam mit dem Kunden designed, entwickelt, getestet und in Betrieb genommen.

Es liegt in der Natur von Entwicklungsprozessen, dass diese nicht frei von Risiken, Fehlern und Rückschlägen verlaufen. Die Lösung ist schließlich neu und individuell - sie wird zum allerersten Mal für genau diesen konkreten Anwendungsfall in genau diesem Systemkontext erdacht und entwickelt. Fehler (und in der Softwareentwicklung explizit „Bugs“) gehören also zum Entwicklungsprozess dazu. Trotzdem soll am Ende der Entwicklung ein möglichst fehlerfreies Produkt entstanden sein. Um dies zu gewährleisten, unternehmen auch Spezialist:innen für Individualsoftware – wie wir bei dataformers – zahlreiche Anstrengungen und Maßnahmen. Eine der wichtigsten ist das Testen.

1.3 Testen, Fehler und wirtschaftliche Betrachtung von Qualität

Um die Qualität der Software hoch zu halten und Fehler (Bugs) sowie Fehlerkosten zu minimieren, wird bei dataformers eine breite Palette an Maßnahmen ergriffen. So wird beispielsweise jede Softwareerweiterung zunächst vom Software-Engineer sowohl lokal, als auch in der Development-Stage getestet. Erst wenn das neue Feature alle Tests des Software-Engineers besteht und auch alle automatisierten Testfälle erfolgreich durchlaufen, wird die Funktionalität mittels automatisierter Prozesse auf die Quality-Assurance-Stage (QA-Stage) gehoben. Hier testet das Team erneut die Funktionalität. Erst wenn auch hier alles funktioniert, wird der Entwicklungsstand am Ende des Scrum-Sprints dem Kunden und den Testusern zur Verfügung gestellt.

Mit der QA-Stage hat nun der Kunde (meist in der Product-Owner-Rolle) die Möglichkeit, die Software selbst zu testen und in der Sprint Review abzunehmen. Er kann die Funktionalität jederzeit auch noch, während der gesamte nächste Sprint läuft, selbst testen. Erst wenn der Kunde von der Stabilität der Software überzeugt ist, wird das Software-Produkt auf die Produktiv-Stage, durch manuelles Auslösen eines automatisierten Prozesses, deployed (also veröffentlicht).

Staging und Teststrategie

Es ist ratsam, dass, bevor die Software auf der Produktiv-Stage veröffentlicht wird, explizit weitere Zeit zum Testen und Stabilisieren eingeplant wird. Im Normalfall planen alle Projekte gegen Ende des Projekts diese Integrationstestphase standardmäßig ein.  Die folgende Grafik veranschaulicht die Staging und Teststrategie:

Veranschaulichung von Staging und Teststrategie

Jede neue Funktionalität und somit auch das gesamte Software-Produkt durchlaufen also mehrere Stufen von Tests. Die Intensität und der Umfang der Tests kann vom Kunden gemeinsam mit den dataformers-Expert:innen individuell abgestimmt und zugeschnitten werden: Je nach Qualitätsanforderungen des Kunden (und diese sollten sich eng am Einsatzzweck orientieren) muss dementsprechend mehr oder weniger Budget für die Softwarequalität bereitgestellt werden. Das ist natürlich auch eine wirtschaftliche Frage, besonders vor dem Hintergrund, dass die Kosten für Individualentwicklungen ja auf eine wesentlich kleinere Gruppe zahlender Kunden umgelegt werden müssen als bei weitverbreiteten Standardprodukten. Wir als dataformers sind von den Vorteilen maßgeschneiderter Entwicklungen für spezifische Probleme natürlich überzeugt, doch sollten vorab unbedingt auch die Kosten für Tests und Qualitätssicherung als normaler Teil der Entwicklungskosten mit bedacht und - soweit abschätzbar – mit eingeplant werden.

Aufwandsverteilung in Software-Projekten

Als grober Anhaltspunkt kann man davon ausgehen, dass üblicherweise genauso viel Zeit in das Planen und Durchführen von Tests gesteckt werden muss, wie der Software-Engineer für das Erstellen der Funktionalitäten und der Testautomatisierung benötigt. Auf den gesamten Entwicklungsprozess gesehen, wird sinnvollerweise rund 30-40 % in das Erstellen von Testfällen und das eigentliche Testen investiert.

Grafik Aufwandsverteilung in Software-Projekten

In agilen Projekten erstreckt sich dieser Aufwand über den gesamten Verlauf der Entwicklung: Er fällt somit nicht einmalig und abschließend an, sondern „verteilt“ und als inhärenter Teil der Entwicklung.

Grafik Verteilung der Aufwände in den einzelnen Phasen

Es wird also einiges an Aufwand für die Qualitätssicherung und das Testen betrieben. Auch wenn es sich um hohe Summen handeln kann, sind diese gut investiert: Denn ihnen gegenüber stehen die Kosten, die verursacht werden, wenn etwaige Fehler erst in der Produktivumgebung auftreten oder Schäden entstehen, die tatsächlich durch Fehler in der Software verursacht werden. Um hier ein wirtschaftliches Optimum zu finden, ist die folgende Faustregel (siehe auch die nachstehende Grafik) sehr anschaulich:

"Rule of 10"

Die „Rule of 10“ (Quellen: siehe Anhang) sagt aus, dass sowohl die Kosten für die Fehlerbehebung als auch die Kosten, die ein Fehler (oder beispielsweise eine fehlerhafte Annahme) verursacht, mit Fortschreiten eines Entwicklungsvorhabens um ein Vielfaches höher sind als zu Beginn. Die Regel stammt ursprünglich aus der Wasserfall-artigen (also „starren“, nicht agilen) Entwicklung. Im Wasserfallmodell, so die Regel, vervielfachen sich die Kosten für eine Fehlerbehebung um den Faktor 10 von einer Phase des Projekts zur nächsten. In agilen Projekten durchlebt das Projekt in jedem Sprint diese Phasen und Phasen laufen parallel zu anderen ab. Ziel und Methode ist es hier also ganz besonders, Fehler einerseits möglichst frühzeitig im Projekt und andererseits möglichst früh beim Entstehen zu vermeiden.

Grafik Kosten je Fehler in einzelnen Phasen Darstellung frei nach T. Pfeifer, Qualitätsmanagement, 2. Aufl., 1996, S. 11.[/caption]

Wird also ein Fehler gleich zu Beginn in der Analyse und in der Spezifikation entdeckt und vermieden, so entsteht nur ein minimaler Mehraufwand, z.B. 10 Cent pro in das Feature investierten 100 Euro. Wird der Fehler aber nicht entdeckt und gelangt ins Design, so steigen die Kosten für die Behebung des Fehlers auf das 10-fache, also auf 1 Euro an. Entdeckt man den Fehler erst im Produktiveinsatz, so haben sich die Kosten bereits um das 1000-fache erhöht. In diesem Beispiel würde das bedeuten, dass wir aufgrund des Fehlers das gesamte Feature neu implementieren, also tatsächlich 100 Euro pro bereits investierte 100 Euro neuerlich in die „Korrektur“ stecken müssten.

Qualitätskostenoptimum

Diese Aufwände für die Fehlervermeidung können den Fehlerkosten gegenübergestellt werden, um ein „Qualitätssicherungsoptimum“ aufzuzeigen. Genau das tut die folgende Grafik:

Grafik Qualitätskostenoptimum

Genau deshalb versuchen wir, mit unseren Kunden ein Qualitätsoptimum zu identifizieren und zu treffen, bei dem sowohl die Qualität den Bedürfnissen (insbesondere: dem Einsatzzweck) entspricht, als auch die Kosten auf einem wirtschaftlich sinnvollen Niveau liegen.

1.4 Welche Maßnahmen setzten wir bei dataformers im Qualitätsmanagement?

Fehler muss man möglichst frühzeitig, idealerweise bei ihrer Entstehung, erkennen und verhindern. Dazu setzen wir bei dataformers auf eine sorgsam ausgewählte Kombination aus Prozessen, Know-how und Tools, welche wir in Form von Reviews, Kommunikation, Wissensaufbau und -transfer und Automatisierung in der Praxis anwenden.

Denn Software-Tests allein sind nur begrenzt effektiv, um die Fehlerrate zu reduzieren. So findet man nur bis zu 25% der Fehler mit Unit-Testing-Methoden, 35% mit Funktions-Tests und 45% mit Integrations-Tests. Im Gegenzug dazu werden beim herkömmlichen Code-Reviews und Design-/Architekturreviews zwischen 55 und 60% der existierenden Fehler gefunden (Quelle: siehe Anhang).

Wir bei dataformers setzen in unseren Kundenprojekten laufend folgende Maßnahmen:

  • Inspect and Adapt
  • Pull-Requests ( = Code-Reviews)

Bei jedem Merge in den Master ist ein Pull-Request erforderlich, um nach dem 4-Augen-Prinzip sicherzustellen, dass die Code-Qualität den Kriterien entspricht und auch sonst wichtige Prinzipien des Software-Engineerings eingehalten wurden.

  • Development-Prozess-Reviews auf regelmäßiger Basis

Wir führen mindestens einmal im Quartal bei jedem unserer Projekte ein Development-Prozess-Review durch. Dadurch stellen wir sicher, dass jedes Umsetzungsprojekt ein Optimum an Qualitätssicherungsmaßnahmen erfährt. Dabei identifizieren wir auch Verbesserungspotentiale und werden so unseren eigenen, hohen Anforderungen an den Software-Engineering-Prozess gerecht.

  • Testen

Bis zum Release der Software wird diese mehrmals vom Software-Engineer und vom Kunden getestet. Jeder Software-Engineer testet die Änderungen und checkt sie gegen die Anforderungen und Akzeptanzkriterien ab.  Danach erstellt er den Pull-Request. Rechtzeitig vor dem Review testet man die Funktionalität auch noch auf der QA-Stage. Im Sprint-Review testet der Product-Owner nochmals die neue Funktionalität und nimmt diese ab. Beim Release auf die Productive-Stage oder in die Produktivumgebung wird von jedem Projektteam nochmal extra Testzeit eingeplant, um das gesamte System noch einmal auf Herz und Nieren durchzutesten und die Projektphase oder das Projekt abzuschließen. Dieser finale Testaufwand kann natürlich auch nur vom Kunden investiert werden. Das Team kümmert sich währenddessen bereits um die nächste Projektphase oder das nächste Projekt.

  • Sprint-Reviews

Beim Sprint-Review stellt das Team gemeinsam sicher, dass die Anforderungen des Product Owners richtig verstanden und umgesetzt wurden. Der PO nimmt die Änderungen ab oder erfasst Nachbesserungen, diese plant er im nächsten Sprint ein bzw. erfasst sie im Backlog.

  • Sprint-Retrospektiven (= KVP)

Nach jedem Sprint halten wir eine Sprint-Retrospektive ab, um die Qualität des Entwicklungs-Prozesses „an sich“ zu diskutieren und zu verbessern.

  • Automatische und regelmäßige statische Codeanalyse auf Feature-Ebene

Wird der automatische Build-Prozess angestoßen, so wird automatisch die statische Codeanalyse durchgeführt. Entdeckt die Software beispielsweise einen Bug oder erkennt eine Verletzung der Clean-Code-Regeln, informiert sie den Software-Engineer und bricht ggf. den Build ab.

  • Tools and Techniques
  • Continuous Delivery / Continuous Integration

Alle dataformers-Projekte besitzen Build- und Release-Queues. Diese liefern laufende Entwicklungsstände auf die Stages automatisiert aus. Dadurch hat der Kunde immer den aktuellen Entwicklungsstand im Überblick. In diese Continuous Integration / Continuous Delivery-Chain sind automatisierte Qualitätssicherungstools integriert. dataformers verwendet in jedem Build die Testautomatisierung und baut die Software nur dann, wenn alle Tests grün sind.

  • Staging – Environments

Um stabile Produktqualität zu gewährleisten und dem Kunden laufend eine Möglichkeit zur Einsicht über den aktuellen Produktentwicklungsstand zu geben, gibt es mehrere Auslieferungsstages. Jede Stage ist stabiler als die vorhergehende.

  • Testautomatisierung

Schon während der Entwicklung produzieren dataformers-Engineers nicht nur reinen Lösungscode, sondern schreiben auch Testfälle.

  • Statische Codeanalyse während der Entwicklung

Schon während der Entwicklung wird der Code mit Hilfe von Linting durch bspw. SonarLint analysiert und der Software-Engineer beim Erstellen eines Pull-Requests auf etwaige Probleme hingewiesen. Dies fördert die Source-Code-Qualität, steigert die Erweiterbarkeit und Wartbarkeit und minimiert das Fehlerpotential.

  • Source-Code-Verwaltung

Alle unsere Projekte werden mit professionellen Software-Engineering-Tools erstellt. Eines der wichtigsten ist die Source-Code Verwaltung. Die Source-Code-Verwaltung macht Änderung nachvollziehbar, erleichtert die Kollaboration und rollt Fehler leicht zurück. Dies steigert die Qualität des Produkts, hilft Fehler zu reduzieren und führt zu einer gesteigerten Effizienz des Umsetzungsteams.

  • Setzen auf Standardkomponenten und Libraries

Um schneller produktive Lösungen zu erstellen, setzt dataformers auf zahlreiche Standardkomponenten und Komponentenbibliotheken. Diese sind sowohl in der Logik im Backend, als auch im Frontend zu finden.

  • Coding-Standard

Die von dataformers eingesetzten Tools unterstützen und kontrollieren den einheitlichen Coding-Standard automatisch. Dies führt zu einem einheitlichen Source-Code-Bild. Software-Engineers können sich schneller in den Code einarbeiten, die Lesbarkeit steigt und Fehler werden vermieden.

  • Bugtracking

Zur Behebung von potentiellen Fehlern, sammelt man diese in professionellen Bugtracking-Tools. Bei dataformers sammeln wir alle Bugs im Azure-DevOps. Hier ergänzt man die Fehler um Informationen, priorisiert, versieht sie mit einer Timebox und plant sie in die nächstpassende Iteration ein.

Zusammenfassend soll folgende Grafik noch einmal alle einzelnen Maßnahmen in Verbindung mit der Staging-Strategie und Teststrategie veranschaulichen:

Verbindung der Staging-Strategie und Teststrategie

1.5 Was tun, wenn dennoch Fehler auftreten?

Fehler in Software sollen also in jenem Maß vermieden werden, in dem das auch wirtschaftlich und sinnvoll ist. Dies impliziert, dass Fehler (insbesondere: „Bugs“) auch in eigentlich fertiggestellter Software hin und wieder auftreten können.

Wichtig ist, und das macht den Unterschied, wie man auf Fehler reagiert. Manche Software-Entwicklungsdienstleister reagieren nicht immer geeignet auf Fehler, das kann aber auch am jeweiligen Vertragswerk mit dem Auftraggeber liegen. Gerade in Fixpreisprojekten kann es zu lästigen Change-Requests und Verzögerungen in der Fehlererkennung und Fehlerbehebung kommen. Besonders dann, wenn ein Auftrag abgeschlossen wurde, ohne weitere Vorkehrungen und (auch kommerzielle) Vereinbarungen für den Fehlerfall zu treffen.

Agile Formen der Zusammenarbeit bieten die Chance, dass sich bereits während der Entwicklung der Kunde regelmäßig am Sprintende Zeit nimmt und mit dem Team die entwickelten Features sauber testet und abnimmt. Die Fehler, die hier auftreten, kann der Kunde dann gesammelt mit dem Team besprechen. Die Behebung kann dann gleich zeitnah in einen der nächsten Sprints eingeplant werden. Dies ist ein klarer Vorteil gegenüber Wasserfall-Projekten, bei denen die Sammlung des Feedbacks erst am Ende des Projekts stattfindet. Somit sind erst sehr spät Korrekturen möglich sind. Selbst wenn ein Programm noch so sauber getestet wurde, kann es passieren, dass erst im Feldtest dennoch technische Fehler auftreten.

Es passiert aber auch oft, dass User technische Fehler mit Feature-Wünschen verwechseln. Deswegen wollen wir uns die Begriffe Bug/Fehler und Feature-Wunsch noch einmal genauer ansehen:

1.5.1 Bug

Ein Fehler, häufig auch als Bug bezeichnet, ist ein Fehlverhalten von Programmen. Diese treten auf, wenn beim Entwickeln der Software eine bestimmte Festlegung der Spezifikation nicht / falsch umgesetzt worden ist, die Spezifikation falsch / unvollständig war, wenn die Laufzeitumgebung, eine verwendete Bibliothek, das Netzwerk, verwendete Ressourcen, oder Betriebssystemfunktionen fehlerhaft sind / anders als erwartet arbeiten.

1.5.2 Neues Feature

Eine neue Anforderung oder ein Feature liegt dann vor, wenn der Anwender:innen oder Product-Owner neue Funktionalitäten wünscht. Diese wurden aber nicht in der Anforderungsanalyse festgehalten und somit auch nicht für die Software-Entwicklung eingeplant. Oftmals wünschen sich User andere/zusätzliche Features und empfinden das Fehlen dieser als sehr unangenehm. Diese sind jedoch keine Bugs, sondern als gesonderte Änderungswünsche zu betrachten. Es ist die Aufgabe des Product-Owners, Anforderungen im Zuge der Produktentwicklung zum richtigen Zeitpunkt und in geeigneter Form zu definieren und mit End-Usern des Systems abzustimmen. Des Weiteren ist es die Aufgabe des Product-Owners vor Entwicklungsbeginn eines Features sicherzustellen, dass das gesamte Projektteam und somit alle Software-Engineers die Aufgabe verstanden haben und jeder dasselbe Bild von den zu entwickelnden Funktionalitäten hat.

1.6 Wie geht es nach dem Projekt weiter?

In eine möglichst frühe Fehlervermeidung und sorgfältige Tests fließen also nicht unbeträchtliche Aufwände. Bei dataformers genauso wie bei jedem anderen seriösen Entwicklungsdienstleister. Man muss dennoch damit rechnen, dass es nach Abschluss einer Entwicklung zu Fehlern im laufenden Betrieb kommen kann. Die Qualitätssicherung zielt ja normalerweise nicht auf gänzliche Fehlerfreiheit, sondern auf eine dem Einsatzzweck angemessenen Qualität ab.

Umso wichtiger ist es, rechtzeitig weitere Vorkehrungen für den laufenden Betrieb zu treffen. Dazu gehören Strukturen und Ressourcen für die stabile Inbetriebhaltung einer Software genauso wie ein Supportkonzept für den Anlassfall auftretender Fehler bei Anwender:innen. Auch dazu beraten wir Sie gerne!

In jedem Fall hoffen wir, dass wir Ihnen ein Bild von unseren Qualitätssicherungsmaßnahmen vermitteln konnten. Eine sorgfältige Kombination aus Prozessen, Know-how und Tools. Haben Sie weiterführende Fragen oder wünschen Sie einen Erfahrungsaustausch? Melden Sie sich jederzeit gerne für ein beratendes Gespräch!

Hier geht's weiter

Erfahren Sie noch mehr zu Software Engineering mit dataformers. Mit uns generieren Sie digitale Produkte mit absolutem Mehrwert.

Anhang/Quellen

Siehe zur „Rule of 10“ z.B.:

https://www.standishgroup.com/sample_research_files/RuleTen.pdf

https://www.olev.de/0/10er-regl.htm

Pfeifer, Tilo / Schmitt, Robert: Qualitätsmanagement. Strategien, Methoden, Techniken. 4. Aufl., München 2010 S154

Verwendete Quelle / Zitat zur Effektivität von Tests:

Code Complete: A Practical Handbook of Software Construction, by Steve McConnell:

“... software testing alone has limited effectiveness — the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. Case studies of review results have been impressive:

In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.

In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.

The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.

IBM’s 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.

A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.

Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by finding and fixing defects at an early stage.”

Weitere Beiträge
crosschevron-left
Datenschutzinformation
Der datenschutzrechtliche Verantwortliche (dataformers GmbH, Österreich) würde gerne mit folgenden Diensten Ihre personenbezogenen Daten verarbeiten. Zur Personalisierung können Technologien wie Cookies, LocalStorage usw. verwendet werden. Dies ist für die Nutzung der Website nicht notwendig, ermöglicht aber eine noch engere Interaktion mit Ihnen. Falls gewünscht, treffen Sie bitte eine Auswahl: