TOPシステム開発> 第3回:バグが開発者と開発チームメンバーをツナグ! (2/3)




バグ管理再考のススメ - TFSの場合

バグ管理再考のススメ - TFSの場合

第3回:バグが開発者と開発チームメンバーをツナグ!

著者:マイクロソフト 長沢 智治

公開日:2008/03/18(火)

バグ管理での作業の進捗と品質のチェック

それでは、バグ管理ではどうか。バグは共通の関心ごとであり、バグのライフサイクルを通じて、ソフトウェアの品質とプロジェクトの進捗を知ることができることは前回に説明した。このことから、開発者が実施するバグの駆除作業の品質と進捗の把握もバグ管理下で行うことができると言える。これが行えれば、開発者間および、プロジェクト管理者をはじめとする他のロール間でも情報のやり取りを同じ粒度で行えるようになるのではないだろうか。

これを実現するためには、バグと実際にバグを駆除したソースコードとの関係を保持しておくことが条件となるだろう。なぜならば、バグの情報にはソースコードの詳細な情報やソースコードの構成についての情報が含まれていないからである。またバグ管理の情報とソースコードの情報の乖離が起きる可能性もあるだろう。すなわち、バグ管理とソースコード管理の関連付けがカギを握っているといえる。

この関連付けには非常に意義がある。バグ管理の観点からすると、バグと関連するソースコードの関係をレビューすることで、例えばリリースビルドで確かにそのバグが駆除されているかといった詳細まで追跡ができるようになる。

ソースコード管理の観点からも、1つ1つのソースコードのバージョンがどのバグを駆除するために行われたのかを把握することができるし、複数のソースコードへの変更であってもバグを基点にし、すべての関連するソースコードのバージョンを特定することでもできるようになるだろう。

図2:変更セットによる効果
(画像をクリックすると別ウィンドウに拡大図を表示します)

変更セット

バグと各ソースコードのバージョンを関連付けることは、非常に意義があるが、実はまだ複雑な要素を含んでいる。ソースコードの各バージョンというのは、ソースコード管理システムとしては必須で持っていなければならないものである。しかし、開発者にとって必ずしもなくてはならないものではない。

なぜならば、開発者にとって最も把握したい単位は「今回のバグの駆除作業で作成や変更したソースコードの一式」だからだ。必ずしも、個々のソースコードの詳細なバージョン番号を1つ1つ把握している必要はないのである。そこまで注意深く認識しなければならないのでは、開発者の負担を増加しているにすぎない。

そこで変更セットである。変更セットとは、先に述べた自分の作業で作成や変更したソースコードの一式(正確には個々のソースコードのバージョンの一式)である。いわば、バグの駆除作業のトランザクションと言えるものである。

変更セットでソースコードの構成を把握できると、開発者は自分の作業の単位で、それ以外の開発チームのメンバーはバグという単位でものごとを把握でき、さらにバグと1対1で関連付けられた変更セットでより詳細なソースコードの情報へも追跡できるようになる。 次のページ


前のページ  1   2  3  次のページ


マイクロソフト株式会社 長沢 智治
著者プロフィール
マイクロソフト株式会社  長沢 智治
ソフトウェア開発業務改善のプリンシパル コンサルタントやソリューション アーキテクトとして多くの多種多様なソフトウェア開発の現場のお手伝いを経験。2007年1月よりマイクロソフトのエバンジェリストとして、特にチーム開発の訴求を行うべく活動中。
ブログ「長沢智治のライフサイクルブログ」
http://blogs.msdn.com/tomohn


この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。

INDEX
第3回:バグが開発者と開発チームメンバーをツナグ!
  開発者のバグ駆除作業を振り返る
バグ管理での作業の進捗と品質のチェック
  バグがツナグ!開発者と開発チームメンバー
バグ管理再考のススメ - TFSの場合
第1回 バグのライフサイクルを理解する!
第2回 開発チームにおけるバグの扱い方
第3回 バグが開発者と開発チームメンバーをツナグ!
第4回 バグを作り込む前に開発者にできること
関連記事
今こそ聞きたいVisual Studio 2008の基礎の基礎