テスト計画・不具合やバグは優先度をつけてトラッキングする
不具合やバグの管理では優先度を決める事が大切です
ソフトのテスト報告書では、見つけた不具合やバグの優先度の付け方と、優先度に従ったトラッキングの方法についても具体的に書いておく必要があります。優先度の付け方は、重要度を重視するのか、発生のし易さを重視するのか、サービス提供への影響度を重視するのか、重視する項目を明確に決めておくと判り易いです。
ソフトのテストで見つけた不具合やバグの件数が増えてくると、対応の優先度付けと対応の進捗状況のトラッキングがとても大切になってきます。次のリリースまで不具合やバグの全てがが対応でれば良いのですが、不具合やバグの件数が多いそうはならないのが現実です。そうなると、重要性の高い不具合やバグから先に対応を進めるような優先度による対応の管理が大切になってくるので、不具合やバグの優先度の割り振りと、優先度に従ったトラッキングが明確になっている事が重要になってきます。
この記事では前の記事に続いて、不具合やバグの管理に必要な以下の７項目のうちの６項と７項について紹介します。
- 不具合の分類（バグ、テスト設様間違い、テスト実施ミス、環境不備 など不具合をどう分類するのか）
- 不具合の記録（不具合の記録では不具合の再現方法と管理情報を漏れなく書く）
- 不具合の記録方法（何かのシステムに入力するのか EXCEL 表に書くのか）
- 状態定義（個々の不具合やバグはどんな状態を遷移して最終的に終了状態に行きつくのか）
- 終了判断（誰がどんな基準で不具合の対応が終了したと判断するのか）
- 優先度付け（不具合やバグの調査や対策の優先度は誰がどうやって決めるのか）
- トラッキング（個々の不具合の状態遷移は誰がどうやって監視して遅れの対策をするのか）
６．不具合やバグの優先度付け
不具合やバグの対応の優先度の決め方にもいくつかあります。どれが正解という訳ではなくそれぞれのソフト開発プロジェクトに適した決め方を使うのが良いのですが、どのようにして優先度を決めるのはは、テスト計画で明確にしておきましょう。参考にいくつかの例を挙げてみます。
（１）重要度を元に優先度をつける
不具合やバグの重要度に従って対応の優先度をつけるのは、割と判り易い考え方です。不具合やバグの重要度というのもいろいろな定義がありしますが、この記事ではその不具合やバグが発生した時にユーザがどれだけ困るのかと言うのを重要度と言う事にします。やや乱暴ですが、例えば家庭用のHDDレコーダを例にして重要度をもう少し具体的に書くと以下のようになります。
重要度大：装置や機能が全く使えない、HDDレコーダなら電源を入れても起動しない
重要度中：主要な機能が使えない、HDDレコーダなら新しい番組の録画ができないなど
重要度低：補助的な機能が使えない、HDDレコーダなら録画一覧画面の端が切れて見えない
ソフトのデバッグを進めるとい視点から見ても、重要度が大のバグがあるとそもそもテストが始まらないので大至急対策をする必要がありますし、例のような重要度が中のバグがあると録画した番組の再生機能のテストができないのでこれも急いで対策をする必要があります。このように、不具合やバグの重要度が大きい物に高い優先度をつけるというのは、割と判り易い考え方です。
（２）問題の起こり易さを元に優先度をつける
不具合やバグが元で何等かの問題が起きるのですが、起こり易い問題は優先度を高くしましょうという考え方もあります。特殊な条件で滅多に起きないような問題よりは、すぐに起こる問題を先に片付けようという考え方ですね。ここでもHDDレコーダを例にして問題の起き易さを具体的に書くと以下のようになります。
必ず起こる：普通の使い方をして必ず起きる、HDDレコーダなら録画の操作をすると起きる
たまに起こる：幾つかの条件が揃うと起きる、HDDレコーダなら日曜に火曜22時の録画を予約すると起きる
滅多に起きない：幾つかの条件と確率が揃うと起きる、HDD レコーダなら日曜に火曜22時の録画予約をすると、200回に1回くらいの頻度で起きる
必ず起こるような問題が残ったままソフトをリリースしては、コールセンターの電話が鳴りやまなくなるので、最優先で対応をする必要があるので、起こり易い問題ほど優先的に対応するというのも納得のいく優先度の付け方です。
（３）ユーサービスへの影響度を元に優先度をつける
重要度も起こり易さもどちらも大切なので、その両方を合わせて考えようというのが、ユーザサービスへの影響度という考え方です。簡単に言えば、重要度が大で起き易い問題は影響度が最大で、重要度が小で滅多に起きない問題は影響度は最低と考えるというものです。
重要度や起こり易さが中間の物も含めて順位付けするために、重要度の大/中/小 の順番に3/2/1 と値を割り振り、起こり易さも必ず起こるに 3、たまに起こるに2、滅多に起きないに 1 と値を割り振って、重要度と起こり易さの掛け算で求まる値が大きいものから重要度を割り振るという考え方です。
不具合やバグの１つ１つに対して、重要度と起こり易さの２つの値を決めないといけないので少し手間は掛かりますが、不具合やバグの件数が多い場合にはこのユーザサービスへの影響度を元に優先度をつけると、納得性の高い優先度となります。
（４）ソフトのリリースに対策を入れるかどうかで重要度を付ける
前述の３つとは少し考え方の方向が違いますが、不具合やバグの対応の成果は次にリリースされるソフトに織り込まれて市場に提供されて初めて効果が出ます。と言う事は、次のソフトのリリースのタイミングまでに対策が終えられるかどうかも非常に重要になってきます。
不具合やバグの対応では、限られた時間と人と機材を使って最大の効果を出す事も大切なので、次のリリースに間に合う不具合やバグに注力して対策を進めるという考え方もあります。そのために、次のソフトのリリースで対策を入れる不具合やバグは優先度を高くし、次回よりも後のリリースに回すものは優先度を下げるという優先度付けるといのが、このやり方です。
７．不具合やバグのトラッキング（進捗管理）
不具合やバグに優先度を割り付けたら、優先度の高い不具合やバグがちゃんと対策が進んでいるのかのトラッキングの方法についてもテスト計画の段階でやり方を決めておく必要があります。トラッキングは日本語では進捗管理が一番近い用語ですが、海外の開発拠点との連携作業をする場合には Tracking と呼ぶ事も多いので、グータラ親父は国内でも不具合やバグについては進捗管理と呼ばずにトラキングと呼んでいました。このトラッキングについてテスト計画を作成する時に注意する事が３点あります。
（１）不具合やバグの管理データベースの更新
不具合やバグは検出した時点で管理用データベースであるトラッキングシステムやEXCELの表に登録します。その後、再現や調査や対策などの実際のデバッグ作業が進むのですが、作業の進捗に同期してデータベースの内容が更新される事が管理の第一歩です。
あまりにも当たり前の事のように聞こえるのですが、実際にソフトのデバッグ作業を進めている場面では、担当者は複数の不具合やバグのバックログを抱えて目前に迫ったソフトリリース日程に追い立てられるというデスマーチ状態になる事が多いです。その様な時に、実際のバグ修正に貢献しない管理用データベースの更新はちょっと気を抜くと後回しにされがちです。
管理用データベースの更新が滞ってしますと、どこまでのバグが修正されているのか現状が見えなくってしまうので、そのような状況にならないように毎日の作業の最後には必ず管理用データベースの更新をする、というような作業ルールを定めておく等の対策も大切です。
（２）優先度別・状態遷移別の残件数の確認
不具合やバグの対応状況を数値的に確認する場合には、優先度と状態遷移とで作ったマトリクス表で残件数を見ると状況が判り易くなります。ソフト開発プロジェクトの規模にもよりますが、毎週１回くらいの頻度でこのマトリクス表での残件数を見ていると、デバッグの進み具合やリリースの時までにどの程度のバグ修正が間に合いそうなのか、ある程度の予測を付ける事ができます。不具合やバグの残件をどんなフォーマットでどの程度の頻度で管理するのかは、テスト計画で具体的に決めておきましょう。
（３）リリース時期が迫ってきたら優先度の見直しを
不具合やバグは優先度をつけて対応しているのですが、リリース時期が近づいてきたら一度、残件の優先度の見直しをする事をテスト計画の中に組み入れておくことをお勧めします。リリース前の数週間は、ソフトの品質を左右する大切な期間です。この期間を有効に使うには正しい優先度管理が必要なので、そのための優先度見なおしのタイミングをテスト計画に入れておきましょう。
デバッグ能力に余裕があって残バグの件数が少ないなら、優先度が低く次のリリースに先送りしていた不具合やバグの優先度を上げて、今回のリリースに織り込む事ができるかもしれません。逆にデバッグ能力が不足していて残バグが多い場合には、優先度の高い不具合やバグのうち何件かの対応を先送りして、浮いた人員を最優先の不具合やバグの対応の支援に割り当てるほうが良いかもしれません。
優先度の見直しは頻繁に行うものではありませんが、リリース時期が近づいてきたら少なくとも１度は実施して、現状の優先度のままで最後まで走りぬいていいのかどうか、再確認する機会を持つようなテスト計画にしておく事をお勧めします。