読者のあなたも、多かれ少なかれ「テスト」というものに携わったことがあるだろう。このテストについては、メンバー全員で必死になっても一向にバグが減らない、あるいは何度もやり直すという“負”のイメージが強いのではないか。テスト嫌いの方も多いはず。「こんなにがんばっているのに、なぜバグが減らないのか」と、疑問を持つことも少なくない。

　ただし、プロジェクト・マネージャ（PM）になれば、先の見えないテストを成功に導くために、しっかりとマネジメントすることが大切だ。そこには、出口が見えないテスト工程ならではの“リーダーの流儀”がある。今回は、そんなテストのルール「テストは塗り絵である」について紹介しよう。

疑似本番テストで全く動かない

　ある大規模プロジェクトにPMとして参加したときのこと。現場はリリース直前の最終確認テストを迎えていた。すでに開発を請け負った協力会社のメンバーはいない。発見されたバグ件数は、実施したテスト件数に見合うものだったからだ。

　最終確認テストを実施する担当者からは「順調です」という報告を受けていた。筆者は「専門家が言うのだから問題なし」と思っていた。まさに、大船に乗った気分だった。

　その船が“泥舟”であることに気付いたのは、先の協力会社が開発したサブシステムと、別のサブシステムを連動させたテスト（疑似本番テスト）を始めたときだった。二つのサブシステムを連動させてテストすると、全くと言っていいほど動かないのだ。サブシステム間のインタフェースは合意済みのもの。仕様の思い違いがあったとは、とても考えられなかった。

計画なきテスト 塗り絵は完成せず

　詳しく調べると、原因は協力会社が開発したプログラムのバグだった。後の祭りである。筆者らは最終確認テストを急きょ中止。バグの修正を余儀なくされた。大きな手戻りだ。それでなくてもこのプロジェクトは、設計工程からスケジュールが逼迫していた。実装工程に入ってもユーザーと細かい仕様調整に追われていた。それがこの段階で大きなトラブルに見舞われるとは。なぜバグが作り込まれたのか、なぜこの段階まで致命的なバグを見つけられなかったのか―。筆者は自問自答を繰り返した。

　この答えをくれたのが「テストは塗り絵である」だった。テストを実施する前には「テスト計画」を立てる。このテスト計画は、塗り絵の下地に相当する。もし下地がなければ「どの部分をどのような色で塗ればよいのか（作業計画）」「誰がいつまでにどこを塗るのか（要員計画とスケジュール計画）」「どこまで塗れば完成なのか（完了基準）」という点が分からなくなる。各テスト工程では、この下地を塗っていくことで、やがて白地の部分が小さくなる。稼働を迎えるときには、完全に白地を塗りつぶす必要がある。

　今回のプロジェクトでは、この塗り絵の下地、つまりテスト計画がない状態でテスト工程に突入していた。テスト担当者からすれば、自分がどの範囲まで塗ればよいのか分からず、自分たちの基準で「ここまでだろう」と判断していた。このためバグが残ったまま疑似本番テストに入り、問題が発覚した。筆者は「絵の具」となる工数を使い切ったにもかかわらず、結果的に白地の部分があちこちに残る事態を招いたのである。

どこが白地かはPMしか分からない

　塗り絵が完成しなければ、テストの網羅性を必要十分に確保したとはいえない。振り返ると筆者は、テスト件数やバグ件数ばかりに目を奪われていた。PMは「誰が」「いつ」「どの部分を」「何色で」という下地を作ることが責務である。それが「テストは塗り絵である」と呼ばれるゆえんなのだ。

　テストを依頼する側は「これくらいは何も言わなくてもやってくれるはず」と安易に考えてはいけない。どこが白地として残っているかは、テストをマネジメントするPMにしか分からないのだから。