テスト設計ではテストケースを作成する。テストケースの記述の仕方を少し変えるだけで、その後のトラブルリスクを低減できる。

「なぜこの値を入力するのか」を明確にする

 テストケースには、テスト対象の項目、テスト条件、テスト手順などを記載する。このうち、テスト条件の書き方に、その後の工程をスムーズに進めるための小ワザがある。テスト条件の欄に「なぜこの値を入力するのか」を明記しておくのだ。

 例えば、ECサイトのテストで商品購入の機能をチェックするとしよう。商品を選択したうえで購入ボタンを押したとき、きちんと在庫チェック機能が動くかを試す、といった趣旨のテストである。

 このときのテスト条件に「購入する商品:商品A」としか書かれていないことがある。これでは「なぜ商品Aを選択しなければならないのか」がテストケースの読み手に伝わらない。意図がドキュメントから読み取れないと、テストケースのレビューの効率が落ちる。レビュアーが確認すべき項目が増えてしまうからだ。

 もし、レビューを通り抜けてしまうと「妥当性が不明なテストケース」が出来上がる。すると、テスト実行フェーズで確認すべき事項の抜け漏れが発生しやすくなる。

 それだけではない。リリース後の改修時に、何をテストしたのか過去のテストケースを参照するときもある。テストの意図が分からなければ改修の役に立たない。

 こうした事態を防ぐための小ワザとして、入力値の持つ意味を書いておくのだ。例えば、「購入する商品:翌日お届けが可能な商品(商品A)」「購入する商品:翌日お届けが不可能な商品(商品B)」といった具合だ。こうすれば読み手に意図が伝わり、手戻りや誤解を避けられる。

期待値に「処理が正しいこと」と書いてはいけない

 テストケースには、どのような結果になっていれば合格なのかを分かるようにするため、期待される結果を示す条件や値を記載する。この項目を「期待値」と言う。

 期待値でよく見かけるのが、「処理が正しいこと」「問題がないこと」といった表現だ。

 しかし、これらの表現は異なる解釈を与える余地がある。読む人によって様々な意味に捉えられてしまうのだ。

 もし、テストケースを記述したエンジニアとテスト実行者とで、想定している「正しい処理」に食い違いがあれば、トラブルにつながる。

 例えば、エラーメッセージの扱いだ。エラーメッセージが表示されることが正しい場合もあるし、エラーメッセージが表示されないことが正しい場合もある。テストケースの作成者は、エラーメッセージが表示されることを想定して「処理が正しいこと」と記載したとする(図1)。

図1●テストケースの期待値に「処理が正しいこと」と書くと誤解を招きやすい
[画像のクリックで拡大表示]

 しかしテストしたところ、何のエラーもなく処理が完了してしまった。テストケース作成者の意図としては、この場合は「誤った処理」なのだが、期待値の欄に「処理が正しいこと」としか書いていなければ、テスト実行者は「正しい処理」と判断してしまう。テスト実行者が合格と報告すれば、見つかるはずの不具合が見逃される。

 期待値で誤解を生まないためには、期待される処理の内容を具体的に書くべきだ。先ほどの例では、「『在庫切れのため購入できません』とエラーメッセージダイアログ画面が表示されること」といった内容にする。こうすれば、何が正しい処理なのか読み手に誤解を与えにくい。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら