Testbericht und Qualitätssicherung
„Funktioniert!" ist keine Qualitäts-Sicherung. Wer nach einer Implementierung kurz prüft, ob die Hauptfunktion läuft, und dann „abgenommen" sagt, hat das Wesentliche verpasst. Eine professionelle Lösung wird systematisch getestet: jede Anforderung mit einem konkreten Test-Fall, jede kritische Funktion mit dokumentierten Ergebnissen, jeder Test-Fall mit klaren Erwartungswerten. Genau das wollen die IHK-Prüfer:innen sehen – auch (und gerade) bei FISI-Projekten, wo Test gerne unterschätzt wird. Diese Lektion zeigt dir, wie eine gute Test-Fall-Tabelle aussieht, welche Test-Arten für welche Projekte passen (Funktion, Last, Sicherheit, Restore, Usability), wie du die Test-Pyramide bei Software-Projekten einsetzt, wie eine saubere Abnahme-Doku aufgebaut ist und welche typischen Antipatterns du vermeiden solltest. Wer hier 1-1,5 Seiten gut investiert, holt verlässlich Punkte – das Test-Kapitel ist oft der Unterschied zwischen 2 und 1.
1) Warum Test & QS so wichtig sind
- Erfüllung der Anforderungen nachweisen. Jede MUST-Anforderung aus dem Soll-Konzept muss getestet sein.
- Risiken absichern. Was passiert bei Ausfall? Bei Daten-Verlust? Bei Last-Spitze?
- Vor Übergabe Bugs finden. Fehler im Test-Umfeld sind günstig, im Produktiv-Umfeld teuer.
- Vertrauen schaffen. Beim Auftraggeber, bei dir selbst, bei den Anwendern.
- Reproduzierbarkeit. Tests können wiederholt werden, z. B. bei Patches.
- Bewertungs-Punkte. Ein gut ausgearbeitetes Test-Kapitel hebt sich deutlich von einer „funktioniert"-Notiz ab.
2) Test-Arten im Überblick
Je nach Projekt-Typ passen verschiedene Test-Arten – meist eine Auswahl, nicht alle:
Funktionstest
Erfüllt die Lösung die geforderten Funktionen? Klassisch: jede Anforderung wird mit mindestens einem Test-Fall geprüft.
Lasttest / Performance-Test
Wie verhält sich die Lösung unter Last? Antwortzeiten, Durchsatz, Stabilität. Bei Backup: wie lange dauert ein Restore eines 500-GB-Volumes?
Restore-Test
Bei Backup-Projekten zwingend. Backup ist nur so gut wie der getestete Restore. Mindestens ein vollständiger Restore-Test.
Sicherheits-Test
Berechtigungen korrekt? Verschlüsselung aktiv? Schwachstellen-Scan, Penetration-Test im Kleinen.
Integrations-Test
Spielen die Komponenten zusammen? Schnittstellen funktional? Beispiel: Backup-System ↔ Monitoring ↔ Mail-Versand.
Usability-/Akzeptanz-Test
Können Anwender die Lösung nutzen? Bei UI-Projekten oder Self-Service-Portalen wichtig.
Recovery-/Failover-Test
Wie verhält sich die Lösung bei Ausfall? Schwenkt sie um? Bei HA-Architekturen Pflicht.
Regressions-Test
Funktioniert noch alles, was vorher funktionierte? Nach Patches/Updates wichtig.
3) Test-Pyramide (bei Software-Projekten)
Bei Software-Projekten (FIAE) gilt die Test-Pyramide: viele kleine Tests unten, wenige große Tests oben:
4) Test-Fall-Tabelle – das Herzstück
Mindestens 3-5 dokumentierte Test-Fälle, besser 5-10. Pflichtspalten: ID, Beschreibung, Vorbedingung, Schritte, Erwartung, Ergebnis, Status:
| ID | Test-Fall | Erwartung | Ergebnis | Status |
|---|---|---|---|---|
| TF-01 | Vollständige Sicherung Server PROD-01 durchführen | Backup-Job läuft erfolgreich durch, Größe ~ 180 GB, Dauer < 4h | Job erfolgreich, 182 GB, Dauer 2h 47min | OK |
| TF-02 | Inkrementelle Sicherung nach Daten-Änderung | Nur geänderte Blöcke (~ 8-12 GB) werden gesichert | 10,4 GB inkrementell gesichert in 22 min | OK |
| TF-03 | Restore eines einzelnen Files aus letzter Tageskopie | File ist in < 5 min am Ziel-Ort verfügbar, Hash identisch | File verfügbar nach 3 min 12 s, Hash-Vergleich identisch | OK |
| TF-04 | Komplett-Restore des Servers PROD-01 in Test-Umgebung | Restore in < 4h, Anwendung startbar, Daten konsistent | Restore in 3h 18min, Anwendung läuft, Daten ok | OK |
| TF-05 | Verschlüsselung der Repository-Dateien prüfen | Dateien dürfen ohne Schlüssel nicht lesbar sein | Direkt-Zugriff schlägt fehl wie erwartet | OK |
| TF-06 | Backup-Job bei VSS-Fehler – Verhalten prüfen | Job bricht ab, Mail-Alarm wird ausgelöst | Initial: Mail-Alarm nicht versandt | FAIL |
| TF-06b | TF-06 nach Konfigurations-Anpassung (Mail-Smarthost) | Mail-Alarm wird ausgelöst | Mail nach 92 s erfolgreich zugestellt | OK |
| TF-07 | Cloud-Kopie nach Tagessicherung | Innerhalb 24h ist Kopie im S3-Bucket vorhanden, Vergleichs-Hash | Kopie nach 6h 14 min vollständig, Hash ok | OK |
Wichtig: Auch fehlgeschlagene Tests sind Erfolge der Test-Phase – sie haben Fehler aufgedeckt, die du dann korrigieren konntest. Im obigen Beispiel zeigt TF-06 mit dem Re-Test TF-06b genau diesen Ablauf.
5) Aufbau des Test-Kapitels
Typische Sub-Struktur:
| Abschnitt | Inhalt |
|---|---|
| 6.1 Test-Konzept | Welche Test-Arten werden durchgeführt? Welche Anforderungen werden abgedeckt? Welche Umgebung? |
| 6.2 Test-Umgebung | Hardware/VMs, Software-Stände, Test-Daten. Wichtig: keine Produktiv-Tests ohne Absicherung. |
| 6.3 Test-Fälle | Tabellarische Übersicht (siehe oben). Detail-Protokolle im Anhang. |
| 6.4 Test-Ergebnisse | Auswertung: wie viele Tests bestanden, fehlgeschlagen, Korrekturen. |
| 6.5 Abnahme | Wer hat die Lösung wann abgenommen? Übergabe-Protokoll. |
6) Übergabe & Abnahme
Die Abnahme ist der formale Akt, mit dem der Auftraggeber bestätigt, dass die Lösung den Anforderungen entspricht und in den Produktiv-Betrieb übernommen werden kann.
📅 Termin & Beteiligte
Wer war dabei? Datum und Ort. Auftraggeber-Rolle, IT-Verantwortliche, du selbst, ggf. Ausbilder.
📋 Abnahme-Kriterien
Welche Punkte mussten erfüllt sein? Direkt aus dem Soll-Konzept (MUST-Anforderungen) abgeleitet.
✅ Geprüfte Funktionen
Welche Funktionen wurden im Abnahme-Termin live demonstriert? Backup-Job startet, Restore-Test, Dashboard, Alerting.
⚠ Vorbehalte / Restpunkte
Falls Abnahme „unter Vorbehalt": welche Punkte sind nachzuliefern? Mit Termin.
📑 Übergebene Artefakte
Was hat der Auftraggeber bekommen? Doku, Zugangsdaten, Schulungs-Material, Service-Vereinbarung.
✍ Unterschriften
Datum, Unterschriften beider Seiten. Protokoll im Anhang. Wichtige Pflicht-Anlage.
7) Übergabe-Doku für den Betrieb
Was du dem Auftraggeber zur Übergabe mitgibst:
- Betriebshandbuch – Aufbau, Konfiguration, regelmäßige Wartung. Mehr in K65 Betriebshandbuch.
- Notfall-Anleitung – was tun bei Ausfall, wer ist Ansprechpartner.
- Zugangsdaten – im sicheren Passwort-Manager hinterlegt, nicht im Klartext im Dokument.
- Architektur-Diagramm – aktualisierte Version.
- Wartungs-Plan – wer macht was wann (z. B. monatliche Restore-Tests).
- Schulungs-Material – falls Anwender oder Admins eingewiesen werden. Mehr in K66 Kunden einweisen.
- Lizenz-Übersicht – welche Lizenzen sind aktiv, Laufzeiten, Verlängerungs-Termine.
- Übergabe-Protokoll – das schriftliche Dokument selbst. Siehe K65 Übergabe-Protokoll.
8) Qualitätssicherung als Prozess
QS ist nicht nur am Ende – sondern während des Projekts:
- Code-Reviews (bei FIAE) – Kollege schaut über Code, vor Merge.
- Vier-Augen-Prinzip bei Konfigurations-Änderungen kritischer Systeme.
- Continuous Integration / Continuous Delivery – automatisierte Tests bei jedem Commit.
- Static Analysis – Tools wie SonarQube, Snyk, ESLint.
- Versionskontrolle – Git: alle Änderungen nachvollziehbar, rückrollbar.
- Doku parallel pflegen – nicht erst am Ende. Reduziert Erinnerungs-Lücken.
- Definition of Done klar definieren – was muss erfüllt sein, damit eine Aufgabe als „fertig" gilt.
9) Antipatterns
- „Habe getestet, läuft." Pauschal-Aussage ohne Test-Fälle, ohne Erwartungen, ohne Ergebnisse. Lösung: Tabelle mit konkreten Test-Fällen.
- Nur Glücks-Tests. Nur Cases getestet, die sicher klappen. Lösung: auch Fehler-Cases (Negative Tests) – z. B. „Was passiert bei vollem Speicher?".
- Test in Produktiv-Umgebung. Backup-Restore „mal eben" in Produktiv. Riesiges Risiko. Lösung: separate Test-Umgebung.
- Backup ohne Restore-Test. Klassiker. Backup läuft – aber niemand weiß, ob Restore geht. Lösung: Restore-Test ist Pflicht.
- Erwartungen unklar. „Sollte funktionieren" – wie genau prüft man das? Lösung: messbare Erwartung („Datei wiederhergestellt in < 5 min").
- Fehlgeschlagene Tests verstecken. Schade – sie zeigen Problemlöse-Kompetenz! Lösung: ehrlich dokumentieren + Korrektur.
- Abnahme ohne Unterschrift. Mündliche Abnahme reicht nicht. Lösung: schriftliches Protokoll mit Unterschriften.
- Sicherheits-Tests vergessen. Berechtigungen / Verschlüsselung nicht geprüft. Lösung: mindestens 1-2 Sicherheits-Test-Fälle.
- Performance ungetestet. Backup, das im Test 5 GB schafft, scheitert an 500 GB Produktiv-Daten. Lösung: mit realistischen Daten-Mengen testen.
- Übergabe ohne Doku. „Hier sind die Zugangsdaten, viel Erfolg." Lösung: Betriebshandbuch und Notfall-Anleitung dokumentieren.
Zusammenfassung
Das Test- und Qualitäts-Kapitel ist der formale Nachweis, dass deine Lösung die Anforderungen erfüllt. Pflicht-Inhalte: Test-Konzept, Test-Umgebung, Test-Fall-Tabelle (mindestens 3-5 dokumentierte Fälle mit ID/Beschreibung/Erwartung/Ergebnis/Status), Auswertung, Abnahme. Test-Arten passend zum Projekt: Funktion, Last/Performance, Restore, Sicherheit, Integration, Usability, Failover. Bei Software-Projekten zusätzlich die Test-Pyramide: viele Unit-Tests, weniger Integrations-Tests, wenige E2E-Tests. Abnahme ist formaler Akt mit Unterschriften – im Anhang dokumentieren. Übergabe-Doku umfasst Betriebshandbuch, Notfall-Anleitung, Zugangsdaten, Wartungs-Plan, Schulungs-Material. Goldstandard: ehrliche Dokumentation auch fehlgeschlagener Tests + Korrekturen – zeigt Problemlöse-Kompetenz und bringt Punkte.
Verwandte Lektionen: Umsetzung · Fazit & Anhänge · Beispiel-Doku · und mehrWeitere relevante LektionenIst & SollHäufige FehlerÜbergabe-Protokoll (K65)Betriebshandbuch (K65)Kunden einweisen (K66)