Qualitätssicherung und Validierung - Softwareanwendungen

Qualitätssicherung und Validierung

In dieser Lerneinheit eignest du dir professionelle Methoden zur Qualitätssicherung von Softwareprojekten an, mit Fokus auf Reviews und Inspektionen von Spezifikationsdokumenten. Du lernst systematische Vorgehensweisen kennen, um Anforderungsdokumente auf Vollständigkeit, Konsistenz und Umsetzbarkeit zu prüfen und erhältst praktische Werkzeuge zur frühzeitigen Fehlererkennung im Entwicklungsprozess. Diese Kompetenzen ermöglichen dir die eigenständige Durchführung und Dokumentation von Qualitätssicherungsmaßnahmen in deinen Projekten.

Einführung

Softwareprojekte scheitern oft an vermeidbaren Fehlern. Spezifikationen sind unklar, Anforderungen widersprechen sich oder kritische Details fehlen komplett. Das Ergebnis: Teure Nacharbeiten, verzögerte Projekte und frustrierte Teams.

Fehlerhafte Spezifikationen führen zu teuren Problemen - Qualitätsprüfung vor der Implementierung spart Zeit und Kosten — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Was wäre, wenn du Fehler finden könntest, bevor auch nur eine Zeile Code geschrieben wird?

Genau hier setzen Qualitätssicherung und Validierung an. Sie helfen dir, Spezifikationsdokumente systematisch zu prüfen, Anforderungen frühzeitig zu testen und Änderungen kontrolliert zu managen.

In dieser Lerneinheit lernst du, wie du Reviews durchführst, Prototypen zur Validierung einsetzt, Testfälle aus Spezifikationen ableitest und Impact-Analysen durchführst.

Lernziele

Nach dieser Lerneinheit kannst du:

• Reviews und Inspektionen von Spezifikationsdokumenten systematisch durchführen
• Prototyping und Simulation zur Validierung von Anforderungen einsetzen
• Testfälle aus Spezifikationen ableiten mit Äquivalenzklassen und Grenzwertanalyse
• Änderungsmanagement und Impact-Analysen durchführen

Überleitung

Um zu verstehen, wie du Fehler vor der Implementierung erkennst, schauen wir uns zunächst an, was Qualitätssicherung und Validierung im Kontext von Spezifikationsdokumenten bedeuten.

Dann lernst du die konkreten Werkzeuge und Techniken kennen, mit denen du systematisch Qualität sicherst.

Qualitätssicherung und Validierung: Abgrenzung

In der vorherigen Lerneinheit (Anforderungsanalyse und Definition) hast du gelernt, wie Anforderungen erhoben werden. Jetzt geht es darum, wie du deren Qualität sicherst und validierst.

Qualitätssicherung (QA) identifiziert Qualitätsmängel in Spezifikationsdokumenten wie Inkonsistenzen, Unvollständigkeiten oder nicht realisierbare Anforderungen.

Validierung prüft, ob die Spezifikationen die richtigen Anforderungen beschreiben: Bauen wir das richtige System?

Reviews und Inspektionen: Die Zielsetzung

Reviews und Inspektionen sind systematische Verfahren, um Spezifikationsdokumente auf Qualitätsmängel zu überprüfen. Diese Verfahren helfen dir, Fehler frühzeitig zu identifizieren.

Das Ziel:

• Qualitätsmängel identifizieren: Inkonsistenzen, Unklarheiten oder fehlende Details erkennen.
• Realisierbarkeit prüfen: Können die Anforderungen überhaupt umgesetzt werden?
• Kosten sparen: Frühzeitige Fehlererkennung vermeidet teure Nacharbeiten.

Wichtig: Diese Prüfungen finden statt, bevor der Code geschrieben wird. Dadurch verhinderst du, dass Fehler in der Implementierung landen.

Review-Typen im Vergleich

Es gibt verschiedene Review-Typen, die sich in Formalität, Rollen und Einsatzzweck unterscheiden:

Review-Typ	Formalität	Rollen	Hauptziel	Typischer Einsatz
Peer Review	Niedrig	2-3 Entwickler	Wissensaustausch	Code-Reviews im Team
Walkthrough	Mittel	Autor + Stakeholder	Feedback sammeln	Präsentation von Designs
Formale Inspektion	Hoch	Moderator, Reviewer, Protokollant	Qualitätsprüfung	Kritische Dokumente

