一度はふーん、と読み飛ばしたものの二度目は悪寒がした。ニョーボのおかげで栄養は足りているはず。最近睡眠時間も多いから風邪なんか引かないはずである。インフルエンザの予防接種も受けている。こういうときは、だいたい「何か問題が隠れている」。それに潜在意識が気がついたのだ。
先ほどの外注区分をもう一度見直してみる。頭に図が浮かんだ。Ｖ字モデルという奴だ。 この図に先ほどの外注区分を当てはめると、どうやらバランスが悪い。Ｖ字モデルの左右が非対称になるのだ。Ｖ字モデルの図は、日経プロフェッショナルの記事「知っておきたいテストのイロハ」によると、こんなものらしい。（以後の論、日経プロのこの記事を参考にさせてもらいます。日経ＢＰはイマイチな記事が多いですが、世間一般の常識とおぼしきものを推測するネタ探しにはよい出版社です。）各四角のなかの括弧入りの文字は、上であげた外注区分をそれっぽく当てはめたものです。
簡単に言うとＶ字モデルは、品質の作り込みプロセスと品質の検証プロセスを対比させて見てゆくというものみたいだ。で、この図の点線内を外注に一任したということになる。
一見して「内部設計と結合テストがバランスしていない」というのが落ち着かない要因であるとわかる。ただしそれだけなら悪寒まではしない。この外注区分を行っているところだって、多分「テスト設計およびテストケースをチェックしているから大丈夫だ」と言うのだろう。しかしこれは「テスト仕様・ケースをチェックすれば、内部設計自体はチェックしなくとも問題はない」という前提に基づいている。
果たしてそうか。さっきより悪寒がひどくなった。
で、さっきの日経プロの記事をもう少し読むと「単体テスト／結合テスト／システムテスト／受入テスト／運用テスト」の区分とそれぞれの具体例が載っていた。
| フェーズ | テスト名 | 内容 |
| 単体テスト | ロジック確認テスト | 全ての論理的経路を実行させて処理結果を確認する。 |
| 条件分岐確認テスト | 全ての条件分岐が意図したとおりに動作するかを確認する。 | |
| 代表値テスト | 代表的な入力を与えた場合の処理を確認する。 | |
| 上位インターフェース確認テスト | ドライバーを用いたインターフェースの確認。 | |
| 下位インターフェース確認テスト | スタブを用いたインターフェースの確認 | |
| 結合テスト | 基本機能動作確認テスト | システムの基本的な機能について動作させて結果を確認する |
| 設定操作確認テスト | システムの設定に関する全ての操作を実行して結果を確認する | |
| 入力操作確認テスト | システムに関する各種の入力操作を実行して結果を確認する | |
| 入力バリエーションテスト | システムへの全入力値にパターンを与えて動作を確認する | |
| 出力バリエーションテスト | システムにおける出力の全パターンを確認する。 | |
| 設定バリエーションテスト | システム設定の全パターンについて代表的な動作を確認する | |
| 起動・終了動作確認テスト | 起動／終了の全パターンについて動作を確認する。 | |
| モジュール間インターフェース確認テスト | モジュール間の受け渡しデータ全種類について動作を確認する | |
| 外部リンク動作確認テスト | システムで使用する全ての外部環境とのデータ受け渡しを確認する | |
| 業務シミュレーションテスト | 実業務の動作パターンをシミュレーションして動作を確認する |
えーーーー、単体テストってこれだけしかやんないの？というのが感想である。ここでは結合テストに分類されている「起動・終了動作確認テスト」くらいまでは単体テストでやるのが普通でしょう。
ここで悪寒の原因がはっきりした。私が最初の例のような基準で外注に一任すると、〜私は単体テストとして起動・終了確認テストまではやってくれたものと思っている、ところが外注先は上位インターフェーステストまでしか行わない〜ので、基本機能動作確認テスト／設定操作確認テスト／入力操作確認テスト／入力・出力・設定バリエーションテスト／起動・終了動作確認テストがごっそりと抜け落ちるのだ。 悪寒の原因がはっきりした。風邪ではなかった。
まあ、外注先がそれなりのベテランで固められていれば、プライドとしてその辺のテストまでやっていてくれるかもしれない。が、コストを値切って若手とか、文化の違う海外に発注していた場合、で、彼らの「単体テスト」の定義が、この日経プロの記事のようであったとすれば、想像するだに恐ろしい。本番で動いているシステムが使用者のタイプミスで（フロントエンドのプログラムに入力値チェックがなくても最後まで気がつかないんだから）、落ちるんだぞ。
ましてや、システムのデータの流れが追いにくいクライアントサーバー系ならどうなる。
というわけでしばらくオフショアに特にクライアントサーバー系のシステムは発注したくないなあ、というのが結論でありました。
まあ上記の外注をやっていた組織（ホントにあれば）におざなりの改善策提案。
- 毒を食らわば皿まで、詳細設計を外注したのなら、結合テストまで外注すること。
- こっちは起動・終了動作確認テストまで単体テストとおもってます。そこまで責任持ってください、と外注の分担を今一度明確化すること。
さて、この「外注」、オフショア開発みたいにホントーに各開発者とのコミュニケーションがとれなくなっちゃった場合、気になることが一つあるのだな。運用設計である。
先ほどのＶ字モデルにしても、実は「プログラム開発」のことは気にしていても、「運用設計・実装」のことは気にしていない。（「運用の単体テスト」なんてイメージできますか？）当然詳細設計中、プログラムの実装中に運用の制約事項や留意点を思いつくことは多いと思うんだ。なんてったってプログラマはユーザーすら意識していなかった要件や業務上の特殊ケースを思いつくんだぜ（それらが思いつけるほどプログラミングというのはストレスのかかる作業なのだ）。当然細かい運用上の留意点だって気がつく（あるいは作り込む）。
で、開発者とそれなりにコミュニケーションがとれる場合、「ぼくが言うのも何なんですけど、運用時にはこーゆーことに気を遣わないといけないんじゃないかと」などと言ってくれることはある。聞けば答えてくれることもある。が、オフショア開発だとどうなる。
この辺の「インフォーマルな」部分をきっちり救う方法論がない限り、少なくともオフショアへの外注はしない方がいいと思うぞ。（で、どうしてもやれと言われれば、業務パッケージの実装をやってもらいます。SAPとかね。）
だから国内ソフト開発会社としては、海外との競争に勝つために「実装中に気がついたことはどんどんフィードバックします」という仕組みを提供しなければならない。まあ同じ日本人だと注文主が図に乗って「気がつかなかったおまえが悪い」と逆ギレするリスクは高いんだけどね。