Visual Studioの開発現場から（第2回） p.2

イラスト：岡本 敏

テストの自動実行システムを構築し，テスト手順をC#で記述
　マイクロソフトでは，テストを自動実行するためのテスト・システムを構築しています。実際，テスターが作成する多くのテスト手順は，このシステムを使って自動化されています。ちなみにVisual Studioのテストは，各テスターがそれぞれのテスト手順を，C#またはVisual Basic（VB）で実装し，自動化テスト・システムに組み込んでいくわけです。2004年5月末に米国San Diegoで開催されたTech・Ed 2004ではVisual Studio 2005 Team Systemが発表されましたが，これのテスト機能は，私たちが使っているテスト・システムそのものではありませんが，同じコンセプトを実装したものです。

　このようにして作った自動テスト手順が，毎日のように作られる生成物に対して定期的に実行されることで，製品の品質を確保していきます。例えば，プログラマがある部分のコードを変更したために，別の機能が動作しなくなったとします。この問題は自動化テストで見つけられます。ただし，すべてのテスト手順が自動化されるわけではありません。例えば，UI（ユーザー・インターフェース）の操作性や，メニューやダイアログ・ボックス上の文字が適切に表示されていることは，どうしても目視による確認が必要で，手動にせざるを得ません。こういった手動テストは自動化テストよりは頻度が下がりますが，開発工程を通じて定期的に実行されています（図3）。

△　図をクリックすると拡大されます 図3●自動化テスト

　必要なすべてのテスト手順は，プロジェクトの最終段階までに作成しておかなければなりません。そして，すべてのテスト手順に対して，問題なく動作していることが，テスト・チームが製品の出荷を承認するための条件の1つとなります。

　ここで完成した自動化テストは，製品の出荷後も利用し続けます。例えば，製品に対するサービス・パックの妥当性テストや，製品出荷後に出たWindowsのサービス・パックとの互換性（例えば，Visual Studio .NET 2003とWindows XP SP2との互換性）を確認するテストに使うことになります。

　テスト手順は，様々な環境で実行する必要があります。特にVisual Studioの場合は，多様なプラットフォームを考慮しなければなりません。Visual Studioで作成されるマネージ・アプリケーションの実行環境である.NET Frameworkは，Windows 98以上のWindowsに対応しているので，Windows 98はもちろんのこと，Windows XPやWindows Server 2003といった各種Windowsとの組み合わせによる互換性テストが必要です。さらに，Pocket PC向けのアプリケーションや，携帯電話向けのWebアプリケーションの開発機能も備えていますので，それらのようなスマート・デバイスでのテストも必要です。

　また，SQL ServerやInternet Information Services（IIS）のようなサーバー・アプリケーション，Officeのようなデスクトップ・アプリケーションとの互換性に関してもテストします。それだけ多種多様な環境でのテストが要求されているのです。そのため，それぞれのプラットフォームやアプリケーションとの組み合わせ表を作成し，十分な範囲が網羅されていることを検証したうえで，その組み合わせに沿ってテスト手順を実行し，この要求を解決しています。

　テスト作業の中で最も労力を使っているのが，このようなテスト手順の“メンテナンス”です。プロジェクトのスケジュールに合わせて，これらの作業を漏れなく適時に遂行していくには，組織に対してその柔軟性と統率力が要求されると感じています。現在開発中のVisual Studio 2005では，ベータの前段階ですが，既に万単位のテスト手順が作成されていて，テスト手順の実行と評価に多忙な状況となっています。

テスト結果をプログラマにフィードバック
　なにはともあれ，テスト・チームの成果とは，たくさんバグを見つけることです。ただし，バグを見つけるだけでは意味がありません。それを正しく修正できるよう，プログラマに的確に報告する必要があります。では，どのようにバグを報告し，どのような流れでそれを修正しているのでしょうか。ここでは，マイクロソフト内での仕組みを簡単に紹介しましょう。

