黒柴的ソフトウェアテスト考 #10
コンポーネントテスト(単体テスト)に関する調査の考察#5
この記事は、考察#1~4をまとめたものとなる
今まで調査してきた記事を元にすると
TDDで実施するテストは、QAを行うテストとは別物である
QAを行うテストは、テストベースを元に分析、設計を行う必要がある
作成したテストコードは、仕様変更ではメンテンナンスが必要となる
上記を考えると、コンポーネントテストは想定しているよりコストが高い
ということが分かった
コンポーネントテストをQAに寄与する形で実施するやり方を、再度整理してみる
QAに寄与するためには、テスト対象となるコンポーネントをテストするためのテストベースが必要となる
このときのテストベースは、該当コンポーネントがどのような入力(パラメータ)に対して、どのような出力(返却値、ふるまい)をするのかを整理したものとなる
このテストベースは、コンポーネント設計書や、コンポーネント仕様書として整理されたものが想定される
では、このコンポーネント設計書が正しいことは、どのように確認するのだろうか?
JSTQB Foundation Levelシラバスには、以下のような記述がある
つまりレビューという静的テストを実施することで、作業成果物であるコンポーネント設計書の品質が確認できるということになる
では、コンポーネント設計書に対する静的テストのテストベース、テスト対象は、どうなるのか?
テスト対象はコンポーネント設計書で、テスト対象はより上位の設計書となる基本設計書や、詳細設計書となるはずだ
では、その基本設計書、詳細設計書が正しいということは、どのように確認するのか?
これは、基本設計書、詳細設計書に対して静的テストとしてレビューを行うこととなる
つまり、下図ような階層化に伴い、より上位の定義書、設計書を元にして、対象となる設計書が正しいことを確認することになる
では、これをきちんと行えているのだろうか?
テスト考#4で書いたように、コンポーネント設計書については、黒柴の過去の経験だと、契約時に納品物として定義されていなければ、作成することがなかった
また、納品物となっていた場合も、開発がすべて終わり、これ以上ソースコードの修正が発生しないと判断した時点で、ソースコードからリバースで生成していた
これでは、コンポーネントテストは行えない
※長くなったので、次回に続く
この記事が気に入ったらサポートをしてみませんか?