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

最初の考察は、以下のブログ記事に関するものとなる

著者は、「JUnit実践入門」の著作があるエンジニアで、該当記事の執筆時期は2013年9月頃である
この記事を読んで、黒柴が気になったこと、感じたことを述べていきたい
この「10の勘違い」はどれも考えさせられる内容だと思うので、一読して自分自身でいろいろと考えて欲しいと思う

ひとつめは「2.ユニットテストは誰でもできるという勘違い」である
ユニットテスト自体は、製造工程の一部として「製造／ユニットテスト」という工程でスケジュール作成をしているプロジェクトも多いと思う
これは、製造（プログラミング）しながら、ユニットテストの実施（項目作成・テストコード製造・テスト結果の確認）を行うことを想定しており、ユニットテストを製造を行うプログラマに委ねている

しかし、すべてのプログラマがテスト技法、特にブラックボックステスト技法として最低限の「同値分割」、「境界値分析」、「デシジョンテーブル」を理解できているのだろうか？
答えは「否」だと思う
テスト考#4でも書いたように、プロジェクトのスケジュール遅れが発生すると、とかく「とりあえず」プログラミングができればよいというエンジニアがアサインされがちである
とりあえずプログラミングができるというレベルのエンジニアが、テスト技法に関する教育を受け、かつ理解しているとは考えづらい
そのため、QAに寄与するコンポーネントテストを行うためには、きちんとテスト技法の教育を受けたエンジニアが、きちんと仕様確認が行われた設計書を元にテスト項目を作成し、テスト項目の確認をする必要があると考える

もうひとつは「4.ユニットテストはコストが低いという勘違い」である
黒柴は、テストフレームワーク（JUnit）を使ったテストをきちんと実施したことはなく、テスト考#5で書いたようにアーキテクトチームとしてサンプル作成を実施した程度の実績しかない
このサンプル作成では、簡単なコンポーネントのテストコード作成の他、データベースの検索、更新などを確認するサンプルとして、テストデータの作成・テスト用テーブルへのデータの登録・結果の確認をテストの前後で実施するコードの作成なども行った

その感触から言うと、この記事に書かれている「2倍から5倍程度はかかる」という見積もりは、適切だと思う
なお、この見積もりはあくまでも実装（テストコード・テストデータの作成、テスト環境の構築）に関する工数であって、テストベースとなる設計書が正しいことを確認することまで含むと、さらに工数は膨らむと思う

黒柴が気にしているのは、コンポーネントテストにこのような工数をかけて、どれだけQAに寄与しているのかということである
SIerの下請けとして、概ね設計からインテグレーションテストまでを請け負いで実施するソフトハウスは、設計や実装、テストに関する見積もりを行った上での受注となるわけだが、実装の2倍から5倍程度のコンポーネントテスト工数という見積もりを出して、SIerが果たして納得するだろうか？

しかも、それだけの工数をかけても、「2.ユニットテストは誰でもできるという勘違い」で示されているように、実装者に任せたテスト項目の作成が適切でなければ、QAに寄与しているとは言い難い結果しか得られない
そのため、次工程の工数にもリスク分を計上する必要がある
結果として、高額の見積もりとなるが、それでは受注は難しいだろう

この記事の最後には、「みなさんの開発チームでは、ユニットテストしてますか？」とあるが、黒柴の過去の体験から言えば「コンポーネントという工程を設けて、テストは実施しているが、その内容がQAに寄与しているかというと甚だ疑問が残る」という状態である