Inhaltsverzeichnis
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.
Enthält:
- Testziele, Testumfang, Testumgebung
- Testfälle (je: ID, Vorbedingung, Schritte, erwartetes Ergebnis)
- Abnahmekriterien
Output:
- Begründete Auswahl risikobasierter Testfälle mit nachvollziehbarer Anforderungsabdeckung
- Testprotokoll als Nachweis der Durchführung
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.
Testkonzept vs Testplan vs Testprotokoll
Die Begriffe werden oft verwechselt. In der Projektarbeit ist die Unterscheidung wichtig, weil Prüfende erwarten, dass du weißt, was du dokumentierst.
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.
Was: Beschreibt Organisation und Zeitplanung der Tests.
Inhalte: Ressourcen, Verantwortlichkeiten, Zeitplan, Risiken, Eskalationswege.
Wann: Bei größeren Projekten mit mehreren Beteiligten.
In der Projektarbeit: Kann separat stehen oder mit dem Testkonzept kombiniert werden, wenn die Vorgaben das zulassen.
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. 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.
Du beschreibst, was du mit den Tests erreichen willst.
Beispiel: „Die Tests sollen sicherstellen, dass alle im Pflichtenheft definierten Funktionen korrekt arbeiten und die Anwendung unter Normallast stabil läuft."
Zu vage formulieren. „Das System soll funktionieren" ist kein Testziel.
Du legst fest, was getestet wird und was nicht.
Beispiel: „Getestet werden: Benutzeranmeldung, Dateneingabe, Berichterstellung. Nicht getestet werden: Bestandssysteme, da diese bereits produktiv laufen."
Nicht begründen, warum etwas ausgeschlossen wird. Prüfende fragen sich sonst, ob du es vergessen hast.
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.
Teste nicht ungeprüft im Produktivsystem oder mit einer Produktionskopie. Nutze eine getrennte Testumgebung und beachte die Kurzposition des BfDI zu Testdaten.
Du definierst, wann die Tests als bestanden gelten. Die konkreten Schwellwerte hängen von Prüfungsordnung, Auftraggeber und Projektrisiko ab – folgende Werte sind Richtwerte.
Beispiel (Richtwert): „Alle Testfälle mit Priorität 1 müssen bestanden sein. Bei Testfällen mit Priorität 2 sind offene Punkte akzeptabel, sofern Workarounds existieren und ein Fix-Termin definiert ist."
Entscheidungslogik für offene Punkte:
- Severity: Kritisch (blockiert Kernfunktion), Hoch (wichtige Funktion betroffen), Mittel (Workaround möglich), 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: P2 offen lassen nur, wenn: Workaround existiert UND Fix terminiert UND kein Risiko für Datenverlust/Sicherheit.
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 und formuliere imperativ: „1. Menüpunkt Einstellungen öffnen. 2. Passwort-Feld anklicken. 3. Neues Passwort eingeben." Je präziser die Schritte, desto weniger Interpretationsspielraum.
Das erwartete Ergebnis beschreibt, was nach dem letzten Schritt passieren soll. Formuliere es so konkret wie möglich: „Erfolgsmeldung ‚Passwort geändert' wird angezeigt. Bei erneutem Login wird das neue Passwort akzeptiert."
Ein guter Testfall prüft genau eine Sache. Wenn ein Test fehlschlägt, weißt du sofort, wo das Problem liegt. Kombinierst du mehrere Prüfungen in einem Testfall, wird die Fehlersuche schwieriger. Teile komplexe Abläufe lieber in mehrere Testfälle auf.
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 sind das Gegenstück zu funktionalen Tests: Statt zu prüfen, ob etwas funktioniert, prüfst du, ob das System richtig reagiert, wenn etwas schiefgeht. 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."
TC-PERF-001: Ladezeit Übersichtsseite
Ladezeit 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
- Browser-Entwicklertools öffnen (Netzwerk-Tab).
- „Disable cache" aktivieren.
- Übersichtsseite aufrufen.
- Die vorab gewählte Metrik, etwa LCP oder Load, erfassen.
- Nach einem Warm-up mehrere Läufe durchführen und Median sowie Spannweite 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 Funktionen/Methoden. Bei Entwicklungsprojekten sinnvoll, aber nicht zwingend für die Doku. Erwähne sie kurz, falls vorhanden.
Integrationstests: Prüfen das Zusammenspiel von Komponenten (z. B. Schnittstellen). Relevant bei Projekten mit mehreren Systemen.
Systemtests: Prüfen das Gesamtsystem aus Nutzersicht. Hier dokumentierst du am ausführlichsten, da dies die meisten Projektarbeiten betrifft.
Abnahmetests: Prüfung durch den Auftraggeber. Dokumentiere das Ergebnis 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.
| Anforderung | Testfall-IDs | Status |
|---|---|---|
| ANF-001: Login | TC-LOGIN-001, TC-002 | Bestanden |
| ANF-002: Datenexport | TC-EXPORT-001, TC-003 | Bestanden |
| ANF-003: Bericht | TC-REPORT-001 | 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. 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. Achte darauf, wie jeder Testfall alle Elemente enthält und präzise formuliert ist.
TC-LOGIN-001: Login-Funktion
Test mit korrekten Zugangsdaten
Vorbedingung
Benutzer ist nicht eingeloggt. Testbenutzer „test@example.org" existiert.
Schritte
- Login-Seite aufrufen.
- E-Mail „test@example.org" eingeben.
- Das für die Testumgebung hinterlegte Testpasswort eingeben.
- Button „Anmelden" klicken.
Erwartetes Ergebnis
Weiterleitung zum Dashboard. Benutzername wird in Navigation angezeigt.
TC-EXPORT-003: CSV-Export
Export mit Sonderzeichen
Vorbedingung
Mindestens ein Datensatz enthält Umlaute und Semikolons.
Schritte
- Datenübersicht öffnen.
- Datensätze mit Sonderzeichen markieren.
- Export-Funktion auswählen (Format CSV).
- Export starten.
Erwartetes Ergebnis
CSV-Datei erstellt. Umlaute korrekt. Semikolons in Textfeldern escaped.
TC-LOGIN-005: Falsches Passwort
Prüfung der Fehlerbehandlung
Vorbedingung
Benutzer ist nicht eingeloggt. Testbenutzer existiert.
Schritte
- Login-Seite aufrufen.
- Korrekte E-Mail eingeben.
- Falsches Passwort eingeben.
- 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 sicherstellen, dass [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. |
| ID | Beschreibung | Vorbedingung | Schritte | Ergebnis |
|---|---|---|---|---|
| TC-[XX]-001 | [Was wird getestet] | [Ausgangszustand] | 1. [Aktion] 2. [Aktion] | [Messbares Ergebnis] |
Tipp: Ergänze Spalten für „Priorität" und „Anforderung" (ANF-ID), um Traceability zu zeigen.
| ID | Datum | Ergebnis (IST) | Status | Bemerkung |
|---|---|---|---|---|
| TC-LOGIN-001 | [Datum] | [Was passiert ist] | Bestanden | [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 testest, ob etwas funktioniert, fehlt die Hälfte. Prüfe auch, was passiert, wenn Eingaben falsch sind oder Grenzwerte erreicht werden.
Schwach: Alle Tests zeigen erfolgreiche Abläufe.
Besser: Mix aus funktionalen Tests, Grenzfalltests und Negativtests.
Keine Abnahmekriterien: Ohne klare Kriterien weiß niemand, wann die Tests abgeschlossen sind. Definiere vorab, welche Tests bestanden sein müssen.
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 und Abnahmekriterien definiert sind. Deine Testfälle sind vollständig, wenn jeder Testfall ID, Beschreibung, Vorbedingungen, Schritte und erwartetes Ergebnis enthält.
- 1. Testfälle priorisieren: Kennzeichne kritische Tests mit Priorität 1.
- 2. Tests durchführen: Arbeite die Testfälle systematisch ab.
- 3. Protokoll führen: Dokumentiere Ergebnisse, Fehler und Lösungen.
- 4. Abnahme vorbereiten: Prüfe, ob alle Abnahmekriterien erfüllt sind.
Nach erfolgreichen Tests folgt die Abnahme durch den Auftraggeber. Das Abnahmeprotokoll dokumentiert, dass die Lösung den Anforderungen entspricht und vom Auftraggeber akzeptiert wird.
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 freigegebene Rechts-, Schutz- und Löschkonzeption. 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. 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 Serverantwort 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