Software Qualitätssicherung umfasst Maßnahmen, mit denen Qualität über den gesamten Entwicklungs- und Betriebsprozess hinweg planbar, überprüfbar und verbesserbar gemacht wird. Dazu gehören nicht nur Tests, sondern beispielsweise auch prüfbare Anforderungen, Reviews, technische Standards, Abnahmen und die Auswertung von Problemen aus dem laufenden Betrieb.

Qualitätssicherung ist deshalb nicht mit Softwaretesten gleichzusetzen. Testing ist ein wichtiger Bestandteil der Qualitätskontrolle und kann während des gesamten Entwicklungsprozesses stattfinden. Qualitätssicherung verfolgt darüber hinaus einen präventiven und prozessorientierten Ansatz: Sie schafft Rahmenbedingungen, durch die Fehler möglichst früh vermieden oder erkannt werden sollen. Diese Unterscheidung entspricht auch der aktuellen ISTQB-Systematik.

Der wirtschaftliche Gedanke dahinter ist einfach: Je später eine Unklarheit oder ein Fehler erkannt wird, desto mehr bereits entstandene Arbeit kann davon betroffen sein. Was bei einer Anforderung noch durch eine kurze Abstimmung korrigiert werden kann, kann nach Umsetzung zusätzlich Änderungen an Code, Tests, Dokumentation, Daten oder Einführung erfordern.

Dieser Artikel zeigt, was Software Qualitätssicherung umfasst, welche Maßnahmen entlang des gesamten Softwarelebenszyklus sinnvoll sind, wie Verantwortung verteilt werden kann und welche Kennzahlen tatsächlich helfen, Qualität gezielt zu steuern.

• Was Software Qualitätssicherung umfasst
• Maßnahmen zur Qualitätssicherung über den gesamten Ablauf
• Rollen und Verantwortung in der Software Qualitätssicherung
• Vier zentrale Maßnahmen der Software Qualitätssicherung
• Softwarequalität sinnvoll messbar machen
• Wann Qualitätssicherung unverhältnismäßig wird
• Fazit
• FAQ zur Software Qualitätssicherung

Software Qualitätssicherung betrachtet nicht nur einzelne Fehler, sondern die Bedingungen, unter denen Software entwickelt, geprüft, ausgeliefert und weiterentwickelt wird. Dabei lassen sich Qualitätssicherung und Qualitätskontrolle sinnvoll unterscheiden:

• Qualitätssicherung ist überwiegend prozessorientiert und präventiv. Sie schafft Vorgehensweisen und Rahmenbedingungen, durch die Qualitätsanforderungen zuverlässig erfüllt werden sollen.
• Qualitätskontrolle richtet sich stärker auf konkrete Arbeitsergebnisse. Tests, Reviews, Abnahmen oder andere Prüfungen liefern Informationen darüber, ob ein Ergebnis die festgelegten Anforderungen erfüllt.

Testing ist damit ein wichtiger Teil der Qualitätskontrolle, aber nicht die gesamte Qualitätssicherung. Auch das ISTQB unterscheidet Testing als produktorientierte Qualitätskontrolle von der prozessorientierten und präventiven Quality Assurance. Ebenso wichtig ist die Frage, was unter Softwarequalität überhaupt verstanden wird. Funktioniert eine Anwendung fachlich korrekt, kann sie trotzdem langsam, schwer bedienbar, unsicher oder kaum wartbar sein. Die aktuelle ISO/IEC 25010:2023 betrachtet Softwareproduktqualität deshalb über mehrere Qualitätsmerkmale. Dazu zählen unter anderem funktionale Eignung, Performance, Kompatibilität, Interaktionsfähigkeit, Zuverlässigkeit, Sicherheit, Wartbarkeit, Flexibilität und Safety. Insgesamt definiert die aktuelle Fassung neun Produktqualitätsmerkmale. Nicht jedes Merkmal ist für jedes System gleich wichtig. Bei einer internen Anwendung mit wenigen Nutzern können andere Qualitätsziele im Vordergrund stehen als bei einem öffentlich erreichbaren, geschäftskritischen oder sicherheitsrelevanten System. Der erste Schritt guter Qualitätssicherung ist daher nicht möglichst viel zu prüfen, sondern die relevanten Qualitätsziele bewusst festzulegen.

Softwarequalität entsteht nicht erst unmittelbar vor der Freigabe. Unterschiedliche Maßnahmen wirken in unterschiedlichen Phasen des Vorhabens.

