開発の初めから順番に書いていってみる　その８３：単体テスト（８）バグ修正概要 - ウィリアムのいたずらの、まちあるき、たべあるきーPART2

シリーズ「開発の初めから順番に書いていってみる」の続きです。

　設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
　（バックナンバーは、ここ　http://www.geocities.jp/xmldtp/index_kaihatsu.htm）。

　前回で、ここの順番で言う「４．実際にテストする」が終わりましたので、今回は次の、「バグ修正して再テスト」です。

■バグ修正の一般的な流れ

　テストで障害が起きたり、なんらかのはずみでバグを見つけてしまった場合は、イカのような形で、バグ修正するのが、一般的だと思います。

１．バグ発生内容を特定し、エビデンスをとる（とれたら）
２．バグ票に記入
３．台帳に登録、担当者にバグ票を送付
４．担当者がバグ修正
　　　　・バグの原因特定
　　　　・修正
　　　　・確認テスト
５．担当者がバグ票の障害修正欄などいろいろ記入する
６．バグ発見者にバグ票が戻ってくるので、確認
　　　　→OKなら、７へ、NGなら、４へ
７．修正確認をバグ票と台帳に記入、バグ票は保管
８．デグレードしていないかのリグレッションテスト

ということで、ここでの成果物＆入出力は
・バグ票（＋添付資料のエビデンスなど）
・バグ管理台帳
ということになります。

■バグ票、管理台帳と、バグトラッキングシステム（BTS)

　で、バグ票、管理台帳ですが、紙でやる場合は、こんなかんじですが（まあ、これを、特に管理台帳をExcelやAccessなどでやるという話はありますが、それもふくめて）、このようなバグ票、管理台帳を電子化したものが、バグ管理システム（＝バグトラッキングシステム、BTS)となります。

■リグレッションテスト、回帰テスト

　で、バグ修正したときに、修正箇所はなおしたんだけど、今度は他のところに（今までちゃんと動いていたところに）バグを入れてしまうということがありえます。これをデグレードといい、これを防ぐため、すでに行ったテスト項目を、再度確認することをリグレッションテスト（あるいは回帰テスト）といいます。

　これは、2度手間、３度手間・・になるので、いかに自動化して、品質をおとさずテストするかというのが、鍵になります。

■横並びチェック

　あるバグがあったとき、同じモジュールを通るところは、同じようなバグがでるはずです。そして、そのモジュールを直せば、同じようなバグも修正されるはずです。
　また、同じモジュールではないけど、同じようなコーディングをしているときも、同じようなバグがでるはずです。そういうところは、そのようなコーディングしてるところ全部を直して、修正しなきゃいけません。

　このように、あるバグに対し、同じ原因によって、似たようなバグが出ている、出る可能性がある場合、修正して、その似たようなバグが出ているところも、直っているかどうか確認（チェック）する必要があります。
　これが、横並びチェックです。

　横並びチェック項目に対し、あらたにバグ票を発行するか、同じバグ票でやるか、同じバグ票に横並びチェック項目を入れるかは、プロジェクトによって違います。
　

　ということで、バグの概要は書いたので、次回からは、個別にいくつかのテーマを詳しく書いてみたいと思います。