こんにちは 私の名前はEvgeny Emelyanovです。Mail.RuCalendarプロジェクトの責任者です。 今日は、文字とスクリプトを使用してカレンダーのモバイルアプリケーションのテストをどのように強化したかについて説明します。 このようなテストは、ユーザビリティの研究や、ユーザーとインターフェースとの相互作用の研究で広く使用されています。 モバイルアプリケーションの従来の手動テストにも同様の手法を適用することにしました。 最初は、チームは懐疑的でしたが、結果は非常に好意的なものだったので、私たちの経験をあなたと共有したいと思います。



注意：マーケティングおよびユーザー中心のデザインでは、キャラクターは架空のキャラクターです。 これらは、地理、人口統計、行動、および習慣で分けられたさまざまなユーザーグループを表します。 マーケターはキャラクターを使用して、さまざまな市場セグメントを記述します。



キャラクターは、ブランドや製品の消費者の目標、希望、制限を決定するのに役立ちます。 さまざまな新しい開発、現在の機能の変更、設計に関する決定を下すのに役立ちます。 ユーザーキャラクターは、製品の仮想ユーザーグループの目標と動作を表します。 ほとんどの場合、キャラクターは調査やユーザーインタビューから取得したデータから作成されます。 データには、行動パターン、目標、スキル、能力、および外部環境の説明が含まれています。 より現実的な外観を再現するために、架空の小さな個人的な特性が追加されます。 通常、製品ごとに複数のキャラクターが作成されますが、メインターゲットグループの代表であるメインキャラクターが常に存在する必要があります。

問題は期限切れです

キャラクターの使用を開始する前に、テストプロセスは大まかに次のように構成されていました。

1. 開発者はビルドを構築しています。
2. 煙のテストが進行中です。
3. このビルドで実行されるタスクがチェックされます。
4. 変更の影響を受ける機能のブロック全体がテストされます。
5. ビルドがベータ版になる場合、すべてのユーザーケースの完全なテストが実行されます。

条件を確認します。 この場合、「ユーザーケース」は、アプリケーションを使用するための小さなシナリオです。 たとえば、特定のパラメーターを持つイベントを追加します。 問題は2つの方向に生じました。 第一に、ユズケ族はほとんど「合成的」でした。 テスターは、明白な理由で、現実から離婚したデータをもたらし、より頻繁にアプリケーションを意図的に「破壊」しようとしました。 それを行う必要がありますが、何かを壊すことは別のユーザーケースです。 次に、複雑なバグがユーザーケースのジャンクションで発生したか、いくつかのユーザーケースの特定の実装で発生しました。 したがって、そのようなバグは、テスターではなくユーザーによって発見されることが多かった。 これは私たちを大いに悲しませました。

架空の友達

Calendarプロジェクトは小さく、居心地が良く、ほとんど家族経営です。 テクニカルサポートを迂回して、ユーザーと直接通信しようとします。 したがって、私たちはユーザーとその主なタスクを熟知しており、ほとんどの問題を認識しています。 メイングループの肖像画を作ることは難しくありませんでした。



通常のユーザー ：カレンダーにイベント（休日、スポーツ、映画）、誕生日を追加し、さまざまなリマインダーを使用します。 時々、個人的なイベントや新しい誕生日を追加します。







モバイル ：スマートフォンでのみカレンダーを使用します-iOSまたはAndroid。 Webインターフェイスにアクセスすることはほとんどありません。 イベントは主に個人的なもので、単一のイベントでも定期的なイベントでもあります。







アクティブ ：Webインターフェイスとモバイルクライアントの1つ（iOSまたはAndroid）を使用し、多くの場合2つのクライアントを切り替えます。 多くのイベントとタスクを作成および編集し、多くの場合、参加者を招待するか、自分自身がイベントの参加者です。







Technocrat ：両方のモバイルプラットフォームでWebインターフェイスとクライアントを使用します。 多くのイベントとタスクを作成します。 ツールに対して非標準のアプローチを使用し、イベントやタスクを処理する独自のスキームを構築します。







酒に酔ったマスター ：自然界ではめったに見られない、破壊と破壊をもたらすことができる特別な種類。 彼は常にボタンを混乱させ、意識の流れをフォームに押し込み、送信を10回押し、スパムを送信し、あらゆる方法で到達したものを破壊しようとします。







これらの5つのユーザーグループはユーザーケースと重複していますが、シナリオはまったく異なります（ユーザーケースのセットとそれらが実行される順序）。 たとえば、クライアント間の高速で安定したデータ同期は、ActiveクライアントとTechnocratにとって重要であり、モバイルクライアントのみを使用するため、モバイルにとっては特に重要ではありません。 これらの考慮事項に基づいて、既存のユーザーケースに基づいて各キャラクターの使用シナリオをまとめました。



次に、カレンダーでのグループ作業のキャラクター間の相互作用のいくつかのシナリオをまとめました。 重要な点は、グループシナリオを含むすべてのシナリオが、社内のグループの代表者で実行されたことです。 したがって、キャラクターの選択が正しいことと、シナリオが実際の生活に近いことの両方を確認しました。 同僚に対して「コリドーテスト」を使用しましたが、実験の純度を高めるために、メールとインスタントメッセンジャーを使用してサードパーティのユーザーにポーリングすることも試みました。 「廊下のテスト」はより効果的であることが判明しました。忠実なユーザーとコミュニケーションをとると、「どんな費用でも助けになる」という修正効果が生じたからです。 そして、ユーザーはいくつかの点について沈黙しており、彼らの理解において、期待される結果に調整していました。

プロセスが始まった

