ソフトウェアの稼働後の品質は開発時のバグの収束ではなく網羅性によって決定される

ソフトウェア開発の品質管理活動で最も重要なことは網羅性の確保です。 開発時のテストでバグが収束していることを確認することもテストの方法によっては大切なことですが、要件定義、設計、レビュー、テスト等の開発活動全体で網羅的な活動が実施できているかが最も重要です。 著者の記事「 ソフトウェアのバグ摘出モデルとバグの収束性、テストの網羅性について 」の中で記述しているように、 稼働後のソフトウェアの残存バグ数は、網羅率とソフトウェアに作り込まれた全バグ数によって決定されます。 本記事ではこれをソフトウェア開発における網羅性理論と呼ぶことにします。 網羅性理論は、バグの収束性よりも網羅性を如何に確保しているかが重要であることを示しています。

状態遷移行列を用いて実行パスの数式表現を得る方法について

ソフトウェアの動作を状態遷移図で表すことができる場合は、状態遷移図を簡単化することで数式表現にすることができ、網羅性の確保が大切なテストケース作成においてこの数式表現を参考にすることができます。 数式表現は、 著者のブログ「ソフトウェアの実行パスの数式表現について 」で記述しているような手順で得ることができますが、ソフトウェアの構造が複雑で状態数が多くなると、手作業でこの手順を行うのは現実的ではない場合があります。数式表現を得るもう一つの方法として、状態遷移図から状態遷移行列を作成して行列計算を繰り返すことで得る方法があります。この方法について記述します。

ソフトウェアの実行パスの数式表現について

ソフトウェアのテストでは、ソフトウェアの動作の適切性を、実行パスの実行の結果が妥当であるかによって判断しています。 著者のブログ「ソフトウェアのバグ摘出モデルとバグの収束性、テストの網羅性について 」で記述しているように、 稼働後にバグを出さないためにはテストでの実行パスの網羅性が非常に重要になります。網羅性を表す尺度として網羅率がありますが、実行パスの数がソフトウェアにどのくらい存在するかはソフトウェアの構造が複雑であるため把握することが困難な場合があり、網羅率を実際に計算することは難しい場合があります。このような実行パスを分析するために実行パスの表現方法として数式表現（正規表現）について考え、実行パス数や実行パスの選択について検討してみました。

テストで「バグが収束している」と簡単に判断してはいけない理由

ソフトウェアのテストでは、x軸を日付、y軸を累積バグ数にしてバグ収束曲線のグラフを作成し、グラフが収束傾向を示しているかによって、ソフトウェアの品質が十分良好なレベルに達しているかを判断したりしてます。著者のブログ「 ソフトウェアのバグ摘出モデルとバグの収束性、テストの網羅性について 」で記述しているように、ランダムにテストを実行する場合は累積バグ数は収束曲線を描きますが、テストケースを順に実行する場合は累積バグ数と実行パスの累積数（累積テストケース数に相当）は直線的な比例関係であるため、一般に累積バグ数のグラフは収束傾向を示しません。そのためテストでは累積バグ数が収束傾向を示すグラフになっても直ちに「バグが収束している」と判断してはいけません。この点について少し詳しく説明します。

開発工数と開発規模の関係は比例関係か、指数関数的な関係かについて

IPAのデータ白書を見ると開発工数は開発規模を用いて指数関数で関係付けられています。開発工数はガンマ分布で近似できるかもしれないことは「ソフトウェア開発における開発工数の分布について」で記述しましたが、これによると開発工数は開発規模と比例関係にあり、比例係数は生産性の逆数になります。この違いについて考えてみました。

ソフトウェア開発における工数の分布について

ソフトウェアを開発する工数（人数×時間）や作業時間は、要件、開発環境、開発要員、プロセス等によって影響を受け、開発規模が同じであってもばらつきが発生します。この工数や時間の分布を何らかの確率分布で近似できれば、開発プロジェクトの評価や見積もり等に役立てることができます。この工数や時間の確率分布について考えてみました。

ソフトウェアのバグのばらつきについて

ソフトウェアの設計書、ソースコード、テスト仕様書等から発見されるバグは、開発するソフトウェアの仕様、開発環境、開発要員等が異なるため、件数にはばらつきが発生します。このばらつきがどのような傾向になるか把握することは、ソフトウェアの開発が適切な状態になっているかを判断するために参考になります。 このソフトウェアのバグのばらつきについて考えてみました。