リリース判定基準・テストの実施状況は進捗確認から
テストの実施状況はどうやって判定しましょうか
ソフトのリリース判定を行う時に使う４つの判定基準（テストの品質、残存バグ、プロダクト品質、プロセス品質）のうち、この記事ではテスト品質の良し悪しを判定す方法について考えます。グータラ親父はテストの品質をテストの量と個々のテストの種類とテストの実施状況とバグの状況の４つの視点から見ていました。
テスト品質の良し悪しを判定する視点のうち３つ目がテストの実施状況です。テストには色々な種類がありますが。リリース判定の時に最も注意するのはシステムテストですので、この記事でテストと書いてある場合には、システムテストの事だと思って下さい。さて、テストは計画を立てて、テスト設計を行って、ひとつひとつのテスト項目についてテスト実行をしていきます。テストを実行してる時の状況がテストの実施状況なのですが、このテストの実施状況からテスト品質について何が判るでしょうか？
グータラ親父はテストの実施状況については、主に以下の３つの事を確認してテスト品質の判定のための情報としていました。
- テストの進捗状況
- バグの検出状況
- バグの修正状況
テストの状況はリリース判定の時期よりも早めに見始める
実は、これらの３つのテストに関する状況は、リリース判定を行う段階で見ていたわけではありません。もちろん、リリース判定の時期にこれらの状況を確認してテストの状況からソフトウエアのプロダクト品質の良し悪しを推定する事はできます。でも、リリース判定の時点でプロダクト品質が悪いと判っても、あまり嬉しくは無いですね。
リリース判定の時点になって、プロダクト品質が悪いと判った場合にできることは、リリースを止める事だけです。 しかしリリース判定の以前の時点で、例えばテストが半分程度進んだ時点で、テストの状況からプロダクト品質が不足しそうな事が推定できれば、いくつかの手を打つ事ができます。
リリース判定の前にわかれば対策できる・・・かも知れない
テストの内容が不十分ならテスト設計のレビューをする、テスト工数が不足していればテスト担当者を増やして工数不足を補う、テスト日程が不足しそうなら顧客や関連部署と事前に相談してリリース日程を再調整する、いろいろと打てる可能性のある手は考えらえれます。
もちろん、できる事とできない事はあるでしょうが、何もできないとう状況ではありません。 でも、何かできる対策を実行した結果として、プロダクト品質が改善されてリリース判定の時点で品質が良くなっていれば、ずいぶんと嬉しい状態になります。 という理由から、グータラ親父はシステムテストの工程が半分程度進んだ頃からテストの状況を定位的に監視していました。
プロジェクトにはいろいろな背景があり、安心して見ていられるプロジェクトもあれば、相当に危なっかしいプロジェクトもあります。 危なっかしいプロジェクトであればあるほど、テストが不十分な状況でリリース判定をするような羽目に陥らないように、事前の改善対策が大切になってきます。
話が少しそれてしまいましたね、それでは３つの状況について具体的にどんな事を確認していたか、順番に紹介していきましょう。
1. テストの進捗状況
まずはテストの進捗状況です。 進捗状況と改めて言葉にすると何か大変そうですが、要するに何件テストをする予定で、今は何件までテストを終えましたか？ というだけです。
少し恰好いい言葉で言えば、テスト項目で示したテスト進捗の計画値と実績値の監視、ですね。 数字で見てもいいのですが、横軸をテストの日数、縦軸を累計のテスト項目数として、計画値と実績値の折れ線グラフを書くと、状況が一目瞭然になります。例えばこんなグラフです。
計画値はラフでも構いません
テストの 計画なんてそんな簡単には推定できないですか？ 気にする事はありません。 テスト件数が全部で600件で、テスト期間が20日なら、 20日目に600件となる直線を１本引くだけでも良いのです。 その場の勢いでエイヤッと計画値を設定するのでも構いません。
もう少し実態に合わせたいなら、日毎や週毎のテスト作業担当者の人数を推定して、作業工数（人日）を横軸にとったグラフにする程度でも構いません。 計画は目安です、慣れてくれば精度良く計画線を引けるようになりますが、テスト計画が実績とよく合っていたからといって、バグがなくなる訳でもないので、少々適当でも全く問題はありません。
実績値はちゃんと集計しましょう
ただし、実際に実施したテスト項目数である実績値についてはちゃんと数えましょう。 こちらはテスト担当者毎に毎日実施したテスト件数を記録するのが良いです。 一週間分まとめて、とかするとだいたいにおいて数え間違いが起こりります。 人は忘れる生き物ですので仕方無いのです。
先ほどのグラフに実績を入れると、だいたいこんなグラフになる事が多いでしょう。
グラフから何が判るの？
こんなラフな計画値と比較して、いったい何が判るの？ と不思議に思われるかも知れません。 でも、案外と役に立つ事が判ります。 例えば一番よくあるのが、上にあるように直線の計画値に対して、テスト工程が半分進んだ時点で、計画値の半分程度しかテスト実績が出ていない状況ですね。
さて、テストの現場で何が起きているのでしょうか？ テスト計画がもともと無理のある計画だったとか、テスト作業員が予定の半分の人数しか手配できなくて人手不足とか、１つ１つのテスト項目が計画時に想定していたのに比べて２倍の手間がかかったとか、ソフトウエアの品質が良くなくてテストが進まないとか、理由はいろいろとあるでしょう。
でも１つ確実な事は、このままだと予定したテストの終了日であるグラフに右端の日が来ても、未だ実施できていないテスト残が大量に残るだろうな、という事です。 その事が、テスト期間をまだ半分残っている時点で、実績＝事実として判明したという事です。 事実が判ったうえで、何等かの対策を講じる時間として、まだテスト期間が半分も残されています。
テストチームの実力が実績を元に見えてきます
理由がどうであれ、今のテストチームのテスト実施の実力値が計画の半分なのですから、最初に計画した 600項目のテストを計画日までに終えるなら、残りの半分の日程で今までの３倍のテスト人員を投入するか、テスト終了の計画日を残りの日程の３倍先に伸ばすか、どちらかの対策がまずは必要です。
ただし、ソフトの品質が良くなくてテストが進んでいないのなら、これはいくらテスト人員を増やしても状況は良くならないでしょう。 その場合には、テストの実施は一旦凍結して、ソフト開発部署がテストに耐えるだけの品質のソフトウエアを作れるようになるまで待つ必要があります。
そんな事言っても、ソフトウエアのリリース日は決まっているし、テストに掛けられる費用も限られているので、どうにもならない！ という声が聞こえてきそうですね。
ソフトウエアは正直者
でも、残念ながらソフトウエアは正直者です。 どうにもならない物は本当にどうにもならなくって、このままの体制でテストを続けても、テストの終了予定日が来てもテストが終わっていないバグを一杯抱えた状態のソフトウエアがそこに在るだけです。
そのソフトウエアを無理やりリリースすると、市場で稼働を始めた途端に潜在バグがワラワラと発覚して、営業部門も開発部門も大騒動が起きます。 その結果、客先からはバグ修正版ソフトウエアの早急な提供と、完全な品質にするための大量の再テストの実施を要請され、結局は多額の費用を掛けてテストをする羽目になります。
ソフトウエアは、バグが残っていれば必ず市場で問題を起こしてくれます。 抱えこんだ潜在バグを、こっそりと隠し続けてくれるような事は、残念ながら期待できません。 ソフトウエアはとても正直者なのです。
どうしようも無いのでエスカレーションしましょう
ですので、このようなテスト進捗状況のグラフが描かれた時には、淡々と組織の上層部や経営層に対して、今のままではテストが終わらないのでリリースできそうに無いです、対策をお願いします。 と内部告発をするのが一番良い手になります。 少し言い方を変えると、重要な問題のエスカレーションですね。
本来は、開発担当部門がそのような動きをするのが良いのですが、開発担当部門というかソフトウエア技術者は、無理があってもなんとかしようと、最後の最後まで足掻く人が多いのです。 その結果として最後でひっくり返るという事例が多いので、困りものです。
ですので、そのような兆候が見えた時には、開発部門の外でテスト状況を関ししている第三者が、問題点を経営層にエスカレーションしてあげる事で、開発部門を死の行進から救い出す事も可能になります。
テストの進捗の次はバグの検出と修正の状況です
テストの実施状況では、テストの進捗と同時にテストの成果でもあるバグの検出の状況と検出されたバグの修正の状況ｊも見ていきます。 どんな観点で見るのかについては次の記事で紹介しますので、興味のある方はご覧ください。