スタッフが使う前にビジネスアプリの現実的なテストデータを作る

きれいなデモが、スタッフの利用開始後に失敗する理由

きれいに整えたデモでは、空の画面や、完全なデータが入った少数のレコードを使うことがよくあります。顧客には必ず完全な氏名があり、注文には明確なステータスがあり、全員が想定どおりの手順に従います。これでワークフローを表示できることは分かります。しかし、忙しい火曜日にスタッフが使えることまでは証明できません。

実際の仕事はもっと複雑です。営業担当者が電話番号なしで連絡先を保存し、後から正しいメールアドレスを入力することがあります。業務管理者が「Acme」で検索し、似たレコードを6件見つけることもあります。顧客の気が変わったため、誰かが完了済みの依頼を再開しなければならない場合もあります。現実的なテストデータを使えば、こうした状況が本番で混乱を生む前に見つけられます。

空の画面では、実務上の疑問も隠れてしまいます。スタッフは最初に何を入力すればよいか分かるでしょうか。下書きと送信済みの依頼を区別できるでしょうか。必須項目が空欄のとき、足りない情報をアプリが説明してくれるでしょうか。発表者はすべての手順を知っているため、こうした問題を気にせず先へ進めてしまいます。

共有レコードでワークフローは変わる

複数の人が同じアプリを使うと、初めて見えてくる問題がたくさんあります。あるスタッフが顧客レコードを更新している間に、別のスタッフが古いバージョンを見ているかもしれません。上司はすべての依頼を見たい一方で、従業員には自分の依頼だけを見せる必要があるかもしれません。誰かがレコードのステータスを変更したのに、次の担当者へのメモを残していないこともあります。

現実的な活動を再現して、共有作業をテストしましょう。似た名前、未完成の情報、古い日付、重複、修正が必要な情報を持つレコードを作成します。そのうえで、2、3人のテスターに同じレコードを同時に扱ってもらいます。変更の上書き、担当者の分かりにくさ、理解しづらいステータス名、整理しにくい検索結果がないか確認してください。

Koder.aiでは、チャットを通じてWeb、サーバー、モバイルアプリを作れます。ただし、開発が速くても、普通の人の行動をテストする必要がなくなるわけではありません。チーム全体が頼る前に、実際の仕事の進め方で最初のバージョンを試しましょう。

テストデータと実際の情報を分ける

テスト中は、架空の氏名、メールアドレス、電話番号、会社情報を使いましょう。「TEST - Northside Supplies」のように、実在の顧客と間違えない名前を付けます。顧客リスト、従業員記録、財務情報、個人的なメモをテスト環境にコピーしないでください。

大量のレコードを複製するより、少数でも変化に富んだテストデータを用意するほうが効果的です。通常の例、入力途中のレコード、重複、明らかなミスをいくつか入れましょう。スタッフは実データを危険にさらさずに試行錯誤し、分かりにくい点を報告できます。

スタッフが実際に行う仕事から始める

ビジネスアプリは、普通の火曜日に人々が処理する仕事に対応できなければなりません。スタッフが使う言葉で、実際の作業を書き出しましょう。営業担当者が注文を入力する。マネージャーが返金を承認する。顧客担当者が顧客の電話番号を更新する。こうした内容は、「注文画面をテストする」のような大まかなラベルよりも、よい出発点になります。

各作業を、開始点、行動、期待する結果が分かる短いシナリオに変えます。技術的な説明なしでも同僚が読める、分かりやすい文章にしてください。

例えば、次のように書けます。「顧客から、まだ発送されていない注文の配送先を変更したいと電話があった。営業担当者が注文を見つけ、住所を編集して保存すると、注文確認画面に新しい住所が表示される。」これで、どのレコードを準備し、変更後にアプリが何を表示すべきかが分かります。

スタッフが一日中繰り返す定型作業には、特に時間をかけましょう。結果を変える小さな違いも記録します。新規顧客か既存顧客か、商品が1つか5つか、請求書が全額支払い済みか一部支払いか、といった違いです。きれいなデモでは、完全なレコードを1つ使いがちです。しかし、実際の仕事はほとんどそうなりません。

