現場で「テスト計画作成」というタスクが割り当てられたら、何をすれば良いのでしょうか？
この内容で現場のレビューが通ったという私の体験談を記載します。
テスト計画書に書いたこと
- 目的
- テスト対象（範囲）
- テスト工程定義
- 工程の観点
- 工程のインプット
- 工程のアウトプット
- 工程の完了条件
- 工程の使用環境
- 工程の実施者／確認者
目的
そもそも何のためにテストをするか？です。
「〇〇を確認するためにテストを実施する」という本文になります。
- ▲▲ができるようになっていること
- ▲▲が修正されていること
- ▲▲が達成されていること
などが○○の部分にはいるでしょう。
テスト対象
テスト対象とするシステムの機能を定義します。
案件によって、システム全体をテスト対象とするのか、
特定の機能のみをテスト対象とするのか変わってくるものです。
ここでは、後に続くテスト工程がどの機能を範囲とするのかを明示しておきます。
テスト工程定義
テスト工程定義が、テスト計画作成で最も頭を使うところです。
テスト工程といえば、現場によって、
・単体テスト（UT）
・結合テスト（IT）
・システムテスト（ST）
・受け入れテスト
などさまざまな工程があります。
テスト計画の対象を、今回の案件ではどの工程まで実施するかを定義していきます。
工程の観点
工程の観点は、工程の目的であり、非常に大事です。
単体テストであれば、
「プログラムが期待通りに動作することを確認する」
が主な観点になるでしょう。
結合テストであれば、
「○○機能が期待通りに動作することを確認する」
になります。
システムテストであれば、
「○○システムが要件を満たすことを確認する」
になります。
受け入れテストは、
「○○システムが業務を実施できることを確認する」
になります。
工程のインプット
テストケース作成のインプットとなる資料を記述します。
多くの場合は、
・要件定義書
・基本設計書
・詳細設計書
・〇〇定義書
この辺りがインプットになります。
テストケースを作成するときに、上位ドキュメントがないとケース作成のしようがありません。
逆にいいうと、この工程ではこのドキュメントの内容を検証するんですよ。
という提示になります。
工程のアウトプット
この工程によって作成される成果物を定義します。
アウトプットとしてはまず「テストケース」が必要です。
テスト計画は「計画」ですから、テスト全体の工程や各工程の観点を定義するタスクです。
それとは別にテストケースを別途作成する必要があります。
普通、テスト計画でテストケースを作成する必要はありません。
そして、テストケースを作成しただけでは意味がないので、
「テストケースに実施結果を記入すること」と書いておきます。
工程の完了条件
何をもってこのテスト工程を完了とみなすかを記述します。
多くの場合は、アウトプットで作成される「テストケースが全てOKとなること」となるでしょう。
場合によっては、全てOKとならずとも次の工程に進む場合もあるので、
その条件を記述しておきます。
工程の使用環境
どの環境でテストを実施するのか記述します。
単体テストはローカル環境、結合テストは検証環境、システムテストはステージング環境、受け入れテストは本番環境。
といった具合です。
また、
・◯○の部分はモックサーバーを使用する。
・○○の部分は検証環境を使用する。
のような条件をつけないと実施できないテストケースも出てくるので、
計画段階で予めそれを想定して記述しておきましょう。
工程の実施者／確認者
テストケースに記述されている各ケースを動かすのは誰か（実施者）、
実施者の実施結果にOK/NGを付けるのは誰か（確認者）を定義します。
テスト工程の最初の方は、
実施者＝確認者となることが多いと考えています。
単体テストなんかは、プログラミングした人が、実施して自分でOK/NGをつけるので、実施者＝確認者となるでしょう。
システムテストでは、
動かすのはエンジニア、確認するのは現場担当者ということもあるかもしれません。
日程
既にテスト日程が組めるようであれば、「いつからいつまでにこの工程を実施する」と記述しても良いでしょう。
ただし、WBSやBacklogなどでスケジュール管理されていたり、設計が進んでおらず日程が未定の場合は、日程を書く必要はありません。
テスト工程の考え方
あなたの開発で必要なテスト工程を考えてみましょう。
まず、最初にやるべきは、単体テストでしょう。
これは、プログラミングが設計通りにできていることを検証するものです。
最下位の設計書の単位で実施するのが進めやすいでしょう。
最後にやるべきは、受け入れテストです。
受け入れテストとは、そのシステムを使う人が、期待する結果を得られるか、目的を達成できるか？を検証するものです。
これがないと、システムを作ったはいいけど、誰も喜ばなかった＝使われないということになっちゃいます。
そのため、本来は必ずやるべきテストです。
（ですが、あまりお目にかかることはないです。
なぜなら、開発者とエンドユーザーの距離が遠いからです。）
単体テストと受け入れテストの間に、どんなテストが必要かを考えていけば良いです。
単体テストは機能を構成する画面であったり、API1つずつを検証するものです。
1つずつでは意味のある機能を提供することはできません。
そこで、単体テストの次に必要になるのが、
機能検証です。多くの場合、結合テストと呼ばれる工程です。
1つ1つの画面・APIを結合すると、意味のある機能となります。
その、意味のある機能が期待通りに動くかという確認をするのが、
機能検証です。
1つ1つの機能の総体がシステムです。
1つ1つの機能が期待通り動いていることがわかったとして、
次は機能と機能を結合して、システム全体が期待通りに動くか検証する必要があります。
1つの１つの機能が正常に動いたとしても、
システム全体として見たら要件を満たせていなかったということはあり得ます。
システム全体として要件が満たせているかを確認する、
システム検証（＝システムテスト）が必要です。
システム全体として要件が満たせているとしても、
いざユーザーが使ってみたら、期待するものと違ったということはあり得ます。
そこで、エンドユーザーが最終的に自分で確認することがどうしても必要で、
それを確認するのが受け入れ検証です。
受け入れ検証が行われないと、本番リリースしてから、
改善要望が来ることになります。
もしくは、ユーザーが使われないまま放置されます。
本書の内容を元に、テスト計画を書いておけば、最低限のことは書けているはずです。
最も大事なのは、どんなテスト工程を組んで、各工程で確認することは何か？（観点）を定義することです。
それが定義できていれば、あとは別の担当者でもテストケースを作成することができるからです。つまり、テスト計画作成の次の工程に渡すことができます。