この記事では，何人かのプロジェクトリーダの証言を紹介する。いずれも極めて低いCoverity Scan欠陥密度を達成したプロジェクトにおいて，採用されたプロセスを詳しく説明したものだ。
先日リリースされた Coverity Scan Report 2012 には，調査に参加したオープンソースプロジェクト中のトップ108に関する検査結果が報告されている。調査対象となったコードは総計で6,800万行になり，昨年の3,700万LoC に対して大幅に増加している。Coverityはメモリ破壊や初期化されない変数，エラー処理の問題など，重要度が中ないし高のエラーを対象として静的コード解析による検査を実施し，欠陥密度(Defect Density)をプロジェクト単位，および全プロジェクトの平均として算出する調査である。
平均欠陥密度は過去５年間，最低値である2009年の0.25から最高値である2010年の0.81までの間を変動している。変動の要因として挙げられるのは，欠陥を検出する新たなアルゴリズムが年毎に導入されてきたこと，さらには "2010年にはCoverity Scanサービスに非常に多くのプロジェクトが参加しました。これによって多数の "ファーストタイム・スキャン" があったことが，欠陥密度の数値が多少上昇するのに貢献したのです。" と，Coverity Scanのプロジェクトディレクタを務めるZack Samocha氏は述べている。
そのSamocha氏によると，2012年のオープンソースプロジェクトの平均欠陥密度は 0.69 で，業界の平均値である 1.5 よりもかなり低い値であった。
Coverityテクノロジで実施した初期スキャンの平均欠陥密度 (欠陥の修正を行う前) は 1.5 でした。Coverityを公開した最初の年以降，この数値は 1.0 ほど低下しています - 新たなコードが絶えず追加されていて，より多くの欠陥が検出されているのですが，開発者が欠陥を修正する速度も速くなっているのです。2012年のCoverity Scan Reportでは再び数値が低下しています。オープンソースとプロプライエタリコードがそれぞれ 0.69 と 0.68 でした。このことは開発テストによって，コードの品質が継続的に改善されていることを示しています。
レポートには非常に低い欠陥密度を達成した何人かのプロジェクトリーダによる談話も含まれていて，彼らがコード品質の向上に用いたプロセスが説明されている。アプローチはそれぞれ違っているが，Coverityの検査 とは別に，コードレビューや何らかのユニットテストを導入している点は共通しているようだ。以下はその証言からの抜粋である。
AMANDA – IT管理者用のバックアップソリューション
コードベース: 160,800 LoC
欠陥密度: ０
インタビュー： Jean-Louis Martineau氏 (プロジェクト・ゲートキーパ)，Paddy Sreenivasan氏 (開発者)
Q: 最高レベルのコード品質を達成できた理由は何だと思いますか？
A: 最も大きなものは，プロセスを遵守させるゲートキーパの存在でしょうね。パッチや変更はすべて，この人を通じて行わなければなりません。私たちのプロジェクト規模であれば，この役は一人で十分に可能です。すべての変更がレビューされることになります。
広域テストもあります。私たちは通常のディストリビューションに対して，定期的にテストを実施しています。パッチを受け入れる時も，前もってテストにパスすることを確認します。
後方互換性が維持されていること，変更を行った場合にメインのWebページがすべて更新されていること，ドキュメントが更新されていることなどもここで確認します。チームの開発者たちはこのプロセスに慣れています - ずっと前からこの方法と関わっていますし，それに従うことも理解しています。その一方で，リリーススケジュールにはある程度の融通を利かせるようにしています。私たちの仕事には特定の出荷日といったプレッシャがありませんので，それが役に立っている部分もあります。
Q: Coverity以外には，どのような品質検査技術を採用しているのでしょうか？
A: マニュアルコードレビューを行っています。汎用的なテストケースの実行には buildbot [同じようにオープンソースのツール] も利用しています。
Q: あなた方のプロジェクトが高品質のコードを提供できた，最大の理由を３つ教えてください。
A:
• コードベースのサイズ - 品質コントロールを維持するため，管理可能なサイズにしています
• 開発者の安定性と専門技術 - ゲートキーパは，すでにこの役割を10年以上続けています
• リリース期日を守るための余分なプレッシャのないこと - 品質とスケジュールのトレードオフを計る必要がありません
Mesa – OpenGL 実装
コードベース: 1,038,075 LoC
欠陥密度: 0.5
インタビュー: Brian Paul氏 (Mesa 創始者，VMware 技術者)
Q: これほど高いレベルのコード品質を達成できた理由は何だと思いますか？
A: ピアレビューを念入りに行ったことでしょう。コードにコミットした変更は，いくつか例外を除けばすべてメーリングリストにポストされて，仲間のレビューを受けています。私たちにはチェックインに先だって，コードレビューのためにサインオフする，というプロセスがあるのです。プロジェクトには30～50名のアクティブな開発者が参加していますが，その中に15人程度，特に貢献してくれている人たちがいます。
Q ：期待される品質を満たしていないコードを提出する開発者がプロジェクトにいるとしたら，どうなりますか？
A: それほどしつこく，質の悪いコードの提出を続けるような人は，これまで例がありません。私がコードを書き始めたのは20年前ですが，現在でもコードポストしてレビューを受けています。このプロセスを超越する人は誰もいません。プロジェクトに関わっている開発者たちは，自分の作業に誇りをもっています。チェックボックスをオンにするためだけに，コードをスローしているのではありません。このコードが数百万の人たちに利用されるという責任感を，開発者たちが非常に真剣に捉えているからなのです。
Q: Coverity以外には，どのような品質検査技術を採用しているのでしょうか？
A: piglitという，オープンソースのテストスイートを使っています。これには約10,000テストが含まれています。メモリや並行処理の問題にはValgrindも使用しています。Mesaはクロスプラットフォームなのでさまざまなコンパイラを使うのですが，そのためにいろいろと，低レベルのバグが見つかったりするのです。バグトラッキングとリポジトリにはGitを使っています。
Network Time Protocol (NTP) – ネットワークを越えてコンピュータのクロックを同期するために使用するNTPプロトコルの実装
コードベース: 286,295 LoC
欠陥密度： 0.32
インタビュー: Harlan氏 (プロジェクトマネージャ)
Q: Coverity以外には，どのような品質検査技術を採用しているのでしょうか？
A: SCMシステムにはBitKeeperを使用しています。それからユニットテストも，私たちの品質テストではますます重要な部分になってきています。
いつもGoogle Summer of Codeの学生たちにユニットテストスイートで作業してもらっていますが，
すべての開発者がユニットテスト技術者になれる訳ではありません。ですから，プロジェクト内に既存のスキルセットに制限される部分もあります。これらのテスト用に十分な信頼性を持ったセットを１つ用意して，サンプルとして利用できるようにすることが，私たちの当面の目標です。
そうすれば従来型の開発に慣れている人たちも，パッチ提出時の作業のひとつとしてテストを受け入れてくれるでしょう。Q: あなた方のプロジェクトが高品質のコードを提供可能な理由について教えてください。
A:
• プロジェクトの最も重要な要素は人です。適切なスキルを持っていることがキーになります。このプロジェクトで作業しているのは，10年以上のキャリアを持った人たちばかりですから，何をするべきかはよく分かっています。
• 監視方法の変更。20年以上の経験のある私でも，コードを変更するときには，
コードのコミットに先立って３，４人程度がそれを実行して，疑問があれば私に教えてくれます。
XBMC – メディアプレーヤおよびエンターティメントハブ
コードベース: 1,201,946 LoC
欠陥密度： 0.17
インタビュー: Kyle氏 (Developer)
Q: これほど高いレベルのコード品質を達成できた理由は何だと思いますか？
A:–私たちはさまざまなプラットフォームをサポートしているので，高い品質を維持するために，フレキシブルであること，多くのユースケースでテストを行うことを心掛けています。
Q: 開発者コミュニティに対して，プロジェクトについて説明してください。
A: 小規模で，地理的に分散したチームです。定期的にコード提供をする5～10名のコアグループを中心に，20～30名の開発者が参加しています。
Q ：期待される品質を満たしていないコードを提出する開発者がプロジェクトにいるとしたら，どうなりますか？
A: そういったことはよくあります。コードがメインラインにチェックインされてから一旦前に戻って，バグトラッキングを経由して問題をフィックスしなければなりません。この作業にはCoverityが非常に役に立ちます。品質的な問題を繰り返す開発者に対しては，マージ権限の取り消しを警告することになると思います。コミュニティの判断は重要ですし，品質への期待も高いのです。高品質のコードで貢献してくれれば開発者としてのランクも上がりますし，コミュニティにおける発言の重要性も増します。過去に品質的な問題を起こした開発者は，今後のコミットにおいては，より高い品質レベルを保証するためにより多くの時間を費やすことになるのが通常です。
私たちの開発者は仕事に誇りを持っています。このソフトウェアを自分自身が日常的に使っていますから，品質の高いコードを書くことへのモチベーションも高いのです。単にチェックボックスをオンにしようとするのではありません。
Q: コードに関して，公式の受け入れ基準はありますか？
A: プロセス自体は結構ルーズなので，正式な指標や目標はありません。マニュアルでコードレビューを実施して，
メイントランクに統合するときに，私がそのコードにCovertyを実行しています。Coverityの問題を私自身が修正した後，修正全体をポストして相互レビューを実施します。開発者たちが変更セットにコメントする，といった具合です。Q: Coverity以外には，どのような品質検査技術を採用しているのでしょうか？
A: 障害追跡のためにGitHubとTracを使用しています。今のところビルドは手作業で行っています。ユニットテストのターゲットは特にありません。コードベースのサイズを考えれば，品質は非常によいと思います。現在の品質を維持するため，今後は，より正式なプロジェクト管理手法とプロセスの導入を目指しています。現時点では，個々の開発者が個人的に持っている開発目標以外には，特に目標は設けていません。もっと正式なスケジュールと目標，評価指標を定義する必要があると思っています。