テスト計画・テスト目標（その２）プロセス品質と作業品質とテスト管理
テストの目標にはプロセス品質と作業品質と管理もあると良い
テスト目標で、納期とコストとプロダクト品質の目標の次ぎに大切なのは、テストプロセスの品質目標とテスト作業の品質目標とテスト管理の目標の３つです。目標の決め方には色々ありますが、この記事ではグータラ親父の経験を元に、レビューの頻度や指摘件数でテストプロセスの品質目標を決め、作業効率や不具合の再現率でテスト作業の品質目標を決め、日程の維持率やテストの完了率でテスト管理の目標を決めるという例を紹介します。
テストプロセスの品質目標はレビューと見つけたバグの種類に注目
テストプロセスの品質というのはちょっと判り難いのですが、要するに良いテストの設計やテストの実行の手順になっているか、というプロセスそのものの品質やそのプロセスを実施した結果が良いかというプロセス実施結果の品質です。 これらについても、定量的な目標を設定しておくと、テスト管理に使えます。それでは順番に、もう少し具体的に紹介していきましょう。
（１）テスト設計のレビュー頻度
テストの設計では具体的なテストの項目や手順を設計して、それを実際のテストの仕方に書き下したテスト要領書やテスト指示書を作成します。これらの、テスト要領書やテスト指示書は、テスト設計の成果物なので、ちゃんとできているかを確認して問題点があればこれを洗いだすために、テスト設計のレビューを行います。どの程度の頻度でテスト設計のレビューを行うのか、はテスト設計プロセスの品質を示す一つの指標となります。
レビュ頻度の表し方としては、レビュー回数/テスト要領書のページ数 や レビュー回数/改修ソースコード KLOC 等、正規化に使う分母の取り方で色々あります。どんな表し方でお構わないので、ビューの頻度を数値目標に設定しておけば、テストを計画した時点に考えていた濃さのレビューが実際にできているかを、管理する事ができます。
（２）テスト設計のレビューでの指摘率
テスト設計のレビューを行えば何件かの指摘が見つかります。指摘の件数も正規化して、総指摘件数/テスト要領書のページ数 や 総指摘件数/改修ソースコードのKLOC 等の指摘率で表す事で、レビューというテストプロセスの成果に対する目標として設定する事ができます。
ただし、レビューの指摘率は大きいほうが良いのか小さいほうが良いのか一概には言えないので、指摘率を使ったテストプロセスの管理は少し難しい面があります。これは、レビューの指摘件数が、レビュー対象のテスト仕様書やテスト手順書の出来具合と、レビューをするレビューアの技量の２つに影響されるからです。テスト仕様書やテスト手順書の出来具合が悪いとレビューの指摘件数が増えるはずですが、レビューアが十分な知識と経験を持っていないと指摘件数は小さくなります。
ですので、レビューの指摘率を目標に設定してレビューのプロセス品質を管理する場合には、レビューアの知識や経験のレベルをできるがけ一定に保つか、レビューアの知識や経験によってレビュー指摘率の判定基準を調整するような仕組みを考えておく必要があります。
（３）テストで発見した不具合の分布（単純不具合と複雑不具合ととっても複雑な不具合の比率）
テストを実施すると不具合が見つかるのですが、簡単に見つかる不具合もあれば見つけるのがとっても難しい不具合もあります。テストが進む従って簡単に見つかる不具合はどんどん修正されてて減っていくので、テストの最終段階では見つけにくい不具合が残ってきます。見つかった不具合を、不具合の見つけ易さから以下のような３種類に分類して、その比率を目標に設定するというのも、テストプロセスの品質目標の１つの方法です。
- 単純不具合：不具合の発生条件が１つだけのもの
- 複雑不具合：発生条件が２つ以上重なる事で起きる不具合
- とっても複雑な不具合：発生条件が２つ以上で、そのうち１つが確率的な条件の場合（何回か繰り返すと１回発生する、など）
テスト期間が十分に取れていて良いテスト設計ができていれば、とっても複雑な不具合もある程度の比率で発見されます。逆に言うと、とっても複雑な不具合の比率が低いとテストの期間やテスト設計に問題が潜んでいる可能性があります。
テスト作業の品質目標は効率や不具合の再現率を使う
テスト要領書やテスト指示書ができあがると、それらに従って実際のテスト作業が進みますが、このテスト作業についても幾つかの品質目標を置く事でテストの管理を行えるようになります。
（１）テストの作業効率（１つの作業で幾つの項目を確認するか）
テストの作業で確認する項目は１つのテスト作業について１つとは限りません。１つのテストの作業で２つや３つの確認を同時に実施できる事もあります。当然、複数の確認を１つのテスト作業でできたほうが、１つずつ個別にテスト作業をするよりも効率が良くなります。ですので、総てのテストで確認する項目数/全てのテストの作業数 でテストの作業効率を数値で表す事ができます。
１つのテスト作業に何件の確認を入れ込むのかは、テスト設計の段階で決まってくるので、テスト設計を終わった時点でテストの作業効率の目標値は決まります。テストが計画どおりに進めばテストの作業効率は計画値と同じですが、実際のテストは計画通りに進まない事がよく起こります。
例えば、テストをしたら結果がNGだったので、その修正を行ったソフトに対して同じテストをもう１度実施する事もあります。この場合には、１つの確認項目に対して２回のテストを実施していますので、テスト効率の低下が起きます。別の例えだと、３つの確認を１つのテスト作業で行える計画だったのが、何かの機材の準備が間に合わず１つの確認は後でもう一度やり直す事になる場合もあります。この時は、１回のテストで３つの確認を行う計画だったのが、２回のテストで３つの確認を行う事になり、やはりテスト効率の低下が起きます。
このように、計画段階でのテスト効率を目標にしておくと、テスト作業が計画どおりに進んでいるかどうかを管理する事ができます。
（２）テストの自動化率（確認項目のうちなん％を自動テストで確認できるか）
ソフトの規模が大きくなるに従ってテストの規模も大きくなってくるので、出来るだけテストを自動化しようという試みも増えてきています。自社のテストで一部でもテストの自動化が実施されているのなら、テストの自動化率も品質目標になります。 自動化で確認する項目数/全てのテストでの確認項目数 で何％の確認が自動化できているかを計算できます。
計画の時点では、既にある自動化テストと今回新たに開発する自動化テストを元に、自動化率の目標値を決めておけば、実際のテスト作業の中でどれだけの自動化テストを作れたのか、を管理する事ができます。
（３）不具合の再現率（環境や手順による不具合の再現の度合い）
テストで検出した不具合は、その後に原因を調査して対策するため同じ不具合を再現できる事が大切です。不具合を再現するには、その不具合を発生させるための条件を的確に記録しておく事が大切で、ここが不十分だと折角見つけた不具合が再現できずに、不具合の原因を見逃してしまう事も起きます。ですので、再現できた不具合の件数/発見した全ての不具合の件数 で計算できる不具合の再現率も、テスト品質の目標の１つになります。
理想的には不具合の再現率は100%なのですが、何万回か試行して１回しか起きない不具合とか、ある試験データが無いと再現しないが試験データが自由に作れないので再現できない、とかがあるので、実際には再現の出来ない不具合もあります。どの程度の比率で再現できない不具合があるのかは、これまでのテストの経験からある程度は推定できると思いますので、その値から不具合の再現率の目標を決めておくのが良いでしょう。
テスト管理にについての目標は日程の維持や成果物の完成率
最後にテスト管理についての目標です。ソフトのテストも目に見えない事が多いので管理が大切ですが、テスト管理それ自体もちゃんとできているのか監視・管理する事が必要なので、そのための目標です。
（１）テスト日程の維持率（マイルスストーンの維持率）
テストの日程管理はテスト管理の中でも一番よく使う項目です。リリース予定日までにテストが終わっていないと大きな問題になるので、しっかりと日程管理をする必要があります。テスト日程が計画通りに進んでいるかどうかを定量的に表すには、計画日までに完了したマイルストーンの数 / これまでに計画されていたマイルスーンの数 で計算される日程の維持率を使うと良いです。
例えば、今日までに１０個のテストのマイルストーンが設定されていて、そのうつ７個は計画日までに達成されたけど３個は計画日よりも遅れて達成されたとすると、今日の時点での日程の維持率は 7/10 で 70% となります。この日程の維持率の目標は100%なので、実績を監視する事で日程管理の品質の良し悪しを判断する事ができます。
（２）テスト成果物の完成率（テスト成果の完成率）
テストの日程とおなじく、テストの成果物もテスト管理として重要な項目です。テストの成果物とはテスト結果やテスト結果を分析・整理したテスト報告書などです。これらのテスト結果も、計画時にはそれらの成果が出来上がる日程が決められています。 なので、今日までに完成したテスト成果物の件数/今日までに完成が計画されていた成果物の件数 で計算される成果物の完成率もテストを管理するための目標に使えます。
例えば、今日までに３００件のテスト結果がえられる計画に対して、実際に得られているテスト結果が２５０件だとすると、成果物の完成率は 250/300 で 83% となります。テスト成果物の完成率も目標は 100% なので、実績を監視する事でテスト管理の品質の良し悪しの判断に使えます。
（３）平均の不具合対応日数（不具合発見から対応完了までの平均日数）
もうひとつ良く使うテスト管理の目標は、不具合対応に掛かった日数の平均値です。不具合が検出された日から対応が完了となった日までの日数をそれぞれの不具合事に数えて、その平均の日数を計算する事で、平均の不具合対応日数が判ります。
平均の不具合対応日数は、テストチームが記録した不具合の再現方法の正確さと、不具合を調査・対策する設計チームの調査・対策能力と、対策済のソフトを再度テストするテストチームの余力に左右されます。ですので、平均の不具合対応日数の目標値を何日にするのかはなかなか難しいのですが、これまでのソフト開発やソフトテストの経験から、同じような規模・難易度のソフト開発を探し出して、その時の実績値を目標にするのが良いと思います。