Besonders wichtig ist die Verbindung zwischen Anforderungen und späterer Prüfung. Eine Aussage wie „Das System soll schnell sein“ lässt offen, was tatsächlich erwartet wird. Erst eine überprüfbare Qualitätsanforderung macht deutlich, unter welchen Bedingungen ein Ergebnis akzeptiert werden kann.

Wie fachliche und nichtfunktionale Anforderungen eindeutig und testbar beschrieben werden können, behandelt der Beitrag zum Requirements Engineering.

Auch frühe Entwürfe können Teil der Qualitätssicherung sein. Wenn beispielsweise Abläufe oder Bedienlogik noch unsicher sind, kann Prototyping Annahmen überprüfen, bevor sie vollständig umgesetzt werden.

Nach dem Go-live endet Qualitätssicherung ebenfalls nicht. Fehler und Störungen aus dem Betrieb liefern Informationen darüber, welche Risiken nicht ausreichend berücksichtigt wurden. Entscheidend ist deshalb nicht nur die unmittelbare Behebung, sondern auch die Frage, ob Anforderungen, Entwicklung oder Prüfprozess daraus verbessert werden sollten.

Softwarequalität sollte nicht ausschließlich an eine einzelne Person oder Abteilung delegiert werden. Das ISTQB beschreibt Quality Assurance ausdrücklich als Verantwortung, die Entwicklung und Testprozesse betrifft und grundsätzlich im gesamten Projekt verankert werden muss.

Welche Rollen zusätzlich benötigt werden, hängt jedoch von Größe, Kritikalität und regulatorischen Anforderungen des Vorhabens ab.

Eine eigene QA- oder Testrolle kann insbesondere bei komplexen oder kritischen Systemen sinnvoll sein. Sie sollte Qualität jedoch nicht zu einer „Aufgabe der QA-Abteilung“ machen, sondern dabei helfen, Qualitätsarbeit über die beteiligten Rollen hinweg systematisch zu organisieren.

Entscheidend ist außerdem, dass Qualitätssicherung Zeit und Priorität erhält. Code Reviews, Testpflege oder Ursachenanalysen können nur zuverlässig stattfinden, wenn sie als Teil der Entwicklungsarbeit eingeplant werden und nicht dauerhaft hinter neuen Funktionen zurückstehen.

Eine benannte Person oder Rolle mit Überblick über übergreifende Qualitätsthemen kann dabei helfen, wiederkehrende Probleme sichtbar zu machen, Verbesserungen anzustoßen und Verantwortlichkeiten nachzuverfolgen.

Die konkrete Ausgestaltung hängt vom System ab. Vier Maßnahmen sind jedoch in vielen Softwarevorhaben besonders relevant.

Eine zweite fachkundige Person kann Änderungen auf Verständlichkeit, Fehler, Auswirkungen und Einhaltung gemeinsamer Standards überprüfen. Besonders wirksam sind Reviews, wenn Änderungen überschaubar bleiben und zeitnah geprüft werden.

Automatisierte statische Analysen können Reviews ergänzen, indem sie beispielsweise bestimmte Regelverstöße oder potenzielle technische Probleme früh sichtbar machen. Sie ersetzen jedoch nicht die fachliche Beurteilung durch Menschen.

Alle Beteiligten sollten verstehen, welche Bedingungen erfüllt sein müssen, bevor ein Ergebnis tatsächlich als abgeschlossen gilt.

In agilen Vorgehensweisen kann dafür beispielsweise eine Definition of Done eingesetzt werden. Sie kann unter anderem Tests, Reviews, Dokumentation oder notwendige Freigaben enthalten.

Wie solche Kriterien in kurzen Entwicklungszyklen eingesetzt werden, behandelt der Beitrag zur agilen Softwareentwicklung.

Automatisierte Tests können bestehende Funktionen nach Änderungen wiederholt und reproduzierbar überprüfen. Ihr Nutzen ist besonders hoch, wenn Prüfungen häufig ausgeführt werden und ein eindeutiges Ergebnis besitzen.

Automatisierung ist jedoch kein Selbstzweck. Testbestand, Testdaten und technische Integration verursachen selbst Aufwand und müssen langfristig gepflegt werden.

Welche Tests sich automatisieren lassen, wie Testebenen sinnvoll kombiniert werden und wie Flaky Tests vermieden werden, behandelt der Beitrag zur Testautomatisierung.

Nicht jeder Bereich einer Anwendung benötigt dieselbe Prüftiefe. Risikobasiertes Vorgehen richtet den Qualitätsaufwand stärker danach aus, wie wahrscheinlich ein Problem ist und welche Auswirkungen es hätte.

