はじめに
「テスト仕様書を初めて作成する人にどうやって指導していますか？」
ある日、別チームのベテランプログラマから聞かれました。
テスト経験のない新人さんにテスト作業がどんなもので、どうやるのかを教えたい、最終的にはケースが作れるようにしたいとのこと。
OJTに入る前にもう少し全体的というか、実践の前に知っておくと良いようなものはないかという相談を受けたので、以前、私自身がJSTQBの資格取得のために勉強した時の資料や自チームの新人さんに説明するときに使った資料から、実践につながりそうな部分を抜き出してまとめました。
ベースはJSTQBのシラバスのはずですが、実際の作業については私独自のやり方になっているところもあると思います。こういうやり方もあるよ、という一例としてみていただければと思います。
良いテストケース
良いテストケースとは何でしょうか？
一般的には以下のように言われています。
- テスト対象の要素（機能など）を漏らさず、網羅している
- バグが検出できる
- テストケースの数がより少ない（コスト・期間がより低く抑えられる）
こうしたテストケースを作るために、テストケース作成時に押さえておくポイントを明確にしておきましょう。
また、実際にテストが始まってからあるいは終わってから、実はあれが足りないとかになると手戻りが大きいので、レビューは早い段階から行っておいた方がよいです。
1.分析
テスト対象の分析
-
テストベースを明らかにする。
テストベース＝テストケースを作成する際に根拠とするもの。例えば要件定義書、システム仕様書（設計書）、プロダクトリスクなど -
テストベースを分析・整理して曖昧なことや抜け漏れがないかをチェック
システム仕様書や設計書からテストケースを作成することが多いですが、そもそも設計書に書かれていることで要件・要求を満たせるのかという視点も必要です。
品質管理の観点からすると一番基にするべきなのは顧客の「期待通り」かというところです。
自分の中でストーリーを作る
エンドユーザーは何の目的でこのシステムを使うのかを念頭におき、実際にどう使うのか、どこにどんな値が入るのか、どんな結果が欲しいのかを考えるようにします。ユーザー目線でテストケースを作成することで、仕様のダブルチェックにもなります。
2.設計
テスト基本設計
「そのシステムには（または機能には）、どんなテストが必要か」というレベルで、テスト全体の指針を決めていきます。
- テスト対象範囲の確認
テストに使うデータや環境、実行方法（DB/OS/ブラウザ/ツール…）はどんなものが必要か - テスト項目の定義（要求・機能仕様とのマッピング）
機能的な抜け漏れの確認、矛盾がないか →ここで開発範囲もかなり明確になるので、スケジュールや予算に無理がないかチェックできる
網羅性を気にする／効率を気にする
○○はいらないんですよね、という合意を取る＝範囲の確定を意識しましょう。
やることのリストから抜けているものをあえて指摘して、テストする範囲を明確にします。また、同じことを繰り返さないように、同値分析やデシジョンテーブルなどのテスト技法を利用してテストを効率化します。
同じような画面/機能についてまとめておく
同様の機能、共通部品（エラーメッセージの表示、グリッド、ページング、ナビゲーションバーなど）がある場合は、システム全体で統一感があるかチェックし、同じものとして省けるテストがないか適宜プログラマに確認します。
テスト詳細設計
テスト基本設計を詳細化（例えば、テキストボックスの入力チェックで、どのような文字種・文字数でテストするかなど。）します。
テストベースを見て、実際にどんなデータを作ってどんな値を入力してテストする？と考えます。
抽象的な設計書を具体化していく作業になるので、この時に細かい疑問点がたくさん出てきて、矛盾に気が付いたりもします。
ここまでに、テストケースの粒度についてもきめておきましょう。
ケースの粒度（論理的ケースと具体的ケース）
テストケースを作成するときに、どこまで具体的（詳細）にするか、という問題があります
論理的テストケースと具体的テストケースにはそれぞれにメリット・デメリットがあります。状況やテスト実施する人に合わせて検討してください。
| 具体的テストケース | 論理的テストケース | |
|---|---|---|
| 提供するもの | テストケースを実行し結果を検証するために必要な特定の情報と手順のすべて | テスト対象とすべきものに関するガイドライン |
| 実データや手続きの変更 | 不可 | 可能 |
| 再現性 | 優れた再現性 | 再現性が失われる可能性がある |
| 適する場面 | テスト担当者の経験が少ない場合 監査などテストの外部検証が必要な場合 | 要件が適切に定義されていない場合 実行するテスト担当者がテストとプロダクトの両方に精通している場合 公式なドキュメントが必要でない場合 |
| メリット/デメリット | メンテナンスに非常に多くの労力が必要 実行時にテスト担当者の創造力を制限する傾向 | 属人的になりがち 各実行時での変更を許容するので、具体的テストケースよりも優れたカバレッジ（網羅性）を提供することがある |
3.実装
以下のことを明確にしてテストケースを作成します。
| 目的 | 何を確認するためのケースなのか（テスト観点） |
| 事前条件(Preconditions) | プロジェクトまたはローカルのテスト環境が要求するものとそれの受け渡し方、システムの状態など |
| 必要なテストデータ | テストケースを実行するための入力用データとシステム内にセットしておかなければならないデータの両方 |
| 期待結果 | どうなるべきなのか |
| 事後条件(Post-conditions) | 影響を受けるデータ、システムの状態、後続処理のためのトリガーなど |
同じような画面や機能についてはコピー＆ペースを活用するようにすると手間が省けるうえに機能毎での差異の明確化やダブルチェックにつながるのでお勧めです。
併せて、テストデータの作成やテスト環境のセットアップを行い、テスト実施の準備を整えます。
テストケース作成時には分析→設計→実装に向かって詳細化していくのですが、実際の作業として特に分ける必要はありません。
詳細設計と実装は同時進行で進むことが多いです。詳細化するときに疑問が湧く→テストベースを確認する→曖昧・矛盾を見つける→設計者・顧客に確認→設計書修正 のように、実際には行きつ戻りつしながら進みます。
終わりに
システム会社でテストを始めて早云十年、この業界に来た新人さんに、一番お話ししておきたいことで締めくくりたいと思います。
顧客の要求を鵜呑みにしてはいけない
システム発注の際はシステム部門やシステムに強い（と思われている）人で臨時に編成されたチームが取りまとめをしていることがあり、結果として現場の実態をわかっていない人が要求をまとめていた、ということがよくあります。また、現場はシステムやコンピュータになじみがない人も多く、そもそもシステム化する際に伝えなければならないことが何であるかわからず、的確に伝えることができていないということもあります。
そんな時、要求としてまとめられたものが現実から乖離してしまっている、ということはそれが些細なことであればあるほど多くあります。
発注を受ける側としては、発注された通りのものを作成して納品すればよいと言えなくもないですが、使う側からすればどうしても不満が残ります。
要求がシステムとして具体化されたときにそれが実用に耐えるのかを検証するというのも、テストの大事な側面のひとつです。