Softwarequalität mit messbaren Kriterien beurteilen
Du übersetzt Qualitätsziele in prüfbare Kriterien, ordnest passende Maßnahmen zu und dokumentierst eine belastbare Abnahmeentscheidung.
Vor der Freigabe fehlen klare Antworten
Die Nordlicht Logistik GmbH führt ein Retourenportal ein. Beschäftigte scannen ein Paket, erfassen den Rückgabegrund und lösen anschließend die weitere Bearbeitung aus. Morgen soll die Fachabteilung die neue Version abnehmen.
Im Projektstatus steht bisher nur: “Die Anwendung soll schnell, wartbar und zuverlässig sein.” Das klingt sinnvoll, hilft bei einer Freigabe aber kaum. Eine Entwicklerin hält die Anwendung für schnell, weil sie auf ihrem Notebook sofort reagiert. Der Fachbereich empfindet schon eine Wartezeit von einer Sekunde als störend. Beide Aussagen können ehrlich sein, beruhen aber auf verschiedenen Maßstäben.
Softwarequalität wird entscheidbar, wenn aus einem Wunsch ein beobachtbares Kriterium wird. Du brauchst dazu eine festgelegte Bedingung, eine Kennzahl oder Beobachtung, einen Grenzwert und einen Nachweis.
In dieser Lektion planst du keine einzelnen Normal-, Rand- oder Fehlerfälle. Das übernimmt die Lektion Eine Softwareänderung mit passenden Testfällen absichern. Hier geht es um die Ebene darüber: Welche Qualitätsziele gelten, welche Maßnahmen liefern passende Nachweise und welche Befunde tragen eine Abnahmeentscheidung?
Aus einem Wunsch wird eine prüfbare Qualitätsanforderung
Eine funktionale Anforderung beschreibt, was eine Anwendung leisten soll. Das Retourenportal soll zum Beispiel eine angenommene Retoure an das Warenwirtschaftssystem übertragen.
Eine Qualitätsanforderung beschreibt, wie gut die Anwendung diese Leistung unter festgelegten Bedingungen erbringen soll. “Die Übertragung soll schnell sein” reicht dafür noch nicht. Die Aussage lässt offen, welche Übertragung gemeint ist, welche Last gilt und ab welchem Messwert das Ergebnis akzeptiert wird.
Eine belastbare Qualitätsanforderung beantwortet vier Fragen:
- Gegenstand: Was wird beurteilt?
- Bedingung: Unter welcher nachvollziehbaren Situation wird geprüft?
- Messgröße: Welche Zahl oder Beobachtung dient als Nachweis?
- Grenze: Welches Ergebnis gilt als erfüllt?
Für das Retourenportal vereinbart das Team diese Kriterien:
| ID | Qualitätsziel | Prüfkriterium |
|---|---|---|
| Q1 | kurze Antwortzeit | Bei 120 gleichzeitig aktiven Sitzungen und dem festgelegten Lastprofil liegt das 95. Perzentil der Antwortzeit höchstens bei 800 ms. Keine Anfrage überschreitet 1.500 ms. |
| Q2 | wartbarer geänderter Code | In den geänderten Dateien gibt es keine offenen Befunde der Stufen “blockierend” oder “kritisch”. Keine geänderte Funktion überschreitet den vereinbarten Komplexitätswert 10. |
| Q3 | nachvollziehbare Fehlerbehandlung | Schlägt die Übergabe an das Warenwirtschaftssystem fehl, zeigt das Portal eine verständliche Meldung und eine Vorgangskennung. Der Fehler wird mit derselben Kennung protokolliert. |
| Q4 | zügige Bearbeitung | Mindestens vier von fünf Personen aus der vereinbarten Nutzergruppe schließen den vorgegebenen Retourenablauf in höchstens 120 Sekunden ohne Unterstützung ab. |
Die Zahlen sind Projektdaten des neu erstellten Szenarios. Sie sind keine allgemeingültigen Empfehlungen. In einem echten Projekt legen Auftraggeber und Umsetzungsteam Grenzwerte passend zum Risiko, Nutzungskontext und Budget fest.
Mehrfachauswahl
Erkenne entscheidbare Qualitätsanforderungen
Wähle alle Formulierungen aus, die Bedingung, Messgröße und Grenze ausreichend erkennen lassen.
Alle passenden Antworten gefunden.
Die Auswahl ist noch nicht vollständig richtig.
B nennt Last, Messgröße und Grenze. D legt Umfang, Verfahren und Freigabegrenze fest. A und C nennen nur einen Wunsch. Für sie fehlt ein gemeinsamer Maßstab.
Verschiedene Maßnahmen sehen verschiedene Risiken
Keine einzelne Maßnahme beweist “die Qualität” einer ganzen Anwendung. Jede Maßnahme betrachtet einen Ausschnitt. Eine passende Auswahl beginnt deshalb beim Risiko, nicht beim Lieblingswerkzeug des Teams.
Statische Maßnahmen prüfen ein Artefakt ohne Ausführung
Bei einer statischen Prüfung wird der untersuchte Code nicht als laufende Anwendung ausgeführt. Dazu gehören:
- ein Code-Review durch eine andere Person,
- regelbasierte Analyse durch Linter oder Analysewerkzeuge,
- die Auswertung struktureller Kennzahlen wie Komplexität,
- ein Schreibtischtest, bei dem ein Ablauf gedanklich nachvollzogen wird.
Ein Werkzeug findet zum Beispiel eine nicht verwendete Variable oder eine Funktion mit vielen Verzweigungen zuverlässig. Ein Review kann zusätzlich erkennen, dass ein Name die fachliche Bedeutung verschleiert oder ein Fehlerfall unverständlich behandelt wird. Automatische Analyse und menschliches Review ergänzen sich. Sie sind nicht austauschbar.
Dynamische Maßnahmen beobachten die laufende Software
Bei einer dynamischen Prüfung wird Software ausgeführt. Ein Lasttest misst Antwortzeiten unter einem festgelegten Lastprofil. Ein Lauf durch den Retourenprozess zeigt, ob Fehlermeldung und Vorgangskennung tatsächlich zusammenpassen. Erst die Ausführung macht Laufzeitverhalten sichtbar.
Die Unterscheidung sagt noch nichts darüber aus, ob eine Maßnahme automatisch oder manuell erfolgt. Ein Lasttest kann automatisiert laufen. Eine Person kann die ausgeführte Oberfläche manuell beurteilen. “Statisch” und “dynamisch” beschreiben, ob das Prüfobjekt ausgeführt wird.
Die Abnahme vergleicht Nachweise mit der Vereinbarung
Bei der Abnahme beurteilt die zuständige Seite, ob die vereinbarten Kriterien erfüllt sind. Sie ersetzt weder Review noch Analyse oder dynamische Prüfung. Sie nutzt deren nachvollziehbare Ergebnisse als Nachweise.
Zuordnungsaufgabe
Ordne die Maßnahme ihrem Hauptzweck zu
Ordne danach, wie der Nachweis in dieser Situation entsteht.
Richtig zugeordnet. Prüfe diese Zuordnung noch einmal.
Richtig zugeordnet. Prüfe diese Zuordnung noch einmal.
Richtig zugeordnet. Prüfe diese Zuordnung noch einmal.
Richtig zugeordnet. Prüfe diese Zuordnung noch einmal.
Richtig zugeordnet. Prüfe diese Zuordnung noch einmal.
von 5 richtig
Review und Strukturanalyse untersuchen Artefakte ohne laufende Anwendung. Lastmessung und ausgelöster Fehler brauchen eine Ausführung. Bei der Abnahme werden die Nachweise gegen die vorher vereinbarten Kriterien gehalten.
Kennzahlen brauchen eine Leserichtung und eine Grenze
Eine Metrik bildet eine ausgewählte Eigenschaft als Zahl ab. Die Zahl hilft beim Vergleichen, entscheidet aber nicht allein über die Qualität. Vor der Messung müssen Messverfahren und Grenze feststehen. Sonst lässt sich ein Ergebnis nachträglich passend auslegen.
Das 95. Perzentil lässt wenige langsame Werte bewusst außen vor
Für Q1 sortiert das Team 20 repräsentativ ausgewählte Antwortzeiten aufsteigend:
420, 430, 450, 470, 480, 490, 500, 510, 520, 530,
550, 570, 590, 610, 630, 660, 700, 740, 790, 1150 msDas Team verwendet für dieses Projekt die Nearest-Rank-Methode. Die Position des 95. Perzentils ist:
aufrunden(0,95 × 20) = 19Der 19. Wert beträgt 790 ms. Das Perzentil-Kriterium von höchstens 800 ms ist erfüllt. Der langsamste Wert von 1.150 ms verschwindet dadurch aber nicht. Genau deshalb enthält Q1 zusätzlich die Grenze von 1.500 ms für jede einzelne Anfrage.
Rechenaufgabe
Bestimme das 95. Perzentil
Ein weiterer Lauf enthält 20 aufsteigend sortierte Messwerte. Das Projekt nutzt wieder die Nearest-Rank-Methode. Der 19. Wert beträgt 830 ms, der 20. Wert 910 ms. Welches 95. Perzentil wird dokumentiert?
Das Ergebnis liegt im richtigen Bereich.
Das Ergebnis passt noch nicht.
Aufrunden(0,95 × 20) ergibt Position 19. Dort steht 830 ms. Bei einer Grenze von höchstens 800 ms wäre Q1 in diesem Lauf nicht erfüllt. Der Maximalwert beantwortet eine andere Frage und ersetzt das Perzentil nicht.
Strukturelle Kennzahlen zeigen Risiken, keine Fehlerfreiheit
Für Q2 betrachtet das Team die Anzahl der Verzweigungen einer Funktion als vereinfachten Komplexitätswert. Ein hoher Wert kann darauf hindeuten, dass der Ablauf schwerer zu verstehen und zu ändern ist. Die Kennzahl beweist aber weder einen Fehler noch dessen Abwesenheit.
Ähnlich begrenzt sind andere verbreitete Kennzahlen:
| Kennzahl | Hilfreiche Aussage | Aussagegrenze |
|---|---|---|
| Anteil ausgeführter Codezeilen | zeigt, welcher Anteil bei den betrachteten Tests durchlaufen wurde | zeigt nicht, ob die Prüfungen sinnvoll sind oder alle Risiken abdecken |
| Anzahl offener Analysebefunde | macht bekannte, vom Regelwerk erkannte Stellen sichtbar | hängt von Regeln und Einstufung ab; unbekannte Probleme bleiben unsichtbar |
| Komplexitätswert | markiert stark verzweigte und möglicherweise schwer wartbare Funktionen | beurteilt weder fachliche Richtigkeit noch gute Bezeichnungen |
| Anzahl gemeldeter Fehler | zeigt bekannte Befunde in einem festgelegten Zeitraum und Umfang | hängt von Nutzung, Meldeverhalten und untersuchtem Umfang ab |
Ein Grenzwert ist deshalb eine vereinbarte Entscheidungshilfe. Er wird nicht zu einem Naturgesetz, nur weil ein Werkzeug ihn rot oder grün darstellt.
Schnellcheck
Ordne Zahlen vorsichtig ein
Entscheide dich bei jeder Frage. Du bekommst die Erklärung direkt nach deiner Antwort.
Geschafft
von 3
Situationen richtig eingeordnet.
Ein Review macht Begründungen und Kontext sichtbar
Im Code-Review prüft eine zweite Person die geänderte Übergabe an das Warenwirtschaftssystem. Die Checkliste fragt unter anderem nach verständlichen Bezeichnungen, kontrollierter Fehlerbehandlung, Protokollierung und unnötiger Komplexität.
Der Review-Befund lautet zunächst:
Bei einem Fehler wird eine allgemeine Meldung angezeigt. Der Protokolleintrag enthält eine technische Kennung, die Oberfläche zeigt diese Kennung jedoch nicht. Support und betroffene Person können denselben Vorgang deshalb nicht eindeutig zuordnen.
Dieser Befund ist stärker als “Fehlerbehandlung schlecht”. Er nennt die Stelle, das beobachtete Verhalten und die Auswirkung. Außerdem verweist er direkt auf Q3.
Fehlersuche
Finde den schwächsten Review-Befund
Welche Formulierung hilft am wenigsten bei Korrektur und Nachprüfung?
Fehler gefunden.
Diese Stelle ist nicht die Ursache.
Die pauschale Wertung nennt weder eine prüfbare Beobachtung noch ihre Auswirkung. Stelle, konkretes Ist-Verhalten und Folge machen einen Befund bearbeitbar.
Nach der Korrektur zeigt die Oberfläche die Vorgangskennung. Eine erneute dynamische Prüfung löst einen Übergabefehler aus und gleicht Kennung in Oberfläche und Protokoll ab. Damit ist nicht nur der Code geändert, sondern Q3 mit einem passenden Nachweis erneut geprüft.
Aus Nachweisen entsteht ein Abnahmeprotokoll
Ein Abnahmebefund hält den Soll-Ist-Vergleich so fest, dass eine andere Person die Entscheidung nachvollziehen kann. Dafür reichen eine grüne Ampel oder der Satz “Test erfolgreich” nicht aus.
Für jedes Kriterium dokumentiert das Team:
- die Kennung und den vereinbarten Soll-Zustand,
- den verwendeten Nachweis mit Version und Prüfbedingungen,
- das beobachtete Ist-Ergebnis,
- den Status “erfüllt”, “nicht erfüllt” oder “nicht geprüft”,
- bei einer Abweichung die Auswirkung und nächste Maßnahme,
- verantwortliche Person und Termin für die Nachprüfung.
Der Stand für die Abnahme sieht so aus:
| Kriterium | Ist und Nachweis | Status | Folgemaßnahme |
|---|---|---|---|
| Q1 | Lastbericht Version 1.4: p95 790 ms, Maximum 1.150 ms beim vereinbarten Lastprofil | erfüllt | keine |
| Q2 | Analysebericht Version 1.4: keine kritischen Befunde, aber Komplexität 11 in submitReturn | nicht erfüllt | Funktion vereinfachen und Analyse wiederholen |
| Q3 | Review geschlossen; dynamische Nachprüfung zeigt in Oberfläche und Protokoll dieselbe Kennung | erfüllt | keine |
| Q4 | Vier von fünf festgelegten Personen schließen den Ablauf innerhalb von 120 Sekunden ab | erfüllt | Beobachtung der fünften Sitzung als Verbesserungshinweis sichern |
Q4 ist nach dem vereinbarten Kriterium erfüllt. Die kleine Gruppe beweist trotzdem nicht, dass alle späteren Personen den Ablauf problemlos schaffen. Der Nachweis trägt die Abnahme für den vereinbarten Umfang, nicht jede denkbare Aussage zur Bedienbarkeit.
Q2 ist nicht erfüllt. Das Team hat nun drei saubere Wege: die Funktion vor der Freigabe vereinfachen, die Freigabe mit einer ausdrücklich vereinbarten Auflage verschieben oder das Kriterium gemeinsam und begründet ändern. Den Grenzwert nachträglich still zu ignorieren wäre keine nachvollziehbare Abnahme.
Transferaufgabe
Formuliere eine begründete Freigabeentscheidung
Du verantwortest das Abnahmeprotokoll für Version 1.4. Formuliere eine Entscheidung auf Grundlage der vier Befunde. Trenne dabei belegte Ergebnisse, Aussagegrenzen und nächste Schritte.
Musterlösung vergleichen
Musterlösung: Version 1.4 wird noch nicht ohne Auflage freigegeben. Q1, Q3 und Q4 sind im vereinbarten Umfang erfüllt. Q2 ist nicht erfüllt, weil submitReturn mit dem Komplexitätswert 11 den Grenzwert 10 überschreitet. Das Team vereinfacht die Funktion und wiederholt die statische Analyse vor der endgültigen Freigabe. Die vier erfolgreichen Sitzungen aus Q4 tragen das vereinbarte Kriterium, erlauben wegen der kleinen festgelegten Gruppe aber keine allgemeine Aussage über alle späteren Nutzerinnen und Nutzer.
Damit wird Qualität entscheidbar
Du hast aus allgemeinen Wünschen Kriterien mit Bedingungen, Messgrößen und Grenzen gebaut. Danach hast du passende statische und dynamische Maßnahmen ausgewählt. Die Kennzahlen wurden nicht als Qualitätsurteil missverstanden, sondern mit ihren Aussagegrenzen gelesen.
Für die Abnahme zählt die Belegkette: vereinbartes Soll, nachvollziehbarer Nachweis, beobachtetes Ist und eine begründete Folgemaßnahme. So kann das Team über eine Freigabe sprechen, ohne unterschiedliche Eindrücke als Fakten zu behandeln.
Belegmatrix
Die Matrix zeigt, worauf die Lernziele beruhen und wo du sie angewendet hast.
| Lernziel | Ordnungsmittel | Quellen | Lernaktivität |
|---|---|---|---|
| Qualitätswünsche messbar formulieren | LF12a, B2, AE-PB2 | Rahmenlehrplan LF12a; Ausbildungsordnung Abschnitt B Nummer 2; Prüfungskatalog Fragenkomplex Qualitätskontrolle | Anforderungen Q1 bis Q4 und Mehrfachauswahl |
| Maßnahmen einem Risiko zuordnen | LF11a, B2, AE-PB2 und AE-PB3 | Rahmenlehrplan LF11a; Ausbildungsordnung Abschnitt B Nummer 2; Prüfungskatalog statische und dynamische Verfahren | Zuordnungsaufgabe zu Review, Analyse, Ausführung und Abnahme |
| Metriken berechnen und begrenzen | LF11a, B2, AE-PB3 | Prüfungskatalog zu Kennzahlen, Soll-Ist-Vergleich und Testauswertung; abstrahierte Aufgabenmuster zu Metriken | Perzentil-Rechnung und Quiz zu Aussagegrenzen |
| Abnahmebefunde dokumentieren | LF12a, B2, AE-PB2 | Rahmenlehrplan LF12a; Ausbildungsordnung zu aufbereiteten Ergebnissen; Prüfungskatalog zu Protokoll und Auswertung | Review-Befund, Befundtabelle und Statusbewertung |
| Freigabe begründet ableiten | LF12a, B2, AE-PB2 | Rahmenlehrplan LF12a; Prüfungskatalog zu Maßnahmen der Qualitätskontrolle | Transferaufgabe mit Freigabeentscheidung und Nachprüfung |
Durchgearbeitet?
Markiere die Lektion als erledigt, dein Fortschritt wird lokal gespeichert.