Testen und Qualitätssicherung dokumentieren
Das Test- und Qualitätssicherungs-Kapitel ist das Kapitel, das viele Auszubildende unterschätzen – und genau deshalb mit Punkten belohnt wird, wenn es ordentlich gemacht wird. Es macht 10 % der Gesamtbewertung aus und ist meist 1–1,5 Seiten lang. Wer hier nur „funktioniert wie geplant" schreibt, lässt 10 Punkte liegen.
Diese Lektion zeigt dir die Testarten (Unit-, Integrations-, System-, Abnahmetest), wie du Testfälle definierst, Testprotokolle schreibst und die formale Abnahme dokumentierst. Das Test-Kapitel beweist, dass dein Projekt wirklich funktioniert – nicht nur, weil du sagst, dass es funktioniert.
1) Was in das Test-Kapitel gehört
Das Test-Kapitel zeigt drei Dinge: was getestet wurde, wie getestet wurde und welche Ergebnisse herauskamen. Die Tests werden gegen die Anforderungen aus der Ist-Analyse geführt – jede Anforderung sollte mindestens einen zugehörigen Testfall haben.
- Testkonzept: welche Testarten werden eingesetzt, warum diese
- Testfälle: konkrete, prüfbare Testszenarien mit Eingabe, erwartetem Ergebnis, tatsächlichem Ergebnis
- Testprotokoll: Datum, Tester, Umgebung, Schritte, Ergebnisse
- Abnahme: formelle Bestätigung des Auftraggebers
- Bewertung: Erfüllungsgrad gesamt, eventuelle Restrisiken
2) Die Test-Pyramide
In der Software-Welt ist die Test-Pyramide ein Standardkonzept. Sie zeigt, dass möglichst viele kleine Tests unten („Unit") laufen sollten und wenige große oben („Akzeptanz") – weil kleine Tests schneller, billiger und punktgenauer sind. Auch wenn nicht jedes IHK-Projekt alle Ebenen testet, ist das Konzept als gedankliche Klammer hilfreich:
Welche Testarten konkret bei dir relevant sind, hängt vom Projekt ab. Bei einer Softwareentwicklung (FIAE) sind oft Unit- und Integrationstests zentral. Bei einer Infrastruktureinführung (FISI) eher Funktions-, Last- und Abnahmetests. Wichtig ist: du wählst die Testarten bewusst aus und begründest die Wahl.
3) Testarten im Detail
4) Testfälle definieren
Ein Testfall ist eine konkrete Anweisung, was zu tun ist und was dabei erwartet wird. Er hat fünf Elemente: Nummer, Bezeichnung, Vorbedingungen, Eingaben/Schritte, erwartetes Ergebnis. Eine kompakte Form als Tabelle eignet sich für die Doku:
Faustregel: 5–10 Testfälle reichen für eine IHK-Doku. Wichtig ist nicht die Menge, sondern die Abdeckung der zentralen Anforderungen. Jede funktionale (F1–F5) und jede kritische nichtfunktionale Anforderung (N1, N4) sollte einen zugehörigen Testfall haben.
5) Testprotokoll als Nachweis
Während du die Tests durchführst, hältst du die Ergebnisse in einem Testprotokoll fest. Es ist ein chronologischer Bericht über die Testdurchführung – Datum, Tester, Umgebung, getestete Schritte, beobachtete Ergebnisse. In der Doku reicht meist ein Auszug; das vollständige Protokoll kommt in den Anhang.
6) Testumgebung beschreiben
Eine oft vergessene, aber wichtige Information: wo wurde getestet? Im Produktivsystem kann man kaum testen (zu gefährlich). Stattdessen meist eine separate Testumgebung. In der Doku reicht ein kurzer Absatz:
„Die Tests wurden auf einer dedizierten Test-VM (4 vCPU, 8 GB RAM, 200 GB HDD) im selben Netzwerk wie das Produktivsystem durchgeführt. Damit ist die Netzwerkbandbreite und Dateisystem-Performance vergleichbar. Echtzeit-Backup-Jobs wurden auch im Produktivbetrieb beobachtet, jedoch ohne Restore-Operationen, um Datenkonflikte zu vermeiden."
Das wirkt fachkundig: du zeigst, dass du Test- und Produktivumgebung sauber trennst und Risiken im Blick hast.
7) Negativ-Tests und Grenzfälle
Eine besonders erwachsene Doku zeigt nicht nur, dass die Lösung im Normalfall funktioniert (Positiv-Tests), sondern auch, wie sie sich bei Problemen verhält. Diese Negativ-Tests oder Grenzfälle sind oft wertvoller als 10 Positiv-Tests:
- Netzwerkausfall während Backup: bricht der Job sauber ab oder kollabiert er? Folgejob OK?
- Voller Speicher: was passiert, wenn das Backup-Ziel voll ist? Alarm? Reparatur möglich?
- Falsche Berechtigungen: Backup-Account hat keine Rechte – wird das gemeldet?
- Verschlüsselungsschlüssel verloren: ist Restore noch möglich? Dokumentation des Wiederherstellungswegs?
- Riesendatei oder viele kleine: Verhalten bei extremen Datenstrukturen
Du musst nicht alle Negativ-Tests durchführen – aber wenn du 2–3 davon dokumentierst, hebst du dich von anderen Dokus ab.
8) Abnahme dokumentieren
Die Abnahme ist die formelle Bestätigung des Auftraggebers, dass das Projekt fertig ist. Sie hat eine rechtliche Dimension und gehört unbedingt in die Doku. Drei Elemente: Datum, beteiligte Personen, Bestätigungstext mit Unterschrift.
Die Wiederherstellungszeit liegt mit ca. 35 Min knapp über dem Zielwert (< 30 Min) und wird im Folgeprojekt optimiert.
Alle weiteren funktionalen und nichtfunktionalen Anforderungen sind erfüllt.
____________________ ____________________
Auftraggeber Auftragnehmer"
9) Abdeckungsmatrix Anforderungen vs. Tests
Eine sehr starke Visualisierung am Ende des Test-Kapitels ist die Test-Abdeckungsmatrix. Sie zeigt, dass jede Anforderung aus der Ist-Analyse mindestens einen Test hat.
| Anf. | Beschreibung | Testfall | Status |
|---|---|---|---|
| F1 | Tägliche automatische Sicherung | T1 | ✓ pass |
| F2 | Wöchentliche Vollsicherung | T1 | ✓ pass |
| F3 | Verschlüsselte Speicherung | T5 | ✓ pass |
| F5 | E-Mail-Benachrichtigung | T4 | ✓ pass |
| N1 | Restore < 30 Min | T3 | ~ 35 Min |
| N4 | DSGVO-Konformität | T5, T6 | ✓ pass |
Diese Matrix ist methodisch das Pendant zur Erfüllungsmatrix aus dem Soll-Konzept. Während dort die geplante Erfüllung gezeigt wurde, zeigt die Test-Matrix die tatsächliche Erfüllung. Schließt den Kreis schön.
10) Restrisiken benennen
Wenn nicht alles 100-prozentig erfüllt ist (wie bei T3), benennst du das offen als Restrisiko oder offene Punkte. Beispiel: „Die Restore-Zeit für komplette VM liegt bei ca. 35 Min und damit knapp über dem Zielwert von 30 Min. Hauptursache ist die Schreibgeschwindigkeit der NAS-Platten. Für die Praxis ist diese Abweichung akzeptabel; im Folgeprojekt ist eine NAS-Erweiterung um SSDs als Cache vorgesehen, was die Restore-Zeit voraussichtlich auf unter 20 Min senkt."
Solche ehrlich benannten Restrisiken sind kein Makel, sondern Zeichen von Reife. Ein Projekt, das angeblich zu 100 % alle Anforderungen optimal erfüllt, wirkt unrealistisch. Eine Lösung mit 90–95 % Erfüllung und klar benannten Verbesserungspotenzialen wirkt glaubwürdig.
11) Häufige Fehler im Test-Kapitel
- „Test wurde durchgeführt, funktioniert": keinerlei Substanz. Heilung: Testfälle konkret beschreiben
- Nur Positiv-Tests: alles funktioniert immer. Heilung: 2–3 Negativ-Tests einbauen
- Keine Erwartungen formuliert: „Restore funktioniert" – aber was war erwartet? Heilung: erwartetes Ergebnis pro Testfall
- Tests ohne Bezug zu Anforderungen: man weiß nicht, was sie zeigen. Heilung: Anforderung-Test-Matrix
- Testumgebung nicht beschrieben: wo wurde getestet? Heilung: ein Absatz dazu
- Abnahme fehlt: keine formelle Bestätigung. Heilung: Abnahmeprotokoll-Auszug einbauen
- Schönfärben: Restrisiken verschwiegen. Heilung: offen benennen, mit Ausblick
- Nur Screenshots: kein Text, nur Bilder. Heilung: Screenshots mit Erläuterung kombinieren
- Testprotokoll als Wand: 5 Seiten Rohprotokoll. Heilung: Auszug in Doku, Vollprotokoll in Anhang
- Testername fehlt: nicht nachvollziehbar. Heilung: bei jedem Testfall Tester nennen
12) Tipps für ein starkes Test-Kapitel
- Testarten bewusst wählen: Begründung dazu schreiben, warum diese Arten
- 5–10 Testfälle reichen: keine Mengenschlacht, sondern gezielte Abdeckung
- Anforderung → Test verknüpfen: Abdeckungsmatrix am Ende
- Erwartung & Ergebnis pro Test: nur so ist „pass" oder „fail" bewertbar
- Negativ-Tests einstreuen: 2–3 reichen, wertet auf
- Testumgebung beschreiben: ein Absatz, wo und wie getestet wurde
- Abnahme dokumentieren: formelle Bestätigung des Auftraggebers
- Restrisiken offen benennen: ehrlich statt schönen Schein
- Ausblick andeuten: was wäre der nächste Optimierungsschritt
- Vollprotokoll in Anhang: detaillierte Testprotokolle dort, im Hauptteil nur Auszüge
Zusammenfassung
Das Test-Kapitel ist 1–1,5 Seiten lang und macht 10 % der Bewertung aus. Inhalt: Testkonzept (welche Testarten, warum), Testfälle (5–10 mit Eingabe, erwartetem Ergebnis, Ist-Ergebnis, Status), Testprotokoll (chronologischer Nachweis), Testumgebung, Abdeckungsmatrix (Anforderung → Test), Abnahme (formell vom Auftraggeber) und Restrisiken (offen benannt). Testarten: Unit, Integration, Funktion, System, Last, Akzeptanz – passend zum Projekt auswählen. Negativ-Tests sind wertvoller als 10 Positiv-Tests. Test-Pyramide als Konzept. Häufige Fehler: zu vage Tests, nur Positiv-Tests, keine Anforderungs-Verknüpfung, fehlende Abnahme, Schönfärben. Tipps: Testarten bewusst wählen, Erwartung pro Test, 2–3 Negativ-Tests, Vollprotokoll in Anhang, Restrisiken ehrlich, niemals Tests erfinden.