黒柴的ソフトウェアテスト考 #7
コンポーネントテスト（単体テスト）に関する調査の考察#2
2番目の考察は、以下のブログ記事に関するものとなる
著者は、TDDによる開発を実践したエンジニアで、該当記事の執筆時期は2014年初頭くらいなので、開発時期はそれ以前と思われる
内容はリンク先の読んでいただくとして、黒柴の感想をまとめていきたい
著者自身が、TDDによる開発を実施した結果、気になった点は以下の3点だと思う
想定しているよりコスト（工数、期間）がかかる
想定しているより品質の向上が見られない
特に、GUI部分はテストコードが膨大になり、開発全体のコスト増加を招いた
著者はTDDの実施結果として、「コスト増」ということが特に気になっているようだ
これはテスト考#6でも、「ユニットテストはコストが低いという勘違い」というところで指摘されている
黒柴が興味深いと思うのが、「クライアントがTDDに掛かる費用を全額負担してくれるなら話は別ですが」という部分である
我々はプロフェッショナル（職業的）なソフトウェアエンジニアであるから、作業には常に対価を伴うことをきちんと認識すべきだと考えている
そして、契約して対価を伴う作業を行っているのだから、その作業で想定されている成果についても、きちんと約束するべきだと考えている
すなわち、製造（プログラミング）1人月に対して、コンポーネントテストが10人月が必要という見積もるなら、それをプロジェクトオーナーに説明して、承認を得る必要がある
見積もり時は、コンポーネントテストに2人月だったが、作業を始めたら5人月かかったしまったので、無条件に自腹を切りましたというのは良くないと考える
また、2人月の見積もりだったが、作業の結果5人月かかったので、いきなり差分を請求するのも良くないと考える
作業の着手前に工数が増える原因、対策を説明したうえで、プロジェクトオーナーの承認を得て作業に着手する、というのが正しいあり方だと考える
また、コンポーネントテストを実施した結果として、コンポーネントに関する品質の確認はとれた状態になり、次工程以降にコンポーネントの不具合は流出しない状態になっていることを保証しなければならないと考える
だから、コンポーネントテストの次工程において、次工程に流出したコンポーネントで抽出すべき不具合が多く、手戻りで次工程の工数が見積もりより増加したので、その増加工数を請求するのも良くないと考える
つまるところ、契約に基づいて開発を行うのだから、「その予算内で最大の効率を上げるためには、どうすべきか？」ということを、常に考えるべきだと黒柴は思っている
ウォータフォール型での開発において、過去の経緯から「単体テスト実施」という工程を設けるのであれば、その中で何を実施して、その結果がどのように得られて、次工程以降にどのように反映されるのかを整理したうえで、プロジェクトオーナーの確認・承認を経て開発に着手すべきだろう
逆に漫然とQAに寄与しないコンポーネントテストにコストをかけるのであれば、その作業の縮小を検討し、他にQAに寄与する作業にコストをかけることも検討するべきだと考える
確かに、ウォータフォール型の開発で考えた場合に、コンポーネントテスト（単体テスト・ユニットテスト）とその次工程のインテグレーションテスト（結合テスト）では、QAを保証する内容やテストの条件も異なるのだが、たとえばコンポーネントをビジネスロジックを実装するクラスに限定することで工数を削減し、その分インテグレーションテストのテスト項目のバリエーションや、確認項目を増やすということも検討に値すると考える
何事も、杓子定規に捉えないで、あらゆる可能性を探り、ソフトウェア開発の効率化を図ることが重要だと、黒柴は考える
この記事が気に入ったらサポートをしてみませんか？