K12製品を例に、ユーザーの内部テスト活動をどのように組織化するかについて説明します。

製品機能がリリースされる前の最終ステップとして、通常、テスターが製品テスト ケースを作成し、テストに合格した後にオンラインで展開します。

しかし、テスターの人員が限られているため、ユーザーの使用シナリオ、デバイスの種類、ネットワーク状況を完全にシミュレートすることは難しく、漏れは避けられません。そのため、製品がオンラインになる前に小規模なユーザー内部テストフェーズを追加することで、発売後の製品品質を向上させ、バグのリスクを軽減することができます。

では、ユーザー内部テスト活動をどのように組織化するか、どのような点に注意を払う必要があるのでしょうか?このレビュー文書を通じて、これらの問題を根本から整理します。

01 目標を見直す

すべてのユーザー内部テスト活動を振り返ると、目標は次の 3 つのカテゴリに分けられます。

1) テストされていないバグを明らかにする

製品に新しい機能のリリースや広範囲のプログラムコードの変更など、比較的大規模なアップデートが含まれる場合は、テストプロセス中に発生するバグの数と種類に注目し、ユーザーの使用に影響を与える問題の有無と発生頻度に注意する必要があります。次に、問題の種類と数に基づいて優先順位を決定し、製造および研究の同僚と連携して問題を修正し、最終的なリリースの品質を確保します。

2) 製品発売後に起こりうるリスクを予測する

内部テスト活動を通じて、隠れた問題を発見するために、より多くの実際の使用シナリオをシミュレートする必要があります。また、内部テストインストールパッケージのデータポイントを追跡することで、機能の一部に関するユーザーの使用データを取得することもできます。製品開発の観点からは、製品の発売後に起こり得るリスクを予測し、回避し、対応計画を準備し、製品の安定性を向上させることができます。

3) ユーザーからのフィードバックを収集する

社内テスト活動は、製品とユーザーとのコミュニケーションのよい機会です。この機会を利用して、製品や機能に関するユーザーの提案やコメントを収集することができます。もちろん、毎回主要なテスト機能に限定されるわけではありません。製品全体に関するユーザーの意見はすべて収集でき、その後の製品イテレーションの参考になります。

02 レビュープロセス

内部テスト活動の目標を決定した後、活動プロセス中にどのような点に注意する必要がありますか?以下の5つの観点から整理してみます。

1) 採用

たとえば、私がこれまでに企画したいくつかのアクティビティを見てみましょう。製品タイプはK12 の学生ユーザーであるため、主に小学校の学年に集中しています。

小学生を直接テストユーザーとして採用すると、生徒の学習の進捗に影響を及ぼします。また、重大な製品品質問題が発生した場合、製品イメージの形成に悪影響を及ぼします。そのため、小学生の年齢の母親グループをターゲットにします。

では、このグループの人々をどのように見つけるのでしょうか?

私たちは、定期的に行われるアルバイトグループやフォーラムに狙いを定め、その後のタスクのガイダンスを容易にするために、タスク情報を投稿することでグループにユーザーを募集しました。このリンクでは、頻繁にアルバイト活動に参加する人には独自のアルバイトサークルがあることもわかりました。これらのユーザーの力を活用することで、募集の進行を分裂効果にすることができます。

人材の採用・管理にはQQグループ方式を採用しました。 QQ グループは比較的完全なグループ管理とグループ ファイルのサポートを提供するため、プロセスにおける人員を削減できます。

製品がK12でない場合は、アプリの正式版でポップアップリマインダーを通じて内部テストへの参加に興味のあるユーザーを募集し、これらのユーザーがアプリのテスト版を積極的にダウンロードするように誘導し、フィードバック活動に協力して全員が十分にテストして問題点を明らかにするように誘導することもできます。ただし、この方法は製品の種類とユーザー属性に一定の制限があり、製品開発の同僚のサポートが必要です。実際の状況に応じて選択できます。

2) 活動費

社内テストユーザーがより積極的に活動に参加できるように、一定数の賞品やボーナスなどのインセンティブを設定できます。ソーシャル属性の強い製品であれば、サイト内メダルや称号などの仮想アイテムを配布することもできます。