Eine fehlerhafte Zahlungsabwicklung oder Datenübertragung kann beispielsweise eine andere Prüftiefe erfordern als eine rein kosmetische Änderung.

Risikobasiertes Testen nutzt genau diese Risikoeinschätzung, um Testaktivitäten zu priorisieren. Fachliteratur und etablierte Testmethoden verwenden Produkt- und Qualitätsrisiken deshalb gezielt als Grundlage für Testentscheidungen.

Damit wird Qualitätssicherung nicht möglichst umfangreich, sondern möglichst zielgerichtet.

Bei DIPS werden Qualitätsanforderungen, Entwicklungsprozess und technische Rahmenbedingungen gemeinsam betrachtet. So lässt sich festlegen, welche Maßnahmen für ein Vorhaben tatsächlich notwendig sind und an welchen Stellen zusätzlicher Prüfaufwand den größten Nutzen erzeugt.

Softwarequalität lässt sich nicht sinnvoll auf eine einzige Kennzahl reduzieren. Die passenden Messgrößen hängen davon ab, welche Qualitätsziele für das jeweilige System wichtig sind. Auch die ISO/IEC 25010:2023 sieht Qualitätsmerkmale als Grundlage für Spezifikation, Bewertung und Messung von Softwarequalität vor.

Beispielsweise:

Kennzahlen sollten dabei nicht isoliert als Leistungsbewertung einzelner Personen oder Teams verwendet werden.

Die reine Anzahl gefundener Fehler ist beispielsweise nur begrenzt aussagekräftig. Viele gemeldete Fehler können sowohl auf intensive Prüfung als auch auf geringe Produktqualität hindeuten. Erst Kontext, Schweregrad und Entwicklung über die Zeit machen eine Kennzahl interpretierbar.

Besonders wertvoll ist häufig die Betrachtung wiederkehrender Ursachen. Tritt derselbe Fehlertyp mehrfach auf, sollte nicht nur der konkrete Defekt behoben werden. Die interessantere Frage lautet, ob eine Anforderung, Entwicklungspraktik oder Prüfung angepasst werden kann, damit vergleichbare Probleme künftig früher sichtbar werden.

Für die Praxis gilt deshalb: Zuerst Qualitätsziel festlegen, danach eine geeignete Kennzahl auswählen – nicht umgekehrt.

Mehr Qualitätssicherung ist nicht automatisch bessere Qualitätssicherung. Maßnahmen erzeugen selbst Aufwand und sollten deshalb zur Kritikalität und zum tatsächlichen Risiko eines Systems passen.

Anzeichen für einen unverhältnismäßigen Prozess können beispielsweise sein:

• Freigabewege dauern regelmäßig länger als die eigentliche Änderung,
• Dokumentationen werden erstellt, aber nicht für Entscheidungen oder Betrieb genutzt,
• sehr risikoarme Änderungen durchlaufen dieselben Prüfungen wie geschäftskritische Funktionen,
• mehrere Freigaben liefern keine zusätzliche fachliche oder technische Aussage,
• manuelle Kontrollen wiederholen sich, obwohl sie sinnvoll automatisiert werden könnten.

Der Schaden besteht nicht nur im zusätzlichen Aufwand. Zu komplizierte Prozesse können außerdem dazu führen, dass Teams informelle Abkürzungen suchen und wichtige Kontrollen dadurch außerhalb des vorgesehenen Ablaufs stattfinden.

Der Maßstab sollte deshalb immer Verhältnismäßigkeit sein. Ein internes Hilfswerkzeug mit geringer Kritikalität benötigt andere Sicherungsmaßnahmen als eine Anwendung, über die zentrale Geschäftsprozesse, personenbezogene Daten oder sicherheitsrelevante Funktionen laufen.

In regulierten Umgebungen können zusätzliche Nachweis-, Dokumentations- oder Freigabepflichten bestehen. Dort ist nicht jede Maßnahme frei verhandelbar. Trotzdem sollte auch dort klar sein, welchem Qualitäts-, Risiko- oder Compliance-Ziel eine Aktivität dient.

Ein hilfreicher Prüfstein lautet:
Welches konkrete Risiko reduziert diese Maßnahme, welchen Nachweis liefert sie und gibt es einen einfacheren Weg mit vergleichbarer Wirkung?