Die Wahl des Review-Typs hängt von der Kritikalität des Dokuments und den verfügbaren Ressourcen ab. Für schnelles Feedback nutzt du Peer Reviews. Für sicherheitskritische Spezifikationen setzt du formale Inspektionen ein.

Werkzeuge und Hilfsmittel für Reviews

Für Reviews kannst du verschiedene Werkzeuge nutzen:

Einfache Hilfsmittel:

• Checklisten: Prüfe systematisch: Ist jede Anforderung eindeutig? Testbar? Umsetzbar?
• Spreadsheets: Tracke Findings und deren Status.

Professionelle Tools:

• GitHub Pull Request Reviews: Für Code-Reviews mit Kommentaren direkt im Code.
• Confluence/Notion: Für Reviews von Dokumenten mit Kommentar-Funktion.
• Spezial-Tools: ReviewBoard, Crucible für strukturierte Review-Prozesse.
• Defect-Tracking: JIRA, Azure DevOps für Fehler-Management.

Prototyping: Low-Fidelity vs High-Fidelity

Prototyping erstellt frühe Arbeitsmodelle eines Systems, um Design und Funktionalität zu testen. Es gibt zwei Haupttypen:

Low-Fidelity Prototypen:

• Schnell und kostengünstig (Papier-Skizzen, Wireframes).
• Zeigen Grundkonzepte und Hauptinteraktionen.
• Ideal für erste Feedback-Runden.

High-Fidelity Prototypen:

• Detailgetreu und interaktiv.
• Bessere Simulation der echten Benutzererfahrung.
• Tools: Figma, Adobe XD, Framer.
• Aufwendiger, aber realitätsnäher.

Throwaway vs. Evolutionary Prototyping

Prototypen unterscheiden sich auch darin, was nach dem Test passiert:

Typ	Ziel	Nach dem Test	Wann nutzen?
Throwaway	Anforderungen klären	Prototyp wird verworfen	Unklare Anforderungen, frühe Validierung
Evolutionary	Iterative Entwicklung	Prototyp wird zum Produkt	Agile Projekte, kontinuierliche Verbesserung

Throwaway-Prototypen helfen dir, Missverständnisse schnell zu klären – der Code ist “quick and dirty”. Evolutionary-Prototypen hingegen werden von Anfang an mit Produktionsqualität entwickelt und wachsen schrittweise zum finalen System.

Prototyping vs. Simulation: Wann nutze ich was?

Prototyping und Simulation haben unterschiedliche Anwendungsfälle:

Kriterium	Prototyping	Simulation
Fokus	UI/UX, Interaktionsdesign	Systemverhalten, Performance
Ziel	Anforderungen validieren	Technische Machbarkeit prüfen
Typisch bei	Unklaren Anforderungen	Komplexen technischen Systemen
Tools	Figma, Adobe XD	MATLAB, Simulink
Beispiel	Mockup einer Buchungs-App	Lastsimulation eines Webservers

Prototyping zeigt, WIE das System aussieht (User Interface, Interaktionen). Simulation zeigt, WIE es sich verhält (Performance, Lastenverteilung, technisches Verhalten unter verschiedenen Bedingungen).

⏳ Lädt Dataview-Inhalt...

Testfallableitung: Äquivalenzklassen

Testfallableitung aus Spezifikationen ist zentral für die Qualitätssicherung. Die Äquivalenzklassen-Technik teilt Eingabedaten in Gruppen, die ähnlich behandelt werden.

Wie funktioniert das?

Statt jeden möglichen Wert zu testen, bildest du Äquivalenzklassen: Gruppen von Werten, die das System gleich verarbeitet. Pro Klasse testest du nur einen repräsentativen Wert.

Beispiel Login-Formular:

• Gültige E-Mail (z.B. test@example.com)
• Ungültige E-Mail (z.B. test@)
• Leere E-Mail (kein Input)

Nutzen: Du reduzierst Testfälle drastisch, ohne Testabdeckung zu verlieren.

Grenzwertanalyse: Der systematische Ansatz

Die Grenzwertanalyse fokussiert auf Werte an den Grenzen der Eingabebereiche. Software versagt statistisch am häufigsten an Grenzwerten (z.B. Off-by-one-Errors).

Welche Werte testen?

Für einen gültigen Bereich [min, max]:

• min-1 (ungültig, unterhalb)
• min (gültig, untere Grenze)
• min+1 (gültig, sicher im Bereich)
• max-1 (gültig, sicher im Bereich)
• max (gültig, obere Grenze)
• max+1 (ungültig, oberhalb)