これで、アプリケーションのテストプロセスは次のようになります。

1. 開発者はビルドを構築しています。
2. 煙のテストが進行中です。
3. このビルドの特定のタスクがチェックされます。
4. 影響を受ける機能ブロックを使用する文字スクリプトがテストされます。
5. ビルドがベータになる場合、すべてのキャラクターのすべてのシナリオが優先度の順にテストされます。

たとえば、「アクティブ」というキャラクターのテストスクリプトの1つを提供します。 スクリプトは1時間以内に実行されるように設計されています。

• 営業日の初めに、イベント通知のモバイルクライアントを確認します（詳細については一部を確認します）。
• 1-2イベントを別の時間に転送します。
• Webクライアントのイベントの1つに参加者を追加します。
• 現在の日に1〜2個のイベントを作成し、現在の週に2〜3個のイベントを作成します。
• モバイルクライアントで任意の日付の2〜3タスクを作成します。
• Webクライアントの現在のリストから任意のタスクに「完了」のステータスを付けます。
• モバイルクライアントのオフラインモードでは、イベントを表示し、新しいタスクをいくつか作成し、イベントの1つを移動し、オンラインにし、同期を確認します（これをエレベータでの運転シミュレーションと呼びます）。
• Webクライアントで完了したいくつかのタスクにマークを付け、1〜2タスクを別の日に転送し、任意の日付に2〜3イベントを作成し、History in Historyカレンダーからソーシャルネットワークにイベントをシャッフルします。

詳細を退屈させないために、スクリプトはわずかに削減および簡略化されています。 異なるキャラクターとそのシナリオをテストする順序については、異なるユーザーグループの統計情報を使用して、優先順位を付けます-最大のグループが最初にテストされます。 これは、最初に最も人気のある機能を安定させ、より頻繁にアルファ版とベータ版をリリースするために行われます。

ニュアンスのスプーン

当然、キャラクターはすべての病気の薬ではありません。 テクニックの使用に関連する問題と、キャラクターが解決しない問題があります。



主なものは、エピソードの冗長性と、さまざまなキャラクターやさまざまなシナリオでのユーザーケースの賦課です。 実行パラメーターによってユーザーケースを分割し、これに苦労しています。 たとえば、キャラクターごとにイベントを個別に作成し、各イベントには、現実に可能な限り近い独自のパラメーターセットがあり、イベントを作成するためのすべての可能な条件をカバーしています。



別の問題は、一部のユーザーケースは、実際には非常にまれであるか、性格が合成されているため、スクリプトに含めることができないことです。 これらのユーザーケースはスクリプトとは別にし、すべての機能の完全なテストを行います。

利益

キャラクターとスクリプトの操作の結果に基づいて、モバイルクライアントの3つの更新がリリースされました。 リリースされたバージョンは非常に異なり、相互に比較することは完全に正しいわけではないため、ユーザー自身による不快なバグの発見に関する統計の改善について言及することは不可能です。 しかし、他にも同様に重要な有益な効果があります。



まず、テスターはキャラクターを扱うのがはるかに楽しいです。 テストプロセスはより多様になり、製品とユーザー自身の理解が深まりました。 抽象的で実際の状況では再現が難しいバグを探す代わりに、エンドユーザーにとって重要な問題が最初にキャッチされます。



第二に、テスターは機能テストだけでなく、ユーザビリティテストにも参加しています。 そして今、インターフェースを議論するときの意見の数は、彼らの議論とビジョンで製品のアクティブなユーザーによって補充されました。



第三に、新しいテスターのエントリーしきい値が低下しました。 最近、私たちは実験を行い、テスターの立場でテスト経験のない人を引き受けました。 一般的な問題に関する「若い戦闘機のコース」とは別に、約3日後に効果的なテストが開始されました。



開発者もアプリケーションをテストする必要があることを忘れてはなりません。スクリプトが用意されています。 カレンダーなどのニッチ製品は、直接参加者による使用の問題に直面しています。 シナリオとキャラクターは、「なぜこれを使用する必要があるのか​​、私にはそのような必要はない」と尋ねる素晴らしい仕事をします。 私たちの場合、開発者は時間の経過とともに製品を使い始め、徐々にシナリオから離れていきます。



最後に、機能テストだけでなく文字を使用します。 行われた作業のおかげで、マーケティングで潜在的に使用できる重要で便利なツールを構築し、思い浮かべました。



Yuri Vetrov（@jvetrau）、Mail.Ru Group Interface Design Groupのヘッド：

キャラクターはデザイナーとデザイナーにとって強力なツールであり、製品の実際の使用で最も需要のあるシナリオに集中することができます。 彼が使いやすさだけでなく、実装の品質をテストするプロセスでアプリケーションを見つけたのは素晴らしいことでした。



理想的な状況では、バグがすべてを一度に修正します。 しかし、人生には常に、完全で取り消せないバグ修正を押し戻すタスクの束があります-新機能、緊急のホットフィックスなど。 したがって、バグを修正するときと発見するときの両方で優先順位を付ける良い方法が必要です。 このためにユーザーの最も重要なカテゴリを使用するための主要なシナリオを使用する-それだけです。 これは、まず、ユーザーを最も頻繁に妨げる問題が見つかって修正されることを意味します。



これに先立ち、キャラクターはユーザビリティとユーザーテストの専門家による評価に依存していました。 それらを使用して実装の品質をチェックすることは、興味深く、かなり新鮮なアプローチです。 私は長い間、インターフェースに取り組んでいる現代の方法について多くを読んできましたが、そのようなことを聞​​いたことがありません。 したがって、これは製品チームの貯金箱への素晴らしい追加です。