リリース判定その他・特別採用はテストの状況と潜在バグと残存バグで判定する

2020年12月16日リリース判定

ソフトの特別採用はテストの未完了か、潜在バグのリスクか、残存バグの状況のどれかが理由

前の記事では特別採用によるソフトのリリースもあり得る事を紹介しましたが、実際にグータラ親父が特別採用によるソフトのリリースを認めていたのは、以下の3とのどれかの場合です。

  1. 計画していたテストの一部が未だ終わっていない (プロセス品質不足)
  2. 潜在バグの洗い出しがまだ充分に終わっていない (プロダクト品質)
  3. 潜在バグによるサービス提供への影響が残っている (プロダクト品質)

であ、順番にもう少し具体的に紹介していいましょう。

計画していたテストが一部未完了による特別採用

計画していたテストの一部でも未完了だと普通に考えるとリリースは不可ですね。テストが終わっていないのにリリースするというのは、さすがに乱暴すぎます。とはいえ、世の中には建前と本音というのがあります。

例えば、もう殆どのテストは終わっているけど、いろいろな事情があって一部のテストについて現時点ではまだテストを実施している最中でテストが完了していない。既に終わった部分のテスト結果から推測すると、今実施している最中のテストでも新たな問題が発見されるリスクはかなり低い。でもテストが終わっていないとう事実には変わりはない。それなのに営業的にはどうしても遅らせられないリリース日が来てしまった。 どうしよう??? という様な時に、貴方ならどうしますか? 

もう少し具体的な場合を仮定してみましょう。例えば 起動してから長時間の安定稼働を確認するために、30日間の通電テストというテスト項目があったとします。 そして、テストの開始が遅れたために、今日の時点でまだ 27日までしテストが実施できていない状況だとします。 

本来ならあと 3日間テストをしないと30日間の通電テストに合格した事にはなりません。ですので、他のテストが全部済んでいてもテストとしては未完了です。 だけどソフトは明日リリースしないといけないと営業が言っています。 

別の具体例では、妥当性を確認するテストとして、客先が準備した本番運用に近いテスト環境での客先との共同テストを計画していたとします。自社の分担しているテスト箇所は実行を終わっているけど、客先が担当しているテスト箇所が98%までは完了しているけどあと2%についてはテストの実施が遅れていて完了が3日後になる。  

未完了のテスト箇所は社内のテスト環境を用いたテストでは完了していて問題は出ていないのだけど、テスト計画としてはまだ完了していない。でも、ソフト上は明日リリースしないといけない。

どんな時なら一部のテストが未完了でも大丈夫なのでしょう?

この様に、長時間を必要とする安定性の確認テストの最後のほうの一部の期間のみの未完了な場合や、数日単でのテスト遅れによるテスト未完了があっても、他の環境や設定でのテストは終わっていて問題が出ていないのならば、それらのテストが未完了な事による潜在バグの検出漏れのリスクはかなり小さい、と考えても妥当性はあります。

その様な状況でさらに営業的にどうしても今日リリースしなければならない、という様な場合には、グータラ親父は今回に限り特別採用でリリースを許可していました。テストが終了するまでの数日間はテスト未完了という品質不足の状態で、特別採用によるソフトウエアのリリースとなります。 

もちろん、リリースから数日が経過して全てのテストが終了しテスト結果に問題が無ければ、その時点で特別採用によるリリースは終了して、普通のリリースに切り替わります。

潜在バグの洗い出しがまだ充分に終わっていないための特別採用

一部のテストの未完了とともに、時々発生するのが、潜在バグの洗い出しが充分には出来て居ない時点での特別採用によるリリースです。 グータラ親父は、潜在バグの洗い出しが充分に出来ているかどうかは、信頼度成長曲線を推定するツールを使って、全てのバグのうち現時点で何%のバグが検出できているかを示すバグ検出率という値を推定計算して、この値を判定に使っていました。

