受入テスト設計書(受入テスト仕様書)の作り方

req-definer.com

上記の手順に従って要件定義をしたら、その要件通りに動作するのかどうかを確認する必要がある。この動作確認行為は、通常、受入テストと呼ばれる。実現されたシステムが、受け入れ可能なシステムかどうかをテストするというわけだ。本稿では、システム開発における、受け入れテスト設計書(受入テスト仕様書とも呼ばれる)の書き方を説明する。

受入テスト設計方針の合意
受入テスト設計書の作成
受入テスト設計書のレビュー
- 要件定義者によるレビュー
- 設計者によるレビュー
受入テスト設計書の発行連絡
まとめ
参考記事

受入テスト設計方針の合意

まずは、テスト設計方針についてステークホルダーと合意をする。ステークホルダーは、要件定義した者と、プロジェクト責任者だ。受け入れテストといっても、テスト内容に対するイメージは人によって異なるので、どんなテスト設計書を作るのかを、ステークホルダーと認識を合わせるようにしよう。テスト設計方針として指し示すべきことは一つである。テスト設計書の上位文書としての要件定義書を示して、この書に書いてある通りにテスト設計書を作ると宣言するだけだ。下図に示すように、要件定義書で定義した要件は、そのまま受入テストの内容となる。この関係性を常に意識しておこう。システム開発というのは、大勢が認識を合わせながら一つのものを作り上げる行為だ。認識がずれないように、テスト設計作業の前に方針を合意して、成果物の認識がずれないようにしよう。

受入テスト設計書の作成

ステークホルダーとテスト設計方針の合意ができたら、テスト設計書の作成に着手する。ここでは、テスト設計書に書くべき内容、テスト設計書項目、および、テスト設計パターンについて説明する。

受入テスト設計書に書くべき内容

受け入れテスト設計書に書くべき内容はシンプルだ。基本的には要件定義書に書いてある内容と同じとなる。テストというのは、要件を満足できているかを確認する行為であるので、要件定義書の書き方が良ければ(例：〇〇できること、というような命令形で要件が記載されている)、要件＝テスト項目となる。逆に、テスト設計書に書くべきでないことは、要件定義書に書いてないことだ。要件定義書に書いてないことがテスト設計書に書かれてしまうと、間接的に要件を追加したことになってしまう。要件定義書に書かれていないテスト項目は、設計段階で考慮されているはずもなく、テストしたとしてもNGとなるはずである。本来であれば、そのような内容は、まず要件定義書に追記され、設計業者とコスト変動有無の協議がなされるべきだ。コストが変動するだけで済めばよいが、要件の内容如何によっては、設計の大幅見直しが必要となるので、そもそもの要件定義をしっかり行い、このようなことが起こらないようにしよう。

受入テスト設計書項目

テスト設計書項目としては、最低限下記を記載するようにしよう。

ポイントは、①誰でもテスト設計書のメンテナンスをできるようにすること、②テストの進捗をコントロールしやすくすることだ。そのために、可能な限り、どの要件を元にして、どのようなテストをするのかがわかるようにしよう。

項目	左記項目を記載する理由
上位要件番号	どの要件に基づいてテストをするのかがわかるようにするため
テスト内容概要	どんなテストなのかわかるようにするため
テスト優先度	テスト計画を作成できるようにするため
事前準備	テストを実施する前にやるべきことを明確化するため
テスト手順	何回もテストできるようにするため
判定基準	客観的に判定をできるようにするため
見積工数	テスト計画を作成できるようにするため
実績工数	テスト実施途中で計画を見直しできるようにするため
判定結果	テスト結果が一目でわかるようにするため
判定理由	テスト結果の妥当性を判断できるようにするため
判定者	テスト結果について問い合わせをできるようにするため
承認結果	テスト結果の信頼性を確保するため
承認理由	テスト結果の信頼性を確保するため
承認者	テスト結果の信頼性を確保するため
2回目以降のテスト結果記入欄	1回目のテストでNGとなったとき、やり直しの結果を記入できるようにするため

受入テスト設計パターン

受け入れテスト設計書を書く際、パターンが2つ存在する。要件定義書を書いた本人が書くパターンと、要件定義書を書いた本人以外が書くパターンだ。パターンによって進め方が異なるので、下記、意識されたい。

パターン① 要件定義書を書いた本人が書くパターン

このパターンは、最も理想的なパターンだ。要件を書いた本人が受け入れテスト設計書を書けば、要件定義書と受け入れテスト設計書間での認識に相違が発生することはない。要件定義書通りの受け入れテスト設計書が作られる。

パターン② 要件定義書を書いた本人以外が書くパターン

時間的な制約やプロジェクト体制上の制約で、要件定義書を書いた本人が受け入れテスト設計をできない場合がある。その場合は、本人以外に受け入れテスト設計書を書いてもらう必要がある。このパターンは注意が必要だ。本人以外が要件定義書を読み込んで受け入れテスト設計書を作成することとなるため、認識齟齬が発生する可能性がある。要件自体の内容が明確でない場合は、その部分を改めて明確化する必要がある。テスト作成時に疑問点が生じた際の質疑応答や、テスト設計書のレビューによる認識齟齬の排除ができるような体制にしておこう。

受入テスト設計書のレビュー

テスト設計が終わったら、テスト設計書のレビューをしてもらおう。要件定義者によるレビューと設計者によるレビューを実施することが望ましい。

要件定義者によるレビュー

この場合のレビュー観点は、「この受け入れテストを実施することで、要件は満足されるか？」である。要件が満足されないのならば、受入テストの内容について追記を行う。

設計者によるレビュー

この場合のレビュー観点は、「追加要件が存在していないか？」である。追加要件が存在しているならば、追加要件への対応可能性を協議し、対応可能であるならば、要件定義書にまず内容追記をして、その後に受入テスト設計書の内容を変更する。設計者によるレビューというのは、こういう受入テストを行うよというのをあらかじめ宣言する意味合いも含まれている。あらかじめ受け入れ側の期待値を明示することで、設計者側との認識齟齬を排除するようにしよう。

受入テスト設計書の発行連絡

テスト設計書のレビューが完了したら、要件定義者と設計者に連絡をしよう。受入テストというのは、完成したシステムに対する最低限の品質担保という役割を持つ。兎にも角にも受入テストをすべて合格にできねば、システムをリリースすることはできない。可能な限り多くの開発関係者に周知し、「システム品質の最低基準に対する認識」を合わせるようにしよう。

まとめ

今回は、受入テスト設計書の作り方について説明した。やることはシンプルで、要件定義書に書いてあることを、認識齟齬が発生しないよう、テスト項目に落とし込むだけだ。

受入テストを作成する過程で、必然的に要件定義書の記載内容を改めて見直すこととなる。これは、大変良い機会だ。作成した要件定義書が、第三者視点で読みやすい、かつ、理解しやすい内容になっているかどうかを確認するようにしよう。

仮に要件自体の不備が見つかった場合は、要件定義書自体を書き直す必要がある。要件定義書を直すということは、設計書を直すことを意味する。となると、追加の費用が発生する可能性がある。こうなったら、要件に過ちがあることを認め、設計業者に修正をお願いし、プロジェクトマネージャーに費用発生の連絡をしなければならず、修正には、大変な苦労が伴うこととなる。そうならないよう、要件定義をしっかり行うようにしよう。