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

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

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

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

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

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

開発者のバグ駆除作業を振り返る

開発者は、バグの駆除を実践する。これは、開発者がバグだけではなく、それと同時に関係するソースコードとも付き合う必要があることを示す。バグを駆除するためには、駆除対象となるソースコードの構成を特定し、取得する必要がある。場合によっては、バグが発見されたときのソースコードの構成を参照することもあるかもしれない。そしてバグの駆除作業を終えて適切な確認を経た後に、バグが駆除されたソースコードの構成を結合(共有)することになる。

この一連のソースコードの扱いは極めて複雑であるが、定型的な作業でもある。そして、手作業で行うと思わぬミスを犯しソースコードの紛失や、バグの再発などを引き起こす危険性もある。開発者にとっては厄介な作業の代表例だ。

このためこれらのソースコードを扱うために、多くのプロジェクトではソースコード管理を行う(本来は、ソフトウェア構成管理について言及すべきであるが、ものごとをわかりやすくするため今回は、ソースコード管理とする)。

ソースコード管理では、格納されたソースコードがそれぞれバージョン制御(リビジョン制御とも言う)される。個々のバージョンでは、そのソースコードについての詳細な情報が格納されている。例えば、いつ誰が変更したか、どのような理由で変更したかなどの情報や、前のバージョンと比較することで何を変更したのかという情報を得ることができる。

図1:バグとソースコードのライフサイクルの関係
(画像をクリックすると別ウィンドウに拡大図を表示します)

ソースコード管理での作業の進捗と品質のチェック

では、バグの駆除作業の進捗や品質(ひいてはソフトウェアの品質やプロジェクトの進捗)をソースコード管理の情報のみから把握するのはどうか。なぜならば、開発者にとってもっとも馴染みがあり、扱いやすいのがソースコードであるからだ。馴染みのあるものでこれらの情報を把握できるのならば、価値があると言える。

しかしながら、開発者以外の開発チームメンバーとの間での報告はどうか。例えば、プロジェクト管理者がバグの駆除作業の最中や終了後の報告として考えてみると、「BankAccount.csのver.1.4などでバグ管理番号101を駆除しました。詳細はソースコードと付随する情報を見てください」と言われたとする。

この場合、プロジェクト管理者はソースコード管理下にアクセスし、同じコメント(おそらく「バグ管理番号101」が記載されているはずであろう)が付加されているすべてのソースコードを識別し、次回のテスト用のベースラインに含まれているのかどうかを確認しなければならない。この作業を「全開発者数×全バグ数」を繰り返し行うことでしか、品質や進捗を推しはかることができないとなると、大きなオーバーヘッドになる危険性があるだろう。

つまり、ソースコード管理のみで、開発チーム全体で品質や進捗を共有するのは難しいということが言えるのではないか。 次のページ


1   2  3  次のページ


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


INDEX
第3回:バグが開発者と開発チームメンバーをツナグ!
開発者のバグ駆除作業を振り返る
  バグ管理での作業の進捗と品質のチェック
  バグがツナグ!開発者と開発チームメンバー