テスターの評価は解決された障害の内容で決まる
 次にテスターに対する定量的な評価方法について説明しましょう。基本的にテスターの責務は,製品の品質を管理し,最終的に保証することです。単純に考えると,多くの障害を報告したテスターが製品の品質の管理,向上に最も従事しているという印象を与えるかもしれません。

 しかし,テスターが報告した障害を,テスターの判断だけで解決することはできません。実際に障害を修正するプログラマやプログラム・マネージャは,テスターが報告した障害を,再現手順や再現環境,製品の仕様やユーザーに与える影響など,様々な角度から調査します。その結果,障害報告データベースに解決方法を登録します。その解決方法はテスターに伝えられ,テスターとの間で解決内容を確認し,その障害報告は閉じられることになります。当然,テスターが同意できない場合は,対策を再度検討することになります。

 そのため,テスターによる障害報告が,製品の品質向上や管理にどのような形で寄与したかは,プログラマやプログラム・マネージャによって出された解決方法によって測ることができます。

 さらにテスターによって報告された障害報告は,製品品質の向上や管理に対して意味をなさなければ,その本質的な意味がありません。またテスター自身の評価は,単に報告した件数を競うだけでなく,いかに効率よく問題となる障害を的確にレポートしているかにかかってきます。そのためには,図3に示した障害報告件数の内訳をさらに細かく見ていきます。

 表2は,機能別の処理済み件数の内訳です。前述した「修正済み」「重複」「仕様など」,そして「未処理」の件数も示しました。それぞれ各機能を担当するチームがあり,表2を見るとそのチームの評価が分かります。

表2●機能別の処理済み件数の内訳

 ここでは障害報告を,プログラマとプログラム・マネージャが判断した解決方法によって分類しています。テスターが障害だと認識し,報告しても,製品の仕様を決め,実装するプログラマやプログラム・マネージャにとっては,必ずしも実装による修正が必要になるとは限りません。

 この辺りは,なかなか現場での判断が難しいところで,仕様を完全に把握してテストすれば修正を要する問題を的確に指摘できるのですが,開発(実装)とほぼ同時期にテスト作業が始まる開発形態では,開発半ばでの仕様変更がしばしばあります。そのため,なかなかテスト全般を通して,テスターが常に仕様を完全に把握することは困難です。従って,テスターは「疑わしきは報告せよ」という姿勢でテストせざるを得ないのです。

 テスターは障害だと認識して報告した報告でも,プログラマやプログラム・マネージャが調査した後では,その判断が変わってきます。また,テスターは基本的にコンパイル後の生成物をテストするのが役目で,ソース・コードなどを見ながらテストするわけではありません。そのため,テスターが報告した障害は実際に自分の目で確認したものなのですが,実際にソース・コードを見ながら実装しているプログラマや,製品の仕様を管理しているプログラム・マネージャはより深いレベルで判断しています(当然,仕様変更のリクエストやテスターが報告した障害をプログラマが取り違えて判断している場合など,例外はあります)。

報告した障害の分類からテスターを評価する
 では,表2を例に,解決された障害報告の分類項目を使ってテスターを評価してみましょう。

●修正済み
 修正済みの障害は,何らかの修正が必要で,その修正を実装したことによって製品または機能の品質が向上(または修復)したと考えられます。従って,修正済みが多ければ,そのテスターは製品品質の向上を妨げる障害を正しくとらえていたといえます。

 表2では,機能Aチームの処理済みに占める修正済みの割合は56.5%です。これは解決された障害のうち半分は,製品に反映されていると考えられ,機能Aを担当したチームまたはテスターは,正しい視点で効率よくテスト作業を実行しているといえます。

 それに対して機能Bを担当したチームの場合は,処理済みに占める修正済みの割合が36.1%です。これは7割近くが,製品に反映されない障害報告だったことになります。このような場合には,機能Bのチームまたはテスターは,自分のテスト作業の視点が,正しいかどうか,的確に現開発段階でテストしなければならない領域をとらえているかを見直し,改善の必要があるといえます。

●重複
 重複の障害は,既に同じ障害が障害報告データベースに登録されていたということです。従って,この項目に分類される報告は,テスト作業でのムダを作ってしまっているともいえるでしょう。テスターはテスト作業で発見した障害と思われる問題を,そのまま障害報告としてデータベースに登録するのではなく,障害の再現性や再現手順の明確化,そしてその障害がまだデータベースに登録されていないことを確認したうえで,報告しなければなりません。テスターには,そのような作業を効率よくこなせる力量が求められます。

 そのため,重複が多いテスターは,障害を報告する前にデータベースで重複の確認を怠っていると思われます。従って,そのような傾向を持つテスターに関しては,注意の徹底が必要になります。実際には何万個という障害報告のすべてを毎回チェックするわけにはいかないので,重複調査にかけられる時間との兼ね合いとなってしまいます。

 表2を見ると,機能Bの障害報告件数は機能Aを上回りますが,重複数が機能Aの2倍になっています。さらに,修正済みの割合と重複の割合を比べるとほぼ同じになっています。この点から,機能Bチームが報告した障害の2つに1つが重複しているものだったと考えられます。この場合,機能Bチームは,重複した障害を報告したことによって,本来見つけるべき障害を見つけるための労力と時間をムダに費やしてしまったと考えられます。テスト作業自体の改善が必要です。