Software Qualitätssicherung ist mehr als das Testen einer fertigen Anwendung. Sie beginnt bei nachvollziehbaren Qualitätszielen und prüfbaren Anforderungen, begleitet Entwurf und Umsetzung und endet auch nach der Freigabe nicht, wenn Erkenntnisse aus dem Betrieb für die Weiterentwicklung genutzt werden.

Wirksame Qualitätssicherung verbindet dabei Prävention, Prüfung und Rückkopplung. Reviews und Entwicklungsstandards reduzieren technische Risiken, klare Fertigstellungskriterien schaffen ein gemeinsames Qualitätsverständnis, automatisierte Tests sichern wiederkehrende Prüfungen ab und ein risikobasiertes Vorgehen konzentriert Aufwand auf die Bereiche mit den relevantesten Auswirkungen.

Wie viel davon notwendig ist, hängt vom jeweiligen Vorhaben ab. Ein kleines internes Werkzeug benötigt andere Qualitätsmaßnahmen als ein geschäftskritisches oder reguliertes System. Entscheidend ist deshalb nicht die Zahl der Kontrollen, sondern ob die gewählten Maßnahmen die relevanten Qualitätsrisiken tatsächlich reduzieren.

Bei DIPS werden fachliche Anforderungen, Nutzerperspektive, technische Qualität und Entwicklungsprozess gemeinsam betrachtet. Dadurch kann Qualitätssicherung so in ein Vorhaben integriert werden, dass sie verlässliche Ergebnisse ermöglicht, ohne den Entwicklungsprozess unnötig schwer zu machen.

Software Qualitätssicherung umfasst Maßnahmen, mit denen die Qualität von Software über Entwicklung, Prüfung, Einführung und Betrieb hinweg sichergestellt und verbessert werden soll. Dazu gehören beispielsweise prüfbare Anforderungen, Reviews, Tests, technische Standards, Abnahmen und die Auswertung von Problemen aus dem Betrieb.

Qualitätssicherung ist breiter als Softwaretest und konzentriert sich auch auf Prozesse und vorbeugende Maßnahmen. Softwaretests prüfen konkrete Arbeitsergebnisse und sind ein wichtiger Bestandteil der Qualitätskontrolle. Qualitätssicherung umfasst zusätzlich beispielsweise Anforderungen, Standards, Reviews und kontinuierliche Verbesserungen.

Typische Maßnahmen sind prüfbare Anforderungen, Code Reviews, technische Standards, manuelle und automatisierte Tests, Abnahmen, risikobasiertes Testen sowie Monitoring und Fehleranalyse im Betrieb. Welche Maßnahmen notwendig sind, hängt von Kritikalität, Technologie und Qualitätszielen des Systems ab.

Softwarequalität ist eine gemeinsame Verantwortung. Entwicklung, Fachbereich, Projekt- oder Produktsteuerung und Betrieb tragen unterschiedliche Teile dazu bei. Zusätzliche QA- oder Testrollen können die Arbeit strukturieren und methodisch unterstützen, übernehmen aber nicht allein die Verantwortung für Qualität.

Wichtige Qualitätsmerkmale sind unter anderem funktionale Eignung, Performance, Zuverlässigkeit, Sicherheit, Wartbarkeit, Kompatibilität und Interaktionsfähigkeit. Welche Merkmale besonders wichtig sind, hängt vom jeweiligen Einsatzgebiet und den Risiken der Software ab. Die ISO/IEC 25010:2023 bietet dafür ein international anerkanntes Qualitätsmodell.

Softwarequalität sollte anhand der relevanten Qualitätsziele gemessen werden. Geeignete Kennzahlen können beispielsweise Fehler nach Freigaben, Verfügbarkeit, Antwortzeiten, kritische Sicherheitsbefunde, wiederkehrende Fehlerursachen oder Aufwand für Änderungen sein. Eine einzelne Kennzahl reicht normalerweise nicht aus, um Softwarequalität vollständig zu beurteilen.

Testautomatisierung eignet sich besonders für wiederkehrende Prüfungen mit eindeutigem Ergebnis. Sie kann Regressionstests beschleunigen und nach Änderungen schneller Rückmeldung liefern. Sie ersetzt jedoch weder manuelle Tests noch Reviews, Nutzerfeedback oder andere Maßnahmen der Software Qualitätssicherung.

Qualitätssicherung wird unverhältnismäßig, wenn ihr Aufwand nicht mehr zum Risiko und Nutzen einer Maßnahme passt. Prüf- und Freigabeprozesse sollten deshalb an Kritikalität, regulatorische Anforderungen und tatsächliche Fehlerfolgen des jeweiligen Systems angepasst werden.