TestFlightには、スクリーンショット、クラッシュレポート、コメントをビルドや端末の情報と結び付けて受け取る仕組みがあります。ベータテストを始める段階で、別のアンケートを先に増やす必要はありません。
収集方法を決める前に、テスターへ何を試してほしいか、届いた報告を誰がどう判断するか、修正版をどのビルドで確認するかを決めます。道具より先に、フィードバックが修正へ進む流れを作ります。
Test Informationで依頼内容を絞る
AppleのTestFlight公式案内では、App Store ConnectのTestFlightタブで、テスターに確認してほしい内容と関連情報を設定し、フィードバックを確認・返信するためのメールアドレスも用意するよう案内しています。
「自由に使って感想をください」だけでは、テスターごとに確認範囲が変わります。一つのビルドにつき、中心となる確認項目を短く示します。
- 今回追加または変更した機能
- 最初から最後まで通してほしい操作
- 特に確認したい画面や状態
- 問題が起きたときの報告方法
- 既知の問題と、今回は確認しなくてよい範囲
確認項目を増やしすぎると、どれを試したか分からなくなります。アプリ全体の自由利用と、今回の変更点を確認するタスクを分けて伝えると、一般的な感想とリリース判断に使う結果を区別できます。
最初はTestFlight標準の報告を使う
TestFlightでは、テスターがアプリのスクリーンショットを撮り、注釈やコメントを付けて送れます。クラッシュが発生した場合は、クラッシュレポートに追加の状況説明を添えられます。
App Store Connectのテスターフィードバック確認手順では、受け取る内容を次の三つに分けています。
| 種類 | 含まれる内容 | 最初の判断 |
|---|---|---|
| スクリーンショット | 画面、注釈、コメント | 表示位置と指摘内容を確認する |
| クラッシュ | 発生時刻、クラッシュ詳細、追加コメント | 同じビルド・環境で再現範囲を調べる |
| 一般コメント | 操作感、要望、説明 | 不具合、改善案、質問へ分類する |
詳細画面では、アプリ、テスター、端末に関する情報も確認でき、プラットフォーム、アプリバージョン、ビルドグループ、ビルド、OS、端末で絞り込めます。報告本文に端末名を書いてもらう前に、標準画面で確認できる項目を使います。
スクリーンショットとクラッシュを別に処理する
スクリーンショットの指摘は、見えている場所が明確です。ただし、画像だけではその画面へ至る操作や期待した結果が分からないことがあります。コメントを読み、次が不足していれば追加で確認します。
- どの操作の直後か
- 実際の表示と期待した表示は何か
- 毎回起きるか
- 画面向き、文字サイズ、言語など条件があるか
クラッシュ報告では、まず同じビルド、OS、端末の報告が他にもないか絞り込みます。テスターの記憶に頼って環境を聞き直す前に、App Store Connectへ結び付いた情報を確認します。
Appleのヘルプでは、クラッシュレポートをダウンロードできる期間は120日とされています。あとで調べる可能性がある報告は、期限前に必要なファイルと判断記録を保存してください。応答不能になった事象など、クラッシュレポートが含まれない場合もあるため、レポートがないことだけで問題がなかったとは判断できません。
公開リンクの匿名性を理解する
招待メールから参加したテスターは、詳細画面でメールアドレスを確認できます。一方、公開リンクから参加したテスターは、フィードバック送信時に本人がメールアドレスを入力しない限り匿名で表示されます。
匿名の報告でも、画面やクラッシュの修正には使えます。違いが出るのは、追加質問や修正版の個別確認が必要な場合です。
返信が必要になりそうなテストでは、次のどちらかを事前に伝えます。
- 連絡を受けられるよう、フィードバックへメールアドレスを添える
- 個別返信が必要な内容は、別の問い合わせ窓口から送る
メールアドレスの入力を必須とする前に、なぜ返信が必要かを説明します。表示の感想を匿名で受け取るだけなら、個人を特定する情報は不要です。
別フォームを足す条件を決める
TestFlight標準機能で、報告、環境の確認、短い返信まで足りるなら、窓口を増やさない方がテスターにも開発者にも分かりやすくなります。
追加フォームを検討するのは、次のような場合です。
- TestFlight以外のWeb版やAndroid版も同じ形式で受け付けたい
- 修正後の確認を複数回行い、対応状態を追跡したい
- テスト終了後も同じ窓口でやり取りを続けたい
- アプリ固有の状態を報告へ添えたい
- 不具合、質問、改善案を一つの一覧で管理したい
反対に、クラッシュレポートやスクリーンショットをTestFlightから別システムへ手作業で移すだけなら、管理場所が二重になります。追加する窓口がどの不足を補うのか、一文で説明できる場合だけ使います。
報告から再確認まで状態を残す
届いた意見は、読むだけで終わらせず、次の状態へ進めます。
| 状態 | 判断 |
|---|---|
| 未確認 | まだ内容と環境を読んでいない |
| 調査中 | 再現条件や影響範囲を確認している |
| 対応予定 | 変更内容と対象ビルドを決めた |
| 再確認待ち | 修正版を配布し、同じ操作の確認を依頼した |
| 完了 | 修正を確認した、または対応しない理由を記録した |
すべての要望を実装する必要はありません。意図した仕様、今回のリリース対象外、再現情報が不足している、といった判断も残します。何を採用したかだけでなく、なぜ見送ったかが分かると、同じ要望が届いたときに見直せます。
修正版では「直りましたか」ではなく、対象ビルドと再確認する操作を指定します。元の報告、修正内容、確認結果がつながれば、そのビルドを公開候補にできるか判断できます。
IndieFormを補助窓口にする場合
IndieFormはTestFlightのフィードバックを自動で取り込むサービスではなく、クラッシュレポートの代替にもなりません。TestFlight内で完結する報告は、そのままApp Store Connectで扱う方が文脈を失いません。
追加のやり取りが必要なときは、アプリ内からIndieFormの公開フォームを開き、バージョン、ビルド、OS、端末、言語を問い合わせへ添える使い方ができます。TestFlightの外へ移った後も、本文と環境を対応付けて状態を管理できます。
フォームで不具合を受ける項目の設計は、アプリの不具合問い合わせで集める情報を参照してください。TestFlightですでに得られる情報を重ねて入力させず、追加質問と継続対応に必要な項目だけを残します。
ベータ配布前の確認項目
ビルドをテスターへ渡す前に、次を確認します。
- Test Informationに今回確認してほしい内容を書いた
- フィードバック用メールアドレスを監視できる
- スクリーンショット、クラッシュ、一般意見の処理先を決めた
- 公開リンク経由では匿名になり得ることを理解した
- 個別返信が必要な報告の送り方を案内した
- 修正版のビルドと再確認結果を元の報告へ結び付けられる
TestFlightの標準機能を起点にすると、ビルドや端末の情報を保ったまま判断できます。別フォームは、標準機能にない継続対応を補うときに限定し、テスターが報告先を迷わない構成にしてください。