マイクロソフト プロダクト ディベロップメント リミテッド
ディベロッパー製品開発統括部テスティンググループ
テスト リード
橋本 芳昭
長年ため込んだ体脂肪を燃焼させるべくウォーキングでも始めようかと思う今日このごろです。





イラスト:岡本 敏

 マイクロソフトの製品開発部門には「QAチーム」と呼ぶ組織があります。QAはQuality Assuranceの略。製品開発に伴うテストを専門に行っているテスト・チームのことです。テスト・チームは当然,製品の品質に関して最も詳しくかつ厳しく,その製品が出荷できる品質に達しているかを判断する責任を負っています。つまり,テスト・チームが最終的に承認しなければ,その製品の出荷はできないのです。では,このような責任を全うするために,具体的にどのように作業しているのでしょうか。

 本連載の第2回となる今回からは,3回にわたってテスト・チームについて説明していきます。まず今回は,テスト・チームが行っている作業内容について,実際のVisual Studioの例にも触れながら,その概略を紹介します。次回の本連載第3回ではテスト・チームが効率的に作業するための工夫について,そして第4回ではテスト作業の定量的な評価方法についてお話しします。

テスト・チームの役割は,テスト計画の立案,実行,結果報告
 製品の出荷を承認するためには,製品に関する品質上のすべての問題を見つけ出し,それらのすべてが対処済みであることを確認する必要があります。これが製品開発工程におけるテスト・チームのゴールといえるでしょう。このゴールを達成するためのテスト・チームの作業は,多岐にわたります。以下に主なものを3つに分けてまとめてみました。

(1)テストの計画を立てる
 (a)テスト計画書を作成する
 (b)テスト仕様書を作成する
 (c)品質基準の策定に参加する
(2)テストを実行する
 (a)テスト手順を作成し,それを保守する
 (b)テスト自動化の仕組みを開発する
 (c)テスト支援ツールを開発する
 (d)ビルドしてできた生成物に対して定期的にテスト手順を実行する
(3)テストの結果を報告する
 (a)バグを報告し,その修正状況を追跡する
 (b)報告したバグが修正されていることを確認する
 (c)各機能の品質基準への達成度を報告する

 また,これらの作業とプロジェクト全体のスケジュールを同期させるため,テスト・スケジュールの管理やテスト用資源(人員やハードウエア)の割り当て,といった管理作業も発生します。余談になりますが,Visual Studioのテスト・チームは,現在開発中のVisual Studio 2005だけでなく,Visual Studio .NET 2003や.NET Framework 1.1といった現行製品のサービス・パックなどについても,並行してテストしています。そのため,スケジュールやテスト用資源の割り当てに対しては,柔軟に対応することが要求されています。

設計やコーディングと同時にテストもスタート
 テスト作業は,ソフトウエア開発工程の中で実装(コーディング)の次に位置し,製品の出荷・運用前までにテストを完了するという開発モデルが,日本では主流のようです。ところが,マイクロソフトではプロジェクトの初期段階からテスト作業も開始し,プログラム・マネージャ(マイクロソフト社内ではPMと呼ばれている)による設計作業や,プログラマ(マイクロソフト社内ではDevと呼ばれている)による実装作業とほぼ並行して進める体制を採っています。


△ 図をクリックすると拡大されます
図1●開発工程中でのテスト作業概要

 テスト・チームが担当する各作業が開発工程のどの段階で発生するか,その概略を図1に示しました。このように,テスト・チームの作業は開発工程の初期から始まり,製品の出荷まで続きます。そのため,製品について一番詳しいのは,プロジェクトの初期段階ではプロジェクト・マネージャ,実装段階ではプログラマ,そして最終的に製品を出荷した後にはテスト・チームと,その製品について一番詳しい担当者が変わっていきます。

 それでは,前述したテスト・チームの作業内容を具体的に説明していきましょう。

製品仕様とスケジュールを基にテスト計画を作成
 プロジェクトの初期段階では,プログラム・マネージャが作成した製品仕様とプロジェクト全体のスケジュールを基に,テスターがテスト計画書を作成します。テスト計画書には,プロジェクトのどの時期にどのようなテストを行うかという,テスト・チーム全体にかかわるテストの指針やその概略を記述します。また,テストを効率的に行うために,自動化システムやツールを開発する必要がある場合には,その内容も計画書に記述します。

 その後,製品仕様書を基に,各テスターは担当分野に対するテスト仕様書を作成します。テスト仕様書には,担当分野のそれぞれの機能に対して,実施しなければならないテスト手順の詳細を記述します。これは,実際にテストするときの条件,環境,使用するテスト・データといった情報です。

 また,この初期段階では,プログラム・マネージャやプログラマとともに,品質基準をどこに置くかを確認することも重要です。この基準に沿って,実際のテスト作業の優先順位,バグ報告の深刻度を決めます。

テスト手順を作成して実際にテスト
 開発工程の中で,テスターが最も時間を費やしている作業が,テスト手順の作成と実行です。テスターは,各担当分野に関して,製品仕様書と事前に作成したテスト仕様書を基にテスト手順を作成していきます。テスト手順が完成すると,ビルドしてできた生成物に対して実行します。

 このようにして不具合を発見するのですが,実際には生成物にバグがあって不具合が発生するだけではなく,テスト手順が原因となって起こる不具合もあります。そのため,テスト結果を評価し,テスト手順自体に問題があるのか,それともテストした生成物の機能にバグがあるのかを解析します。バグと判断できれば,後述するバグ管理データベースに報告し,テスト手順に問題がある場合にはそれを自ら修正します。テスト手順の実行が自動化されている場合には,自動化自体の問題かもしれないので,慎重に解析する必要があります。

 前述したようにマイクロソフトでは,開発工程の中で,設計・実装・テストがほぼ同時に進行しています。このモデルを遂行するには,テスト対象となる生成物を,定期的に,かつ高い品質でビルドする仕組みが必要です。マイクロソフトでは,実際にそのようなシステムを構築しています。


△ 図をクリックすると拡大されます
図2●定期的なビルドとテスト作業

 マイクロソフトでは,ほぼ毎日のようにビルドが繰り返されます。ただし,新しい生成物が必ずしもテスト可能な品質に達しているとは限りません。そこで,毎回のビルド終了後にセットアップ・テストや生成物の妥当性テストが自動的に実行され,その生成物がさらに詳細なテストを実行するに耐えうる品質に到達しているかどうかが判断されます。

 これらの初期テストで問題がなければ,テスト・チーム全体にその生成物がテスト可能であることが伝えられ,各テスターがそれぞれの担当分野の詳細なテストを実行していきます。テスターは,新しい生成物に対してプログラマがどの機能までを実装しているかその状況を見つつ,テスト手順を実行しています(図2)。

(次のページへ続く)