●仕様など
 この種類に分類される障害報告は,テスターがあまり仕様を考えずに報告した場合によく見られます(新人のテスターによくあることです)。

 ただ,中には単なる不注意が原因の場合だけではなく,実際に開発期には最終判断が下されるまで仕様が決まらないことがあるため,一度仕様などとされた障害報告が各チームでの議論を通じて仕様変更を導き,最終的には修正を要する障害に変わることも,まれにあります。その間の議論は長々と続く場合があります。

 また,障害と思われる問題が,仕様書などを調べても明らかになっていないことがあります。実装とテスト作業がほぼ同時に進行している私たちの開発モデルでは,たまに見られるケースです。その場合テスターは,その問題が障害なのか仕様なのかの判断を,プログラム・マネージャやプログラマなどに求めることもあります。このようなとき,テスターは意図的に,その問題を障害報告データベースに登録します。

 機能BとCのようにこれに分類された障害が多い場合,テスターはテスト作業でムダを生じていることになります。その場合,テスターはテスト作業自体を見直す必要があります。

障害を深刻度によって分類する
 私たちVisual Studio開発チームでは,障害報告を重要度の観点からも分類・評価しています。重要度の高い障害の発見/報告/修正は,品質の向上や安定には欠かせません。障害の重要度とは,「深刻度」と「優先度」の2つに分けられます。ここでは,障害の深刻度に絞って話を進めましょう。

 私たちの現場では,深刻度に対して以下のような認識を持っています。 ・深刻度1:最も深刻で,その障害が起きると,その機能自体の実行が妨げられる恐れがあるものです。つまり,その障害によってそれ以降の機能操作が不可能になるものです。具体的には,アプリケーションのクラッシュや,ユーザー・データを喪失する障害などが深刻度1になります。

・深刻度2:深刻度1のように機能自体が遮断されることはありませんが,ユーザーの操作に不都合を与える障害です。この種の障害は回避策が存在しますが,その回避策自体もユーザーの操作に不都合を強いるものになります。

・深刻度3,4:軽度の障害です。例えば,ダイアログ・ボックスの文字が,読解可能だが,厳密に見れば欠けている場合や,機能は全く問題ないが,コントロールの成形やダイアログ上のコントロールの配置が整っていないなどです。深刻度3,4の障害は,ユーザーがアプリケーションを操作するうえでは何も影響を与えない障害です。

 表3は機能A~Dの全ての障害報告件数を,深刻度別に表したものです。この数値は,「修正済み」もあれば,「重複」「仕様など」と分類されたもの,あるいは「未処理」「繰り越し」と,すべての項目に分布しています。

表3●障害報告の深刻度ごとの傾向

報告した障害の深刻度からテスターを評価する
 表3の障害深刻度を基に,各機能を担当したテスト・チームを評価してみましょう。比率を見ると,機能Bのテスト・チームが深刻度の高い障害をほかのチームよりも多く発見し,報告していることが分かります。

 深刻度の高い障害は,その度数が高ければ高いほど,プログラマやプログラム・マネージャが実装または仕様を計画するときに,懸念される障害です。そのため,製品開発の極めて初期の段階では多く存在するかもしれませんが,製品の品質が固まってきている開発後期にはあまり出現しない傾向にあります(そもそも,品質が安定してくる開発後期にそのような深刻度の高い障害が多数ある場合,テスターだけではなくプログラマまたは仕様を管理するプログラム・マネージャの作業自体にも疑問が生じます)。従って,この場合は,機能Bのテスト作業は効率よく実行されているといえます。

 この深刻度別による評価は,単なる障害報告の数だけではなく,各テスターが各開発段階で,深刻度の高い障害をどの程度見つけているかを調べられます。また,深刻度の高い障害は製品の出荷時点では必ず解決していなければならないものなので,その製品の管理や品質向上に対する貢献度も測ることができます。

終わりに
 今回の内容はいかがでしたでしょうか。評価というものは様々な局面からしていかなければならないものです。今回はすべてをお話しできませんでしたが,参考になったでしょうか。私自身もこの仕事を始めて間もないころは,どうしても障害報告数だけを追いがちでしたが,製品の開発過程における評価基準や障害報告が製品の品質向上や安定に与える意味というものを深くつきつめて考えていくうちに,テスト作業も様々な角度から評価できることを知りました。

 また,テストという作業は単純ではなく,テスターには障害の発見以外にも様々な要素が要求されるものだと思いました。皆さんの現場ではどうでしょうか。3回にわたったテスト・チームの話も今回が最後になりました。Visual Studioの開発チームの中でもあまり表に出る機会が少ないといわれているテスト・チームが,皆さんにはどう写ったでしょうか。

 次回はVisual Studio開発チームのプログラム・マネージャ(PM)が担当し,Visual Studioの開発プロジェクト全体を管理して製品リリースにこぎ付けるための「プロジェクト・ライフサイクルとグループ・マネージメントの実際」について説明する予定です。



◆会社紹介◆

マイクロソフト プロダクト ディベロップメント リミテッド」は,日本のマイクロソフトの中で研究開発を担当する会社。日本のマイクロソフトの組織は,2つの会社で成り立っており,ほかにマーケティング,製品の流通,サポート業務を担当している「マイクロソフト株式会社」がある。

日経 xTECH SPECIAL

What's New!

経営

クラウド

アプリケーション/DB/ミドルウエア

運用管理

ネットワーク/通信サービス

セキュリティ

もっと見る