頻度の低い作業もテストします。スタッフが手順を忘れていることもあれば、最初の開発者が試したことのない作業もあります。次のような業務を含めてください。

• 月を締め、期限超過の請求書を確認する
• 間違った顧客名義で入力された注文を修正する
• マネージャーの承認後に返金を処理する
• 退職した従業員の未完了の仕事を引き継ぐ
• 財務担当者や監査人向けにレポートを出力する

Koder.aiでアプリを作った場合は、開発中にこれらのシナリオを直接チャットで依頼しましょう。スタッフを招待する前に、準備したレコードで繰り返し実行し、各シナリオの横に期待する結果を置いておきます。

よいシナリオには、明確な終点があります。「顧客情報を更新する」だけでは曖昧です。「顧客の請求先メールアドレスを変更してレコードを保存し、次の請求書にそのメールアドレスが使われることを確認する」なら、テスターが確認すべき内容が具体的になります。

日常の業務データに似たレコードを作る

空のアプリはデモではきれいに見えても、普通の火曜日には失敗することがあります。スタッフは、よくある名前の顧客を探し、期限超過の請求書を確認し、仕入先のメモを見つけ、2回担当者が変わったレコードの内容を理解しなければなりません。

サンプルレコードを、会社が扱う情報に近づけましょう。顧客や従業員のデータをコピーせず、架空の氏名と連絡先を使います。新規顧客、長期顧客、情報が不完全な仕入先、部署を異動した従業員、複数のメモが付いたレコードなど、適度な組み合わせを用意してください。

日付、金額、ステータスにも変化を持たせます。すべての請求書が同じ金額で、すべての依頼が「Open」なら、並べ替え、絞り込み、レポートが正しく機能するか判断できません。数か月にまたがるレコードを作り、アプリに合う範囲で、下書き、送信済み、支払い済み、遅延、キャンセル、アーカイブ済みなどの状態を混ぜましょう。

少数の現実的なパターンから、同じレコードを何百件も作るより多くの問題が見つかることがあります。

• 1人の顧客に同じ日の注文が2件ある。
• 1社の仕入先に古い電話番号と、変更理由を説明する最近のメモがある。
• 退職した従業員が過去のレコードには表示されるが、新しい仕事は受け取れない。
• 複数の顧客が同じ姓や会社名を持っている。
• 多数の少額の通常取引の中に、1件だけ大きな金額がある。

古いレコードも意図的に追加します。新しい5件だけが検索結果に出る状態では、スタッフが昨年の依頼を見つけられるか、月次レポートが正しく情報をまとめられるか分かりません。古いデータがあれば、扱いにくい日付形式、アーカイブ済みのステータス、担当者が設定されていないレコードも見つかります。

メモは簡潔でも、実際にありそうな内容にします。「顧客から、配送を2回に分けてほしいと言われた」は、「テストメモ14」より役立ちます。社内向けの試験であっても、実在の住所、口座番号、電話番号、個人的なコメントをテストアプリに入れないでください。

チームを招待する前にユーザーと権限をモデル化する

全員が同じ画面とボタンを見られるアプリは、問題を起こします。現実的なテストには、レコードを入力するスタッフ、承認するマネージャー、進捗だけを確認する人など、実際の利用者も含める必要があります。

役職名だけでなく、日々の作業で役割を定義しましょう。「マネージャー」と呼ばれる2人でも、必要なアクセス権が異なることがあります。営業マネージャーは割引を承認できても、給与情報は見られないほうがよいかもしれません。経理担当者は請求書を作成できても、顧客の与信限度額は変更できないようにします。

各役割でできることを書き出し、その役割用のアカウントで一つひとつの操作をテストします。ユーザーが必要なレコードを閲覧、作成、編集できるか確認し、制限された項目や操作は利用できないようにします。レポート、ファイル、設定、エクスポート、通知もテストしてください。個人情報はメインのレコード画面ではなく、こうした場所に表示されることもあります。

想定した手順だけをテストしてはいけません。権限が限られたスタッフとしてログインし、検索からレコードを開き、保存したブラウザーのアドレスからアクセスしてみます。アプリは操作をブロックする必要があります。メニュー項目を隠しただけでは、権限のない人がページにアクセスできる問題を防げません。

