リリース判定基準・バグは顕在バグと潜在バグに分けて考える

2020年11月20日リリース判定

リリース判定ではテストで見つかった顕在バグと見つかっていない潜在バグを考える

ソフトのリリース判定を行う時に使う4つの判定基準テストの品質残存バグプロダクト品質プロセス品質)のうち、この記事ではテスト品質の良し悪しを判定す方法について考えます。グータラ親父はテストの品質をテストの量と個々のテストの種類テストの実施状況バグの状況の4つの視点から見ていました。この記事では、4つ目のバグの状況について紹介します。 

ところでバグにはテストで既に見つけた顕在バグと、まだ見つけていない潜在バグの2種類があります。 テストの品質を判定する時には、この2種類のバグを区別して考えないと、混乱してしまいます。では、この顕在バグと潜在バグについて、どんな情報を元にどんな考え方でテスト品質を判定するのが良いのでしょうか、順番に考えていきましょう。

テストで見つけた顕在バグはどこに偏っているのか

顕在バグの状況って何でしょうか? テストの品質を判定する時に、バグの状況としてどんな情報を集めて判断するのが良いのか、もう少し具体的に書きだしてみると以下のようになります。

    • 多くのバグの原因設計間違いなのか実装間違いなのか
    • 特定の機能にバグが集中してないか
    • 特定のコーダのソースコードにバグが集中してないか
    • 修正に長時間かかっている重要なバグは無いか

いつもこれらの情報が使えるといいのですが、、、

全てのリリース判定でこれらの情報が使えれば良いのですが、なかなかそのようにはならないのが現実です。 例えば1つ目の多くのバグ原因が設計間違いか実装間違いか、を知るには個々のバグについて設計間違いか実装間違いかを判定してそれを記録しておく必要がります。

これは、実際のソフト開発の作業とは別のソフト開発の管理作業です。 そしてこの作業を行うには設計者や実装者の作業時間が必要です。 これをソフトの管理コストと呼びます。 グータラ親父の経験では、充分な管理コストが見込まれていないソフト開発プロジェクトもわりとあって、その場合には設計者や実装者は発見されたバグが設計間違いか実装間違いかを判定するだけの管理作業の時間を確保できません。

その結果、そのプロジェクトでは設計間違いが多いのか実装間違いが多いのか、開発プロジェクトの外からは判断できなくなります。開発プロジェクトの中で実際に開発やテストに直接関わっている人たちは、直感的に判っているとは思いますが、プロジェクト外の人には判らない事が多いです。

特定の機能に品質低下が集中してないか

ほかの3つの情報についても、利用できる場合と利用できな場合があり、リリース判定の時に必ずこれらの情報が利用できるとは限りません。ですので、リリース判定の時にこれらの情報のうちで利用できる情報があれば、ソースコードの品質を判定する時の参考に使う、というのがグータラ親父のやってきた方法です。 

といってもそれほど明確な手順や手法は有りません。これらの4つの情報からは、ソースコードのどのあたり品質の不足している部分があるのかな? という漠然とした範囲が判ります。一番簡単な例で言えば、2つ目の特定の機能にバグが集中していれは、その機能は他の機能に比べて品質が不足していのではないかな? という事が推定できます。 

そして、どれかの機能が品質が不足していると推定できたら、その機能についてのテスト計画の状況やテストの内容やテストの結果について、他の機能よりも注意深く確認して、ソースコードに品質不足が起きていないか注意する、という程度です。

リリースの判定は悪い所が残っていないかの確認

リリース判定時のソースコード品質の確認とは、要するにリリースするソフトに悪いところつまりはまだ修正されていない潜在バグが残っていないのか、を確認する作業になります。 その作業の一環として、出来上がったソースコードの品質が良いか悪いかを判定します。 そして、ソースコード品質だけではなく設計品質にも言える事なのですが、ソフトの開発では特定の機能に不具合が多発して品質不足が起きる問のは、割とよくある事です。

初めて搭載する機能だったり、内部の仕組みが複雑だったり、複数の処理が連携する必要があったり、開発の途中から追加された仕様だったり、色々な理由や背景はありますが、特定の機能が品質不足になっている事は、割と良くあります。

ですので、推定でも良いのでソースコードのどのあたりに品質不足が起きているかを推定して、その部分を注意深く調べるというのは、ソースコードの品質を判定する場合に、わりと大切な事です。

バグの確認で重要なのは潜在バグの状況

テストで見つかった顕在バグがどこに偏在してるいるのかも重要な情報ですが、ソフトのリリース判定で大切なのは、もうバグが残っていないかどうかという潜在バグの状況です。次の記事ではテストの実施結果から推定する潜在バグの状況について、グータラ親父の考を紹介していきます、興味のある方はご覧ください。

(次の記事)リリース判定基準・潜在バグは何件残っているかを推定する に続く
(前の記事)リリース判定基準・テストの実施状況はバグの検出状況も見る に戻る
リリース判定の先頭の記事 に戻る