Ein Nachweis erledigter Aufgaben hilft der nächsten Person, eine Prüfung zu wiederholen, statt nur einem Kommentar „fertig“ zu vertrauen. Wir verwenden ein erfundenes Beispiel: Nach Änderung einer Kontaktadresse im Shopkonto soll der neue Wert beim erneuten Öffnen erhalten bleiben. Der Ergebnisnachweis betrifft dieses konkrete Verhalten und die geprüfte Produktversion. Du bereitest eine Beobachtungskarte und eine Entscheidung zum nächsten Schritt vor, unabhängig vom verwendeten Projektwerkzeug.
Beginne mit dem beobachteten Ergebnis
„Ich habe das Formular geändert“ beschreibt die Arbeit des Autors, während „die neue Adresse blieb nach erneutem Öffnen erhalten“ das Ergebnis benennt. Zur Bewertung brauchst du vor allem die zweite Aussage und die Bedingungen, unter denen sie zutraf. Überspringe die Probe nicht, weil die Korrektur klein erscheint oder die Umsetzung einfach war. Eine andere Person kann dieselbe Handlung in einer anderen Version durchführen und ein abweichendes Ergebnis erhalten.
Prüfe im Verlauf vom Ticket zur Aufgabe, was der Kunde ursprünglich gemeldet hat. Ging es um gespeicherte Daten nach einer erneuten Anmeldung, deckt bloßes Aktualisieren der Seite nicht den vollständigen Ablauf ab. Beziehe deine Beobachtung auf dasselbe Verhalten, statt eine einfachere Probe zu wählen. Sind die ursprünglichen Bedingungen unbekannt, dokumentiere diese Lücke vor der Abschlussentscheidung.
Nutze beobachtbare Formulierungen wie „Wert sichtbar“, „Meldung erschienen“ oder „Datei geöffnet“. Die Aussage „alles funktioniert“ verbirgt den Umfang und gibt dem nächsten Leser keinen konkreten Ansatzpunkt. Du kannst eine Schlussfolgerung ergänzen, solltest sie aber von der zugrunde liegenden Beobachtung trennen. Neue Informationen über einen Fehler können den Nachweis dann präzisieren, ohne jede frühere Beobachtung automatisch ungültig zu machen.
Notiere Bedingungen für eine wiederholbare Prüfung
Die Beobachtungskarte sollte Umgebung, erkennbare Produktversion, Art des Testkontos und geprüfte Handlung nennen. Im Beispiel können Administrator- und Kundenkonto unterschiedliche bearbeitbare Felder anbieten. Nutze Demonstrationsdaten, damit du den Nachweis ohne unnötige Kundendaten im Team weitergeben kannst. Bestimmt eine Versionsnummer den Stand, notiere diese Kennung statt lediglich „aktuell“.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Feld | Eintrag im Beispiel |
|---|---|
| Prüfort | Testversion des Shop-Kontobereichs. |
| Ausgangsbedingung | Kundenkonto mit einer Demonstrationsadresse. |
| Handlung | Feld bearbeiten, speichern und Konto erneut öffnen. |
| Ergebnis | Der neue Wert bleibt sichtbar. |
| Grenze | Die öffentliche Version wurde noch nicht geprüft. |
Ergänze den Prüfzeitpunkt, um später eine Beobachtung von vor der nächsten Aktualisierung zu erkennen. Du brauchst keinen umfangreichen Bericht, wenn wenige konkrete Felder die Situation nachvollziehbar machen. Die Karte dokumentiert das Ergebnis; die Festlegung des erwarteten Verhaltens beschreibt der Leitfaden zu Abnahmekriterien für Aufgaben. Ändere die Erwartung nicht erst nach Sichtung des Ergebnisses, um eine positive Bewertung zu erzielen.
Vergleiche Ergebnis und Erfolgsbedingung
Kennzeichne jede Bedingung als erfüllt, nicht erfüllt oder ungeprüft. Im Beispiel sind Speichern und erneutes Öffnen zwei Teile derselben Prüfung des dauerhaften Werts. Wurde nur der erste Teil beobachtet, bleibt der zweite ungeprüft, auch wenn der Autor ein korrektes Verhalten erwartet. So kann der Prüfer die fehlende Kontrolle anfordern, ohne die gesamte Aufgabe neu zu beginnen oder eine Annahme zum Nachweis zu machen.
Bereite einen kurzen Eintrag vor: „In der Testversion blieb die neue Adresse nach Schließen und erneutem Öffnen des Kundenkontos erhalten. Die öffentliche Version wurde noch nicht geprüft. Vor der Bestätigung an den Kunden fehlt die Kontrolle nach dem Release“. Das Beispiel nennt Ergebnis und Wissensgrenze, sodass der Leser den nächsten Schritt ohne zusätzliche Annahmen auswählen kann. Bei der Übergabe einer ganzen Website sammelt ein Abnahmeprotokoll mit Checkliste und Mängelliste solche Ergebnisse an einem Ort.
Scheitert die Probe, beschreibe das tatsächliche Symptom statt lediglich „negativer Test“. Zum Beispiel erschien beim erneuten Öffnen der bisherige Wert, obwohl zuvor eine Speicherbestätigung angezeigt worden war. Das beschreibt eine sichtbare Abweichung aus Nutzersicht, noch keine fertige technische Ursachendiagnose. Bewahre die genaue Meldung und die Reihenfolge der Handlungen auf, die zu diesem Ergebnis geführt haben.
Wähle Material für den entscheidenden Ausschnitt
Ein Screenshot kann einen sichtbaren Wert zeigen, belegt aber normalerweise nicht dessen Fortbestand nach erneutem Öffnen. Eine kurze Ablaufbeschreibung oder Aufzeichnung kann diese Lücke schließen, sofern sie die relevanten Schritte enthält. Ergänze Material nicht nur, damit die Karte überzeugender aussieht. Jeder verlinkte Nachweis sollte eine Frage beantworten, die der schriftliche Eintrag allein offenlässt.
- Objekt benennen.Benenne das Demonstrationskonto und das beobachtete Feld. Zeigt ein Bild mehrere ähnliche Werte, markiere den relevanten, ohne sämtliche Bildschirmbereiche zu beschreiben oder unnötige Kontoinformationen hinzuzufügen.
- Umfang begrenzen.Bewahre den Ausschnitt mit Speichern und erneutem Öffnen auf oder beschreibe diese Handlungen in der Karte. Entferne unnötige Daten anderer Personen aus dem Material für die Übergabe.
- Verweis prüfen.Stelle sicher, dass der Prüfer das Material im richtigen Arbeitskontext öffnen kann. Eine private Datei des Aufgabenautors ist kein gemeinsamer Nachweis, wenn niemand sonst darauf zugreifen kann.
- Erläuterung ergänzen.Erkläre, was das Material bestätigt und was ungeprüft bleibt. Ein Bild der Testversion belegt weder den Release auf der öffentlichen Website noch erfolgreiches Verhalten für jede Art von Kundenkonto.
Verwendest du aufgezeichneten Besuchskontext, nutze die Regeln zur Analyse von Sitzungsaufzeichnungen und nenne den konkreten Zeitpunkt. Ein beobachteter Klick beweist nicht zwangsläufig das Speichern im System. Vergleiche das Material mit dem später ausgelesenen Ergebnis, statt Bildschirmbewegung als Bestätigung zu behandeln. Zeigt die Aufzeichnung das Ende der Handlung nicht, kennzeichne diese Grenze in der Beschreibung.
Gib dem Prüfer eine klare Entscheidung
Die prüfende Person muss wissen, ob sie das Ergebnis akzeptieren, eine fehlende Probe durchführen oder die Aufgabe zur Korrektur zurückgeben soll. Nenne die vorgeschlagene Entscheidung zusammen mit ihrer Grundlage. „Ergebnis in der Testversion bestätigt; Releaseprüfung offen“ ist präziser als „kann geschlossen werden“. Der Prüfer sollte nicht erraten müssen, welche fehlenden Schritte der Autor für unwichtig hielt.
Bei unterschiedlichen Beobachtungen gehe zu Version, Berechtigungen und Handlungsschritten der jeweiligen Probe zurück. Zwei Einträge können gleichzeitig stimmen, wenn sie unterschiedliche Konten oder Veröffentlichungsstände betreffen. Bewahre den Unterschied und wiederhole den notwendigen Ausschnitt, statt das frühere Ergebnis zu löschen. Für die Rückgabe eines erneut gefundenen Problems nutze die Aufgabenvorlage aus einem Kundenfehlerbericht.
Bewahre Ergebnis und Grenze bei der Aufgabe auf
Du kannst die Karte in Beschreibung oder Kommentar einer Aufgabe in Meetlead Projekte ablegen. Eine Verknüpfung zum Ticket oder einer verfügbaren Aufzeichnung bewahrt den notwendigen Kontext zum Verständnis der Beobachtung. Du brauchst ein Konto, passende Rechte und die aktive Anwendung im verfügbaren Plan. Der Eintrag führt keine Tests für dein Team aus und bestätigt nicht automatisch die Veröffentlichung einer Korrektur.
Vor einer Kundeninformation bereite eine eigene Übergabe der Änderung an den Support vor. Übernimm aus dem Aufgabenergebnis das bestätigte Verhalten, seine Verfügbarkeit und die Grenzen für das Gespräch. Prüfermaterial kann technische Einzelheiten enthalten, die eine Kundenantwort nicht benötigt. Halte beide Zwecke klar, damit Arbeitsnachweis und Supportanleitung nicht zu einem unübersichtlichen Dokument werden.
Atlassian beschreibt Definition of Done als gemeinsame Kriterien für abgeschlossene Arbeit. Hier geht es um den Beobachtungsnachweis; die Karte ist unser Beispiel: ein gemeinsames Verständnis von Abschluss.
Fragen zum Nachweis erledigter Aufgaben
Braucht jede Aufgabe einen Screenshot? Nein, wenn ein schriftlicher Eintrag das Ergebnis prüfbar macht. Wähle Material danach, was bestätigt werden muss, statt aus Gewohnheit Bilder zu sammeln. Bei einer Textänderung reichen manchmal Stelle und neue Formulierung, während Verhalten über mehrere Schritte eine Ablaufbeschreibung benötigt.
Bedeutet eine erfolgreiche Probe einen erfolgten Release? Sie bestätigt nur das Ergebnis in der geprüften Version und unter den geprüften Bedingungen. Notiere öffentliche Verfügbarkeit und fehlende Kontrollen separat. Erst die Beobachtung der passenden Version erlaubt eine Aussage, die dem entspricht, was der konkrete Kunde sehen oder tun kann.
Was tun, wenn das Ergebnis später veraltet? Bewahre die bisherige Karte als Beobachtung ihres Zeitpunkts und ihrer Version auf. Ergänze eine neue Probe mit Unterschied und aktueller Teamentscheidung. Die nächste Person erkennt dadurch, ob ein neuer Fehler, andere Bedingungen oder eine Lücke der ursprünglichen Prüfung vorliegt.