管理者アカウントも用意し、慎重にテストします。管理者は権限を変更し、すべてのレコードを見て、データを削除できることがよくあります。このアカウントで、設定を間違えたスタッフアカウントのアクセスを復元できるか確認してください。

2週間だけ手伝う契約スタッフなど、一時的なアカウントも追加しましょう。その仕事に必要なレコードと操作だけを与えます。期間が終わったら、その人が入力した仕事を削除せずにアクセスだけを失える状態にします。

Koder.aiの計画モードでは、スタッフを招待する前に役割を説明できます。テスト用のアカウントを分けて作り、各アカウントで同じ短い作業を繰り返しましょう。アプリが急速に変化している間なら、権限の問題をより簡単に修正できます。

通常のワークフローで扱いにくいケースを試す

アプリの問題は、きれいなデモ中よりも、普通の仕事の途中で見つかることが多いものです。日付、氏名、メモ、金額が日々の業務に似たレコードを、ワークフローの各段階に用意しましょう。

注文アプリなら、誰も触れていない新しい注文、スタッフが準備中の注文、マネージャーが承認した注文、先月チームが完了した注文を作ります。各段階でスタッフが変更できる項目を確認してください。完了済みの注文を誰かが配送先の住所を編集しただけで、ひそかに「進行中」に戻してはいけません。

実際の仕事で起きる例外もテストします。

• スタッフが作業を始めた後で注文をキャンセルする
• アプリが支払い完了を記録した後で、支払いが返却される
• 期限を過ぎた依頼を開く
• ワークフローで必要とされる添付ファイルなしでレコードを送信する
• 情報が不足した項目を承認しようとする

2人が同じ項目を変更するケースには、専用のテストが必要です。1人には顧客の電話番号を更新してもらい、もう1人には注文のステータスを変更してもらいます。アプリは結果を明確に示すべきです。両方の変更を保存する、2人目にレコードが変わったことを警告する、更新を求めるなどの方法があります。誰かの作業を通知なしに隠してはいけません。

後から確認が必要になったときは、ステータスの履歴が重要です。次のような簡単な流れをテストしましょう。Samが9時10分に依頼を作成し、Priyaが9時25分に承認し、顧客から電話を受けたSamが10時にキャンセルする。依頼にアクセスできるスタッフは、誰がいつ各変更を行ったか、アプリが収集した理由を確認できる必要があります。同時に、長いメモの履歴をすべて読まなくても現在のステータスが分からなければなりません。

Koder.aiのアプリでは、テスト版を作る前にこうした状況を普通の言葉で説明しましょう。その後、画面が完成しているかを見るのではなく、作業として実行します。

わざと間違った入力を入れる

スタッフは日常的なミスをします。項目を入力し忘れたり、余分な空白が入った電話番号を貼り付けたり、符号を間違えた金額を入力したりします。実際のレコードがアプリに入る前に、こうしたミスを含めましょう。きれいなデモデータでしか動かないフォームは、忙しい勤務日に失敗します。

同じフォームを何度も使い、毎回1つの要素だけを変えます。どのチェックが働いたのか、メッセージが修正に役立つかを確認しやすくなります。

• 条件付きの項目も含め、必須項目を空欄にする
• 長い顧客メモ、記号、アクセント付き文字、改行、絵文字を貼り付ける
• 将来の予定に過去の日付を入れる、請求金額をマイナスにする、小数点以下を多く入力する
• 別のレコードですでに使われているメールアドレスを送信する
• 空白、カンマ、通貨記号を含む数値を貼り付ける

アプリは、何を直せばよいかを分かりやすい言葉で説明する必要があります。「電話番号は10桁以上で入力してください」なら、次の行動が分かります。「入力エラー」だけでは不十分です。できるだけ項目の近くにメッセージを表示し、送信を試みた後も見える状態にしてください。

フォームの他の部分がどうなるかも確認します。Mariaが新しい顧客の情報を5分かけて入力し、郵便番号だけを間違えたとします。アプリは正しいメモ、連絡先、選択項目を保持しなければなりません。最初からやり直すのではなく、1つの項目を直して再送信できるようにします。

