結合テストと呼ぶことをやめる前にやっておこうよ、という話

自分の周りのプロジェクトマネージャやスクラムマスタは、ウォーターフォールに限らず、アジャイル開発であっても成果物（アウトプットと表現してもよい）を作る作業の括り毎に、作業内容の定義、完了の定義をしなければいけない、と言う認識を持っている。

言い換えると、工程（アジャイルに工程という概念がフィットするかは別にして）の作業プロセスをデザインしてから個々のタスクをWBS（開発手法やプロジェクトの方針で作らないかもしれないが）に展開した上で、作業を着手させろ、と言うことになる。

前説

工程の作業プロセスをデザインするとは、その工程の中で成果物を作成するためにメンバ誰もが行う共通の手続きを決めると言うことだ。

例えばテスト工程なら、以下の手続きを経て、テストの合格基準をパスしたものだけが次工程のデプロイに進める、などと決めておく。

項番1〜3は、この工程を実施する前に決めておく。もちろん、メンバ全員が理解していなければならないので、決める際にはメンバと工程の作業と完了基準の意識合わせをしなければならない。

その上で、4〜7をメンバが各自で行う。

前説を読んでご理解いただけていれば、どうなるか想像に難くないだろう。メンバの実績を聞き、完了したと報告を受けて実績を見ると、メンバごとにテストの粒度がバラバラであることが判明し、粒度を揃えてテストをやり直すことになる。

そうなることは、エンジニアであれば誰も手戻りという喜ばれない経験をしたことがあるから予測がつくはずだ。

でも、現場ではハルヒのエンドレスサマーのように繰り返し行われている。

細々としたことやお作法のテストについては、テストの書籍をご覧になって欲しい。以下は、あくまでも段階テストを行う上で、チームがどのような単位でテストをするかを考えなさい、という例である。

テストは、段階的にテストを行う。それはテストの観点があるし、そうしなければ、コードの不具合の解析が大変になるからだ。

テストは、機能を確認するためのホワイトボックステスト、機能を連結し、インタフェース及び連結した機能のテスト、対外システムとのインタフェーステストの3種類の観点を行う必要がある。

そのテストを自分のプロジェクトではどのコードの塊で行うかは、チームで決めることである。その決め事を工程の作業プロセスでデザインしなければならない。

例えば、ホワイトボックステストはxunitで行う。単体のプログラム、モジュール、クラスまでで、単体で動かないコードはスタブ、ドライバを用意する、と決めておく。

機能を連結して行うテストは、自分たちのプロジェクト全体のコードをすべて連結する、と決めておく。プロジェクト全体の機能、コードが大きければ、サブシステムに分解（当然、システムデザインの時点で機能分解されているはずだ）し、サブシステムの機能連結するテストを経て、システム全体のテストを行う。

最後に、システム全体を塊として、そのシステムと対外的なインタフェーステストを行う、などを決めておく。

標題のとおりである。これしかない。何もしないで勝手にメンバが相互に慮って、テストの粒度を調整して、テストを始めることを期待するなんて馬鹿げている。

リーダ役は仕事をしていないのと一緒である。仕事しろ。以上、でしかない。