Beispiel Alter 18-65: Teste: 17, 18, 19, 40, 64, 65, 66

Grenzwertanalyse: Realistisches Beispiel

Eine Anwendung soll einen Rabattcode akzeptieren (10% Rabatt ab 100 Euro).

Äquivalenzklassen:

1. Ungültige Eingaben: negative Werte, 0, Strings
2. Gültiger Bereich ohne Rabatt: 0.01 - 99.99 Euro
3. Gültiger Bereich mit Rabatt: 100+ Euro

Grenzwerte und Testfälle:

• TC1: -10 Euro → Erwarte Fehlermeldung
• TC2: 0 Euro → Erwarte Fehlermeldung
• TC3: 99.99 Euro → Kein Rabatt
• TC4: 100.00 Euro → 10% Rabatt
• TC5: 100.01 Euro → 10% Rabatt
• TC6: 999999 Euro → 10% Rabatt
• TC7: ABC → Erwarte Fehlermeldung

Entscheidungstabellentechnik

Die Entscheidungstabellentechnik hilft bei komplexen Geschäftsregeln mit vielen Bedingungen.

Wann einsetzen?

Wenn mehrere Bedingungen kombiniert werden und verschiedene Aktionen auslösen. Beispiel: Versandkosten abhängig von Bestellwert, Gewicht und Zielland.

Wie funktioniert das?

Erstelle eine Tabelle mit allen Bedingungen (Zeilen) und Kombinationen (Spalten). Jede Spalte ist ein Testfall.

Nutzen:

• Alle Kombinationen werden systematisch erfasst.
• Keine Testfälle vergessen.
• Komplexe Regeln werden übersichtlich.

Änderungsmanagement: Der Prozess

Änderungsmanagement steuert kontrolliert, wie Änderungen an Spezifikationen durchgeführt werden. Das verhindert unerwünschte Nebenwirkungen.

Der 8-Schritte-Prozess:

1. Änderungsanforderung: Fehlerkorrektur, Verbesserung oder neue Funktion.
2. Review: Grund, Dringlichkeit und Nutzen prüfen.
3. Impact-Analyse: Welche Teile sind betroffen?
4. Genehmigung: Entscheidung basierend auf Analyse.
5. Implementierung: Änderung umsetzen.
6. Testen: Änderung validieren.
7. Deployment: In Produktion übernehmen.
8. Dokumentation: Änderung und Auswirkungen festhalten.

Impact-Analyse: Die Schlüsselaspekte

Die Impact-Analyse bestimmt, welche Systemteile von einer Änderung betroffen sind.

Was wird analysiert?

• Betroffene Komponenten: Welche Module, Funktionen, Datenbanken?
• Risikobewertung: Wie wahrscheinlich sind Fehler? Wie schwerwiegend?
• Ressourcenbedarf: Zeit, Personal, Budget für die Änderung.
• Zeitplan-Auswirkung: Verzögert sich das Projekt?
• Testanforderungen: Welche Tests sind nötig?

Werkzeug: Traceability Matrices verknüpfen Anforderungen, Code und Tests, um Abhängigkeiten sichtbar zu machen.

Impact-Analyse: Ein konkretes Beispiel

Szenario: Änderung der Login-Funktion (z.B. Zwei-Faktor-Authentifizierung hinzufügen).

1. Betroffene Komponenten:

• Frontend: Login-Formular, Session-Management
• Backend: Authentication-Service, User-Database
• Tests: Login-Tests, Integration-Tests

2. Abhängigkeiten (Traceability):

• Welche Features nutzen Login? Dashboard, Profil, Admin-Bereich
• Welche Tests müssen angepasst werden? Alle Login-bezogenen Tests

3. Risikobewertung:

• Wahrscheinlichkeit: Mittel (zentrale Funktion)
• Schweregrad: Hoch (Login-Ausfall betrifft alle Nutzer)

4. Ressourcen: 3 Tage Entwicklung + 1 Tag Testing

Entscheidung: Genehmigt, Sprint 3, hohe Priorität

⏳ Lädt Dataview-Inhalt...

QA-Beispiel: Buchungsverwaltung

Ein vollständiger QA-Workflow für ein Hotelzimmer-Buchungssystem:

1. Anforderungen: Buchen und Stornieren von Zimmern, Buchung innerhalb 2 Sekunden bestätigt.

