テスト報告書・テスト計画の評価にはテスト効率についての評価も書く
テスト評価にはテスト作業の効率についての評価も書く
ソフトのテスト報告書には、テスト評価としてテストの作業効率についても書いて置きます。テストの作業効率は、実施したテストの項目数をテストのコストで割って求めます。テストの良し悪しを評価するテストの効率としては、テストの成果であるバグ数を掛かったコストで割って測るのが良いのですが、バグ数はテスト対象のソフトの質に大きく左右されるので今後のテスト計画の改善の指標としては使い難い面があります。そこでグータラ親父はテストの作業効率をテスト効率の代用品として使っていました。
テスト評価のうちテスト内容の評価とテスト日程の評価について前２つのの記事で紹介したので、この記事ではテスト効率の評価について具体的に紹介していきます。
テスト効率の評価はテスト作業項目数かテスト確認項目数で測る
テスト効率とはテストの成果を掛かったテストコストで割って得られるテストについてのコストパフォーマンスですが、テストの成果の数え方によっていろいろなテスト効率が考えられます。代表的な物は以下の4つでしょうか。
- テスト作業項目数/テストコスト：テスト作業量についてのコストパフォーマンス
- テスト確認項目数/テストコスト：テスト確認内容についてのコストパフォーマンス
- 検出バグ件数/テストコスト ：テストで検出したバグについてのコストパフォーマンス
- 修正バグ件数/テストコスト ：テストで検出し修正したバグについてのコストパフォーマンス
テストの主な目的がバグの修正による品質改善なのでテスト効率としては４の修正バグ件数/テストコストか 3 の検出バグ件数/テストコストを使うのが良いのですが、テストで見つかるバグの件数はテスト対象のソフトの品質に左右されます。バグが多い品質の悪いソフトなら大量のバグが見つかるけど、バグの少ない良質なソフトだと少しのバグしか見つからないのは当たり前ですね。
しかしテスト効率を計算する事の目的はテスト作業そのものの作業効率の改善なので、テスト効率の値が元のソフトの品質に左右されると、計算して得られたテスト効率の値が使い難くなってしまいます。ですので、グータラ親父はテスト効率としては１のテスト作業項目数/テストコストか 2のテスト確認項目数/テストコスト を使っていました。
テスト作業項目数は簡単だけどテスト準備等の効率化が見えやすい
テスト作業項目数/テストコストで計算されるテスト効率を計算する時のテスト作業項目数は、最終的に何項目のテスト作業を実施したのかという、延べのテスト作業項目数です。例えば、機能１確認テストーＡ というテスト作業を初版のソフトに対して１回、バグ修正版のソフトに対して２回の合計３回実施した場合には、機能１確認テストーＡについてのテスト作業はのべ３回実施した事になるので、テスト作業項目数として３回と数えます。
このような数え方で全てのテストについてテスト作業項目数を数えて合計し、掛かったテストコストで割り算して得られるテスト効率は、テスト作業をどれだけ効率的に実施できたかを示す指標になります。テスト作業では、実際のテストを行っている時間の他にも、テスト環境を準備したりテストの後の後片づけのような作業も必要です。このようなテスト前後の時間は、同じテスト環境を使うテストを一気に実施する事で節約する事ができます。
テスト作業項目数で計算したテスト効率の値は、このようなテスト準備等も含めたテスト作業の効率を表すので、例えば前回のテストに比べてどれだけ工夫して全体のテスト作業を減らす事ができたか、というような評価に役に立ちます。
テスト確認項目数はソフト品質不足に対するテスト管理の状況の判断に使える
テスト確認綱目数/テストコストでは、先ほどとは逆に同じテスト項目は何度繰り返し実施した場合でも１項目として数えます。機能１確認テスト-A が初回を含めて３回実施された場合でも最終的にソフトの品質を評価する時に意味を持つのは最後のテストの結果だけです。それ以前の２回の結果は、途中のデバッグ作業等では活用されるでしょうが、最終的なソフトの品質を示すのは最終回のテストの結果がＯＫかＮＧかです。
最終的なソフトの品質の良し悪しを判定するために必要なのは、延べ何回のテスト作業を実施したかではなく、何件のテスト項目をテストしたかなので、そのような視点でテスト効率を計算するのがテスト確認綱目数/テストコスト です。ですので、テスト確認項目数/テストコスト を計算するには、テストの終了を時点で実施が終わって OK/NG の結果が出ていたテスト項目数を数えて、その値を掛かったテストコストで割り算します。
テスト確認項目数/テストコスト の値は①テスト作業に掛かった工数と ②同じテストを何度繰り返し実施したのか の２つに大きく影響されます。特に、②の同じテストの繰り返しが多いとテスト確認項目数/テストコストの値は小さくなっていきます。言い方を変えると、テスト確認項目数/テストコスト の値がそれまでの他のテストに比較して小さすぎる時には、同じテストの繰り返しが大量に発生していると考えて良いでしょう。
そのような場合は、テスト対象のソフト品質が悪くてなかなかバグが取り切れないという状態になっている事が多く、本来ならばテストの実施を中断して、テスト対象のソフトを設計・実装部門に差し戻すようなテスト管理のアクションが必要とされている事が多いです。 テスト確認綱目数によるテスト効率の値は、このようなソフト品質の不足に対するテスト管理のアクションの良否を判断する事にも使えるので、できれば計算しておくのが良いと思います。
テストコストはテストの設計・実行の人件費が主体で設備費や機材費用も必要なら加算
テスト効率を計算すためのテストコストは、何を使うのが良いでしょうか。テストコストには、テストの設計・実行に要した人件費、テスト環境の整備に掛かった設備費、テスト用の機器やデータなどの機器費用 等があります。一般的には人件費が一番大きなコストになるので、テストコストとしてはテストの設計・実行に掛かった人件費を使うので良いと思います。
ただし、テストの自動化が進んでいる組織の場合等では、人件費よりも自動化のための開発投資や設備投資の回収（設備償却費）のほうがコストとして大きな場合もあります。或いは、大量のテストデータの準備費用が多額に必要になる場合もあります。そのような時には、設備費用やデータ等の準備費用もテストコストに含めてテスト効率を計算するのが良いでしょう。
テストの自動化は自動化による効率改善と自動化のために必要な開発投資を並べる
テスト効率を評価する時にはテストの自動化についての評価も必要になってきます。テストの自動化の割合が高いと、それだけテスト効率が良いようにも思えますが、実際にはテストを自動化するためには自動化の開発コストと自動化の維持コストが必要になります。
自動化の開発コストとは、テストの自動化のためのツールソフトを準備したり、そのツールソフトに必要な設定をしたりという、初期開発に掛かるコストです。自動化の維持コストとは、一旦開発した自動化のソフトやツール設定を、テスト内容やテスト対象の細かな変更に合わせて再調整するためのコストです。
テストの自動化はテスト効率の改善に役に立つのですが、最初に必要になる開発コストが大きいのと作りによってはかなりの維持コストが必要になるで、何度も同じテストを繰り返し実施する場面でないと、開発コストを上回るだけのテストコストの削減に貢献できない場合もあります。テストの自動化をある程度取り入れている場合には、自動化により削減できたテストコストと、自動化の導入のために必要だった開発コスト＋維持コストを併記して、本当にテストコストの削減に効果を出せているかを評価しておく事が必要です。
テストが終わったら結果を整理して次に繋げる
テストはソフトリリースの最後のフェーズなので、リリース直前のドタバタに巻き込まれる場合が多いです。場合によっては、リリース判定の直前までテストをしている事もあるでしょう。その様な場合にこそ、テストが終わった後でテストについてのテスト結果とテストの評価をしっかりとテスト報告書に纏めて、次のテストの改善に繋げるようにしましょう。