業務テスターにわかるテストケースの書き方

業務テスターに別のテストケースが必要な理由

システムテストは、システムを構築した人やシステムをよく知る人が行います。ユーザー受け入れテストは、システムを使う人が行います。彼らは仕事のことは知っていますが、設定のことは知りません。どの項目が新しいのか、どのフローがバックグラウンドで動いているのか、開発者が何を意図したのかは知りません。

そのため、UAT のテストケースは次のような人に通用するものでなければなりません。

• 業務プロセスは熟知しているが、新しい画面は知らない。
• 他の仕事の合間に数時間しかなく、1 週間はない。
• ステップが合格か不合格かを推測しなければならない状況にあってはならない。
• ステップがわかりにくいと、手を止めて待ってしまい、時間を失う。

わかりやすいテストケースに費やした 1 時間は、テスト日の何時間もの節約になります。質問が減り、誤解だったとわかる課題が減り、go/no-go で信頼できる結果が得られます。

ユーザーストーリーとプロセスから

テストケースの作成元は 2 つあり、その両方が必要です。

ユーザーストーリーとその受け入れ基準

ユーザーストーリーは、誰が何をしたいのか、そしてその理由を表します：営業担当者として、取引先、取引先責任者、商談を得るために、見込みの高いリードの取引を開始したい。受け入れ基準は、いつ完了とするかを表します。各受け入れ基準は、ステップやテストケースの候補になります。

カバレッジを確認します。対象範囲のすべてのユーザーストーリーには、少なくとも 1 つのテストケースが必要です。テストケースのないストーリーは抜け漏れであり、抜け漏れは本番環境で見つかります。

業務プロセスをエンドツーエンドで

ユーザーストーリーは開発者向けに小さく分けられています。業務部門は、多くのストーリーにまたがるプロセスで仕事をしています。リードから入金、見積から注文、メールから解決までのケース管理などです。ストーリーは単独では合格しても、2 つのチームの間の引き継ぎでプロセスが壊れることがあります。

そこで、プロセスを最初から最後まで、ロールをまたいでたどるエンドツーエンドのテストケースを加えます。営業担当者が見積を作成し、マネージャーが承認し、注文が経理に渡る、といった流れです。業務部門にとって最も重要なのは、多くの場合こうしたテストケースです。

UAT Studio ではUser stories カードで Jira や Azure DevOps のユーザーストーリーを読み込み、Only stories without test cases にチェックを入れると抜け漏れがわかります。AI test design モジュールでは、AI がストーリーやプロセスの説明からテストケースを提案します。自社のモデルでも実行できます。承認するまでは何もテストケースになりません。モジュールがない場合は、Prepare with your own AI で、自社の AI に貼り付けるプロンプトが得られます。[CHECK] の付いたステップは、確認が必要な仮定です。

テストケースごとに 1 つの目的

テストケースは、1 つの業務シナリオを 1 つの目的でテストします。タイトルには、テスターが達成することを業務の言葉で書きます。

• 既存の取引先でリードの取引を開始する
• 20% を超える値引きのある見積を承認する
• 既知の顧客からのメールを適切なキューに振り分ける

リードオブジェクトをテストするやリード、商談、見積ではありません。1 つのテストケースに複数の目的があると、1 つの不合格がすべてをブロックし、結果からはほとんど何もわかりません。何が不合格で、何はまだ動くのでしょうか。

1 つのテストケースの大きさは？

目安として、テストケースのステップは 3～15 個で、テスターが 5～20 分で終えられるものです。それよりずっと長いなら、おそらく目的が 1 つではありません。分割してください。ずっと短いなら、隣のテストケースとまとめるべきかもしれません。

エンドツーエンドのテストケースは例外です。プロセス全体をたどるため、長くなってもかまいません。それは残しつつ、プロセスの各部分にもそれぞれ短いテストケースを用意し、不合格の箇所を特定しやすくします。

期待結果付きのステップ

各ステップは 2 つの部分から成ります。操作（テスターが行うこと）と期待結果（起きるべきこと）です。ステップをテスト可能にするのは期待結果です。期待結果がないと、何をもって十分とするかをテスターが決めることになり、テスターによって判断が分かれます。

操作を書く

• 1 つのステップに 1 つの操作。リードを開き、取引の開始 をクリックするは問題ありませんが、1 つのステップに 5 回のクリックは多すぎます。
• 動詞で書きます：開く、クリックする、入力する、選択する、保存する。
• 画面上のラベルをそのまま使い、太字またはかぎかっこで示します。
• システム内部の仕組みではなく、何をするかを書きます。承認フローを起動するではなく、見積を保存する。

期待結果を書く

• テスターに見えるものを書きます：メッセージ、項目の値、新しいレコード、ステータス。
• 具体的に書きます。動作するではなく、商談のフェーズが Qualification になっている。
• 重要な場合は、起きてはならないことも書きます：2 つ目の取引先は作成されない。
• システムが自動で行うことについては、どこを見ればよいかを書きます：1 分以内にケースがキュー Benelux Support に表示される。

テストデータとロール

テストデータ

