Ein Testkonzept beschreibt, was du testest, wie du testest und wann ein Test als bestanden gilt. In der Projektarbeit lieferst du damit den Nachweis für systematische Qualitätssicherung.
Das Testkonzept entsteht idealerweise parallel zur Anforderungsdefinition. Wenn du weißt, was deine Lösung können soll, kannst du direkt festlegen, wie du das prüfst. Hier bekommst du eine klare Struktur, Entscheidungshilfen für die Testfallauswahl, Vorlagen und konkrete Beispiele.
Enthält
-
Testziele, Testumfang, Testumgebung
-
Testfälle (je: ID, Beschreibung, Vorbedingung, Schritte, erwartetes Ergebnis)
-
Abnahmekriterien
Ergebnis
-
Begründete Auswahl risikobasierter Testfälle mit nachvollziehbarer Anforderungsabdeckung
-
Testprotokoll als Nachweis der Durchführung
Inhaltsverzeichnis
Testkonzept vs. Testplan vs. Testprotokoll
Testkonzept und Testplan werden je nach Vorgehensmodell unterschiedlich abgegrenzt und teilweise überlappend verwendet. Für deine Projektarbeit kannst du die folgenden Schwerpunkte unterscheiden; maßgeblich sind die Begriffe deiner Vorgaben.
Testkonzept
- Was: Beschreibt, was und wie getestet wird.
- Inhalte: Testziele, Testumfang, Testumgebung, Testfälle, Abnahmekriterien.
- Wann: Vor der Testdurchführung erstellen.
In der Projektarbeit: Umfang und Platzierung richten sich nach den Dokumentationsvorgaben.
Testplan
- Was: Verbindet die fachliche Testplanung mit Organisation und Zeitplanung.
- Inhalte: Testziele, Umfang und Vorgehen sowie Ressourcen, Verantwortlichkeiten, Zeitplan, Risiken und Eskalationswege.
- Wann: Vor der Testdurchführung; die Detailtiefe richtet sich nach Umfang und Beteiligten.
In der Projektarbeit: Kann separat stehen oder mit dem Testkonzept kombiniert werden, wenn die Vorgaben das zulassen.
Testprotokoll
- Was: Dokumentiert die durchgeführten Tests und deren Ergebnisse.
- Inhalte: Testfall-ID, Datum, tatsächliches Ergebnis, Status (bestanden/fehlgeschlagen/blockiert).
- Wann: Während und nach der Testdurchführung.
In der Projektarbeit: Zeigt, dass du tatsächlich getestet hast. Oft im Anhang.
Eine kompakte Dokumentation kann Konzept, Planung und repräsentative Testfälle im Hauptteil verbinden und das vollständige Protokoll in den Anhang auslagern.
Hinweis zu Vorgaben: Ob diese Aufteilung zulässig ist, bestimmen deine Prüfungs- und Dokumentationsvorgaben.
Testkonzept: Aufbau und Struktur
Der Aufbau des Testkonzepts folgt einer logischen Struktur. Du beschreibst zuerst die Ziele, dann den Umfang, die konkreten Testfälle und schließlich die Kriterien für die Abnahme.
Element 1: Testziele
Du beschreibst, was du mit den Tests erreichen willst.
Beispiel: „Die Tests sollen prüfen, ob die im Pflichtenheft definierten Funktionen korrekt arbeiten und die Anwendung unter Normallast stabil läuft.“
Stolperstelle: Zu vage formulieren. „Das System soll funktionieren“ ist kein Testziel.
Element 2: Testumfang
Du legst fest, was getestet wird und was nicht.
Beispiel: „Getestet werden: Benutzeranmeldung, Dateneingabe, Berichterstellung. Nicht getestet werden unveränderte interne Funktionen der Bestandssysteme außerhalb des Projektumfangs. Ihre betroffenen Schnittstellen werden mitgeprüft.“
Stolperstelle: Nicht begründen, warum etwas ausgeschlossen wird. Prüfende fragen sich sonst, ob du es vergessen hast.
Element 3: Testumgebung
Du beschreibst, in welcher Umgebung du testest, inklusive der Testdaten.
Muster: „Die Tests erfolgen auf dem getrennten Testsystem [Versionen] mit reproduzierbaren synthetischen Testdaten aus [Generator/Seed].“
Testdaten dokumentieren:
- Quelle: Bevorzugt synthetische Daten oder Seed-Daten aus dem Testframework; Produktionsdaten nur nach ausdrücklicher Freigabe und Schutzprüfung.
- Personenbezug: Anonymisierung und Pseudonymisierung korrekt unterscheiden; bei Personenbezug Rechtsgrundlage, Zugriff, Schutz und Löschung dokumentieren.
- Reproduzierbarkeit: Datensatzgröße (z. B. „100 Testdatensätze“), Version/Seed angeben, damit Tests wiederholbar sind.
Stolperstelle: Teste nicht ungeprüft im Produktivsystem oder mit einer Produktionskopie. Nutze eine getrennte Testumgebung.
Beachte dazu die Kurzposition des BfDI zu Testdaten.
Element 4: Testende- und Abnahmekriterien
Ein Testfall gilt als bestanden, wenn sein tatsächliches Ergebnis die festgelegten Erwartungen erfüllt. Testendekriterien legen fest, wann du die Testaktivitäten abschließt; Abnahmekriterien regeln, unter welchen Bedingungen die Lösung akzeptiert werden kann. Die folgenden Werte sind ein mögliches Projektschema, das du vorab abstimmst.
Beispiel (Richtwert): „Alle Testfälle mit Priorität 1 müssen bestanden sein. Offene Punkte bei Priorität 2 sind nur akzeptabel, wenn ein Workaround und ein Fix-Termin vorliegen und die zuständige Person die Abweichung nach den vereinbarten Kriterien akzeptiert.“
Entscheidungslogik für offene Punkte:
- Severity: Beschreibt die Auswirkung des Fehlers, getrennt von der Behebungspriorität. Mögliche Stufen: Kritisch (Kernfunktion blockiert), Hoch (wichtige Funktion stark eingeschränkt), Mittel (begrenzte Auswirkung), Niedrig (kosmetisch).
- Workaround: Gibt es eine alternative Lösung, bis der Fehler behoben ist? Dokumentieren.
- Retest-Termin: Wann wird der behobene Fehler erneut getestet? Festlegen und nachverfolgen.
- Akzeptanz-Check: In diesem Beispiel bleibt ein P2-Punkt nur offen, wenn ein Workaround existiert, der Fix terminiert ist, kein bekanntes Risiko für Datenverlust oder Sicherheit besteht und die zuständige Person die Ausnahme akzeptiert. Der betroffene fehlgeschlagene Test wird dadurch nicht zu einem bestandenen Test.
Stolperstelle: Keine messbaren Kriterien. „Das System soll zufriedenstellend laufen“ ist nicht prüfbar.
Welche Testfälle nehme ich?
Du kannst nicht alles testen. Die Kunst liegt darin, die richtigen Testfälle auszuwählen. Dieser Schnellcheck hilft dir, aus deinen Anforderungen sinnvolle Testfälle abzuleiten.
-
Kernprozesse (Happy Path): Was ist der häufigste Standardablauf? → Normalabläufe mit unterschiedlichen relevanten Ausgangslagen abdecken
-
Kritische Anforderungen: Welche Funktionen sind geschäftskritisch oder wurden explizit gefordert? → Jede kritische Anforderung nachweisbar prüfen
-
Risiken: Wo droht Datenverlust, Sicherheitslücke oder Systemabsturz? → Testtiefe nach Schadenspotenzial festlegen
-
Häufige Fehlerquellen: Wo treten erfahrungsgemäß Probleme auf? → Relevante Fehlerbilder gezielt reproduzieren
-
Grenzwerte: Was passiert bei Minimal- und Maximalwerten? → Unter-, Ober- und unmittelbar angrenzende Werte prüfen
-
Negativfälle: Was passiert bei Fehleingaben? → Relevante Validierungs- und Fehlerpfade abdecken
Beispiel: Aus der Anforderung „Benutzer kann sich mit E-Mail und Passwort anmelden“ leitest du ab: TC-LOGIN-001 (korrekter Login), TC-LOGIN-002 (falsches Passwort), TC-LOGIN-003 (leere Felder), TC-LOGIN-004 (Sperre nach dem in der Sicherheitsanforderung festgelegten Schwellenwert).
Testfälle richtig formulieren
Ein Testfall beschreibt einen einzelnen Test so präzise, dass ihn jemand anderes wiederholen könnte. Er besteht aus einer eindeutigen ID, einer Beschreibung, Vorbedingungen, konkreten Schritten und dem erwarteten Ergebnis.
Die ID ist eine eindeutige Nummer, mit der du den Testfall im Protokoll referenzierst. Nutze ein Schema wie TC-001, TC-002 oder gruppiere nach Funktionsbereichen: TC-LOGIN-001, TC-EXPORT-001.
Die Beschreibung fasst in einem Satz zusammen, was der Test prüft. Sie sollte so präzise sein, dass du beim Lesen sofort weißt, worum es geht. Vermeide vage Formulierungen wie „Funktion testen“.
Die Vorbedingungen beschreiben den Ausgangszustand. Was muss gegeben sein, damit der Test starten kann? Beispiel: „Benutzer ist eingeloggt. Im Warenkorb liegt mindestens ein Artikel.“ Ohne klare Vorbedingungen sind Tests nicht reproduzierbar.
Die Testschritte beschreiben die einzelnen Aktionen. Nummeriere sie als eindeutige Handlungsanweisungen: „1. Menüpunkt Einstellungen öffnen. 2. Passwort-Feld anklicken. 3. Neues Passwort eingeben. 4. Änderung speichern und die Meldung prüfen. 5. Abmelden. 6. Mit dem neuen Passwort erneut anmelden.“ Je präziser die Schritte, desto weniger Interpretationsspielraum.
Das erwartete Ergebnis beschreibt, was an den festgelegten Prüfpunkten passieren soll. Formuliere es so konkret wie möglich: „Erfolgsmeldung ‚Passwort geändert‘ wird angezeigt. Bei erneutem Login wird das neue Passwort akzeptiert.“
Ein Testfall braucht ein klares Prüfziel. Zusammengehörige Prüfungen eines Ablaufs können darin kombiniert werden, etwa beim Ändern eines Passworts. Dokumentiere, welcher Schritt und welche Erwartung abweichen; die Fehlerursache musst du anschließend untersuchen. Trenne voneinander unabhängige Prüfziele in eigene Testfälle.
Testfallkategorien in der Projektarbeit
In der Projektarbeit solltest du verschiedene Arten von Tests dokumentieren. Das zeigt Prüfenden, dass du unterschiedliche Szenarien bedenkst und nicht nur den Idealfall testest.
Funktionale Tests prüfen, ob eine Funktion das tut, was sie soll. Sie bilden den Kern deiner Testfälle und orientieren sich an den Anforderungen aus dem Pflichtenheft. Beispiel: „Benutzer kann sich mit korrekten Zugangsdaten einloggen.“
Grenzfalltests prüfen das Verhalten an den Rändern des erlaubten Bereichs. Was passiert bei sehr langen Eingaben? Bei leeren Feldern? Bei der maximalen Anzahl von Einträgen? Diese Tests finden oft Fehler, die im Normalbetrieb verborgen bleiben.
Negativtests prüfen, ob das System Fehleingaben korrekt behandelt. Sie ergänzen Positivtests und können ebenfalls funktionale Tests sein. Beispiel: „Fehlermeldung bei ungültigem Passwort.“
Nicht-funktionale Tests prüfen Qualitätseigenschaften wie Performance, Sicherheit oder Benutzerfreundlichkeit. Leite die Auswahl aus Risiken und vereinbarten Qualitätsanforderungen ab und begründe, welche Eigenschaften du prüfst oder bewusst ausklammerst.
Performance: „Ladezeit der Übersichtsseite bei [definiertem Datenstand] unter [vereinbartem Zielwert].“
Sicherheit: „SQL-Injection im Suchfeld wird abgefangen, keine Fehlermeldung mit Datenbankdetails.“
Browser-Kompatibilität: „Anwendung funktioniert in Chrome, Firefox und Edge ohne Darstellungsfehler.“
Datenintegrität: „Nach Abbruch während des Speicherns sind keine inkonsistenten Daten in der Datenbank.“
Usability: „Fehlermeldungen sind verständlich und zeigen, wie der Fehler behoben werden kann.“
Beispiel: Nicht-funktionaler Testfall (Performance)
TC-PERF-001: Ladezeit Übersichtsseite. Zeit bis zum Load-Ereignis bei 100 Datensätzen.
Vorbedingung: Testdatenbank enthält exakt 100 Datensätze. Browser-Cache ist geleert. Netzwerk-Throttling deaktiviert. Gleiche Testbedingungen: lokaler Rechner, Chrome-Browser.
Schritte:
1. Browser-Entwicklertools öffnen (Netzwerk-Tab).
2. „Disable cache“ aktivieren und die Entwicklertools geöffnet lassen.
3. Übersichtsseite einmal als Warm-up laden; diesen Lauf nicht auswerten.
4. Die Seite unter gleichen Bedingungen fünfmal neu
laden und jeweils die Zeit des Load-Ereignisses im Netzwerk-Tab notieren.
5. Aus den fünf Messwerten Median und Spannweite
berechnen und dokumentieren.
Erwartetes Ergebnis: Der Median erfüllt den vereinbarten Zielwert. Alle Testdatensätze werden korrekt angezeigt.
Hinweis: Messwerte sind umgebungsabhängig. Dokumentiere Gerät, Browser, Netzwerk, Datenstand, Warm-up und Messwerkzeug. TTFB, Load und LCP messen unterschiedliche Teile des Ablaufs und dürfen nicht austauschbar interpretiert werden.
Stelle die Mischung risikobasiert zusammen; die Zahl ergibt sich aus Anforderungen und Prüfungsumfang:
-
Funktionale Tests für die Kernanforderungen
-
Grenzfalltests für kritische Werte und Eingabefelder
-
Negativtests für relevante Fehl- und Missbrauchsfälle
-
Nicht-funktionale Tests für die vereinbarten Qualitätseigenschaften
Testebenen in der Projektarbeit
In der Softwareentwicklung unterscheidet man verschiedene Testebenen. Für die Projektarbeit ist wichtig zu wissen, welche davon realistisch sind und was du dokumentieren solltest.
Unit-Tests: Prüfen einzelne Komponenten, etwa Funktionen oder Methoden, isoliert. Dokumentiere die für deinen Projektanteil relevanten Tests und Ergebnisse in angemessener Detailtiefe.
Integrationstests: Prüfen das Zusammenspiel von Komponenten innerhalb eines Systems oder die Schnittstellen zwischen mehreren Systemen.
Systemtests: Prüfen das Verhalten und die Eigenschaften des Gesamtsystems, etwa vollständige Abläufe aus Nutzersicht. Die Detailtiefe der Dokumentation richtet sich nach Anforderungen und Risiken.
Abnahmetests: Prüfen die Erfüllung der vereinbarten Bedürfnisse und Abnahmekriterien, etwa durch vorgesehene Nutzende oder beauftragte Vertretungen des Auftraggebers. Dokumentiere Ergebnis und Entscheidung im Abnahmeprotokoll.
Wähle die Testebenen passend zur Architektur und zu deinem Projektanteil. Bei einem Entwicklungsprojekt können Unit-, Integrations- und Systemtests zusammengehören; bei einem Einführungsprojekt stehen eher Schnittstellen-, System- und Abnahmetests im Vordergrund. Dokumentiere Auswahl und Nachweise statt pauschal eine Ebene zu bevorzugen.
Anforderungen und Testfälle verknüpfen
Eine Traceability-Matrix zeigt auf einen Blick, welche Testfälle welche Anforderungen abdecken. So werden Lücken und der Status kritischer Anforderungen nachvollziehbar.
Ausgefülltes Beispiel: Traceability-Matrix
Die Statuswerte sind für dieses Beispiel angenommen. Trage in deiner Arbeit die tatsächlich dokumentierten Ergebnisse ein.
| Anforderung | Testfall-IDs | Status |
|---|---|---|
| ANF-001: Login | TC-LOGIN-001, TC-LOGIN-002 | Bestanden |
| ANF-002: Datenexport | TC-EXPORT-001, TC-EXPORT-003 | Bestanden |
| ANF-003: Bericht | TC-REPORT-001 | Bestanden |
-
ANF-001: Login
Testfall-IDs
TC-LOGIN-001, TC-LOGIN-002
Status
Bestanden
-
ANF-002: Datenexport
Testfall-IDs
TC-EXPORT-001, TC-EXPORT-003
Status
Bestanden
-
ANF-003: Bericht
Testfall-IDs
TC-REPORT-001
Status
Bestanden
Bei kleineren Projekten reicht auch ein Verweis im Testfall selbst: „Prüft Anforderung ANF-001“. Die vollständige Matrix kannst du in den Anhang auslagern.
Testprotokoll erstellen
Das Testprotokoll ist der Nachweis, dass du tatsächlich getestet hast. Pro Testfall dokumentierst du: ID, Datum, tatsächliches Ergebnis und Status (bestanden, fehlgeschlagen, blockiert).
Bei fehlgeschlagenen Tests ergänzt du eine Fehlerbeschreibung und dokumentierst, wie du den Fehler behoben hast. Nach einer Korrektur dokumentierst du den Retest und risikobasiert ausgewählte Regressionstests für mögliche Nebenwirkungen. Wenn alle Tests bestanden wurden, hältst du Testumfang und Nachweise ebenso nachvollziehbar fest.
Du kannst das Testprotokoll als Tabelle im Hauptteil zeigen oder eine Zusammenfassung im Text schreiben und die vollständige Tabelle in den Anhang auslagern.
Testkonzept Beispiele
Hier siehst du konkrete Beispiele für Testfälle aus verschiedenen Projekttypen, darunter einen Negativtest. Achte darauf, wie jeder Testfall alle Elemente enthält und präzise formuliert ist.
Beispiel: Webentwicklung
TC-LOGIN-001: Login-Funktion. Test mit korrekten Zugangsdaten.
Vorbedingung: Benutzer ist nicht eingeloggt. Testbenutzer „test@example.org“ existiert.
Schritte:
1. Login-Seite aufrufen.
2. E-Mail „test@example.org“ eingeben.
3. Das für die Testumgebung hinterlegte Testpasswort
eingeben.
4. Button „Anmelden“ klicken.
Erwartetes Ergebnis: Weiterleitung zum Dashboard. Benutzername wird in Navigation angezeigt.
Beispiel: Datenbankprojekt
TC-EXPORT-003: CSV-Export. Export mit Sonderzeichen.
Vorbedingung: Der vereinbarte Export verwendet UTF-8, Semikolon als Trennzeichen und doppelte Anführungszeichen als Textbegrenzung. Mindestens ein Datensatz enthält den Text „Köln;Müller“.
Schritte:
1. Datenübersicht öffnen.
2. Datensätze mit Sonderzeichen markieren.
3. Export-Funktion auswählen (Format CSV).
4. Export starten.
5. Die Datei mit einem CSV-Importwerkzeug öffnen, UTF-8, Semikolon und doppelte Anführungszeichen
einstellen und die Werte mit dem Ausgangsdatensatz vergleichen.
Erwartetes Ergebnis: Die CSV-Datei wird erstellt. Das Feld mit „Köln;Müller“ ist in doppelte Anführungszeichen eingeschlossen. Beim Import bleibt der Text mit Umlauten und Semikolon vollständig in einem Feld erhalten.
Beispiel: Negativtest
TC-LOGIN-002: Falsches Passwort. Prüfung der Fehlerbehandlung.
Vorbedingung: Benutzer ist nicht eingeloggt. Testbenutzer existiert.
Schritte:
1. Login-Seite aufrufen.
2. Korrekte E-Mail eingeben.
3. Falsches Passwort eingeben.
4. Button „Anmelden“
klicken.
Erwartetes Ergebnis: Fehlermeldung „Zugangsdaten ungültig“ erscheint. Passwortfeld geleert.
Vorlage zum Kopieren
Diese Vorlagen kannst du direkt in Word oder Excel übernehmen. Ersetze die Platzhalter in eckigen Klammern durch deine Inhalte.
Testziele
Die Tests sollen prüfen, ob [Funktionen] korrekt umgesetzt sind und [Qualitätskriterium] erfüllt wird.
Testumfang
Getestet: [Funktionen]. Nicht getestet: [Ausnahmen] (Begründung: [Grund]).
Testumgebung
[System], [Browser/Software], [Testdaten-Quelle].
Abnahmekriterien
Alle Testfälle Priorität 1 bestanden. Max. [X] offene Punkte bei Priorität 2, sofern die vereinbarten Ausnahmebedingungen erfüllt und durch [zuständige Person] akzeptiert sind.
ID
TC-[XX]-001
Beschreibung
[Was wird getestet]
Vorbedingung
[Ausgangszustand]
Schritte
1. [Aktion]
2. [Aktion]
Erwartetes Ergebnis
[Messbares Ergebnis]
Tipp: Ergänze Spalten für „Priorität“ und „Anforderung“ (ANF-ID), um Traceability zu zeigen.
ID
TC-[XX]-001
Datum
[Datum]
Ergebnis (IST)
[Was passiert ist]
Status
[Status]
Bemerkung
[Analyse / Lösung]
Typische Fehler vermeiden
Zu vage Testfälle
Formulierungen wie „Funktion testen“ oder „System prüfen“ sind nicht nachvollziehbar. Schreibe so präzise, dass jemand anderes den Test wiederholen könnte.
Schwach
„Login testen.“
Besser
„Login mit korrekten Zugangsdaten: E-Mail und Passwort eingeben, Weiterleitung zum Dashboard prüfen.“
Nur Positivtests
Wenn du nur erfolgreiche Abläufe testest, bleiben wichtige Fehlerpfade ungeprüft. Prüfe auch, was passiert, wenn Eingaben falsch sind oder Grenzwerte erreicht werden.
Schwach
Alle Tests zeigen erfolgreiche Abläufe.
Besser
Positive und negative funktionale Tests sowie passende Grenzfalltests.
Keine Testendekriterien
Ohne klare Kriterien weiß niemand, wann die Testaktivitäten abgeschlossen sind. Definiere vorab, welche Tests bestanden sein müssen und wie du mit offenen Punkten umgehst.
Schwach
„Das System sollte funktionieren.“
Besser
„Alle Testfälle mit Priorität 1 müssen bestanden sein.“
Testprotokoll fehlt
Das Testkonzept allein zeigt nur die Planung. Ohne Protokoll wissen Prüfende nicht, ob du tatsächlich getestet hast und wie die Ergebnisse waren.
Nächster Schritt: Vom Test zur Abnahme
Dein Testkonzept ist fertig, wenn Testziele, Testumfang, Testumgebung sowie Testende- und Abnahmekriterien definiert sind. Deine Testfälle sind vollständig, wenn jeder Testfall ID, Beschreibung, Vorbedingungen, Schritte und erwartetes Ergebnis enthält.
-
Testfälle priorisieren: Kennzeichne kritische Tests mit Priorität 1.
-
Tests durchführen: Arbeite die Testfälle systematisch ab.
-
Protokoll führen: Dokumentiere Ergebnisse, Fehler und Lösungen.
-
Abnahme vorbereiten: Prüfe, ob alle Abnahmekriterien erfüllt sind.
Die Testergebnisse bilden eine Grundlage für die Abnahmeentscheidung durch den Auftraggeber. Das Abnahmeprotokoll hält Prüfergebnisse, offene Punkte und die Entscheidung über die Abnahme fest.
In der Dokumentation beschreibst du im Fazit, wie die Tests verlaufen sind und ob die Abnahmekriterien erfüllt wurden. In der Reflexion kannst du beschreiben, was du über Qualitätssicherung gelernt hast.
Abgabe vorbereiten: Prüfe die formalen Anforderungen deiner Prüfungsordnung. Bei IHK-Projektarbeiten sind oft Seitenumfang und Anhänge genau vorgegeben. Ein Blick auf Gliederung und Inhaltsverzeichnis hilft, nichts zu vergessen.
Häufig gestellte Fragen
Wie umfangreich sollte das Testkonzept in der Projektarbeit sein?
Dafür gibt es keine allgemeine Seiten- oder Testfallzahl. Maßgeblich sind Projektumfang und Prüfungs- beziehungsweise Dokumentationsvorgaben. Dokumentiere Ziele, Umfang, Umgebung, Abnahmekriterien und so viele risikobasierte Testfälle, dass die relevanten Anforderungen nachvollziehbar abgedeckt sind.
Wie priorisiere ich Testfälle und was muss zwingend bestanden sein?
Leite die Priorität aus Auswirkung und Eintrittswahrscheinlichkeit ab. Ein mögliches Projektschema ist P1 (kritisch), P2 (wichtig) und P3 (Optimierung). Welche Tests für die Abnahme bestanden sein müssen und wer Ausnahmen akzeptieren darf, legst du vorab mit Auftraggeber beziehungsweise Prüfungsstelle fest.
Was zeige ich im Hauptteil und was kommt in den Anhang?
Hauptteil: Ziele, Umfang, Kriterien, eine begründete Auswahl repräsentativer Testfälle und die Ergebniszusammenfassung. Anhang: Falls laut Vorgaben zulässig, vollständige Testfall-Tabelle, detailliertes Protokoll, Nachweise und Traceability-Matrix. Verweise im Hauptteil präzise auf den Anhang.
Wie dokumentiere ich Testdaten und Anonymisierung?
Bevorzuge synthetische Testdaten. Wenn Produktionsdaten ausnahmsweise verarbeitet werden sollen, brauchst du eine ausdrückliche Freigabe und eine geklärte Rechtsgrundlage. Das Ersetzen von Namen kann nur Pseudonymisierung sein; behaupte keine Anonymisierung ohne belastbare Prüfung. Dokumentiere Quelle, Schutzmaßnahmen, Zugriff und Löschung.
Welches Format ist am sinnvollsten für Testfälle?
Nutze eine strukturierte Tabelle im freigegebenen Werkzeug. Sinnvolle Spalten sind ID, Bezug zur Anforderung, Vorbedingung, Schritte, erwartetes und tatsächliches Ergebnis sowie Status. Eine vollständige Tabelle kann nach den formalen Vorgaben in den Anhang, wenn du im Hauptteil darauf verweist.
Wie viele Testfälle sollte ich in der Projektarbeit zeigen?
Eine universelle Zahl gibt es nicht. Leite die Auswahl aus Anforderungen und Risiken ab: Kernabläufe, relevante Grenzwerte, Fehlerbehandlung und projektrelevante nicht-funktionale Eigenschaften. Eine Traceability-Matrix macht sichtbar, ob wichtige Anforderungen ungetestet bleiben.
Muss ich jeden Testfall einzeln dokumentieren?
Jeder ausgeführte Test sollte im Protokoll eindeutig nachvollziehbar sein. Im Hauptteil genügt häufig eine begründete Auswahl repräsentativer Fälle; die vollständige Übersicht kann nach den Vorgaben in den Anhang. Verweise im Text etwa auf „Anhang A3: vollständige Testfall-Übersicht“.
Was mache ich, wenn Tests fehlschlagen?
Dokumentiere Status, tatsächliches Ergebnis, Abweichung, Analyse und Folgemaßnahme. Nach einer Korrektur folgt ein Retest; prüfe außerdem risikobasiert, ob die Änderung andere Funktionen beeinträchtigt. Wenn alle Tests bestanden wurden, ist auch das ein mögliches Ergebnis. Wichtig sind ein plausibler Testumfang und nachvollziehbare Nachweise.
Wie gehe ich mit offenen Fehlern bei der Abnahme um?
Klassifiziere Auswirkung und Dringlichkeit, dokumentiere Workaround, Verantwortlichkeit und Retest-Termin. Ob ein offener Punkt die Abnahme verhindert oder als bekannte Abweichung akzeptiert wird, entscheidet die autorisierte Stelle anhand der vereinbarten Kriterien und des dokumentierten Risikos.
Wie messe ich Performance-Werte richtig?
Definiere Metrik und Zielwert vorab, etwa TTFB für die Zeit bis zum ersten Antwortbyte einschließlich Netzwerkanteilen oder LCP für die Darstellung des größten sichtbaren Inhalts. Führe mehrere Läufe nach einem dokumentierten Warm-up unter gleichen Bedingungen durch und berichte Median sowie Streuung oder Spannweite. Gerät, Browser, Netzwerk, Datenstand und Werkzeug gehören ins Protokoll.
Gliederung der Projektarbeit 
Plagiate vermeiden 
Projektarbeit schreiben: Aufbau und Tipps