送信を止めた後には、明確な次の行動が必要です。マークされた項目を修正する、安全にキャンセルする、作業が未完了なら下書きとして保存する、といった道筋を示します。読めないうちに消えるエラーポップアップや、失敗後に反応しなくなるボタンは避けてください。

Koder.aiで作るときは、各フォームへの依頼にこうしたケースを含めます。項目ごとの明確なルール、重複チェック、読みやすいエラーメッセージ、送信失敗後も入力内容を保持することを依頼しましょう。その後、リストアップした実際の不正な値でアプリをテストします。

現実的なスタッフのシナリオを1つ通してみる

スタッフ12人の暖房・配管会社を想像してください。1つのアプリで顧客、サービス作業、請求書、支払いを管理しています。

オフィスマネージャーのMayaは、暖房ラジエーターの水漏れについてJordan Leeから電話を受けます。MayaがJordanを検索すると、同じ住所に「Jordan Lee」と「J. Lee」という2つの顧客レコードが見つかります。Mayaは一方を選び、水曜日の午前に作業を登録し、問題の内容を追加して、技術担当のSamを割り当てます。

作業は「Booked」で始まります。Samは現場でスマートフォンからアプリを開き、写真を追加し、ステータスを「Work complete」に変更して、部品代と作業費を入力します。このラベルは最終完了のように見えますが、請求書を作成する前にMayaが料金を確認しなければなりません。スタッフは「Work complete」を「請求可能」と読み、Samは「現場を離れた」という意味で使うかもしれません。

「Awaiting office review」のように、より明確なステータスを使いましょう。Mayaの次の作業が分かり、料金を確認する前に請求書が送られることも防げます。

Mayaは、Jordanに45日間期限を過ぎている古い請求書があることに気付きます。新しい作業の請求には上司の承認が必要だと判断しました。上司のPriyaはSamのメモを確認し、前回の修理が失敗したため割引を承認します。

このシナリオでは、アプリが現実の判断を扱えるかを確認できます。

• Mayaは重複の可能性がある顧客を確認し、統合するか、確認待ちとしてマークできる必要がある。
• Samは担当する作業を更新できるが、請求金額の編集や割引の承認はできない。
• Priyaは、関係のない給与情報や会社設定にアクセスせずに作業を承認できる。
• Mayaが新しい請求書を送る前に期限超過の請求書を確認できるが、緊急の修理作業は止まらない。
• 各ステータスから、次に誰が行動するのか、どの操作が残っているのかが分かる。

通りの住所、変化のある作業メモ、18.75ドルの部品、支払日が異なる請求書など、現実に近いレコードでシナリオを実行します。テスターに別々に作業してもらい、それぞれが各ステータスをどう理解したかを比較しましょう。

Samがスマートフォンから割引を承認できるなら、権限ルールを修正します。Mayaが「Work complete」が請求済みを意味するのか、現場で作業が終わっただけなのか判断できないなら、スタッフが頼る前にステータス名を変更してください。

簡単なテストセッションを行い、結果を記録する

短く集中したテストセッションなら、完成度の高いデモでは見つからない問題を発見できます。各テスターに、顧客を追加する、経費を承認する、期限超過の請求書を見つけるなど、普通の作業を1つ与えます。すべてのクリックを教えず、1人で作業してもらいましょう。

立ち止まった、違うメニューを選んだ、ラベルの意味を尋ねた、といった出来事を記録します。こうした瞬間は、言葉を明確にする必要がある場所や、手順を簡単にできる場所を示しています。

簡単な問題管理表を作ります。小さなチームなら共有表で十分です。問題が起きたページ、使用した操作とサンプルレコード、期待する結果、実際に起きたこと、ユーザーの役割を記録します。修正担当者が推測せずに再現できる内容にしてください。

セッションが終わる前に問題を整理します。最初に、作業を止める問題を置きます。次に、個人情報を漏らしたり、閲覧だけのはずの人がレコードを変更できたりする権限の問題を置きます。分かりにくいラベルや余分なクリックも重要ですが、通常は同じ緊急度で対応する必要はありません。

修正後は、同じ役割、同じサンプルレコード、同じ手順で正確に再テストします。検索結果やエクスポートなど、関連するページも確認してください。顧客ページでの修正が、別の場所に残っている同じ問題まで解決するとは限りません。

