Eine Vorlage für die Aufgabenübergabe soll einer anderen Person ermöglichen, denselben Fehler zu sehen und seine Behebung zu prüfen. „Terminänderung funktioniert nicht“ nennt weder den Ausgangszustand noch ein überprüfbares Ergebnis. Unser ausgefülltes, fiktives Beispiel beschreibt ein Formular, dessen Speichern-Schaltfläche nach der Auswahl eines neuen Termins deaktiviert bleibt. Du kannst den Bericht in jedem Aufgabenboard verwenden und dabei Kundenangaben, eigene Testergebnisse und eine unbestätigte Erklärung klar voneinander trennen.
Beschreibe die Beobachtung vor der vermuteten Ursache
Beginne mit der Aktion des Kunden und der Stelle, an der er nicht weiterkam. „Nach der Auswahl von morgen, 10:00 Uhr, bleibt Speichern deaktiviert“ beschreibt das Verhalten; „die Datumsvalidierung ist kaputt“ behauptet bereits eine Ursache. Solange niemand die Implementierung geprüft hat, gehört der zweite Satz zu den Hypothesen. So kann die bearbeitende Person auch die Terminverfügbarkeit, den Formularzustand oder Änderungsregeln untersuchen, statt nur den ersten Verdacht bestätigen zu wollen.
Kennzeichne die Herkunft jeder Angabe. Ein Kunde hat den Fehler gemeldet, und der Support hat drei eigene Versuche unter den genannten Bedingungen durchgeführt, die alle scheiterten. Das belegt keine Störung bei sämtlichen Kunden oder auf allen Geräten. Wann daraus eine Aufgabe werden sollte, erklärt vom Kundenticket zur Projektaufgabe; hier geht es um den Bericht nach dieser Entscheidung.
Übernimm die ausgefüllte Vorlage mit zehn Feldern
Die folgenden Angaben betreffen ein erfundenes Formular und zeigen eine Dokumentationsmethode, keinen Fehler in Meetlead. Ersetze „morgen“ im echten Bericht durch ein konkretes Datum und ergänze die tatsächlich gemessenen System- und Browserversionen. Ihre Nummern sind im Beispiel bewusst unbekannt: Eine fehlende Information muss sichtbar bleiben, bis sie geprüft wurde.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Feld | Ausgefülltes Beispiel | Nutzen für die Bearbeitung |
|---|---|---|
| Titel | Terminänderung: Nach Auswahl von morgen, 10:00 Uhr, bleibt Speichern deaktiviert. | Nennt Ansicht, Aktion und sichtbares Verhalten statt eines allgemeinen „Buchungsproblems“. |
| Kundenziel | Den bestehenden Termin auf morgen, 10:00 Uhr, verschieben, ohne eine zweite Buchung anzulegen. | Derselbe Eintrag muss geändert werden; eine neue Buchung wäre kein gleichwertiges Ergebnis. |
| Startbedingungen | Eine Testbuchung besteht, Änderungen sind erlaubt und der Zieltermin ist nach den Testregeln verfügbar. | Fehlt eine Bedingung, kläre zuerst die tatsächliche Einschränkung, bevor du sie als Fehler einordnest. |
| Umgebung | Android, Chrome, deutsche Seitensprache, Hochformat, WLAN; Versionsnummern noch zu erfassen. | Begrenzt die bestätigte Beobachtung, statt alle möglicherweise betroffenen Konfigurationen aufzuzählen. |
| Schritte | Terminänderung öffnen → morgen auswählen → 10:00 Uhr auswählen → Speichern prüfen. | Stelle vor jedem Versuch dieselbe Testbuchung wieder her und notiere das konkrete Datum. |
| Soll-Ergebnis | Eine gültige Änderung aktiviert Speichern; eine Bestätigung ändert den Termin genau einmal und zeigt das Ergebnis. | Prüfe den dauerhaft gespeicherten Termin, nicht nur Farbe oder Verfügbarkeit der Schaltfläche. |
| Ist-Ergebnis | Speichern bleibt deaktiviert; die Änderung lässt sich nicht absenden, und kein Hinweis erklärt die Sperre. | Welcher Mechanismus das Speichern verhindert, ist noch nicht festgestellt. |
| Häufigkeit und Auswirkung | Drei Supportversuche, drei Fehlschläge; ein bekannter Kunde, Auswirkung auf andere unbekannt. | Der Kunde kann den Termin nicht selbst ändern; Datenverlust und eine breitere Störung sind nicht belegt. |
| Nachweis und Umgehung | Maskiertes Bild nach der Uhrzeitauswahl; ein berechtigter Mitarbeiter kann nach Verfügbarkeitsprüfung und Kundenbestätigung manuell ändern. | Prüfe, ob die Umgehung tatsächlich möglich und zulässig ist, bevor du sie anbietest. |
| Abnahme und Kontakt | Gültige Änderungen speichern einmal; unzulässige Änderungen zeigen den Grund; Aufgabenverantwortlicher und Supportkontakt sind benannt. | Der Support meldet sich nach der Prüfung zurück, ohne einen ungeklärten Veröffentlichungstermin zu versprechen. |
Benenne fehlende Angaben konkret: die Chrome-Version, das Verhalten am Computer oder den Test mit einem zweiten Konto. Vermeide „Standardeinstellungen“, denn darunter kann die nächste Person etwas anderes verstehen. Der Bericht braucht nicht den gesamten Gesprächsverlauf, sondern die Tatsachen, die das Nachstellen und die Abnahme dieser bestimmten Aktion beeinflussen.
Die Fehlerbericht-Vorlage von Atlassian enthält Umgebung, Schritte sowie Soll- und Ist-Ergebnis. Das ausgefüllte Beispiel und die Abnahmeregeln sind unser Vorschlag.
Lass eine zweite Person die Schritte nachvollziehen
Gib den Bericht einer Person, die am Kundengespräch nicht beteiligt war, und lass sie ohne mündliche Hinweise testen. Sie beginnt mit dem beschriebenen Ausgangszustand und notiert nach jedem Schritt, was sie sieht. Muss sie nachfragen, wo die Terminänderung startet oder wie die Testbuchung vorbereitet wird, ergänze genau diese Stelle. Der Versuch prüft die Verständlichkeit der Anleitung und nicht, ob ein Kollege deine Absicht erraten kann.
Ergänze das zweite Ergebnis als eigene Beobachtung mit Gerät, Testdatum und Erfolg oder Fehlschlag. Funktioniert das Speichern am Computer, behalte den ursprünglichen Bericht und grenze den bestätigten Umfang auf die geprüften Konfigurationen ein. Findet die Person die Änderungsfunktion nicht, untersuche die Navigation separat anhand von Usability-Tests für die Website. Eine schwer auffindbare Aktion und ein blockierter gültiger Speichervorgang können unterschiedliche Korrekturen erfordern.
Füge den benötigten Nachweis bei
Ein Bildschirmfoto sollte Terminwahl, Schaltflächenzustand und mögliche Hinweise zeigen, ohne Kundennamen, Adresse, Telefonnummer oder vertrauliche Leistungsdetails. Entferne diese Angaben vor dem Anhängen dauerhaft, statt sie nur in einer Vorschau zu überdecken. Benenne die Datei nach Testschritt und Beobachtungszeit. Der Empfänger muss verstehen können, was das Bild belegt, ohne das vollständige Kundengespräch zu öffnen.
Ist eine kurze Aufzeichnung nötig, zeige nur die relevante Abfolge und verwende eine Testbuchung. Bitte den Kunden nicht vorsorglich um sein Passwort, eine Aufnahme des gesamten Kontos oder einen Netzwerkexport. Zusätzliche Protokolle sollte ein berechtigter Spezialist für eine konkrete Hypothese auswählen. Bewahre den Verweis auf den ursprünglichen Nachweis und regle den Zugang, statt Kopien an Personen ohne Aufgabe in der Bearbeitung zu verteilen.
Wenn du um ein Bild eines technischen Problems bittest, hilft der Leitfaden: Screenshot für den Support: Fehler zeigen und Daten verbergen.
Vereinbare die Abnahmekriterien vor der Umsetzung
„Die Schaltfläche funktioniert“ ist als Abnahmekriterium zu eng. Prüfe bei einer gültigen Änderung, dass Speichern verfügbar ist, eine Bestätigung den bestehenden Termin genau einmal ändert und erneutes Öffnen den neuen Wert zeigt. Bei einer unzulässigen Änderung muss das Formular den Grund erklären und den bisherigen Termin unverändert lassen. Vereinbare beide Fälle vor der Umsetzung, damit das bloße Aktivieren der Schaltfläche nicht als vollständige Lösung gilt.
Führe die Abnahme in der gemeldeten Umgebung und einer zusätzlichen, vom Bearbeiter gewählten Variante durch. Erneutes Drücken oder Aktualisieren darf keinen zweiten Eintrag erzeugen; kontrolliere den gespeicherten Zustand statt nur die Erfolgsmeldung. Trenne notwendige Abnahmekriterien von Ideen zur Neugestaltung des gesamten Formulars. Bestimme die Dringlichkeit anhand von Auswirkung und verfügbarer Umgehung mit dem Vorgehen zu Prioritäten in der Supportwarteschlange. Bewerte dabei technische Auswirkung und Dringlichkeit der Korrektur getrennt, wie im Leitfaden zu Schweregrad und Priorität bei Fehlern beschrieben.
Bevor du eine Anfrage als Fehler einordnest, hilft der Leitfaden: Fehler oder Feature-Wunsch: Kundenanliegen richtig einordnen.
Verbinde Aufgabe, Verantwortung und Kundenrückmeldung
Benenne in der Aufgabe den Verantwortlichen für die Umsetzung und im Ticket die Person für die Kundenantwort. Füge Verweise in beide Richtungen hinzu, damit ein Aufgabenstatus den Kontakt zum ursprünglichen Melder nicht unterbricht. Muss ein anderes Team entscheiden, ergänze die konkrete Frage und benötigte Antwort, statt nur einen Link weiterzuleiten. Den umfassenderen Verantwortungswechsel behandelt die Eskalation von Kundenanfragen.
Mit dem vorbereiteten Bericht kannst du in Meetlead Projekte manuell eine Aufgabe erstellen und sie mit Ticket, Gespräch oder passender Aufzeichnung verknüpfen. Verantwortlicher und Status helfen bei der Bearbeitung, doch das Produkt reproduziert den Fehler nicht automatisch und überträgt ihn nicht an Jira. Du brauchst ein Konto, die aktive Projekte-App sowie Zugang entsprechend Tarif und Berechtigungen. Nach der Prüfung teilt der Support dem Kunden das Ergebnis mit und bittet bei abweichenden Bedingungen um Bestätigung.
Fragen zur Übergabe von Fehlern
Darf ich die Aufgabe schließen, wenn ich den Fehler nicht nachstellen kann? Das Ergebnis beweist nicht, dass kein Problem vorliegt. Notiere deine Testbedingungen und vergleiche sie mit den Kundenangaben. Fehlen Zugang oder Versionsinformationen, benenne die Lücke und den nächsten Prüfschritt, statt die Meldung als falsch einzustufen.
Muss ich sofort eine Ursache nennen? Nein, der Bericht soll zuerst ein überprüfbares Verhalten vermitteln. Ergänze eine Hypothese getrennt mit der Beobachtung, auf der sie beruht, und schreibe sie nicht zum Ist-Ergebnis. Eine später gefundene Ursache ersetzt nicht die ursprünglichen Schritte, die für die Abnahme der Korrektur nötig bleiben.
Reicht eine Umgehung aus, um den Fall abzuschließen? Eine manuelle Änderung kann diesem Kunden helfen, während das Formular weiterhin repariert werden muss. Unterscheide den Abschluss der unmittelbaren Anfrage von der Abnahme der technischen Aufgabe. Kläre vor dem Gesprächsende, wer weitere Fälle beobachtet und wer die dauerhafte Korrektur zurückmeldet.
