黒柴的ソフトウェアテスト考　#10

コンポーネントテスト（単体テスト）に関する調査の考察#5

この記事は、考察#1～4をまとめたものとなる

今まで調査してきた記事を元にすると

• TDDで実施するテストは、QAを行うテストとは別物である

• QAを行うテストは、テストベースを元に分析、設計を行う必要がある

• 作成したテストコードは、仕様変更ではメンテンナンスが必要となる

• 上記を考えると、コンポーネントテストは想定しているよりコストが高い

ということが分かった

コンポーネントテストをQAに寄与する形で実施するやり方を、再度整理してみる
QAに寄与するためには、テスト対象となるコンポーネントをテストするためのテストベースが必要となる
このときのテストベースは、該当コンポーネントがどのような入力（パラメータ）に対して、どのような出力（返却値、ふるまい）をするのかを整理したものとなる
このテストベースは、コンポーネント設計書や、コンポーネント仕様書として整理されたものが想定される

では、このコンポーネント設計書が正しいことは、どのように確認するのだろうか？
JSTQB Foundation Levelシラバスには、以下のような記述がある

3.1.1 静的テストで確認可能な作業成果物
ほとんどの作業成果物は静的テストを使用して確認できる。例えば、要件仕様書、ソースコード、テスト計画書、テストケース、プロダクトバックログアイテム、テストチャーター、プロジェクトドキュメント、契約書、モデルが含まれる。
読んで理解できるあらゆる作業成果物はレビューの対象になりうる。しかし、静的解析では、作業成果物をチェックするための構造（例えば、モデル、コード、および正式な構文を持つテキスト）が必要である。
静的テストに適さない作業成果物は、人間による解釈が困難なもの、ツールで解析してはいけないもの（例えば法規制がある第三者の実行可能コード）を含む。

JSTQB-SyllabusFoundation_VersionV40.J01

つまりレビューという静的テストを実施することで、作業成果物であるコンポーネント設計書の品質が確認できるということになる
では、コンポーネント設計書に対する静的テストのテストベース、テスト対象は、どうなるのか？
テスト対象はコンポーネント設計書で、テスト対象はより上位の設計書となる基本設計書や、詳細設計書となるはずだ
では、その基本設計書、詳細設計書が正しいということは、どのように確認するのか？
これは、基本設計書、詳細設計書に対して静的テストとしてレビューを行うこととなる
つまり、下図ような階層化に伴い、より上位の定義書、設計書を元にして、対象となる設計書が正しいことを確認することになる

設計書の階層化

では、これをきちんと行えているのだろうか？
テスト考#4で書いたように、コンポーネント設計書については、黒柴の過去の経験だと、契約時に納品物として定義されていなければ、作成することがなかった
また、納品物となっていた場合も、開発がすべて終わり、これ以上ソースコードの修正が発生しないと判断した時点で、ソースコードからリバースで生成していた
これでは、コンポーネントテストは行えない

※長くなったので、次回に続く