UAT でテスターが最も時間を失うのは、データ探しです。重要な箇所には、テストケースにデータを書き込みます。どの顧客か、どの商品か、どの価格表か、どの金額か。そのデータは、最初のテスト日の前にテスト環境に準備しておきます。

• Jansen Logistics (test) のように、テストデータだと明らかにわかる名前を使います。
• データを変更するテストでは、テスターごとに専用のレコードを用意し、2 人が同じ商談を編集しないようにします。
• 境界の値を加えます：上限のすぐ下とすぐ上の値引き、空のままの必須項目。
• 避けられる場合は、顧客の実際の個人データを使わないでください。

ロール

CRM では、ユーザーが何を見て何をできるかはロールによって決まります。Salesforce ではプロファイルと権限セット、Dynamics 365 ではセキュリティロールと部署です。UAT では、各ロールが自分の仕事をこなせること、そして自分の仕事しかできないことを証明します。そのため、すべてのテストケースにどのロールでテストするかを書き、テスターはちょうどそのロールを持つテストユーザーでサインインします。

管理者では決してテストしないでください。管理者はすべてを閲覧でき、すべての操作ができるため、UAT で見つけるべき問題が隠れたままになります。

UAT Studio では各ステップには、操作、期待結果、必要に応じてテストデータがあります。テスターごとに Test role と Test account が割り当てられ、テストの上部に Log in as … として表示されます。また、テスターが登録するすべての課題で、名前の横にそのロールが表示されます。

優先度とリスク

すべてを同じようにしっかりテストする時間は決してありません。重要なものが先にテストされ、時間が足りなくなっても終わるように、各テストケースに印を付けます。

その横にリスクを加えます。本番稼働後にうまくいかなかった場合の損失です。請求書の価格の誤りは高リスク、レポートのラベルの誤りは低リスクです。同じ優先度の中では、テスターは高リスクのものから始めます。

Must は厳しく付けてください。テストケースの半分が Must なら、そのラベルには意味がありません。業務部門がなくては困るものだけに使います。優先度はプロセスオーナーと合意します。オーナーは go/no-go でも判断を下し、そこでは合格していない Must のテストケースが最も重く扱われます。

UAT Studio ではPriority（Must、Should、Could）と Risk（High、Medium、Low）を、エディターで、またはインポート時に列として設定します。他のツールの値も読み取れます：Critical と High は Must、Medium と Normal は Should、Low は Could になります。テスターには Must のテストケースが最初に表示され、各優先度の中では高リスクのものが先に表示されます。

例

テストケース 12：20% を超える値引きのある見積を承認する

優先度 Must、リスク High。ユーザーストーリー CRM-118。ロール：営業担当者（ステップ 1～3）と営業マネージャー（ステップ 4 と 5）。

うまくいく理由に注目してください。タイトルに 1 つの目的、1 つのステップに 1 つの操作、テスターが確認できる期待結果、明記されたデータとロール、そしてステップ 3 のうまくいかないケースです。上限を下回る値引きについて、承認が不要であることを確かめる 2 つ目のテストケースを追加しましょう。

よくある間違い

• 期待結果がない、または期待どおりに動作する。何が期待されていたのか、テスターが推測しなければなりません。
• 技術的な言葉。データベースの項目名、オブジェクト名、トリガーが起動することを確認するなど。画面上の言葉を使います。
• 1 つのテストケースに目的が多すぎる。1 つの不合格が残りをブロックし、結果からほとんど何もわかりません。
• 正常系だけ。空のままの必須項目、上限を超える値、レコードが見えてはいけないユーザーを加えます。
• テストデータがない。商談を開く：どの商談？ どのフェーズで、どの商品の？
• ロールがない。テスターは手元にあるアカウントを使ってしまい、それは多くの場合、権限が多すぎるアカウントです。
• システムテストからのコピー。開発者向けに書かれており、業務テスターがたどれないステップになっています。
• すべてが Must。それでは何も Must ではなくなり、重要なテストが先に行われません。
• 一度書いたきりで、誰も読まない。テスト日の前に誰も確認しなかったスクリプトは、古いラベルや誤ったメニューだらけです。

キーユーザーにレビューしてもらう

テスト日の前に、業務部門のキーユーザーにテストケースを読んでもらい、テスト環境でそのうち 2～3 件を試してもらいます。書いた本人には見えないものが見つかります。前提知識を必要とするステップ、変更されたラベル、別の国では異なる流れになるプロセスなどです。

同時に、対象範囲のすべてのユーザーストーリーにテストケースがあること、対象範囲のすべてのロールが何かをテストすること、テストデータが存在することを確認します。そして本番稼働後もテストケースを残しておきます。それが次の CRM リリースの回帰テストになります。

UAT Studio ではExcel、Azure DevOps、Xray または Zephyr Scale を使った Jira、TestRail からテストケースを取り込むか、エディターで作成します。テンプレートライブラリ（すべての有料プランに追加できるアドオン）には、自社の設定に合わせて変更できる Salesforce と Dynamics 365 の既製スクリプトがあります。

無料で使える

UAT の前、最中、後に準備すべきその他のことについては、CRM 本番稼働のための UAT チェックリストをご覧ください。こちらも無料の Excel ファイルで提供しています。