概要・リリース判定はテスト品質/残存バグ/プロダクト品質/プロセス品質の４つの基準で判断する
ソフトのリリース判定は４つの判定基準のどれかを満たさないならリリースを許可しない
リリースするソフトの品質が良いか悪いかはどうやって判定するのが良いでしょう。グータラ親父はこの20年近く、以下の４つの考え方でソフトの品質の良し悪しを判断して、ソフトをリリースしても良いかどうかの判断をしてきました。
- テスト品質の判定 （テストは十分な量と質で実施してあるか）
- 残存バグの判定 （残存バグが残っている場合実運用で問題にならないか）
- プロダクト品質の判定 （設計書やソースコードも含めて開発成果物の品質は良いか）
- プロセス品質の判定 （開発に使ったプロセスは良いか）
これらの４つの判定基準のどれかが基準を下回るほど悪いと判断したソフトについて、リリースを承認しないというリリース判定の方法です。これらの４つの判定基準について、次の記事から順番に紹介してきます。なお、ソフトのリリース判定を実施するためのリリース判定の仕組みについては、別の記事に書いてありますので、そちらをご覧ください。
1. テスト品質はテストの量と種類と実施状況とバグ状況で判定する
まずはテストの品質ですが、これは一見判り易そうなのですが、いざ考え始める何を測ればテストの品質の良し悪しを判断できるのか、なかなか悩ましいのです。これが正解というテストの理論のような物も見当たらないので、グータラ親父はテストの品質を４つの視点で見ていました。
１つ目はテストの量です。どの程度の量のテストを計画したのかと実際に計画通りにテストが実施できたのか、という計画と実績の２つの視点でテストの量が十分だったかどうかを判断します。
２つ目はテストの種類です、ソフトの機能確認だけでなく性能、安定性、堅牢性、ドキュメントとの合致、異常回復性、可用性などの面でのテストも実施されているか、という視点でテストの種類を確認します。 そのために、テストの目的をどのように分類して、その目的にそってどんなテストを実施するのか、テストのための環境やテストで見つかったバグの管理なども含めて、テストの種類を確認していきます。
３つ目はテストの実施状況です。テストが作業計画どおりに進めば良いのですが、現実はしばしばテストが止まってしまい計画通りに進まない場合の方が多いです。 なぜテストが止まるのでしょうか、よくあるのが、重大なバグがあってその先にテストを進められないという状態です。
このようなバグの事を、テストブロッカーと呼んでいました。テストブロッカーが１個や２個なら、テスト作業の順番の組み直しなどでテストの作業計画が遅れないように調整する事もできます。しかし、あっちでもこっちでもテストブロッカーが見つかると、そのうちに実施できるテストが無くなってしまい、そこでテストは進まなくなります。 その結果、テスト作業の遅れが起きます。 逆の見方をすれば、テスト作業が計画から大きく遅れていたようなら、テストブロッカーが多くてソフトウエアの品質が良く無かった可能性がとても高いという事が推定できます。
４つ目はテストで見つけたバグの状況です。 テストでバグが何件見つかったのか、バグはどんな目的のテストで多く見つかったのか、バグはもう見つけ尽くしたのか、見つけたバグは修正されたのか、等テストの結果も、色々な視点で見る事で、ソフトの品質の良否を判断するために役に立つ情報を教えてくれます。
2. 残存バグは市場でのサービス提供への影響度合いから判定する
次が残存バグの状況です。もちろん、残存バグがゼロである事が理想ですが、ごく小規模なソフトウエアでない限り、バグがゼロというのは非現実的です。 テストで見つけられていない潜在バグの有無は、バグ収束曲線などで推定するとして、既にテストで見つけているけど出荷（リリース）までに修正が間に合わなかった残存バグというのは、残念ながら有ります。
残存バグがある状態で、ソフトをリリースして良いですか？ と言われれば、理想論ではリリースすべきでは無いのですが、そんな事を言ってたら、大規模なソフトでは永久にリリースできません。という事は、残存バグがあるソフトを、リリースしていいのかどうか？ を何等かの方法で判断しないといけないというのが現実です。
ではどうしましょう？ グータラ親父は残存バグについては、市場でサービスの提供に支障をきたす可能性が高いか低いかを推定して、低いならリリースしても良い、という判定をしてきました。少し極端な言い方をすれば、例え残存バグが残っていても、市場でのサービス提供で全く使わない機能であれば、それは市場で問題を引き起こす事は無いのだからいいんじゃない、という考え方です。
リリース判定での残存バグの判定についての具体的な内容は、このリリース判定という分類の記事の中で [判定基準] 残存バグの判定 というタイトルの付いた記事に書いてあります。
3. プロダクト品質は設計書とソースコードの品質を見る
プロダクト品質とは、ソフトウエア開発の成果物（アウトプット）として作られる、設計書とソースコードの品質です。ソフトウエアの開発の捉え方にも色々とあるのですが、開発業務を中心においてソフトウエアの開発を捉えると、こんなソフトウエアを開発して下さいという事を記載した、要求仕様書が開発業務へのインプットになります。要求仕様書を満足するソフトウエアの構成や内部の機能を、日本語とか英語とかの人が理解できる自然言語で書き表したソフトウエアの中間成果物が、いろいろなレベルの設計書です。
その設計書に従って計算機言語で書かれたソースコードとソースコードをビルドして出来上がった実行コードとが、ソフトウエア開発の最終成果物です。 最終的には実行コードの品質が大切なのですが、コンパイラにバグが無い限りは、ソースコードの品質＝実行コードの品質と考えても大きな間違いにはなりません。 ですので一般的には、ソースコードを開発業務のアウトプットと考えて、ソースコードの品質が良い事を目指します。
プロダクト品質とは、このソフトウエア開発という作業の成果物(アウトプット）である、設計書とソースコードの品質という意味です。
設計書とソースコードの品質が良いか悪いかの判断の方法も、また色々とあります。でもまあ、一番直感的で判り易いのは、間違いが多いか少ないかですね。設計書の間違いは、設計書のレビューでの指摘事項として現れます。ソースコードの間違いは、コードレビューでの指摘事項やテストで見つかったバグとして現れます。これら、レビューの指摘事項やバグの状況を見れば、プロダクト品質が良いか悪いかを判断できますね。
リリース判定でのプロダクト品質の判定についての具体的な内容は、このリリース判定という分類の記事の中で [判定基準]プロダクト品質の判定 というタイトルの付いた記事に書いてあります。 なお、プロダクト品質そのものについては、色々と考える項目も多いので、別の分類を設けてもう少し掘り下げて説明します。
4. プロセス品質は開発プロセスと管理プロセスを見て判定する
プロセス品質とは、ソフトウエアの開発プロセス（開発手順）の品質です。プロダクト品質と違ってちょっと馴染みが無いかもしれませんが、少し考えてみると、開発プロセスにも品質の善し悪しがあることに気付きます。この開発プロセスの品質を考える時には、プロセスを２つの種類に分けて考えると判り易いです。
まず一つ目が、ソフトウエア設計・実装・テストなどのソフトウエアそのものを開発するためのプロセスです。直接プロセスという呼び名を付けてもよいかも知れません。どんな方法で設計・実装・実装・テスト設計・テスト実行をするのか、各々の中間成果物である設計書に対してどんな方法や頻度で、レビューをするのか、承認されないと次の作業に進んではいけないゲートプロセスとしてどんなプロセスを採用するのか、などが直接プロセスになます。
２つ目が、ソフトウエアの開発が計画どおりに進むように、管理するプロセスです。 ところで、管理とは何でしょう？ よく使う言葉ですが何を指しているか説明しろと言われると、ちょっと戸惑いませんか。 管理とは、、計画を立てて、計画通りに進んでいるかを、監視して、計画からズレていたら計画した値に近づけるような、対策を取るという一連の作業です。 良く言われている Plan（計画） Do（実施） Check（確認） Action（改善） の Do（実施）以外の3つが、実は管理なのです。
計画を立てるとは、目標を設定して目標を達成するための具体的な方法を書き出すという事なので、日程の目標だったり、開発費用の目標だったり、性能の目標だったり、品質の目標だったり、色々な目標があります。 どのような目標であっても、計画を立てて実績を監視し計画からのズレを修正するという管理プロセスが無いと、計画どおりには進まないのが普通です。 ですので管理というのは結構大切なプロセスなのです。
プロセス品質とはこの２つのプロセス、ソフトウエア開発の直接プロセスと管理プロセスの品質の事です。 どのようなプロセスが採用されているのか、採用されたプロセスが着実に実施されているのか、プロセスの実施結果は良好か、という視点でプロセス品質の善し悪しを判断する事ができます。
もう少し詳しくは個々の記事をご覧ください
リリース判定の方法は、色々とあります。製品により、市場により、企業風土により、リリース判定の定義や目的など、求められる物も変ってきます。 ここに書いてある事は、一つの例に過ぎませんが、皆さんがリリース判定を考える時の参考になれば、幸いです。
ソフトのリリース判定の基準について、もう少し詳しく知りたい方は、記事上部の リリース判定 のリンクで表示されるリリース判定のトップページに戻って頂いて、個々の記事をご覧ください。 以下のリンクからも判定基準についての個々の記事を順に辿れますので、こちらからご覧頂いても、同じ記事にたどり着きます。