Inhaltsverzeichnis
Die Ergebnisdokumentation deiner Projektarbeit zeigt, dass dein Projekt funktioniert, geprüft wurde und bereit für die Übergabe ist. Hier bekommst du konkrete Vorlagen für Testprotokolle, Kriterientabellen und Übergabelisten, die du direkt kopieren und anpassen kannst.
Du brauchst für eine vollständige Ergebnisdokumentation vier Elemente: ein Testprotokoll (bei technischen Projekten) oder eine Kriterienprüfung (bei Konzeptarbeiten), eine Qualitätssicherungs-Tabelle mit Soll-Ist-Vergleich, einen Abnahme-Nachweis (Protokoll, E-Mail oder Checkliste) und eine Übergabeliste mit allen übergebenen Artefakten. Bei einem Softwareprojekt sind typischerweise 5 bis 15 Testfälle üblich. Bei einer Konzeptarbeit werden oft 3 bis 5 geprüfte Qualitätskriterien erwartet. Die genauen Anforderungen variieren je nach Leitfaden.
Was ist die Ergebnisdokumentation?
Die Ergebnisdokumentation ist der Nachweis, dass dein Projekt die gesteckten Ziele erreicht hat. Sie beantwortet drei Fragen: Funktioniert das Projektergebnis wie geplant? Erfüllt es die festgelegten Qualitätskriterien? Ist es bereit für den Einsatz oder die Übergabe?
Im Unterschied zur Durchführung, die das Vorgehen beschreibt, fokussiert die Ergebnisdokumentation auf messbare Resultate, durchgeführte Prüfungen und die formale Bestätigung, dass das Projekt abgeschlossen ist. Sie ist nicht identisch mit der Reflexion im Fazit, die sich auf Erkenntnisse und Bewertungen konzentriert.
Technisches Projekt: Du dokumentierst Funktionstests, Performancemessungen und Fehlerprotokolle. Üblich sind je nach Umfang 5 bis 15 Testfälle mit Screenshots oder Log-Auszügen als Beleg. Konzeptionelles Projekt: Du prüfst gegen definierte Kriterien wie Vollständigkeit, Nachvollziehbarkeit oder Praxistauglichkeit. Hier sind häufig 3 bis 5 dokumentierte Kriterienprüfungen mit Feedbacknachweis ausreichend.
Testdokumentation mit Vorlage
Die Testdokumentation zeigt, dass du dein Projektergebnis systematisch geprüft hast. Prüfende wollen sehen, welche Tests du durchgeführt hast, was du erwartet hast und was tatsächlich passiert ist. Nutze die folgende Vorlage als Ausgangspunkt.
Spalten: Testfall-ID | Anforderung | Testschritte | Erwartetes Ergebnis | Tatsächliches
Ergebnis | Beleg | Status | Kommentar
Beispiel 1 (bestanden):
T-01 | Login-Funktion | 1. Seite aufrufen, 2. Daten eingeben, 3. Button klicken | Weiterleitung zum Dashboard
| Weiterleitung erfolgt in 1,2 Sek | Screenshot Anhang [X] | Bestanden | Keine Auffälligkeiten
Beispiel 2 (Abweichung):
T-05 | Ladezeit unter 3 Sek | Seite mit Testdaten laden | Max. 3 Sekunden | 4,1 Sekunden | Logauszug Anhang [Y]
| Teilweise bestanden | Akzeptabel für Prototyp, Optimierung empfohlen
Wie viele Testfälle sind genug?
Als Faustregel gilt: Jede Hauptanforderung aus deiner Planung sollte mindestens einmal getestet sein. Bei einem Softwareprojekt mit 8 Funktionen bedeutet das in der Regel 8 Testfälle als Minimum. Für eine gute Bewertung ergänzt du Grenzfälle (was passiert bei Falscheingaben?) und Negativtests (was sollte nicht funktionieren?). Sehr gute Arbeiten dokumentieren oft 10 bis 15 Testfälle mit unterschiedlichen Testarten. Die konkreten Erwartungen variieren je nach Prüfungsordnung.
Wann ist ein Screenshot sinnvoll?
Screenshots eignen sich für visuelle Ergebnisse: UI-Zustände, Fehlermeldungen, Vorher-Nachher-Vergleiche. Bei Performancetests sind Messwerte in Tabellenform aussagekräftiger. Log-Auszüge helfen bei der Nachvollziehbarkeit von Fehlern. Ein Screenshot pro Testfall reicht in der Regel. Wenn du mehr als 10 Screenshots hast, verschiebe sie in den Anhang und verweise im Testprotokoll auf die Seitenzahl.
Qualitätssicherung mit Kriterientabelle
Qualitätssicherung geht über einzelne Tests hinaus. Sie zeigt, dass dein Gesamtergebnis den vorab definierten Anforderungen entspricht. Greife auf die Anforderungen aus deiner Projektplanung zurück und prüfe jede einzeln.
Spalten: Kriterium | Definition/Messgröße | Prüfmethode | Soll | Ist | Bewertung
| Konsequenz
Beispiel hartes Kriterium:
Fehlerfreiheit | Keine kritischen Fehler im Betrieb | 10 Testdurchläufe | 0 Fehler | 0 Fehler | Erfüllt | Keine
Beispiel weiches Kriterium:
Bedienbarkeit | Nutzer findet Funktionen ohne Anleitung | Nutzerfeedback (3 Personen) | Positiv | 2 von 3 positiv
| Teilweise erfüllt | Menüstruktur überarbeiten
Der Unterschied zwischen harten und weichen Kriterien ist wichtig: Harte Kriterien wie Fehlerfreiheit oder Vollständigkeit lassen sich objektiv messen. Weiche Kriterien wie Bedienbarkeit oder Verständlichkeit erfordern Einschätzungen durch Dritte. Dokumentiere bei weichen Kriterien, wer die Einschätzung gegeben hat und auf welcher Grundlage.
Wenn Kriterien nicht vollständig erfüllt sind, dokumentiere das transparent. Ein Satz wie „Das Kriterium wurde zu 80 Prozent erfüllt. Die Abweichung entstand durch [Grund]. Für den geplanten Einsatzzweck ist das akzeptabel, weil [Begründung]" zeigt Reflexion und ist besser als das Verschweigen von Schwächen.
Abnahme vorbereiten und dokumentieren
Die Abnahme ist die formale Bestätigung, dass dein Projektergebnis den Erwartungen entspricht. Je nach Kontext erfolgt sie durch einen Auftraggeber, eine betreuende Lehrkraft oder einen Projektpartner. Nicht jedes Projekt hat einen externen Auftraggeber, aber jedes Projekt braucht einen dokumentierten Abschluss.
Abnahme mit externem Auftraggeber
Bereite ein Abnahmeprotokoll vor, das Datum, Teilnehmende, geprüfte Kriterien und das Ergebnis enthält. Gehe die Qualitätskriterien gemeinsam durch und halte die Entscheidung fest: Abnahme erteilt, Abnahme mit Auflagen oder Nachbesserung erforderlich. Lass das Protokoll unterschreiben oder bestätigen.
Abnahme ohne externen Auftraggeber
Bei Schulprojekten oder internen Arbeiten gibt es oft keinen formalen Auftraggeber. Hier sind drei akzeptable Alternativen: Erstens, eine Checklisten-Freigabe durch die betreuende Lehrkraft, bei der diese bestätigt, dass die Anforderungen erfüllt sind. Zweitens, ein Demo-Termin-Protokoll, bei dem du das Ergebnis vorführst und die Reaktionen dokumentierst. Drittens, eine schriftliche Bestätigung per E-Mail, die du im Anhang beifügst.
Im Text formulierst du das so: „Die Projektergebnisse wurden am [Datum] der betreuenden Lehrkraft präsentiert. Die Funktionen wurden als vollständig und einsatzbereit eingestuft. Das Feedback-Protokoll befindet sich im Anhang." Diese Variante ist bei Schulprojekten üblich und wird von Prüfenden akzeptiert.
Projekt: [Projektname]
Datum: [TT.MM.JJJJ]
Teilnehmende: [Namen und Rollen]
Geprüfte Kriterien:
1. [Kriterium] – Ergebnis: [erfüllt/nicht erfüllt/teilweise]
2. [Kriterium] – Ergebnis: [erfüllt/nicht erfüllt/teilweise]
Entscheidung: [Abnahme erteilt / Abnahme mit Auflagen / Nachbesserung erforderlich]
Auflagen (falls vorhanden): [Beschreibung]
Unterschrift Auftraggeber: ________________
Unterschrift Projektleitung: ________________
Übergabe strukturiert abschließen
Die Übergabe dokumentiert, welche Ergebnisse du an wen weitergegeben hast. Das verhindert, dass nach Projektende Fragen offenbleiben oder Artefakte verloren gehen. Nutze eine Übergabeliste, die alle übergebenen Elemente erfasst.
Spalten: Artefakt | Format/Ort | Empfänger | Übergabedatum | Bestätigt
Beispiel:
Quellcode | ZIP auf USB-Stick | Herr Müller | 15.03.2026 | Ja
Dokumentation | PDF per E-Mail | Frau Schmidt | 15.03.2026 | Ja
Zugangsdaten | Separates Dokument, persönlich übergeben | Herr Müller | 15.03.2026 | Ja
Präsentation | PowerPoint auf Schulserver | Prüfungskommission | 16.03.2026 | Ausstehend
Umgang mit sensiblen Zugangsdaten
Passwörter, API-Keys und andere sensible Daten gehören nicht in den Anhang deiner Projektarbeit. Übergib sie separat, zum Beispiel in einem versiegelten Umschlag oder über einen sicheren Kanal. Im Übergabeprotokoll notierst du nur: „Zugangsdaten wurden am [Datum] separat und persönlich an [Person] übergeben." So ist die Übergabe dokumentiert, ohne dass sensible Informationen im Dokument stehen.
In der schriftlichen Projektarbeit beschreibst du die Übergabe in einem eigenen Abschnitt. Erkläre, was übergeben wurde, an wen und in welcher Form. Die vollständige Übergabeliste kannst du im Anhang beifügen.
Umfang und Platzierung im Dokument
Die Ergebnisdokumentation steht typischerweise nach der Durchführung und vor dem Fazit. Eine übliche Reihenfolge ist: Einleitung, Planung, Durchführung, Ergebnisse und Tests, Qualitätssicherung, Abnahme und Übergabe, Fazit. Manche Leitfäden fassen Tests und Qualitätssicherung in einem Kapitel zusammen. Prüfe die Vorgaben deiner Schule oder Hochschule.
Wie lang sollte die Ergebnisdokumentation sein?
Der Umfang hängt von der Projektart ab. Bei einem technischen Projekt mit ausführlichen Testprotokollen können 3 bis 5 Seiten angemessen sein. Bei einer Konzeptarbeit reichen oft 1 bis 2 Seiten für Kriterienprüfung, Abnahme und Übergabe. Die Protokolle und Tabellen selbst kannst du im Anhang platzieren und im Haupttext nur zusammenfassen. So bleibt der Lesefluss erhalten.
Minimal (ausreichend): Jede Hauptanforderung einmal geprüft, Abnahme dokumentiert, Übergabe aufgelistet. Gut: Zusätzlich Grenzfälle getestet, Qualitätskriterien mit Soll-Ist-Vergleich, Nachweise als Screenshots oder Logs. Sehr gut: Ergänzend Negativtests, Feedbackdokumentation von Dritten, reflektierte Einordnung der Ergebnisse.
Typische Fehler vermeiden
Tests erst am Ende dokumentieren: Wer Testprotokolle aus dem Gedächtnis schreibt, vergisst Details. Speichere Screenshots und Messwerte direkt beim Testen. Ein leeres Protokoll-Template neben dem Testaufbau hilft, nichts zu übersehen.
Nur bestandene Tests zeigen: Eine Dokumentation ohne Abweichungen wirkt unglaubwürdig. Zeige auch, was nicht wie erwartet lief. Formuliere sachlich: „Der Test ergab eine Abweichung. Die Ursache liegt in [Grund]. Für den Einsatzzweck ist das [akzeptabel/nicht akzeptabel], weil [Begründung]."
Abnahme ohne Nachweis: Der Satz „Das Projekt wurde abgenommen" reicht nicht. Ergänze immer einen Beleg: Abnahmeprotokoll, E-Mail-Bestätigung oder Feedback-Protokoll im Anhang.
Qualitätskriterien nachträglich anpassen: Wenn dein Ergebnis die ursprünglichen Kriterien nicht erfüllt, passe nicht die Kriterien an. Dokumentiere stattdessen die Abweichung und erkläre, was du daraus gelernt hast.
Übergabe vergessen: Das Projekt endet nicht mit dem letzten Test. Dokumentiere, was du an wen übergeben hast. Das zeigt, dass du das Projekt vollständig abgeschlossen hast.
Nächster Schritt: Abgabe vorbereiten
Deine Ergebnisdokumentation ist vollständig, wenn du diese Punkte abhaken kannst: Testprotokoll oder Kriterienprüfung vorhanden, Qualitätssicherung mit Soll-Ist-Vergleich dokumentiert, Abnahme mit Nachweis belegt, Übergabeliste erstellt. Prüfe zusätzlich, ob alle Tabellen im PDF lesbar sind und die Verweise auf Anhänge stimmen.
Jetzt geht es an das Fazit, in dem du die Projektergebnisse zusammenfasst und reflektierst. Die Ergebnisdokumentation liefert dir die Grundlage: Du kannst konkret benennen, was funktioniert hat, welche Abweichungen es gab und welche Erkenntnisse du gewonnen hast.
Wenn auch die Präsentation ansteht, nutze Testzahlen und Abnahmeergebnisse als überzeugende Belege. Ein konkreter Testfall mit Screenshot wirkt in der Präsentation stärker als abstrakte Aussagen.
Vor dem Druck: Exportiere dein Dokument als PDF und prüfe: Sind alle Tabellen vollständig sichtbar? Stimmen die Seitenverweise im Inhaltsverzeichnis? Sind Begriffe konsistent (nicht mal „Test", mal „Prüfung" für dasselbe)? Sind Deckblatt und Anhänge vollständig?
Wenn du deine Projektarbeit professionell drucken und binden lassen möchtest, kannst du das bei BachelorHero online konfigurieren.
Häufig gestellte Fragen
Wie ausführlich muss die Testdokumentation in der Projektarbeit sein?
Als Richtwert gelten 5 bis 10 Testfälle für ein technisches Projekt, bei konzeptionellen Arbeiten sind oft 3 bis 5 Kriterienprüfungen üblich. Jeder Testfall braucht Beschreibung, erwartetes und tatsächliches Ergebnis sowie Status. Als Faustregel gilt: Wenn du jede Hauptanforderung einmal geprüft hast, ist das typischerweise ausreichend. Sehr gute Arbeiten ergänzen Grenzfälle und Negativtests.
Was gehört in ein Abnahmeprotokoll?
Datum, Teilnehmende, geprüfte Kriterien mit Ergebnis und die Entscheidung (Abnahme erteilt, Abnahme mit Auflagen oder Nachbesserung erforderlich). Bei formalen Projekten ergänzt du Unterschriften. Ein Satz wie „Die Funktionen wurden am [Datum] von [Person] geprüft und für den Einsatz freigegeben" reicht für einfache Schulprojekte.
Muss ich alle Tests bestehen, bevor ich abgeben kann?
Nein. Dokumentiere alle Tests und erkläre bei nicht bestandenen, warum das Ergebnis abweicht. Formuliere sachlich: „Testfall 3 ergab eine Abweichung von 12 Prozent. Die Ursache liegt in [Grund]. Für den Einsatzzweck ist das akzeptabel, weil [Begründung]." Das zeigt Reflexion und ist besser als verschwiegene Probleme.
Was mache ich, wenn sich Anforderungen während des Projekts geändert haben?
Dokumentiere die ursprünglichen und die geänderten Anforderungen. Erkläre kurz, warum die Änderung nötig war und wann sie erfolgte. Prüfe dann gegen die aktuellen Anforderungen. Ein Satz wie „Anforderung X wurde am [Datum] in Absprache mit [Person] angepasst, weil [Grund]" macht die Änderung nachvollziehbar.
Wie dokumentiere ich die Übergabe an den Auftraggeber?
Erstelle eine Übergabeliste mit Artefakt, Format, Empfänger und Datum. Lass dir die Übergabe bestätigen, per Unterschrift oder E-Mail. Sensible Zugangsdaten gehören nicht in den Anhang, sondern werden separat übergeben. Notiere im Protokoll nur „Zugangsdaten wurden separat übergeben".
Wie belege ich Qualität bei einem Konzeptprojekt ohne technische Tests?
Nutze Kriterienprüfungen statt technischer Tests. Definiere messbare Kriterien wie Vollständigkeit, Nachvollziehbarkeit oder Praxistauglichkeit. Prüfe jedes Kriterium durch Feedbackrunden, Experteneinschätzung oder Selbstbewertung mit Begründung. Dokumentiere, wer wann welches Kriterium wie bewertet hat.
Wo steht die Ergebnisdokumentation im Dokument?
Typischerweise nach der Durchführung und vor dem Fazit. Die Reihenfolge ist meist: Einleitung, Planung, Durchführung, Ergebnisse und Tests, Qualitätssicherung, Abnahme und Übergabe, Fazit. Manche Leitfäden fassen Tests und Qualitätssicherung in einem Kapitel zusammen. Prüfe die Vorgaben deiner Schule oder Hochschule.
Welche Belege sind sinnvoll: Screenshots, Logs oder Messwerte?
Das hängt vom Testtyp ab. Für UI-Tests eignen sich Screenshots (vorher/nachher), für Performance-Tests Messwerte in Tabellenform, für Fehlerbehebung Log-Auszüge. Wähle den Beleg, der das Ergebnis am klarsten zeigt. Ein Screenshot pro Testfall reicht meist. Große Log-Dateien gehören in den Anhang mit Verweis im Text.
Risikoanalyse durchführen
Zeitplan erstellen
Abnahmeprotokoll der Projektarbeit