Koder.aiはスナップショットとロールバックに対応しているため、大きな変更の前に動作が確認できたバージョンを保管できます。新しい役割やワークフローが加わったときにも役立つよう、問題管理表をプロジェクトと一緒に保管しましょう。

最初にスタッフへ展開する前のチェックリスト

現実的なサンプルレコードを使ってアプリのコピーを確認します。受付担当、マネージャー、経理担当が同じ忙しい朝に使えば、整った画面でも問題が起きることがあります。

各担当者に自分の役割でログインしてもらい、普通の作業を最初から最後まで完了させます。営業担当なら、顧客を追加し、商談を更新し、過去の会話を検索し、フォローアップを作成するかもしれません。マネージャーなら、同じ商談を確認し、アカウント設定を編集せずに割引を承認するかもしれません。

各役割が日々の仕事を完了できること、制限された操作が利用できないこと、機密項目が権限のない人から隠れていることを確認します。十分な数のレコードを用意して、少し複雑になった状態で検索、絞り込み、エクスポート、レポート、モバイル画面もテストしてください。

権限テストでは、メニューボタンがないことだけを確認してはいけません。一般従業員が請求書を削除できないはずなら、その従業員としてログインし、請求書が表示されるすべての画面から削除を試みます。アプリは操作を止め、理由を説明する必要があります。

顧客名の重複、古い完了済みレコード、空の任意項目、数か月にまたがる日付、長いメモを追加します。「Smith」で検索し、ステータスで絞り込み、レポートを並べ替え、同じ結果をスマートフォンで開きましょう。サンプルが少ないと、レコードが増えたときの遅いページ、分かりにくいラベル、機能しない絞り込みが隠れてしまいます。

権限レベルごとに別のテストアカウントを作り、1つのログインを共有しないでください。アクセスの問題を再現して修正しやすくなります。

実際の業務データを取り込む前に、すべてのテストアカウントとサンプルレコードを削除します。テスト用のメールアドレス、電話番号、添付ファイル、エクスポートも消えていることを確認してください。その後、展開時の既知の出発点になるクリーンなスナップショットを作成します。

次のテストに向けて準備する

テストは、ローンチ前に一度だけ行う作業ではなく、繰り返すサイクルとして扱いましょう。顧客レコードを作成し、担当者を割り当て、ステータスを更新するなど、スタッフがよく使うワークフローを1つ選びます。すべての画面に無作為なサンプルデータを入れるのではなく、意味のある変更のたびにその流れをテストしてください。

架空のレコードを再利用できるセットとして保管します。通常の顧客、連絡先が2つある顧客、期限超過の請求書、重複して見える名前、任意項目が未入力のレコードなど、それぞれに目的を持たせます。同じデータを使えば、期待される動作の変化を見つけやすくなります。

セットを共有の場所に保管し、各テストの期待する結果を記録します。アカウントマネージャーは顧客の電話番号を編集できるが、給与項目は見られない。経理担当者は請求書を見られるが、顧客レコードは削除できない。このように短く期待値を決めておけば、結果がバグかどうかで議論する必要が減ります。

次のバージョンを作る前に、Koder.aiの計画モードを使いましょう。スタッフの役割、正確な作業、編集できる項目、入力ルールを説明します。例えば、次のように書けます。「サポート担当者はチケットを作成し、顧客を選び、メモを追加し、優先度を設定できる。別のチームに割り当てられたチケットは終了できない。件名を必須にし、フォローアップの電話には過去の日付を設定できないようにする。」

計画が実際の仕事を反映してから変更を作ります。その後、間違った入力も含め、架空のレコードでワークフローを繰り返します。大きな変更の前にはスナップショットを作り、少人数のグループに新しいバージョンを試してもらいましょう。問題が起きたら、修正する間にロールバックします。

簡単なテスト記録には、日付とバージョン、使用したワークフローとレコード、期待した結果と実際の結果、テスター、今すぐ修正するか、後で見直すか、そのままにするかの判断を含めます。権限、項目、ワークフローを追加したら、スタッフが頼る前に関連するケースをもう一度実行しましょう。