それでもうまく行かない「もどかしさ」

開発プロジェクトごとにテスト戦略が異なることを理解し、プロジェクトの開発プロセスや顧客の品質に対する要求を理解してテスト戦略を立案したとしましょう。「これで万全の状態でテストを進めていける……」と思っていても、必ずしも開発プロジェクト自体がうまくいくとは限りません。むしろうまくいかない方が多いかもしれません。それは、開発プロジェクト全体の状況が当初の想定通りには進まないからです。

ソフトウェアの要件や仕様がドキュメントに正確に書かれていれば、ドキュメント通りに動作することをテストで確認すればいいのですが、ドキュメントに不備があれば、何が正解かを調査しながらテストしなければなりません。また、開発メンバーの腕が良く、欠陥が少なければテストを行っても不具合はほとんど見つからないかもしれません。

しかしこれが逆であれば、いつまでたっても不具合は減りません。開発全体の進捗に遅延が発生すれば、日程通りにテスト始めることさえできないでしょう。そんな時でも「想定通りに開発が進まないからテストを中断する」という訳にはいきませんので、品質を確保すべくテストを続けなければなりません。

テストする側から見れば、「テスト対象のソフトウェアの品質が悪いのはプログラマーのせいだ。自分たちの責任ではないのでどうしようもない」と思ってしまい、ただイライラしながらテストを進めていくことになるのではないでしょうか。また、開発終盤で不具合を大量に報告することは、ただでさえ疲れている開発者に対して、さらに「働け」といわんばかりにダメ押しするようなものです。正に「もどかしい」状況となってしまいます。

個別最適の落とし穴

このようなもどかしさは、複雑で巨大化したソフトウェア開発の現場であれば、多くの人が感じている問題かもしれません。大きな原因としては、そのテスト戦略が、結果的に「自分たちが行うテスト」だけしか考えられていないことが挙げられます。つまり、テストをうまく実施するという個別の最適化が、開発全体の最適化の役に立っていない訳です。

例えば、「テストは開発した本人以外が行った方が不具合を見つけやすい」という原則に従ってテストの役割を整理し、「テストではここまで」と定義するのは必ずしも悪いことではありません。最適化が(個別には)できていると言えます。

しかし、テストフェーズと設計・実装フェーズを別のプロジェクトかのように切り離して考えてしまうと、遅れの原因を双方で押し付け合うような状況が発生します。他にも、テストレベルを分割したのはいいが、(開発者が自身で実施する)コンポーネントテストでテスト済みだと思った機能が、その後の独立したテストチームで実施するテストで無視されてしまい、市場不具合につながるケースも見受けられます。

このように、すでに実証されているテスト戦略でも、推し進める際に方向性を誤ると、全体最適の面から見るとボトルネックになってしまうのです。

執筆者プロフィール

湯本剛 (Tsuyoshi Yumoto)
株式会社豆蔵　シニアコンサルタント。1991年に製造メーカーに就職し、原価管理、製品管理システム構築プロジェクトに参画。その後、ソフトハウスにてパッケージソフト、プリンタドライバ、C/Sシステム、Webシステムなどソフトウェアテスト業務に携わる。現在は豆蔵にてソフトウェアテストのコンサルタントとして活動中。日本科学技術連盟SQiPステアリング委員、JSTQB技術委員、s-open幹事、NPO法人ソフトウェアテスト技術振興協会理事。

『出典:システム開発ジャーナル Vol.2(2008年1月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。