例えば、バグ検出率が91% という推定計算値は、ソフトに含まれる全てのバグのうちこれまでのテストで91% のバグが検出されていて、あと 9% のバグが未だ見つからずに潜んでいるでしょう、という推定結果を示します。推定の計算値なので、本当にあと9%のバグが潜んでいるかどうかは確かめる術はありません。 それでもバグ検出率という推定計算値を使う事で、リリース時点での潜在バグの洗い出しの状況を、リリース可否の判定基準に使う事ができるようになります。

バグ検出率という推定値を使う事でリリースの判定はやり易くなるのですが、一方で悩ましい状況も置きます。例えばバグ検出率が 99%以上というのをソフトリリースの合格基準値と決めていたと仮定します。そして、あるソフトのリリー時に推定計算したバグ検出率の値が 98.9%と、あと0.1%足りなかったとします。規定上はバグ検出率が合格基準に達していないので、リリース不可との判断になります。しかしそれで良いのでしょうか?

既に見つかったバグの数とか修正が間に合わずに残っているバグとかは、事実ですのでこれを基にリリースの可否を判定するのは、判定基準値の決め方とか色々と考慮する点はありますが、方法論としては正しいです。 

でもバグ検出率という推定計算値を基にリリースの判定をする時に、規定の値にほんの少し届かなかったからリリース不可と杓子定規に判定する事は、正しいのでしょうか? バグ検出率の推定計算値はそれほど信頼性が高いのでしょうか?

判定に使う推定値の精度が高くないないので経験と勘でカバーしましょう

ルールで決めた合格判定基準を守る事は大切な事です。そうなのですが、実はこの信頼度成長曲線によるバグ検出率の推定計算方法自体が、結構大雑把な物です。数値が出力されるのであたかも正確なように思えてしまいますが、確固とした理論が背景にある訳では無いのです。 バグの検出はこんなグラフの形になるだろうという経験則に基づいて、バグ検出の実績値にグラフの曲線を当て嵌めて、今後はこの程度のバグが見つかるだろうと推定しているだけです。なので、そこから得られるバグ検出率も確固とした理論に基づくものでもないので、それほど精度は有りません

そのような推定値があと0.1% 合格基準に達していなかったので、リリース不可と判定するのには少し違和感があります。そこで、グータラ親父はそのような時には、場合によっては特別採用によるソフトのリリースを許可していました。

場合によってはの場合というのは、バグ検出率以外のいろんな指標を見て、ソフトの品質に問題が無いと判断できる場合です。ソフトのリリース判定の時には、テストが量・質ともに充分かとか、設計レビューやコードレビューの指摘状況に問題はないかとか、いろいろと確認する項目があります。それらの各種の指標がソフトの品質に問題が無い事を示しているのなら、バグ検出率が少々合格基準を満たしていなくても、特別採用でソフトのリリースを当別採用で許可していました。

もちろん、バグ検出率が基準を満たさない事による不合格品をソフトを特別採用でリリース許可とした場合には、リリースの後もテストを継続してバグ検出率が低下するのを待ちます。バグ検出率は、テストを実施しても新たなバグが見つからない状況が継続すると、徐々に値が良くなっていきますので、やがては合格基準を満たす値になります。その時に、特別採用によるリリースから通常のリリースに切り替わりますので、その時までテストを継続する事が必要です。

残存バグによるサービス提供への影響が少し大きい時の特別採用

ソフトの特別採用によるリリースで時々あるのが、残存バグがまだ少々あるのだけどリリースをしたい、という時の特別採用です。もちろん、本来はバグが全て無くなってからリリースするべきなのですが現実はなかなか理想通りにはいきません。リリースの時期になってもまだ直せていないバグが残っている時もあります。

そのような場合でも、リリースの可否をできるだけ客観的に判定できるように、グータラ親父は残存バグについてはユーザへのサービス提供に対する影響度合いという観点で、通常のリリースが可能か特別採用によるリリースが可能かを判定する方法を作っていました。この方法については、判定基準・残存バグ(残バグ??)の記事で紹介していますので、そちらをご覧ください。