リリース判定基準・プロダクト品質はコード品質も確認する
プロダクト品質の判定ではソースコードの品質が最重要
さて、リリース判定の時にプロダクト品質の良し悪しを判定するための１つ目の項目が設計品質で、２つ目の項目はソースコードの品質でしす。この記事では、ソースコード（コードと省略して呼ぶこともあります）の品質の善し悪しをどうやって判定するのか、グータラ親父のやって来た方法を紹介します。
ところで少し話題から外れますが、ソフトウエアの開発にとって一番大切なのはソースコードの品質です。設計レビューやコードレビューやテストの作業は全て、ソースコードの品質を良くするための作業です。良い設計をして良いソースコードを作るためにレビューをして間違いを取り除く。レビューで取り除けなくてソースコードに入ってしまったバグは、テストをして検出してデバッグ作業で取り除く、それらの作業は全て良いソースコードに仕上げるための作業です。
私たちソフトエンジニアやソフト品質担当エンジニアが行うソフト開発の作業は全て、最終的にはソースコードに集約されます。ソフトの品質＝ソースコードの品質と言っても良いと思います。
厳密には、ソースコードがコンパイルされて実行コードになって初めて CPU で実行されるので、コンパイラやリンカにバグがあるとたとえソースコードの品質が良くても実行コードにバグが紛れ込む事もあります。このコンパイラやリンカのバグは原因を見つけ出すのがとても難しくて、困りものです。しかし、開発されて間もない新アーキテクチャのCPUを始めて採用するというような特殊な開発でない限りは、幸い最近のコンパイラやリンカはなかり良くなっているので、そのような事態はあまり気にしなくても良いとおもいます。
ソースコードの品質はバグの数で推定
設計品質と同じように、ソースコードの品質の良否もソースコードに間違いが多いか少ないか、で判断するのが判り易いです。 少し乱暴になりますが、ソースコードの間違い＝バグと考えて、テストやコードレビューで見つけたバグの件数が少なければソースコードの品質は良い、と考えてもまあ間違いは無いでしょう。
社内テストでのバグは見つかっていますか？
多くのバグはリリースまでに実施される様々な社内テストで見つかります。ところで、皆さんの会社では社内テストではリリースするソフトウエアに潜むバグを全て見つける事ができていますか？ 実は見つかっていないバグ（＝潜在バグ）の数は数えられないので、全てのバグを見つけ終わったのかまだバグが残っているのは誰にも判りません。ですので、これだけテストをやってもうバグが見つからないから、もう殆どのバグは見つけ尽くしただろうと推定して、ソフトウエアをリリースするというのが、現実です。
それでは、社内テストで充分な数のバグは見つけた状態とは、具体的に何件のバグを見つけたら良いと判断するのでしょうか？ これもまた難しいですね。でも、社内テストで殆どのバグを見つけ尽くした、と判断しないと、ソフトウエアをリリースできるかどうか、判定ができません。 こでは、グータラ親父がリリース判定の時に行ってきた、バグ件数の判定の方法について、紹介しましょう。
バグはテストとレビューで見つかる
ところで、バグが見つかるのはどんな場面でしょうか？ ソースコードを作る順番に沿って考えると、多くは以下の３つの場面でバグが見つかります。
- ソースコードの単体テスト
- ソースコードレビュー
- 結合テストやシステムテスト
ここで使っているテストの簡単な定義
実は、上で出て来た単体テストとか結合テストとかシステムテストとかの、テストの名前と定義は、ソフトウエアを開発する組織によって結構違いがあります。 ここでは、この３つのテストの名前を、以下のような意味で使っています。皆さんが日ごろ使っておられる名前に読み替えて、記事を参照下さい。
単体テスト：ソースコードを作成した技術者が自ら、ソースコードの各行が考えた通りに動作しているか、とか、作った関数が考えた通りに動作してるかを、ホワイトボックスの手法で確認するテスト。例えば、デバッガを使ったステップ実行での動作確認など。
結合テスト：ソースコードを作成した技術者が自ら、実装した機能が考えていた通りの機能や性能を提供しているかをブラックボックスの手法で確認するテスト。 例えば、スタブ関数と疑似入力データのファイルを準備して、機能の動作を確認するテスト。
システムテスト：ソースコードを作ったのとは別人のテスト技術者が、ソフトウエアの仕様を元にテスト設計をして実施する、機能/性能/安定性/異常回復性/堅牢性などのソフトウエアの様々な側面を確認するテスト。
どのテストでのバグを数えましょうか？
単体テスト、ソースコードレビュー、結合テストやシステムテストでバグが見つかります。 ではリリース判定の時にこれらの３つの作業で見つけたバグの件数を情報として使うのが良いでしょうか？ 実はグータラ親父は社内テストで見つけたバグの件すとしては、この３つの全てを使っていた訳ではありません。
単体テストで見つけたバグの数は測らない
バグを見つける３つの場面のうち一つ目の、単体テストでは結構多くのバグが見つかります。 ではリリース判定の時に単体テストで見つけたバグの数もプロダクト品質の良否を判断する情報として使うのが良いでしょうか？
グータラ親父は、単体テストのバグはリリース判定時には使いませんでした。 単体テストは、ソースコードを作成するコーディング作業と一緒に実行される事も多く、コーディング作業の一環と考える事もできます。 ソースコードを作成するエンジニアによっては、まずは荒っぽくソースコードを書き下して、コンパイラのエラー検出機能を使ってコーディングミスを修正していく、というスタイルを取る人もいます。
このような開発スタイルの場合、単体テストで見つけるバグの件数とソースコードの品質とは相関関係が薄くなります。 このような場合もよく有るので、グータラ親父は単体テストで見つかるバグの数は、リリース判定の時には使いませんでした。
コードレビューで見つけたバグの数も測らない
２つ目のコードレビューで見つけたバグの数ですが、グータラ親父はこのバグの件数もリリース判定の時には使いませんでした。 ただしその理由は、単体テストで見つけたバグとは違って、数えるのが手間だったからです。
コードレビューの実施の仕方にもよるのですが、全ての新規開発と修正/削除したソースコードはコードレビューを実施する、というルールを厳格に運用しようとすると、コードレビューの方法として会議形式と資料回覧形式の両方を使い分けて効率的にコードレビューを実施しないと、開発がタイムリーに進みません。
また、コードレビューの指摘点と指摘点に対する対策を、どうやって記録・トレースするかも、作業効率の良いソフトウエア開発環境が無いと、なかなか大変です。 組み込みシステムの場合には、Windowsアプリやサーバアプリのように、開発環境が統一されていない場合が多く、採用するハードウエアによって使えるソフトウエア開発環境も色々と異なってきます。 そのために、ソースコードレビュ－の指摘件数を、効率よく記録/集計する体制が作れない場合もでてきます。
そのような背景が有ったので、グータラ親父はコードレビューの指摘件数は、リリース判定時には情報として使いませんでした。 しかし、開発環境が統一できて、コードレビューの指摘件数が簡単に収集できるなら、リリース判定時の判断情報として使った方が良いと思っています。 その場合には前篇の設計品質の時と同じように、コードレビューの量（コードレビューの実施率）や質（コードレビューの参加者）の情報も集めて一緒に見るのが良いでしょう。 コードレビューも、レビューをしなければ指摘ゼロですし、レビューをしても指摘できる技量の人が参加していなければ、必要な指摘が出てこない事になってしまいます。
でもまあ、結合テストとシステムテテストで見つかるバグを見て居ればある程度プロダクト品質の良否は判断できるので、コードレビューで見つけたバグの件数が判らなかったとしても、リリース判定にはそれほど困る訳でもありません。
結合テストとシステムテストで見つけたバグでリリース判定
という事で、グータラ親父はソフトウエアのリリース判定では、結合テストとシステムテストで見つかったバグ（＝ソースコードの間違い）に関する情報を元に、ソースコードの品質の良否を判断していました。
少し片手落ちのように見えるかも知れませんが、リリース判定と言えども判定作業のコストパフォーマンスを考慮する事も重要なので、手間が多い割に情報量の少ないデータは思い切って切り捨てる事も必要になってきます。
ソースコードの品質の判定には、テストで見つかったバグの件数以外にも、他の記事にも改訂いますが、テストの量やテストの質、見つかったバグの状況や潜在バグの推定件数なども使います。 色々な視点から総合的にソースコードの品質を判定するので、社内テストで見つかったバグの件数としては、結合テストとシステムテストの件数だけ見て居れば問題ないだろう、というのがグータラ親父の見切りでした。
テストとバグの悩ましい関係
ところで、社内テストでたくさんのバグが見つかるほうが良いのでしょうか？、それともバグはあまり見つからない方が良いのでしょうか？
もちろん、テストの目的がバグを見つけてデバッグする事に重点が置かれてい開発の初期段階のテストの場合は、バグをたくさん見つけるほうが良いですね。 ここで考えたいのは、バグが残っていない事を確認する事が目的のリリース前のテストです。
バグが残っていない事を確認する事が目的なので、当然の事ながら見つかったバグの数は少ないほうが良いですね。 では、見つかったバグがゼロ件だったら、ソフトウエアの品質は良いのでリリースしても問題無いと、無条件に判断できるのでしょうか？
何かちょっと引っ掛かりませんか？ はいそうです テストをしなければバグはゼロ なのです。
テストのバグの関係ですが、ざっくりと纏めるとバグの件数で品質の良否を判断するなら、テストの量と質も合わせて考えないと、正しく判断できないですよ、という至って普通の話ですね。 バグの数が少ないからと言ってソースコードの品質が良いとは言えません、テストの件数が少なければ見つかるバグは少ないでしょうし、テストの方法がザルだとどれだけ多くのテストをしてもバグは余り見つからないでしょう。 このあたりの事は、書くと少し長くなるので別記事に整理していますので、そちらをご覧ください。
プロダクト品質の次はプロセス品質の確認です
プロダクト品質と対になった考えとしてプロセス品質があります。最終的に品質を保証しなければならないのは製品の品質、つまりはプロダクト品質です。しかし、プロダクト品質を良くするには、そのプロダクトを作るプロセスの品質を良くしないといけません。 と言う事で、ソフトのリリース判定では開発プロセスの品質についても状況の確認が必要ですので、次の記事で紹介しましょう。