Jeder Bug muss mit mindestens einem Anhang dokumentiert werden. Mit deinen Anhängen beweist du, dass der Bug auf deinem Gerät, deinem Betriebssystem und/oder Browser auftritt.
Hinweis: Anhänge ERSETZEN KEINE schriftlichen Informationen in deinem Bericht. Anhänge sind eine Visualisierung des Problems und dienen als Beweis.
Screenshot oder Screencast?
Im Allgemeinen erfordern funktionale Bugs einen Screencast, um ordnungsgemäß und effektiv veranschaulicht zu werden. Sofern die Anweisungen oder der Teamleiter nicht spezifische Anlagen verlangen, verwende folgende Faustregel, um zu bestimmen, ob ein Screenshot oder ein Screencast für deinen Bug erforderlich ist:
Immer wenn eine Aktion erforderlich ist, um einen Bug auszulösen, oder wenn ein Prozess veranschaulicht werden muss, lade einen Screencast hoch. Screenshots als statische Bilder sind Momentaufnahmen und können nicht die Ursache veranschaulichen. Funktionale Bugs erfordern aus diesem Grund immer einen Screencast.
Wenn die Natur eines Bugs statisch ist, z.B. bei statischen GUI-Problemen, reicht ein Screenshot aus und ist eine bessere Visualisierung als ein Video. Screenshots sollten für Inhalts- oder visuelle Probleme ausreichen.
Allgemeine Anforderungen an Anhänge
Neue Anhänge müssen für jeden Bug-Report oder jede Reproduktion erstellt werden.
Es ist verboten, Anhänge aus anderen Bug-Reports oder Reproduktionen zu kopieren.
Anhänge müssen alle relevanten Informationen zum Bug anzeigen, um als Beweis zu dienen.
Alle relevanten Informationen müssen in Englisch angezeigt werden (oder optional in Deutsch, wenn die Sprache des Bug-Reports Deutsch ist), z. B. das Datum, die Uhrzeit, Systeminformationen und Fehlermeldungen.
Du solltest nur ein Gerät oder einen Browser auswählen, wenn du den Bug meldest und nur einen Anhang dafür hochladen. Wenn du den Bug auf anderen Geräten oder Browsern reproduzieren kannst, erwähne dies bitte in deinem tatsächlichen Ergebnis.
Zeige keine Informationen über andere Test IO-Kunden, die mit Test IO in Verbindung gebracht werden können (z. B. Einladungs-E-Mails oder Namen in Browser-Tabs). Das Anzeigen von installierten Apps anderer Kunden ist erlaubt.
Zeige keine persönlichen Informationen oder unprofessionelle Daten wie Bilder, Videos oder schlechte Wortvorschläge für die Autokorrektur. Denke daran, dass deine Anhänge anderen Testern, dem Test IO-Personal und dem Kunden zur Verfügung stehen, also sei vorsichtig, was du darin zeigst.
Für Website-Tests muss das URL-Feld in den Anhängen sichtbar sein.
Die Auflösung muss hoch genug sein, damit Texte und Elemente leicht identifiziert werden können.
Bitte zeichne immer deinen gesamten Bildschirm auf.
Ein Crash-Log ist für Bug-Reports und positive Reproduktionen von App-Abstürzen obligatorisch. Das Video, das den Crash dokumentiert, muss dem angehängten Crash-Log entsprechen, d. h. die Zeitpunkte müssen übereinstimmen.
Regeln für Datum und Uhrzeit:
Das aktuelle Datum und die Uhrzeit müssen in den Anhängen sichtbar sein.
Wenn du einen Bug über einen Screenshot auf einem mobilen Gerät nachweist, musst du einen zweiten Screenshot hochladen, der das Datum und die Uhrzeit zeigt (die Akkuladung und die Zeit müssen mit dem ersten Screenshot übereinstimmen).
Das Datum kann in jedem üblichen Datumsformat sein, z.B. TT/MM oder MM/TT, in Englisch (oder optional in Deutsch, wenn die Sprache des Bug-Reports Deutsch ist).
Die Uhrzeit sollte im 24-Stunden-Format sein. Wenn du eine 12-Stunden-Uhr verwendest, stelle bitte sicher, dass du das AM/PM-Format einstellst.
Durch das Anzeigen des aktuellen Datums in deinem Anhang beweist du, dass du es an diesem Tag aufgezeichnet hast. Die folgende Liste zeigt, wo du das Datum finden kannst:
Windows: Anzeige der Taskleiste oder Einblenden des Kalenders
Mac: Anzeige des Kalendersymbols im Dock oder in der Menüleiste
iOS & Android: Herunterziehen des Benachrichtigungszentrums zu Beginn deiner Aufzeichnung.
Weitere Informationen: TecRevue
Was muss auf einem Screenshot enthalten sein?
Regeln für Screenshots:
Das Dateiformat des Screenshots muss JPG oder PNG sein.
Hebe den Fehler auf deinem Screenshot hervor.
Wir empfehlen Aufzeichnungstools und bewährte Praktiken im folgenden Artikel: Screenshots
Was muss in einem Screencast enthalten sein?
Screencasts sollten so kurz wie möglich, aber so lang wie nötig sein. Das bedeutet, dass du Schritte weglassen solltest, die den Fehler nicht verursachen. Wenn beispielsweise die Schaltfläche "In den Warenkorb legen" auf einer Produktseite eines Webshops defekt ist, ist es im Allgemeinen unwichtig, wie du dich durch den Webshop navigiert hast, um die Produktseite zu erreichen. Der letzte Navigationsschritt, der Schritt, der den Fehler auslöst und der Fehler selbst sind normalerweise relevant.
Beispiel 1: Fehler auf einer Website, getestet auf einem Desktop-Gerät
Schritte zur Erstellung eines Screencasts:
Gehe zur Seite, auf der der Fehler auftritt.
Starte deine Aufzeichnung.
Aktualisiere die Seite.
Führe die Aktion aus, die den Fehler auslöst.
Warte, bis der Fehler auftritt.
Stoppe die Aufzeichnung.
Beispiel 2: Fehler in einer App, getestet auf dem Mobilgerät
Schritte zur Erstellung des Screencasts:
Starte die App und gehe zur Seite, auf der nur noch ein Navigationsschritt erforderlich ist, um zur Seite zu gelangen, auf der der Fehler auftritt.
Starte deine Aufzeichnung.
Ziehe das Benachrichtigungszentrum herunter, um das aktuelle Datum einige Sekunden lang anzuzeigen.
Führe den letzten Navigationsschritt aus, um die richtige Seite zu erreichen.
Führe die Aktion aus, die den Fehler auslöst.
Warte, bis der Fehler auftritt.
Stoppe die Aufzeichnung.
Teamleiter können eine Informationsanfrage senden, um eine externe oder zusätzliche Aufzeichnung anzufordern. Dies erfolgt in der Regel dann, wenn ein besseres Verständnis des Fehlers gewonnen werden soll oder wenn Zweifel an der Reproduzierbarkeit des Fehlers bestehen.
Regeln für Screencasts:
Das Dateiformat von Screencasts muss MP4 sein.
Die maximale Zeit für einen Screencast für Bug-Reports beträgt 60 Sekunden, es sei denn, dein Fehler erfordert das Zeigen eines längeren Ladevorgangs oder langer, notwendiger manueller Eingaben.
Die maximale Zeit für einen Screencast für Reproduktionen beträgt 15 Sekunden und Anhänge von User-Stories, da du in diesen Fällen nur die letzte Aktion zeigen musst, welche den Fehler ausgelöst hat.
Deine Klicks/Berührungen und das Mauszeigersymbol müssen sichtbar sein (nur für Android und Desktop-Aufnahmen erforderlich).
Führe deine Aufzeichnung ohne eine Unterbrechung durch. Du solltest den Screencast weder pausieren noch Teile in der Mitte herausschneiden. Wenn dein Screencast zu lang ist und du ihn bearbeiten möchtest, schneide nur den Anfang oder das Ende der Datei.
Das Erhöhen der Geschwindigkeit deines Screencasts ist nicht erlaubt. Wenn du mehr Zeit aufgezeichnet hast als erlaubt, überprüfe bitte, ob unnötige Schritte in deinem Screencast enthalten sind.
Keine Aufnahme von Geräuschen (schreiende Babys, Gespräche, Fernsehen, Musik, Tiere usw.).
Wir empfehlen Aufzeichnungstools und bewährte Praktiken im folgenden Artikel: Screencasts
Screencast-spezifische Regeln für Streaming-Geräte:
Nimm immer deinen gesamten TV-Bildschirm auf.
Der Screencast sollte eine hohe Auflösung und gute Qualität haben.
Das Umgebungslicht sollte nicht dunkel sein.
Deine TV-Fernbedienung muss im Screencast sichtbar sein. Die Fernbedienung muss vollständig und klar sichtbar sein.
Das aktuelle Datum und die Uhrzeit müssen im Anhang angezeigt werden. Du kannst das aktuelle Datum auf dem TV selbst oder auf einem externen Gerät wie einem PC, Telefon oder Tablet anzeigen.
Für Bug-Reports beträgt die maximale Zeit für einen Screencast 60 Sekunden, für Bug-Reproduktionen und Anhänge von User-Stories hingegen 15 Sekunden.
Keine Aufnahme von Geräuschen (schreiende Babys, Gespräche, Fernsehen, Musik, Tiere usw.).
Der Screencast sollte immer professionell aussehen. Zeichne nicht deine Beine, unordentliche TV-Ständer oder Ähnliches auf.
Private Informationen in Anhängen verbergen
Um deine privaten Informationen, wie Lesezeichen, Kontonamen oder gespeicherte E-Mails, vor dem Sichtbarwerden in Browser-Tabs zu schützen, kannst du sie mit einfachen Mitteln verwischen bzw. unkenntlich machen. Für einen effizienteren Bug-Report wird jedoch empfohlen, ein separates Browserfenster für Testzwecke zu verwenden, wie im Beispiel unten gezeigt. Hier sind keine unnötigen Browser-Tabs oder sichtbaren Lesezeichen enthalten.
Wenn du private Informationen in deinen Anhängen anzeigen musst, diese aber nicht sichtbar sein sollen, kannst du diesem Beispiel folgen, um sie professionell zu verbergen. Beachte hierbei, dass die Namen der Browser-Tabs, die E-Mail-Adressen, Benutzernamen und Lesezeichen enthalten könnten, ausgeblendet sind.
Es ist wichtig zu beachten, dass die URL weiterhin sichtbar und die Webseiten-Elemente nicht verdeckt sein sollten.
Aus Gründen der Professionalität ist es entscheidend, handgezeichnete oder skizzenhafte Malereien zu vermeiden, um Informationen in deinen Anhängen zu verdecken, wie im folgenden Beispiel gezeigt.
