はじめに
お題は不問！Qiita Engineer Festa 2023で記事投稿！の参加記事になります！
ソフトウェアの品質確保にはテストは欠かせません。
テストを実施する前には、テストケース（≒テストのための資料）を作成することがほとんどかと思います。
会社やプロジェクトによってテストケースの書き方は様々かと思いますが、広い範囲で取り入れることができそうなテクニックについて3つまとめました
3つのテクニック
1. そのデータにする目的を明確にする
例えば、通販サイトにて「ご利用ポイント」をテストする際、テスト条件に「ご利用ポイント：1000円」としか書かれていないことがあります。
これでは、なぜご利用ポイントを1000円とするのか読み手に伝わりません。その結果、以下のような問題が発生します
- テストケースのレビューが非常にやりにくい
- テスト実施者は何を目的としたテストなのかが分からない
（テスト実施者＝テストケース作成者とは限らない）
このような問題を防ぐため、そのデータにする目的を明確にするのが効果的です
- ご利用ポイント：900円（所有ポイントより少ない）
- ご利用ポイント：1000円（所有ポイントと等しい）
- ご利用ポイント：1100円（所有ポイントより多い）
こうすれば読み手に意図が伝わり、手戻りや誤解を避けることができます。
2. 期待値は具体的に書く
期待値でよく見かけるのが、「処理が正しいこと」「問題がないこと」といった表現です。
このような表現は非常に曖昧であるため、読む人によって様々な意味に捉えられてしまいます。
例えば、「ご利用ポイントの範囲内であれば、買い物ができる」という仕様があったとします。
テストケース作成者は、期待値を以下のようにしたとします。
- ご利用ポイント：900円（所有ポイントより少ない）
- 期待値：処理が正しいこと
これをテスト実施したところ、買い物が完了してしまいました。
テストケース作成者の意図としては、買い物ができてしまったため「誤った処理（バグ）」ですが、テスト実行者は「正しい処理」と判断してしまう可能性があります
期待値で誤解を生まないためには、期待値は具体的に書くべきです
- ポイントが不足している旨を通知するエラーダイアログが表示されること
こうすれば読み手に誤解を与えにくくなります。
3. 「～できること」が出てきたら「～できないこと」を考える
仕様でよく見かけるのが「～できること」のような表現です。
例えば、「管理者ユーザーは、管理画面にアクセスできる」という仕様があったとします。
多くの人は「管理者ユーザーでログインして、管理画面が閲覧できる」といったテストケースを作ると思います。
しかし、このケースだけでは不十分です。一般ユーザーが管理画面にログインできてしまうかもしれないからです
これでは不具合を見逃してしまう可能性があります
この場合は、「一般ユーザーでログインしたときは、管理画面にアクセスできないこと」を確認するテストケースを作るべきです。
仕様書から、表面的な文章だけを参考にしてテストケースを作ると、必要な検証が漏れてしまいます。
そうならないため、「～できること」を確認するテストケースを作ったら、セットとして「～できないこと」のテストケースが必要かどうかを必ず考えるべきです
おわりに
- テスト実施者＝テストケース作成者になるとつい記述を簡略化してしまいます
- しかし忘れた頃にまたテストケースを使用するかもしれません
- 「後々皆が楽するために、今もうちょっと頑張る」ということをできるようにしていきたいですね