Softwarequalität: Wie sie wirklich entsteht
Ein allzu typischer Fall: Das Projekt läuft. Die Software ist entwickelt. Jetzt noch schnell durch die Testphase, um Qualität in das Produkt zu bekommen. Doch ist das der richtige Weg? Erreichen wir Softwarequalität alleine dadurch, indem wir die Software testen? Und: Ist die Testphase tatsächlich die einzige Prozessphase, in der sich Qualität erzeugen lässt?
Klare Antwort: Nein. Denn Qualität entsteht nicht erst durch den Testprozess. Testing deckt lediglich Fehler auf, die dann ausgebessert werden. Wer dagegen echte Softwarequalität sicherstellen möchte, muss deutlich früher ansetzen.
Softwarequalität entlang sämtlicher Softwareprozesse
Um zu verstehen, warum die Qualität der Software nicht erst durch Testen entsteht, sollten wir den gesamten Weg zur fertigen Software betrachten. Dieser besteht aus mehreren Teilschritten, die sich schließlich zum Endprodukt zusammenfügen. Und in jedem einzelnen dieser Schritte werden Grundsteine für die Qualität der Software gelegt.
Aus Sicht der Qualitätssicherung ergeben sich die folgenden Prozessphasen. In jeder von ihnen können sich „Fehler“ einschleichen, welche die Qualität der Software mindern. Um die Softwarequalität sicherzustellen, ist es also essenziell, Qualitätssicherungsmaßnahmen über alle Phasen hinweg zu etablieren.
Quelle: Vision11
Anforderungserhebung
Qualität beginnt bereits bei der Definition der Produktanforderungen. Wird dort nicht auf eindeutig definierte Requirements geachtet – und werden diese nicht in einheitlich abgestimmter Form verfasst, schleichen sich hier bereits die ersten Missverständnisse und Fehler ein. Im Rahmen des Vier-Augen-Prinzips helfen Quality Engineers, Fehlerquellen frühzeitig zu identifizieren. Verbesserungen ergeben sich dabei etwa aus Satzschablonen für User Stories und Akzeptanzkriterien sowie durch die Prüfung ihrer eindeutigen Formulierung.
Bei agilen Projekten bietet sich auch an, in der DoR (Definition of Ready) Kriterien mit dem gesamten Team zu definieren. Diese müssen eingehalten werden, bevor eine Story an die Entwickler zur Umsetzung übergeben wird.
Entwicklung
Der Klassiker, wenn es darum geht, Fehlerquellen im Softwareprozess zu benennen. Doch neben Fehlern, die sich direkt während des Codings einschleichen und unweigerlich zu Bugs führen, können hier auch nicht eindeutig formulierte Anforderungen der Grund für Qualitätsprobleme sein.
Durch folgende Maßnahmen lässt sich der Unit Test hier effizienter gestalten: Mit kontinuierlichem Deployment auf Integrationsumgebungen etwa kann man erkennen, ob sich ein neues „Puzzlestück“ in eine bestehende Landschaft einsetzen lässt. Zusätzlich sollte man sich auf einen Coding-Standard einigen – und diesen regelmäßig durch ein unabhängiges Code Review prüfen lassen. Pair Progamming ermöglicht zudem die sofortige Erkennung von Fehlern und deren Korrektur bereits während des Codierens.
Deployment
Ist die Software oder eines ihrer Inkremente fertiggestellt, wird sie auf eine QA/Prod Umgebung ausgerollt. Dabei ist es wichtig, diesen Prozess besonders zu überwachen. So lassen sich Seiteneffekte vermeiden, die z. B. das Zusammenspiel mit einer anderen Software behindern. Außerdem sollte man ein Auge auf die durchzuführenden Post Deployment Steps werfen. Eine Checkliste hilft hier, keinen Schritt zu vergessen. Auf diese Weise lässt sich bei der Fehleridentifikation ausschließen, dass es sich um einen Fehler durch das Deployment handelt.
Testphase
Kommt die Software dann in die Phase des Systemintegrationstests, sollten auch hier die Prozesse so effizient wie möglich gestaltet sein, um noch vorhandene Fehler zu entdecken. Fehler, die durch die zuvor eingeführten Qualitätssicherungsmaßnahmen nicht verhindert werden konnten, lassen sich hier mit Hilfe einer passenden Teststrategie gezielt identifizieren. Zusammen mit einem effektiven Defect Management, das die Fehlerbehebung nachverfolgt, werden nun so gut wie alle Fehler behoben. In einer DoD (Definition of Done) kann ebenfalls festgehalten werden, welche Testphasen oder Qualitätsmerkmale für die Anforderungen erfüllt sein müssen, um auch hier eine einheitliche Qualität zu gewährleisten.
Weitere Verbesserungspotenziale für Softwarequalität: Projektprozesse
Ein weiterer Schritt, um Verbesserungspotenziale zu heben, besteht darin, über den Entwicklungsprozess hinaus zu denken und den Projektprozess zu betrachten. Dazu gehören z. B. Meetings und Vorgaben, die das gesamte Projekt betreffen. Meetings etwa lassen sich leicht ohne Effizienzeinbußen entschlacken. Neben den Anpassungen bei bestehenden Meetings können aber auch Quality Gateways eingeführt werden, die die Software durchlaufen muss. Zudem ermöglichen durchgängig einfache Workflows effizientere Arbeitsweisen in allen Bereichen.
Darüber hinaus sollte streng darauf geachtet werden, dass die Projektmitarbeitenden keine Doppelrollen übernehmen. Denn das wirkt sich potenziell negativ auf eine der beiden Rollen oder sogar auf beide aus. Auch „On-Top“-Aufgaben sollten vermieden werden, da diese die Planung durcheinanderbringen und so ebenfalls die Qualität beeinträchtigen. Entstehen durch neue Erkenntnisse zusätzliche Aufgaben, ist es besser, sie in die Planung aufzunehmen und diese entsprechend anzupassen.
Fazit: Softwarequalität ganzheitlich denken!
Zusammenfassend lässt sich feststellen: Qualität beginnt definitiv nicht erst in der Testphase. Es geht vielmehr um ein grundlegendes Bewusstsein im gesamten Projektteam, um gemeinsam an diesem Ziel zu arbeiten. So lässt sich nicht nur Entwicklungsprozess noch etwas optimieren: Auch auf der Projektebene gibt es wertvolles Potenzial. Denn wenn mit Hilfe von QS-Consultants alle Prozesse nachhaltig angepasst werden, kann Softwarequalität über den ganzen Projektzeitraum hinweg sichergestellt werden. Echte Qualität entsteht also dann, wenn sie in jedem Aspekt des Projekts gelebt wird.
Sie wollen mehr über Softwarequalität erfahren?
Gerne rufe ich Sie für ein weiterführendes Gespräch zurück:
Florian Abenthum
+4915122362145
Weitere Posts
Ein allzu typischer Fall: Das Projekt läuft. Die Software ist entwickelt. Jetzt noch schnell durch die Testphase, um Qualität in das Produkt zu bekommen. Doch ist das der richtige Weg? Erreichen wir Softwarequalität alleine dadurch, indem wir die Software testen? Und: Ist die Testphase tatsächlich die einzige Prozessphase, in der sich Qualität erzeugen lässt?