マイクロソフト プロダクト ディベロップメント リミテッド
ディベロッパー製品開発統括部 テスティンググループ
根岸 睦
最近,黒酢にはまっています。どちらかというと私は「夜型」の人間なのですが、寝不足の朝でも黒酢を飲むと不思議にパッチリ目が覚めます。読者の皆様で「夜型」の方がいらっしゃいましたら,ぜひ試してみたらいかかでしょうか。




 今回のテーマは,テスト作業の定量的な評価です。これまで2回にわたってテスト・チームの概要や作業内容などについて説明してきました。今回は,開発中の製品の品質を評価する方法と,さらに評価に携わるテスターを評価する方法についてもお話します。


イラスト:岡本 敏

 Visual Studioの開発チームでは,様々なものを数値化して定量的評価というものを実践しています。特にプログラム開発(Dev)とテスト作業(QA)の2つの作業状況を数値化することが大切です。

 これらは日単位でグラフ化されており,テスト作業や製品が目指す到達点の設定が容易にできます。また,開発プロセスでの障害や製品自体の障害(バグ)の傾向もまとめやすくなります。最終的には,プログラム開発とテスト作業の方向性や人員配置,あるいは製品仕様にフィードバックされていきます。そのためにも,客観的かつ精密に把握できる定量的評価は重要なのです。

 では,Visual Studioチームにおける具体的な評価方法を紹介していきましょう。

期間や機能で区切って製品開発する
 最初に製品開発の大枠を把握してもらいましょう。Visual Studioに限らないことですが,Microsoft製品は,長期間にわたって大規模な開発することになるため,(1)開発期間を段階ごとに分けて進める,(2)製品を機能単位に分けて開発する——という開発スタイルを採ります。

 (1)について具体的には,開発開始時→ベータ1→ベータ2→最終製品出荷時といった開発段階に分かれて,その開発段階を順に踏んでいって完成に近付きます。また(2)については,例えばWindows FormやASP.NETなどのように,機能別にチームが分かれており,各チームが自分の機能を開発していって,出荷時に1つのパッケージにまとめられます。製品品質の定量的評価は,このような期間や機能ごとに行われるのです。

開発段階ごとに品質基準も変わる
 複数の開発段階を持つ私たちの開発の枠組みでは,評価基準を各段階で変えています。ベータ1,ベータ2,最終製品出荷時と,その開発段階に応じて,製品が到達しなければならない品質基準を設けているのです。製品全体や各機能がこの基準に到達しなければ,ベータや最終出荷時を問わず,その開発段階を終えることはありません。

 例えば,開発段階を追うにつれて,製品の品質基準をより高度な内容に設定します。「アプリケーションの負荷対応」の目標基準値が,ベータ1では「前バージョンと同等」だったのが,ベータ2では「前バージョン以上」になり,さらに最終製品出荷時には「前バージョンの2倍強」というようにハードルが高く設定されます。

 あるいは,ベータ1にはなかったものが,ベータ2で設定されることもあります。仮にベータ2の基準として予定されている「前バージョンとの互換性」に当てはまる障害が報告されたとしても,ベータ1の期間にその障害を優先的に修正することはしません。ベータ1では「アプリケーションのクラッシュ阻止」のような項目が,品質基準に設定されています。ベータ1の期間では,ベータ1に対して設定されている品質基準に到達することが優先されます。


△ 図をクリックすると拡大されます
図1●ベータ1における品質評価基準と到達度

 図1は,Visual Studioのベータ1段階における,品質評価項目と,その基準への到達度を示したものです。本物の項目やデータを出すことは,会社の決まりでできませんが,ある程度現実に近いものを,多少の脚色も交えて,7つの品質評価項目に絞って掲載しています(実際には21個の項目がありました)。

 これらは大項目と呼ばれるもので,一つひとつはさらに細かい品質評価項目に分かれています。ベータ1より後のベータ2や最終製品出荷時では,ベータ1になかった新しい項目を追加し,ベータ1で既に設定している項目も基準を高く設定し直します。


テスト結果を品質評価基準に照らし合わせる
 図1に示した品質評価基準は,製品全体に対して7つの項目で到達度を示しました。これらの項目は,テストをするうえでの方針のようなものです。しかし,実際のテスト作業は,評価基準の項目ごとに分かれているというより,製品を構成する各機能に沿って行われることが多いのです。

 テスターは手動や自動を交えて,製品上で一連のテスト操作を行います。そして,先に挙げた品質評価基準と照らし合わせて,各機能におけるテスト結果(成功/失敗)をまとめます。


△ 図をクリックすると拡大されます
図2●機能別に見た品質評価基準と到達度

 図2は機能A~Dおよび製品全体について,品質評価基準に到達しているかどうかをまとめたものです。実際にはもっとたくさんの機能についてまとめています。各機能の評価は,「品質基準に到達」「品質基準に未到達」「障害によるテスト継続不可」の3種類が,それぞれ全体の何%かという数値で表します。図1では単純な到達度だけでしたが,図2では未到達を分類しているところにも注目してください。これらの各機能の加重平均を算出すれば,製品全体の評価結果も得られます。

 製品の評価作業の進ちょくと,その結果である品質基準の到達度は日々更新され,各機能のチーム・メンバーに電子メールで送られます。各自はその情報を基にして,プログラム開発とテスト作業の進ちょく度,今後の展望などを把握します。


テスト結果を数値化する評価基準到達度
 実際に図2の数値を見て,各機能の評価を読んでみましょう。データを見ると,製品全体の57.5%が品質基準に到達していることが分かります。ところが,機能別に見ると,品質基準の到達度にバラツキがあります。4つの機能のうち,最も結果に開きがある機能Aと機能Dを比べてみましょう。

 まず,機能Aは37.4%しか基準に到達しておらず,57.6%が未到達です。さらに5%が何からの障害が原因で,テスト継続が不可能な状態です。ようするに残り62.6%(未到達57.6%とテスト継続不可5%の合計)を品質評価基準に到達させる必要があります。一方,機能Dは67.3%が基準に到達しています。この開発段階で基準に到達させなければならないのは,残り32.7%の機能です。

 これだけ到達度が違うのは,その機能ならではの特徴を反映しているためです。例えば,到達度が最も高い機能Dは,インストーラやセットアップ部分など製品の基本的機能によく見られます。それが動かなければ,製品自体どうすることもできない機能です。逆に到達度が最も低い機能Aは,新機能またはユーザーによって使い方が変わる機能,あるいは製品の中で広範囲にわたる機能によく見られます。機能が広範囲にわたれば,当然,複数の到達基準にかかわるので,どうしても開発に時間がかかる傾向があります。