バグ修正自体は簡単な場合が多いでしょうが、正しく修正することは簡単ではありません。逆に、修正が原因で新たなバグが発生することがあります。これが、機能退行です。機能退行がないことを確認するため、バグ修正時には回帰テスト(全機能の正常ケースが正しく動作すること)を実施する必要があります。
筆者がよくやったのが、データにバグを作り込むこと(第124回、第125回掲載)です。「設定値が間違っていたので、修正したつもりが誤ったデータを入れてしまう」「データを変更したことで別の機能に影響が出た」などが発生し、焦ります。
検出したバグだけを修正するのでは品質向上は望めません。そこで、バグを見つけた場合は、同じ原因による類似バグがないか、他のモジュール、他の機能、他人のプログラムをチェックする必要があります(図5)。
図5は、類似バグの例です。例えば、fncAとfncBという2つの関数のどちらも、数値演算のバグ(第132回掲載)におけるゼロ除算の対策ができていません。このように、あるバグと同様のものが、複数箇所に存在しないか確認しましょう。
バグによっては再現性がなく、異常動作の発生頻度が1000回に1回のような低確率の場合もあります。開発日程が厳しくても、必ずリリース日に出荷すべきですが、全てのバグを完全に修正できない場合、例えば以下のような条件を設定し、出荷する/しないを決定します。
上記のような条件を顧客や上司に説明し、どのような判断をすべきか決定しましょう。
今回は、バグ百科事典の総まとめとして、過去20回かけて連載してきたバグを振り返りつつ、それらの検出手順をまとめました。ところどころに連載番号を振っておきましたので、興味のあるバグを見つけた場合は、過去記事を見ていただければと思います。
本シリーズにおいて、全てのバグを取り上げていませんが、解説したバグを思い出し、明日のより良いソフトウェア開発につなげていただければ幸いです。
次回からは、バグ検出ドリル(過去シリーズ)とバグ百科事典を発展させた新シリーズをお届けします。どうぞご期待ください。
本シリーズ「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の新刊「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から発売されました。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しました。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。
前著「ソフトウェア技術者のためのバグ検出ドリル」(2019年11月刊行)も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。
両書とも興味のある方は、Amazon.comや書店でチェックしてください!
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.