Dieses Video zeigt dir, wie du mit Test Suites in Leadtime eine systematische Projektabnahme durchführst. Statt sich unsortiert durch das Ergebnis zu klicken und Feedback per E-Mail zu sammeln, bieten Test Suites einen reproduzierbaren Prozess mit klaren Testfällen, dokumentierten Ergebnissen und direkter Bug-Ticket-Erstellung.
Test Suites sind Teil des Projektbaums und kommen automatisch mit, wenn du eine Komponente aus der Bibliothek importierst. Genau wie Arbeitspakete können sie Conditions haben: Braucht der Kunde keinen Onlineshop, erscheinen die Shop-Testfälle gar nicht erst. Du findest sie im Projekt unter Configuration → Project Tree, typischerweise innerhalb der Epics unter "Testing und Quality Assurance".
Jeder Testfall beschreibt präzise, was geprüft werden soll, und definiert ein erwartetes Ergebnis. Die Bewertung erfolgt über drei Stufen: "Passed" (alles in Ordnung), "Passed with limitations" (grundsätzlich okay, aber mit Einschränkungen) und "Failed" (nicht bestanden). Bei jeder Bewertung kannst du einen Kommentar hinterlassen, und bei fehlgeschlagenen Tests direkt ein Bug-Ticket erstellen – mit korrekter Projektzuordnung und dem Kontext des Tests.
Die Testergebnisse fließen in die Implementation Overview ein und zeigen den Fortschritt des Abnahmeprozesses. Bug-Tickets erscheinen im normalen Ticketsystem, werden vom Team bearbeitet, und der Test wird nach der Korrektur erneut durchgeführt – bis alle Tests bestanden sind.
Für die formale Abnahme lädst du den Kunden als Guest User ein und gehst die Ergebnisse gemeinsam durch. Zusammen mit dem Pflichtenheft ergibt sich ein sauberer Kreislauf: Das Pflichtenheft definiert, was gebaut werden soll. Die Test Suites prüfen, ob es gebaut wurde. Beide referenzieren denselben Projektbaum.
Dein Projekt ist umgesetzt, die Tickets sind abgearbeitet. Aber woher weißt du, ob alles wirklich funktioniert? Bevor du das Projekt an den Kunden übergibst, brauchst du eine systematische Prüfung. In diesem Video zeige ich dir, wie du Test Suites in Leadtime durchführst, Ergebnisse dokumentierst und bei Problemen direkt Bug-Tickets erstellst.
In der Praxis passiert die Abnahme oft so: Jemand klickt sich durch das Ergebnis, findet ein paar Sachen, schreibt eine E-Mail, jemand anders findet andere Sachen. Am Ende fehlt der Überblick, was geprüft wurde und was nicht.
Test Suites in Leadtime machen die Abnahme reproduzierbar. Jeder Testfall hat klare Schritte und ein erwartetes Ergebnis. Die Bewertung wird dokumentiert. Und wenn etwas nicht passt, entsteht direkt ein Bug-Ticket mit der richtigen Zuordnung.
Das schützt dich doppelt: Du kannst dem Kunden zeigen, dass alles systematisch geprüft wurde. Und du hast eine nachvollziehbare Dokumentation, falls es später Diskussionen gibt.
In Video 29 hast du gesehen, wie Test Suites in der Komponentenbibliothek angelegt werden. Sie sind Teil des Projektbaums, genau wie Arbeitspakete und Checklisten. Wenn du eine Komponente in ein Kundenprojekt importierst, kommen die Test Suites mit.
Test Suites können auch Conditions haben. Genau wie bei Arbeitspaketen: Wenn der Kunde keinen Onlineshop braucht, erscheinen die Shop-Testfälle gar nicht erst. Nur was relevant ist, wird getestet.
Du findest die Tests im Projekt unter Configuration → Project Tree. Dort siehst du sie als eigene Elemente innerhalb der Epics, meist am Ende bei „Testing und Quality Assurance".
Ich öffne einen Testfall, zum Beispiel „Responsive Design". Hier steht genau, was geprüft werden soll: Die Website auf Desktop, Tablet und Smartphone aufrufen. Erwartetes Ergebnis: Alle Layouts korrekt, keine Überlappungen, alle Elemente sichtbar.
Ich klicke auf „Evaluate" und bewerte den Test. Es gibt drei Optionen: „Passed" – alles in Ordnung. „Passed with limitations" – grundsätzlich okay, aber mit Einschränkungen. „Failed" – der Test ist nicht bestanden.
Bei jeder Bewertung kann ich einen Kommentar hinterlassen. Bei „Passed with limitations" zum Beispiel: „Auf dem iPhone 12 ist das Footer-Menü leicht verschoben, aber funktional." Bei „Failed" beschreibe ich das Problem.
Das Entscheidende: Wenn ein Test fehlschlägt, kann ich direkt ein Bug-Ticket erstellen. Aus dem Testergebnis heraus, mit der richtigen Projektzuordnung und dem Kontext des Tests. Der Entwickler weiß sofort, was zu tun ist.
Die Testergebnisse fließen direkt in die Implementation Overview ein. Du erinnerst dich: In der Spalte „Done/Total" siehst du den Fortschritt. Bei Test Suites bedeutet das: wie viele Testfälle wurden bewertet, wie viele stehen noch aus.
So behältst du den Überblick über den gesamten Abnahmeprozess. Wenn von zwanzig Tests fünfzehn bestanden sind, drei noch offen und zwei fehlgeschlagen, siehst du das auf einen Blick.
Die Bug-Tickets aus fehlgeschlagenen Tests erscheinen im normalen Ticketsystem. Dein Team bearbeitet sie, und nach der Korrektur führst du den Test erneut durch. Dieser Zyklus wiederholt sich, bis alle Tests bestanden sind.
Wenn alle Tests bestanden sind, hast du eine vollständige Dokumentation der Abnahme. Jeder Testfall mit Ergebnis, Kommentar und Zeitstempel. Das ist deine Grundlage für die formale Projektabnahme mit dem Kunden.
In der Praxis lädst du den Kunden als Guest User ein und gehst die Testergebnisse gemeinsam durch. Der Kunde kann selbst Kommentare hinterlassen und Tests bestätigen. So wird die Abnahme transparent und nachvollziehbar für beide Seiten.
Zusammen mit dem Pflichtenheft hast du dann einen sauberen Kreislauf: Das Pflichtenheft definiert, was gebaut werden soll. Die Test Suites prüfen, ob es gebaut wurde. Beide referenzieren den gleichen Projektbaum.
Test Suites machen die Projektabnahme systematisch und dokumentierbar. Klare Testfälle, reproduzierbare Ergebnisse, direkte Bug-Tickets bei Problemen. Zusammen mit dem Pflichtenheft hast du einen vollständigen Qualitätsprozess.
Im nächsten Video zeige ich dir die Projektabrechnung. Wie du dein abgeschlossenes Projekt abrechnest, wiederkehrende Zahlungen einrichtest und den finanziellen Erfolg in den Insights analysierst.
