テスト報告書・テストの評価はまずテスト内容の評価から
ソフトのテスト報告書に書くテスト評価はまずテスト内容の良し悪しから
ソフトのテスト報告書にはテスト結果に続いて、テスト内容やテスト日程やテスト効率の良し悪しを纏めたテスト評価も書いて置きます。テスト結果については前の記事で紹介したので、この記事からはテスト評価についてもう少し具体的に紹介していきましょう。
テスト評価ではテスト計画と実施を以下の３つの観点で評価したて書くと判り易くなります。
- テスト内容の評価：テストの量や質は今回のソフトの品質の保証に最適だったのか
- テスト日程の評価：テストの日程計画は妥当だったのか
- テスト効率の評価：テスト作業のコストパフォーマンスの計画は妥当だったのか
この記事ではまず、テスト内容の評価について少し具体的にみていきましょう。
テスト内容はバグ密度とテスト密度の妥当性を評価する
テスト結果とテスト内容の評価とはどちらもテストで発見したバグを分析して評価をするという点が同じなので混同し易いのですが、分析して評価する目的を意識するとその違いが判ってきます。テスト結果はテストをしたソフトの品質の良し悪しを判断するためにバグを分析するのに対して、テスト内容の評価ではテスト項目の妥当性を確認するためにバグを分析します。
テスト項目の妥当性を確認するとは、テストの量は十分だったかとか、テストの重点領域は今回のソフトのテストとして適切だったかとか、テストでは想定していた難しさのバグを見付けられたかというような視点で、計画時に考えていた成果（＝バグの検出）ができたかどうかを確認するという意味です。順番にもう少し詳しく見ていきましょう。
計画したテストの量は適切だったのか
テスト量が少なければ見つかるバグは少ないですし大量のテストをすれば多くのバグが見つかります。どれだけのバグが見つかるかはもちろんテストの質にも影響していますが、まずはテストの数をこなさなければ多くのバグを見付ける事はできません。「テストしなけりゃバグはゼロ」なのです。
その様な視点から考えたみ時に、今回のテストの量は検出したバグの数からみて十分だったのか、足りなかったのか、過剰だったのか、まずはテストの量の良し悪しを評価します。テストの量の評価は全体のテスト量と機能毎のテスト量に分けると判り易くなります。
（１）全体のテスト量の評価
まずは全体としてのテストの量が適切だったのかを考えましょう。とはいえ、バグの検出量にはテストの量以外にも、元のソフトの品質やテストの質やテスト期間やテスト環境など、いろいろな要因が関係してきます。ですので、今回のテスト計画のテストの量が適切だっかかどうかなんて、判断するのはとても難しいです。
難しいのは確かなのですが、一つの企業や一つの開発組織であればソフトの開発能力やテストの能力が急に大きく変わる事はありません。つまり、設計・実装チームが作ったソフトに混じっているバグの数も、テストチームがそのバグを検出する能力も大きくは変わらないはずです。それならば、テストで検出したバグのバグ密度とテスト密度の対比は一定の範囲に収まるはずです。
逆に言えば、今回のテストで検出したバグ密度とテスト密度の対比が、これまでの他のテストと比べて大きくかけ離れていれば、何かが起きていると考え良さそうです。非常に曖昧な判断の様にも見えますが、同じ企業や組織のバグ密度とテスト密度を５年分程度蓄積すれば、大体この組織がこの程度のテスト密度でテストをすればこの程度のバグ密度でバグを検出するだろう、という妥当なレベルが見えてきます。過去のテストのバグの密度を一つの基準にして今回のテストのバグ密度を見る事で、全体のテストの量が妥当だったのかどうかを判断するという事ですね。
（２）機能毎のテスト量の評価
機能毎のテスト量の評価は、今回のテスト対象のソフトと比較の対象にする他のテストの対象のソフトとに類似の機能が無いと比較ができないので、類似の機能を持った装置や機器が複数ある場合や、同じ装置や機器向けの別バージョンのソフト開発が複数ある場合にだけ使える方法です。
機能毎のテスト量の評価も全体的なテストの量の評価と方法は同じです。ソフトの機能毎にテスト密度とバグ密度を計算して、他のテストの結果と比較する事で、今回のテストの機能毎のテスト量の妥当性を検討する事ができます。特定の機能でテスト密度とバグ密度の関係が他の機能と大きく異なっていた場合には、何か問題があったのではないかと考えてテスト量を振り返ってみるのが良いかも知れません。
テストの重点領域に対するテスト計画は妥当だったか
テストの重点領域の決め方もテストする対象のソフトによっていろいろな決め方がありますが、大きくわけると２つの決め方があります。ソフトの機能で分類して重点領域を決めるのか、バグの潜在する可能性で分類して重点領域を決めるのかです。どちらの決め方でも、テストを計画する時点では重点領域に対しては他の領域よりも多くの期間や工数を掛けてテストを行うように計画を立てます。このテストの重点領域に対するテストの計画が妥当だったのかどうかを、テストの結果から判断してその内容をテスト報告書に書きます、
重点領域に対するテスト計画の妥当性の判断はなかなか難しくて、最終的にはテストリーダやテスト担当者の感覚による判断になるのですが、それでもそのような現場の判断を報告書に書いて置くことは大切です。
（１）ソフトの機能で分類して重点領域を決める
新規のソフト開発では、十分な時間や費用が取れるならば全ての機能について網羅的にテストをするのが本来のテストの進め方です。しかし現実には、リリースまでの限られた期間に限られた費用で最も効率的なテストを実施せざるを得ない場合が多いです。そのような場合には当然、リリースするソフトの機能毎に品質の重要性を考えて重要な機能を重点的にテストをする、というテスト計画が立てられます。
このような場合、テスト報告書での重点領域に対するテスト計画の評価としては、計画時に重点を置くと決めた機能で十分な密度でバグを検出できたかどうか、から判断する事になります。今回のテストにおける機能別のバグ密度を計算して、重点を置くと決めた機能で十分なバグ密度でバグを検出できたか、という観点でテストの結果を分析してテスト計画が妥当だったかどうかを判断します。
（２）バグの潜在する可能性で分類して重点領域を設定する
既にあるソフトに対して機能追加や不具合修正などの改造開発を行なう場合に一番注意すべきは二次不具合の混入です。機能追加や不具合修正によるコードの変更が、既存の機能に想定外の影響を与えて新たバグを埋め込んでしまうと、エンドユーザから見ると今まで使えていた機能に問題が起きるので、デグレに見えてしまいます。
そのような事を避けるために、機能追加や不具合修正では修正による影響範囲を洗い出して、影響範囲に対して重点的にテストを行うというテスト計画を立てる事が良くあります。この場合でも、洗いだした影響範囲の全てに対して網羅的にテストを行えるのが理想ですが、限られた期間や費用の中ではやはり今回の修正による影響度が高そうな、言い方を変えると二次不具合が入り込んでいる可能性が高そうな領域に重点を置いてテストを計画するという方針を取る事もあります。
この場合でも、重点を置くと決めた領域でのバグ密度が他の領域に比べて高かったのか、言い換えると重点を置いた領域で十分なバグを見付けられたかという観点でテスト結果を分析して、テスト計画の妥当性を判断します。
複雑なバグを検出するテストの計画は妥当だったか
テスト計画を立てる時にはテストの質についての方針も考えていると思います。質の高いテストとはテストで発見できずに見逃すバグが少ないテストの事です。しかし見逃すバグを減らすには、複数の条件が重なった時に起きる複合条件バグや低い発生居頻度でしか起きない確率発生バグを検出するためのテストの比率を高める必要が出てきて、テストの費用や期間が大きく膨らみます。
限られた費用と期間の中でテストを実施しなければならないので、テスト全体として掛ける事のできる費用や期間のうちどれだけの割合を複合条件バグや確率発生バグの検出に割り当てるのかは、テスト計画で検討する大きな方針の１つです。複合条件バグや確率発生バグの検出に割り当てた費用や期間に対して、それらのバグを十分な量や密度で見つける事ができたかという視点で、テスト計画での費用や期間の割り当ての妥当性を判断します。どれだけの密度でバグを見付けていれば良いかという判断基準はなかなか難しのですが、類似のテスト結果と比較して今回のテストの妥当性を判断する、というようなやり方でも良いので何等かの判断を出してお置くのが良いです。
テスト日程やテスト効率に対する評価も必要です
テスト報告書に書くテスト計画の良し悪しは、テスト内容についての評価の他にテスト日程についての評価があります。テスト計画の良し悪が書けたら、最後はテスト効率についての評価です。次の記事てはこの２つについて具体的に紹介していきます。