|
マイクロソフト プロダクト ディベロップメント リミテッド
ディベロッパー製品開発統括部 テスティンググループ
根岸 睦
最近,黒酢にはまっています。どちらかというと私は「夜型」の人間なのですが、寝不足の朝でも黒酢を飲むと不思議にパッチリ目が覚めます。読者の皆様で「夜型」の方がいらっしゃいましたら,ぜひ試してみたらいかかでしょうか。
今回のテーマは,テスト作業の定量的な評価です。これまで2回にわたってテスト・チームの概要や作業内容などについて説明してきました。今回は,開発中の製品の品質を評価する方法と,さらに評価に携わるテスターを評価する方法についてもお話します。
Visual Studioの開発チームでは,様々なものを数値化して定量的評価というものを実践しています。特にプログラム開発(Dev)とテスト作業(QA)の2つの作業状況を数値化することが大切です。 これらは日単位でグラフ化されており,テスト作業や製品が目指す到達点の設定が容易にできます。また,開発プロセスでの障害や製品自体の障害(バグ)の傾向もまとめやすくなります。最終的には,プログラム開発とテスト作業の方向性や人員配置,あるいは製品仕様にフィードバックされていきます。そのためにも,客観的かつ精密に把握できる定量的評価は重要なのです。 では,Visual Studioチームにおける具体的な評価方法を紹介していきましょう。
期間や機能で区切って製品開発する (1)について具体的には,開発開始時→ベータ1→ベータ2→最終製品出荷時といった開発段階に分かれて,その開発段階を順に踏んでいって完成に近付きます。また(2)については,例えばWindows FormやASP.NETなどのように,機能別にチームが分かれており,各チームが自分の機能を開発していって,出荷時に1つのパッケージにまとめられます。製品品質の定量的評価は,このような期間や機能ごとに行われるのです。
開発段階ごとに品質基準も変わる 例えば,開発段階を追うにつれて,製品の品質基準をより高度な内容に設定します。「アプリケーションの負荷対応」の目標基準値が,ベータ1では「前バージョンと同等」だったのが,ベータ2では「前バージョン以上」になり,さらに最終製品出荷時には「前バージョンの2倍強」というようにハードルが高く設定されます。 あるいは,ベータ1にはなかったものが,ベータ2で設定されることもあります。仮にベータ2の基準として予定されている「前バージョンとの互換性」に当てはまる障害が報告されたとしても,ベータ1の期間にその障害を優先的に修正することはしません。ベータ1では「アプリケーションのクラッシュ阻止」のような項目が,品質基準に設定されています。ベータ1の期間では,ベータ1に対して設定されている品質基準に到達することが優先されます。
図1は,Visual Studioのベータ1段階における,品質評価項目と,その基準への到達度を示したものです。本物の項目やデータを出すことは,会社の決まりでできませんが,ある程度現実に近いものを,多少の脚色も交えて,7つの品質評価項目に絞って掲載しています(実際には21個の項目がありました)。 これらは大項目と呼ばれるもので,一つひとつはさらに細かい品質評価項目に分かれています。ベータ1より後のベータ2や最終製品出荷時では,ベータ1になかった新しい項目を追加し,ベータ1で既に設定している項目も基準を高く設定し直します。
テスト結果を品質評価基準に照らし合わせる テスターは手動や自動を交えて,製品上で一連のテスト操作を行います。そして,先に挙げた品質評価基準と照らし合わせて,各機能におけるテスト結果(成功/失敗)をまとめます。
図2は機能A~Dおよび製品全体について,品質評価基準に到達しているかどうかをまとめたものです。実際にはもっとたくさんの機能についてまとめています。各機能の評価は,「品質基準に到達」「品質基準に未到達」「障害によるテスト継続不可」の3種類が,それぞれ全体の何%かという数値で表します。図1では単純な到達度だけでしたが,図2では未到達を分類しているところにも注目してください。これらの各機能の加重平均を算出すれば,製品全体の評価結果も得られます。 製品の評価作業の進ちょくと,その結果である品質基準の到達度は日々更新され,各機能のチーム・メンバーに電子メールで送られます。各自はその情報を基にして,プログラム開発とテスト作業の進ちょく度,今後の展望などを把握します。
テスト結果を数値化する評価基準到達度 まず,機能Aは37.4%しか基準に到達しておらず,57.6%が未到達です。さらに5%が何からの障害が原因で,テスト継続が不可能な状態です。ようするに残り62.6%(未到達57.6%とテスト継続不可5%の合計)を品質評価基準に到達させる必要があります。一方,機能Dは67.3%が基準に到達しています。この開発段階で基準に到達させなければならないのは,残り32.7%の機能です。 これだけ到達度が違うのは,その機能ならではの特徴を反映しているためです。例えば,到達度が最も高い機能Dは,インストーラやセットアップ部分など製品の基本的機能によく見られます。それが動かなければ,製品自体どうすることもできない機能です。逆に到達度が最も低い機能Aは,新機能またはユーザーによって使い方が変わる機能,あるいは製品の中で広範囲にわたる機能によく見られます。機能が広範囲にわたれば,当然,複数の到達基準にかかわるので,どうしても開発に時間がかかる傾向があります。 |