組み込みエンジニアの現場力養成ドリル（6）

「順調すぎるデバッグ」は本当に順調？（2/2 ページ）

公開 2018年07月02日 09時00分

[TechFactory]

印刷する連載新着通知を受け取る

問題点2：5月7日の少し後で、バグ摘出曲線が水平

　ほぼ垂直に立ち上がったバグ累積曲線が、ある日突然、水平になることはありません。水平になったのは、テストをしていないためです。あるいは、バグを見つける能力が全くないテストを実行していたためです。バグを検出できなかった約2,000件のテスト項目は捨てましょう。誰が何の目的で作ったテスト項目かを調査し、ベテラン設計者にテスト項目の再作成を依頼するといいでしょう。

問題点3：テスト項目の消化が速すぎる

　4月2日のマシンデバッグ開始から、テスト項目の消化は予定を遙かに上回るペースで推移し、順調すぎます。このように「極めて順調」である原因は2つ考えられます。「プログラムの品質が非常に良い」もしくは「テスト項目の品質が非常に低く、バグを摘出できていない」のいずれかです。

　このプロジェクトではこれまでの開発で1KLOCあたり5.9件のバグが出ていたということは、全社平均である3.8件／KLOCの約2倍であり、非常に品質が悪いプロジェクトと言えます。そんなプロジェクトが、突然、神が乗り移って超高品質のソフトウェアを開発できるとは思えません。従って「設計したテスト項目はザルで、バグを見つける目的を果たしていない」と判断せざるを得ません。特に、上記でも述べたように5月7日以降に実施したテスト項目には、バグを見つける「パワー」がありません。

　以上を考えて、以下の対策を取るべきです。

短期的な対策（この製品をリリースするための対策）

（1）　ベテラン設計者に依頼してテスト項目を見直し、「バグを見つける能力が高いテスト項目」を追加する。リリースまでの時間がなければ、品質保証部のエンジニアに依頼して、テスト項目を作成してもらう。
（2）　5月7日に摘出された100件のバグのうち、「件数かせぎの同件バグ」を除外し、正しい件数を算出する。そして、バグ摘出目標である310件との差を計算し、それを新たな「摘出目標」として、デバッグ工程を続行する。
（3）　少なくとも4週間はスケジュールが遅延すると思われるので、リリース日程を見直す。

中長期的な対策（プロジェクトの根本的な問題点への対策）

（1）　2週間の机上デバッグで何をしていたか、調査・分析する。
（2）　Aさんのプロジェクトのソフトウェア開発プロセスの全体を精査し、このプロジェクトのバグ生成率が、全社平均の約2倍と高い原因を調査する。今回の「順調すぎるデバッグ」は、バグ率が高いことと深く関係している。

おわりに

　デバッグでの消化テスト項目数と累積摘出バグ数のグラフから、多くのことが読み解けます。デバッグの進捗が、一見、順調であっても、大きな問題を抱えている場合が少なくありません。

　また、プロジェクトの問題はその製品限りの単発的な問題ではなく、プロジェクトが長い間「患っていた病気」が原因である場合がほとんどです。まずは、短期的な対策に取り掛かり、さらに、中長期的な対策で病巣を退治しましょう。この演習で、そんな「巧妙に隠れた病巣」を見つける嗅覚を磨いてもらえれば幸いです。

この連載新着通知をメールで受け取る

印刷する

組み込みエンジニアの現場力養成ドリル

このコラムでは、組み込みエンジニアが日々の開発で実際に遭遇する「小さなトラブルを」取り上げ、演習形式で解説します。

連載新着通知を受け取る

この連載の記事をもっと見る

この記事の著者

山浦恒央　東海大学大学院組込み技術研究科非常勤講師（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科准教授、2016年より非常勤講師。主な著書・訳書は、「Advances in Computers」（Academic Press社、共著）、「ピープルウエア第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。