はじめに
現在のソフトウェア開発において、開発とQAは密接な関係にあります。
それこそ、手を取り合ってプロジェクトを進めていくのが基本となりつつあります。
しかし、開発の専門性が高いようにQAも専門性が高く、用語や意図がわからない場面は多々あるでしょう。
そんな方のため、用語の解説を行っていくシリーズです。
また、本記事は私の独断と解釈によるまとめですので、一部事実と違う点があるかもしれませんが、その際はご指摘ください。
「テストケース」のざっくりとした解説
「テストケース」の概要
普段から何気なく使っている「テストケース」というモノは、何を指すのか具体的に定義があります。
意外とふんわり使っていますが、その一部を以下に記載します。
- テストで確認すべき内容や目的を記載したもの
- テストの条件
- テストの実行手順
- テストの期待値
etc...
つまるところ今この現時点でテストを実施するのに必要なすべての情報を指します。
特にミソなのは「今この現時点」という、4次元的表現が含まれる点です。
何故ならば、テストは「実行したら終わり」ではないからです。
「テストケース」の詳細な解説
品質関連書籍からの引用
まずは私自身の言葉で説明するよりも正確性を大事に、世に出ている公的な書籍から引用します。
- ソフトウェアテスト教科書JSTQB Foundation 第2版
テストケースの構成要素は、入力データ群、実行条件、期待する結果、実行後に期待する状態からなります。
- シラバス2018対応JSTQBFoundation教科書＆問題集
テストケースとは、ソフトウェアテストを実行する手順やデータ、期待される結果などをリスト化したものです。
また、そもそも「テストケースを作成するために作成されるもの」も必要です。
- 要件とのトレーサビリティ（どのテストが何と紐づくのか）
- 機能の仕様書
- テスト計画（テストケースそれぞれの内容や目的）
などなど、テスト設計の話に踏み入れると本筋から大きく脱線するので割愛しますが、まだまだ多くのモノが必要です。
「この機能設計、なんでこうなってるのかコード見ても意図がわからんな」
と
「このテスト、なんでこうなってるのかテストケース見ても意図がわからんな」
は同じです。
ということで、上記を整理すると、
- テスト設計に必要なモノたち
- 実行条件（前提となるデータや実行に利用するデータ等含む）
- 実行手順
- 期待結果
という4つに大きくは分類されます。
また、ここで指しているテストケースとは一般的に「ローレベルテストケース」と呼ばれるものです。
超具体的な内容を取り扱う、ということです。
抽象的になると「ハイレベルテストケース」と呼ばれます。
それらの説明は一旦置いておきます。
テストケースの「設計」
テストケースを設計するために利用したモノたちです。
前述の通り、テスト設計は大きな別単元ですので、簡略化します。
redmineなどのチケット運用をしていれば、問題となる箇所や修正後の動作がかかれています。
不具合修正だけでなく、機能の改善や強化を行ったのであれば、機能の仕様変更ですから、既存の手順書に変更が加わります。
テストケースを作成するための「条件」「手順」「期待結果」などの判断材料は、すぐに確認できるようにする必要があります。
テストケースの「実行条件」
そのテストを実行するために必要な条件です。
例えば、テストに使うアカウントやデータ、設定、テストをする環境の指定などです。
そして、それらのデータや設定が一般的でない場合は、それらの準備する方法も用意が必要です。
必要なデータを挿入するためのSQLを準備したり、スマートフォンなどの端末が必要ならそれらの利用申請を行う資料へリンクを貼っておいたり、クラウド環境なら起動のための諸操作を書いておいたりetc…。
必要な前準備は書いておきましょう。
また、これらの情報のうち、環境周りについては「構成管理」の観点からも有用です。
クラウド環境で利用するAMIによってエラーが出る、OSバージョンは同じでも端末が違うからエラーが出た等々……。
「このテストって正確にはどんな条件で実施していたんだ？」が後からわかる証左にも使えます。
テストケースの「実行手順」
テストケースと聞いて思い浮かぶ最たるものでしょう。
「どのように操作すればよいか」が書いてあるものです。
ここを厳密に書いておくことで、そのシステムを詳しく知らない人でもテストすることができます。
また、そのシステムの利用説明書などがあれば、それを参照するように、と指示することも可能です。
主たる目的は「誰が見ても操作できること」です。
それを良しとするかは置いといて、小さいチームで全員が良く把握しているのであれば、細かい手順が省略されていても成り立ちます。
しかし、暗黙知を利用するため、チーム外の人が見たり、数年後に見返すとわからなくなることがあります。
細かく書きすぎると、ちょっとでもシステムが変わると編集が必要になる。
大まかすぎると、詳しくない人がテストを実行できなくなる。
バランスが大事です。
テストケースの「期待結果」
テストのミソです。
「どうなっているべきか」を書いてあるものです。
これは一般的に、具体的であればある方が良いです。
「数値が正しいこと」「全体的に問題ないこと」
ではよくありません。
他の人が見た時に、具体的にどうだったのかわからないからです。
「このケースでは「400」と表示されること」「このケースなら「400.00」と表示されること」
「ヘッダーのレイアウト崩れが起きないこと」「言語を英語に変更した時、文字列がボタンからはみ出ないこと」
といったように、超具体的に書いておくべきです。
ここで重要になってくるのが、先述した「実行条件」の特にデータです。
具体的な期待値は、データの内容と紐づいていることが多く、どちらかの情報が欠損していると後日のテスト再現の難易度が急上昇します。
データを毎回準備できない場合は、
「元データの数字がそのまま表示されること（今回は400）」「元データの数字を有効桁数2桁で表示されること」
といったような書き方をする必要があります。