文書ドリブン開発 テスト文書編：システム開発プロジェクトの現場から（27）（1/2 ページ）

　システム開発プロジェクトで作成される文書にフォーカスしての連載の最終回です。今回はテスト関連文書について考えたいと思います。なお、以下の記述はあくまで筆者の私見であることをあらかじめお断りしておきます。

最初の仕事はテスト仕様書作り

　わたしがシステム開発業界に入って間もなく配属されたプロジェクトで、最初に作った文書は単体テスト仕様書でした。初めての現場に配属されて期待と緊張の渦巻く中での作業です。いきなり先輩社員に見限られたりすることのないように少ない知識で精いっぱい取り組んだことをいまでもよく覚えています。しかし、そんな思いとは裏腹に、まったくもって作業は進みませんでした。いま思えばそれほど難しくもない機能の単体テスト仕様書作りに丸1日かけ、やっと1枚書き上げることができただけでした。

　そのとき受けた指示は「これ（ほかの機能のテスト仕様書）と同じようにこの機能のテスト仕様書を作ってみて」というものでした。もらった情報は簡単に書くと以下の2つだけです。

• テスト対象となる機能の詳細設計書とプログラムコードを印刷したもの
• ほかの機能のテスト仕様書

　実はこのインプットだけではテスト仕様書を作ることができないということは、いまだからこそ分かります。長くそのプロジェクトに従事している人であればこれだけで十分なのかもしれませんが、その当時は社会人になりたての新人です。それではどういうインプットが必要なのでしょうか？ 答えは最後に書きたいと思います。

テスト工程はいつから始まるか

　システム開発で各工程のインプットは前工程のアウトプットであるというのはほぼ同意いただけることかと思います。基本設計工程のインプットとなるものは要件定義工程のアウトプットですし、プログラム開発工程のインプットは詳細設計工程のアウトプットです。つまり、プログラム開発工程までは主にその直前の工程のアウトプットがインプットとなります。

　ところがテストの工程に入ると、この関係が若干変わることにお気付きでしょうか。あらためてV-モデルをご紹介しますが、テスト工程からはインプットとなるものが直前の工程のアウトプットではなく、合わせ鏡のようにした反対側の作業工程のアウトプットがインプットになるのであるというところが興味深いところです。さらにいうと、要件定義の段階である程度テスト工程のことを念頭に置いておく必要があるということです。

　時々プログラム単体テストのインプットに書いたプログラムそのものを使っている人がいますが、そもそもプログラムのバグを見つけるのがテストの役割なのに、誤りがあるかもしれないものをインプットにすること自体すでに意味のない行為です。これは前回の記事でも触れたとおりです。

図1　V-モデル

　つまり、要件定義の段階からすでにテスト工程は始まっているというのがわたしの考えです。単体テストから受け入れテストまでの各テストには適切なインプットとなる成果物が存在しているので、テスト仕様はこのインプットに従って起こすのが正しい方法です。わたしの会社ではこのV-モデルに関する教育が全社員に対して徹底的に行われています。しかし、わたしが新人時代を過ごしたのは別の会社だったため、こういった筋の通った理屈の説明がないままやみくもに取り組んでいました。いま思うと残念でなりません。