2. Validierung: Funktioniert die Buchung? Erfolgt Stornierung korrekt? Wird 2-Sekunden-Ziel erreicht?

3. Testfälle:

• TC1 (Buchung): Zeitraum wählen → Zimmertyp → Daten eingeben → Bestätigung innerhalb 2s + E-Mail erhalten.
• TC2 (Stornierung): Buchung auswählen → Stornieren → Bestätigung + Rückzahlung.
• TC3 (Edge Case): Keine Zimmer verfügbar → Fehlermeldung.

4-7. Implementierung, Tests, Anpassungen, Deployment

8. Dokumentation: Alle Tests und Ergebnisse festhalten.

Zusammenfassung

Zusammenfassung

Qualitätssicherung und Validierung: Die Unterschiede

Qualitätssicherung (QA) identifiziert Qualitätsmängel in Spezifikationsdokumenten: Inkonsistenzen, Unvollständigkeiten, nicht realisierbare Anforderungen.

Validierung prüft, ob die Spezifikationen die richtigen Anforderungen beschreiben: Bauen wir das richtige System?

Reviews und Inspektionen

Reviews und Inspektionen sind systematische Verfahren zur Qualitätsprüfung von Spezifikationsdokumenten vor der Implementierung.

• Zielsetzung: Qualitätsmängel identifizieren, Realisierbarkeit prüfen, Kosten sparen durch frühzeitige Fehlererkennung.
• Review-Typen:
  • Peer Review (niedrige Formalität): Wissensaustausch im Team
  • Walkthrough (mittlere Formalität): Feedback von Stakeholdern sammeln
  • Formale Inspektion (hohe Formalität): Qualitätsprüfung kritischer Dokumente
• Werkzeuge: GitHub Pull Request Reviews, Confluence/Notion, JIRA, ReviewBoard, Crucible

Prototyping zur Validierung

Prototyping erstellt frühe Arbeitsmodelle zur Validierung von Design und Funktionalität.

• Low-Fidelity: Schnell und kostengünstig (Papier-Skizzen, Wireframes)
• High-Fidelity: Detailgetreu und interaktiv (Figma, Adobe XD, Framer)
• Throwaway-Prototyping: Prototyp wird verworfen nach Anforderungsklärung
• Evolutionary-Prototyping: Prototyp wächst zum finalen Produkt

Prototyping vs. Simulation:

• Prototyping: Zeigt, WIE das System aussieht (UI/UX, Interaktionen)
• Simulation: Zeigt, WIE es sich verhält (Performance, technisches Verhalten)

Testfallableitung aus Spezifikationen

Systematische Techniken zur Ableitung von Testfällen:

• Äquivalenzklassen: Eingabedaten in Gruppen teilen, die ähnlich behandelt werden. Pro Klasse einen repräsentativen Wert testen.
• Grenzwertanalyse: Fokus auf Werte an Bereichsgrenzen (min-1, min, min+1, max-1, max, max+1). Software versagt am häufigsten an Grenzwerten.
• Entscheidungstabellentechnik: Für komplexe Geschäftsregeln mit vielen Bedingungen. Alle Kombinationen werden systematisch erfasst.

Änderungsmanagement und Impact-Analyse

Änderungsmanagement steuert kontrolliert, wie Änderungen durchgeführt werden:

• 8-Schritte-Prozess: Änderungsanforderung → Review → Impact-Analyse → Genehmigung → Implementierung → Testen → Deployment → Dokumentation

Impact-Analyse bestimmt, welche Systemteile betroffen sind:

• Betroffene Komponenten identifizieren (Module, Funktionen, Datenbanken)
• Risikobewertung durchführen (Wahrscheinlichkeit, Schweregrad)
• Ressourcenbedarf ermitteln (Zeit, Personal, Budget)
• Testanforderungen festlegen
• Werkzeug: Traceability Matrices verknüpfen Anforderungen, Code und Tests

Ausblick

Diese Techniken der Qualitätssicherung und Validierung sind die Grundlage für professionelle Softwareentwicklung. Du bist jetzt in der Lage, Spezifikationen systematisch zu prüfen, Anforderungen frühzeitig zu validieren und Änderungen kontrolliert zu managen. Diese Kompetenzen werden dich durch alle weiteren Phasen des Softwareentwicklungsprozesses begleiten und helfen dir, Fehler zu vermeiden, bevor sie zu teuren Problemen werden.

---