MENÜ

Softwarequalität

Qualitätssicherung, Fehler und Testen im Software-Engineering

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.

 

 

1.1           Eine verzerrte Wahrnehmung

 

Diese meist hohe Qualität nehmen Anwender 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          Unterschiede: Standardsoftware und Indiv-Entwicklung

 

Denken wir nun nicht an weit verbreitete Softwareprodukte mit Tausenden oder Millionen von Nutzern, 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. 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 Spezialisten für Individualsoftware – wie wir bei dataformers – zahlreiche Anstrengungen und Maßnahmen. Eine der wichtigsten ist das Testen.

 

 

1.3          Eine 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). 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:

 

 

 

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-Experten 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.

 

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.

 

 

 

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.

 

 

 

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:

 

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.

 

Darstellung frei nach T. Pfeifer, Qualitätsmanagement, 2. Aufl., 1996, S. 11.

 


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. Wird der Fehler erst im Produktiveinsatz entdeckt, 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.

 

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:

 

 

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 müssen also möglichst frühzeitig, idealerweise bei ihrer Entstehung, erkannt und verhindert werden. 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, um sicherzustellen, dass jedes Umsetzungsprojekt ein Optimum an Qualitätssicherungsmaßnahmen erfährt, Verbesserungspotentiale identifiziert und umgesetzt werden können und wir unseren eigenen, hohen Anforderungen an den Software-Engineering-Prozess gerecht werden.

 

  • Testen

Bis zum Release der Software wird diese mehrmals vom Software-Engineer und vom Kunden getestet. Einerseits werden die automatisierten Testfälle regelmäßig ausgeführt, andererseits testet jeder Software-Engineer die Änderungen und checkt sie gegen die Anforderungen und Akzeptanzkriterien ab.  Danach erstellt er den Pull-Request. Rechtzeitig vor dem Review wird die Funktionalität auch noch auf der QA-Stage getestet. Im Sprint-Review wird die neue Funktionalität dann nochmals vom Product-Owner getestet und abgenommen. 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, während das Team sich bereits um die nächste Projektphase oder das nächste Projekt kümmert.

 

  • 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, die im nächsten Sprint eingeplant werden sollen bzw. im Backlog erfasst werden sollen.

 

  • 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. Wird beispielsweise von der Software ein Bug entdeckt oder eine Verletzung der Clean-Code-Regeln erkannt, so wird der Software-Engineer darüber informiert und der Build ggf. abgebrochen.

 

 

Tools and Techniques

 

  • Continuous Delivery / Continuous Integration

Alle dataformers-Projekte besitzen Build- und Release-Queues, die dazu verwendet werden, laufend Entwicklungsstände auf die Stages automatisiert auszuliefern. Dadurch hat der Kunde immer den aktuellen Entwicklungsstand im Überblick. In diese Continuous Integration / Continuous Delivery-Chain sind automatisierte Qualitätssicherungstools integriert. So wird beispielsweise bei jedem Build die Testautomatisierung verwendet und die Software nur dann gebaut, wenn alle Tests grün waren.

 

  • 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. Diese Testfälle werden bei jedem Build-Schritt in der CI/CD ausgeführt und die Software nur dann auf die QA-Stage deployed, wenn alle Tests positiv waren

 

  • 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. Durch die Source-Code-Verwaltung werden Änderungen nachvollziehbar gemacht, wird die Kollaboration erleichtert und Fehler können leicht zurückgerollt werden. 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

dataformers setzt auf einen einheitlichen Coding-Standard, der von unseren eingesetzten Tools unterstützt und automatisch kontrolliert wird. 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

Um potenzielle Fehler zu beheben, werden diese systematisch in professionellen Bugtracking-Tools gesammelt. Bei dataformers sammeln wir alle Bugs im Azure-DevOps. Hier werden die Fehler um Informationen ergänzt, priorisiert, mit einer Timebox versehen und in die nächstpassende Iteration eingeplant.

 

 

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

 

 

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 (erinnern wir uns an unsere eigenen Erfahrungen als Anwender von bekannten Produkten großer Hersteller).

 

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, 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: Treten hier Fehler auf, können sie gesammelt mit dem Team besprochen und die Behebung gleich zeitnah in einen der nächsten Sprints eingeplant werden. Dies ist ein klarer Vorteil gegenüber Wasserfall-Projekten, bei denen Feedback erst am (oder leider oft: nach) Ende des Projekts gesammelt wird und somit erst sehr spät Korrekturen möglich sind. Und 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 oder falsch umgesetzt worden ist, die Spezifikation falsch oder unvollständig war, oder die Laufzeitumgebung, eine verwendete Bibliothek, das Netzwerk, verwendete Ressourcen, oder Betriebssystemfunktionen fehlerhaft sind oder anders als erwartet arbeiten.

 

1.5.2         Neues Feature

 

Eine neue Anforderung oder ein Feature liegt dann vor, wenn neue Funktionalitäten vom Anwender oder Product-Owner gewünscht werden, diese aber nicht in der Anforderungsanalyse festgehalten und somit auch nicht für die Software-Entwicklung eingeplant wurden. 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. Dennoch muss damit gerechnet werden, dass es auch nach Abschluss einer Entwicklung zu Fehlern im laufenden Betrieb der Software kommen kann, zumal die Qualitätssicherung ja normalerweise nicht auf gänzliche Fehlerfreiheit, sondern auf eine dem Einsatzzweck angemessenen Qualität abzielt (dies alleine schon aus wirtschaftlicher Vernunft).

 

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

 

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

 

 

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 contrastthe 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.”

 

 

 

Interesse? Wir unterhalten uns gerne mit Ihnen!
Neueste Beiträge
Softwarequalität
Qualitätssicherung, Fehler und Testen im Software-Engineering
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... mehr dazu
KEBA TrendTreff bei dataformers
Workshop mit 25 innovativen KEBAnern und aktuellen Microsoft-Technologien
Gemeinsam mit dem langjährigen Technologiepartner Microsoft initiierte dataformers einen Technologieworkshop für interessierte Teilnehmer der KEBA AG – dem unmittelbaren Büronachbarn am Standort Linz.... mehr dazu
Wir verpassen uns ein Update: dataformers E-Patch Days
So erweitern wir gemeinsam unseren technologischen Horizont.
Wir bei dataformers haben den Anspruch, mit fortschrittlichen Technologien und Methoden State-of-the-Art Software für unsere Kunden zu entwickeln. Um das langfristig sicherzustellen, geben wir uns im... mehr dazu