　マイクロソフトでは，バグ情報を管理するデータベースを構築しています。各テスターは，テスト作業中に見つけたバグを，このバグ管理データベースに登録します。このとき，バグの再現手順，再現環境，深刻度，優先度といった情報を明確にして登録しなければなりません。ここで深刻度とは，アプリケーションがクラッシュするような重度のバグから，あるダイアログ上で文字が少し欠けているといった軽度なバグまでを，段階的に区分した指標です。そして優先度とは，そのバグを修正する優先順位を意味します。例えば，あるバグがほかの機能の動作を妨げてテスト作業が進まないような場合には，優先度は高く設定されます。

　あるテスターが発見したバグは，既にほかのテスターによって登録されている場合もあります。そのため，事前にデータベースを検索して，新たに発見したバグであることを確認してから登録します。登録されたバグの原因が，実装の誤りにあるならば，それを修正するようプログラマに割り当てられます。プログラマはデータベースに登録された情報を基にバグの修正作業にとりかかります。

△　図をクリックすると拡大されます 図4●バグ修正の流れ

　このとき，バグの再現手順が明確でない場合，プログラマがテスターに対してさらに情報を求めます。テスターとしては，情報不足によってこのような余計な時間を費やすことがないよう，正確かつ詳細な情報を登録する必要があります。ときには，仕様が明確でなかったためにバグとなっている場合もあります。そのときは，製品仕様の責任者であるプログラム・マネージャに対して仕様を確認します（図4）。

　プログラマに割り当てられたバグ修正が行われ，生成物に反映されると，バグ管理データベースを通じて修正の確認がテスト・チームに依頼されます。新しくビルドされた生成物で，その修正を確認すると，ようやくバグ報告に対する作業が終了となります。何らかの原因でバグが修正されていなかったら，プログラマに再度確認します。このようにテスターは，報告したバグの状況を見守り，確実に修正されたことを確認する責任があります。

　また，テスト結果の報告は，バグの報告だけでなく，各機能の品質基準への達成度を報告する作業も担っています。これは，スケジュールの立て直しなどに必要になります。

　スケジュール管理を担当するプログラム・マネージャは，プロジェクトが進行している途中に，全体の進ちょく状況を把握する必要があります。そのとき，どの機能がどこまでの品質に達しているか（このまま出荷しても問題ない程度か，品質上多くの問題が残っているのか）という報告をテスト・チームから受け，スケジュールを立て直したり，十分な品質に達しそうもない機能を削除したり，といったことを検討します。

開発者全員が一斉にテストしてバグを洗い出す
　ここまでに説明してきたテスト仕様書の作成，テスト手順の作成・実行といった作業は，スケジュールに沿って計画的に行うテスト作業です。マイクロソフトではこういった作業のほかに，半日や1日といった短い期間で，特定の機能に集中して，バグ探しをするという施策をよく行っています。この施策には，テスターだけでなくプログラム・マネージャやプログラマも参加し，各テスターも自分の担当以外の機能を試します。

　また，このほかにもプログラムを集中して使ってみるという週を設けています。各メンバーが開発中のVisual Studioを使って実際にアプリケーションを作成してもらい，バグを見つけ出すという施策も行っています。こういった施策は大変に有効です。通常のテスト作業とは異なった視点から開発中の製品を使用することで，製品仕様書・テスト仕様書を基にしたテストでは見つからなかった重要なバグも実際よく発見されています。テスト・チームでは，このほかにも様々な施策を実行することで，品質上のすべての問題を洗い出す作業を行っています。

おわりに
　今回は，テスト・チームが製品の品質を保証するために行っている作業について，その概略を説明させていただきました。プロジェクトの開発工程の中で多様な作業が発生していることが理解していただけたかと思います。次回は，これらの作業を効率的に実行するために，テスト・チームで行っている工夫や，具体的な仕組みを紹介する予定です。