テストケースの書き方｜ログイン画面の記入例とテンプレート

操作の手順が書けても、正常な状態がわからなければ合否を決められません。そこで、先に確認する機能と、使う仕様の版を決めます。何ができれば「正常に動いた」といえるのかを確認すると、操作と期待結果をつなげて書きやすくなります。

以下の仕様と記入例は、練習用に作った架空のものです。実際のサービスの仕様やテスト結果ではありません。メールアドレスは例示用の値にし、パスワードは検証環境の管理先を参照する書き方にしています。

画面が切り替わったところで確認を終える人もいれば、表示名まで見る人もいるかもしれません。この例の仕様では、本人のマイページと表示名を確認します。必要な条件、操作の順番、期待結果を分けて書き、ログアウト状態から判定までの流れがわかるようにします。

条件をそろえるには、「正しいパスワード」がどれを指すかも必要です。チームで管理するテストデータの識別子や参照先を書けば、実際の認証情報を公開するシートに載せずに、使うデータを伝えられます。

この仕様には、空欄や認証の不一致をどう扱うかも書かれています。そのため、メール空欄、パスワード空欄、パスワード不一致の3件を足します。正常系のケースをコピーするときも、変えた条件を明記します。ほかの条件はできるだけそろえ、各ケースを始める前にログアウト状態へ戻します。

この4件だけで、ログイン機能全体を確認できるわけではありません。仕様に書かれていないロックや利用停止ユーザーの扱いは、担当者に確認してから追加します。ダウンロード用の記入例には、4件それぞれの前提・操作・期待結果を省略せず載せています。

前提条件、操作、期待結果を書く場所が決まっていれば、必要な情報を探しやすくなります。文章で管理する場合にコピーして使えるよう、次のテンプレートにまとめました。表で管理する場合は、冒頭のCSVをダウンロードして、1ケースずつ行を追加できます。

使わない欄が多ければ、記入の負担も増えます。項目を減らすときは、何のための欄なのかをチームで確認してから調整します。

期待結果を実際の動作に合わせて書き換え、合格にしてしまうと、仕様との違いが残りません。期待結果は残したまま、実際にどう動いたかと、その違いを別の欄に記録します。

結果を共有するには、判定の意味もそろえる必要があります。このテンプレートでは、下の表の意味で判定を使います。管理ツールなどですでに定義している場合は、そちらに合わせます。

書いた本人は、使うデータや操作の前提を知っています。その情報を省略していても、自分で読み返すだけでは気づきにくいことがあります。下の項目で内容を確認し、書いた人以外に最初の1件を試してもらうとよいと思います。

そのときに見たいのは、補足の説明なしで進められるかどうかです。迷ったところを聞けば、どの条件や手順を書き足す必要があるかを考えやすくなります。

同じ条件を用意でき、操作の順番を追えて、仕様を根拠に合否を決められること。この3つが、詳しさを考える目安になると思います。まず一つの機能で試し、テストする人やレビューする人が困った箇所を直していきます。同じ項目を同じ場所に書くと、担当者の交代や不具合調査でも情報を探しやすくなります。項目を増やしすぎないよう、記入の負担も見ながら調整します。

必要な項目は用途によっても変わります。探索的テストなら目的・範囲・リスクを書くチャーター、性能テストなら負荷条件などが必要です。共通の項目を決めたうえで、用途に合わせて調整します。過去のケースは、再利用するときに新しい書式へ移しても構いません。