インセンティブ方法を選択する際の前提は、ほとんどのユーザーがそれを気に入ることを保証し、ユーザーからのフィードバックに対するモチベーションを刺激することです。最終的なアクティビティ報酬がユーザーにとって重要でない場合、アクティビティの効果は大幅に低下する可能性があります。

イベントのために募集したユーザーのほとんどは外部のパートタイムフォーラムから来たため、インセンティブとして最も直接的な方法であるボーナスを採用しました。ボーナスの配布基準は、テストへの参加時間の長さと問題フィードバックの量と質に基づいています。イベントに参加したすべてのユーザーはQQグループに追加されているため、グループの赤い封筒を通じてボーナスを配布する労力を節約できます。

各社内テスト活動に参加する人数を通じて、活動のコスト支出を見積もり、リーダーまたは協力事業部門に報告することができます。また、団体紅包を配布する際には請求書がもらえないため、事前に財務および税務の同僚とプロセスの遵守を確認する必要もあります。

3) テストを整理する

次に、テストの準備を始めます。このステップも非常に重要なステップであり、活動目標が達成されるかどうかを直接決定します。

まず、製品開発の同僚とテストバージョンのインストール パッケージの配信時間を確認する必要があります。これまでの実際の運用プロセスでは、登録時にアクティビティグループが確立されていたため、インストールパッケージをグループに送信し、アクティビティに参加するユーザーにダウンロードとインストールを案内することができました。

インストールプロセス中、iOS ユーザーはテストに参加するために公式の Testflight アプリをダウンロードする必要があることに注意してください。Android ユーザーは、インストールプロセス中に携帯電話に「公式マーケットに移動してインストールしてください。このバージョンは検証に合格していません」というプロンプトが表示されるかどうかに注意する必要があります。ユーザーがイベントに参加するバージョンを確実にインストールできるように、これらのプロンプトをスキップするようにユーザーを誘導する必要があります。

では、新しくリリースされた機能をユーザーにテストしてもらうにはどうすればよいでしょうか?ここでは 2 つのアプローチを採用しました。

K12 ライブ教育製品であるため、ライブ放送でのみテストできる新機能については、社内の同僚と連携して教師の実際の教育状況をシミュレートできます。ライブ放送時間を設定した後、すぐに社内テストユーザーに通知して参加時間を予約し、ライブ放送中に社内テストユーザーの操作をガイドします。ここで注意すべき点は、ライブ ブロードキャストを通じてユーザーがテストに参加するように誘導する場合、ライブ ブロードキャストでは、操作方法、操作結果、およびその後の問題追跡を容易にするために問題を記録する方法について説明する必要があることです。

非ライブ授業機能に加えて、スクリーンショット、画面録画、GIF 画像、フローチャートなどの形式で機能的な操作説明ドキュメントを作成し、画像、テキスト、ビデオを使用してユーザーの操作をガイドし、問題を明らかにすることができます。

4) 質問集

内部ベータ版と正式版には違いがあるため、内部ベータ版のアクティビティが正式版のフィードバック データに影響を与えないようにするには、問題収集フェーズでユーザー フィードバックを収集するための独立したエントリを選択する必要があります。

これまでの活動では、アンケートを使用して情報を収集しました。活動に参加したユーザーに、アカウント、問題が発生した時間、対応するスクリーンショットまたは再現された画面録画を記入してもらいました。製品の追跡データと組み合わせることで、基本的に問題を特定するための要件を満たしました。

社内のベータ テスト ユーザーからのフィードバックを受け取った後、ユーザーが説明した問題と緊急時の手順を分類して整理する必要があります。同じ種類のフィードバックの頻度を計算するには、ユーザー フィードバックを分類するときに、ユーザーの基本情報 (アカウント、デバイスの種類など) とフィードバック情報 (問題の説明 + スクリーンショット) を一致させるだけでなく、ユーザーが説明した問題をさまざまな種類の単語に置き換えて、同じ問題の大きさの最終的な統計を容易にすることもできます。理解できない、または確信が持てないフィードバックの内容については、ユーザーに再度確認する必要があり、推測は行わないでください。

