前回、個別最適を解決する手段として、新しいアプローチを提示しましたが、これらはすべて手段であり、単なる戦術です。これらを「テスト戦略」として意味を持たせるためには、手段をどのように取捨選択して戦略としてまとめ上げるかが必要です。これが「開発の各役割が行うテストのコーディネート」です。今回は、このテストのコーディネートについて説明します。

テストのコーディネートでは、本稿で紹介した新しいアプローチだけでなく、自社の中での経験則や成功事例などの選択肢を組み合わせて、テスト全体の構造を決めます。例えば、「テスト分析で優先度付けするためにリスクベースドテストを実施する」「レビューはテストレベルに対応する開発レベルの仕様書ができた時点で実施する」「テストレベルはどう分割し、目的は何で、いつ頃実施し、テスト対象はどれになる」というように定義していくのです(図)。

図 テスト全体の構造定義(複数用意する)

これらの組み合わせを定義する際は、プロダクトやプロジェクトを分析した結果が事前に必要になります。プロダクトの分析であれば、「その開発でどの程度の売上が必要なのか」といった開発目的や、顧客の要求とシステム化範囲、出荷日程/運用開始日、販売価格などが該当します。もちろん、技術課題も把握しておく必要があるでしょう。プロジェクトの分析であれば、開発プロセスの中のテストの位置付け、選択した技術(言語やアーキテクチャパターン)、メンバー構成(自社のみ、協力会社含む、オフショアなど)やスキルが該当します。

また、「そもそも自分たちはテストを開発プロジェクトにどう活用したいのか」という基本的な考え方……というか理念を持っていなければなりません。

執筆者プロフィール

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

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