5) フォローアップ

ユーザー フィードバックの問題を整理した後、フォローアップのためにプロジェクトを担当する製品開発スタッフにドキュメントを送信できます。

文書では、ユーザーから報告された使用状況に影響する問題については、バグであるかどうかとその後の修復計画を評価する必要があり、ユーザーの要求提案については、その後の反復が必要かどうかと反復計画を評価する必要があります。

03 評価結果

内部テスト活動の結果を分析することで、次の 2 つの側面で各活動の有効性と品質を評価することができます。

• 活動数：募集目標数、募集実績数、ベータ版インストール数、問題点を報告した人数。
• フィードバックの品質: アクティビティのフィードバックの総数、有効なフィードバックの数、バグであると確認されたフィードバックの数、および需要提案であると確認されたフィードバックの数。

各アクティビティにおける各リンクのコンバージョン率を比較することで、実際のリクルート数→社内ベータ版をインストールした人数→問題を報告した人数から、アクティビティの形態を最適化することができます。また、有効フィードバック数とアクティビティフィードバック総数の推移を比較することで、社内ベータユーザーへのフィードバック教育リンクを最適化し、より質の高いフィードバックを得ることにも役立ちます。

04 原因を分析する

このセクションでは、活動中に私が遭遇した 2 つの落とし穴について説明し、皆さんがそれを回避できるようにお手伝いしたいと思います。

当初は、登録ユーザーの問題発見意欲を刺激するために、追加のフィードバック報酬を設定し、報酬基準をフィードバック数上位3名に設定しました。最初の数回の活動が終了した後、データを観察したところ、有効なフィードバックの割合は約40％に過ぎず、重複したフィードバックと無効なフィードバックの数が比較的多いことがわかりました。

そのため、その後フィードバック報酬のルールを変更し、「質+量」を基準として、より質の高いフィードバックを公開することで、イベントに参加しているユーザーに前向きな刺激を与えました。その後の内部テスト活動では、有効なフィードバックの割合を約 70% に安定させることができました。

500 人以上が参加する社内テスト活動もありました。私たちは引き続き QQ グループを使用して、1 対 N のユーザー管理と社内テストの教育を行っていました。しかし、参加者数の増加により、社内テストの教育がより困難になり、1 対 N モデルは明らかに適用できなくなりました。

イベント終了時に参加ユーザーに報酬を配布する際に、テンセントの担当者は、紅包取引の頻繁な使用によるアカウント停止のリスクについても敏感に注意喚起します。この状況に対応するため、活動グループを設立する際には、バックアップ管理アカウントもグループに追加し、同時に内部テスト教育の人員を増やす必要があります。

長期的な視点で見ると、これまでの活動の中で質の高い社内ベータテストユーザーを多数発掘し、これらのユーザーに社内ベータテスト活動の推進と管理の権限を与えることは、自社の人的資源の解放に大きなメリットをもたらすでしょう。

05 経験のまとめ

K12 業界の特殊性を考慮して、私たちは QQ グループを通じて社内ベータ パッケージを配布し、リリース予定の新機能をテストするために外部ユーザーを募集することを選択しました。

内部テスト活動の鍵は、十分な数のユーザーを募集し、より多くのフィードバックを得て、製品の反復をサポートすることです。正式版と比較して、内部テスト版では新機能を事前に体験できます。募集時には、「限定募集」や「体験への招待」という言葉が、募集の進行に役立ちます。

内部テストのプロセスでは、内部テストユーザーに対する機能のプロモーションとフィードバック教育を適切に行い、より質の高いフィードバックを得るための適切なインセンティブメカニズムを設定する必要があります。

同時に、社内テスト活動に積極的に参加し、質の高いフィードバックを提供するユーザーを迅速に発掘し、これらのユーザーを各社内テスト活動の「イメージキャラクター」として育成し、活動に参加する他のユーザーに良い影響を与える必要があります。

著者: 白碩作戦

出典：白朔作戦