ウィリアムのいたずらの開発?日記

ウィリアムのいたずらがコンピューター関係(本家廃止後はその他も)について思ったことを好き勝手に書いているブログです。

バグ管理の話

2007-02-15 14:12:14 | 開発ネタ

きのう、たまたまなんだけど、(blog.goo.ne.jpをみていたときに、たまたまみつけた)
こんなブログをみつけました
Excelを有効活用すれば効率は上がる
http://blog.goo.ne.jp/wildriver_1977/e/cebd060cf404e78d7409902c01720f26


そこに、

例えば、ソフトウェア開発の世界では、バグトラッキングシステムを活用して、バグの情報を登録しています。
そこで、その機能にExcelやCSV出力機能がついていれば、あるいは自分でつけてしまえば、簡単に集計することができます。

ってかいてあるんだけど、
 Excelや桐やAccessや紙ベースでしか、
バグ管理したことしか「ない」私の立場は(^^;)




 最近は「バグトラッキングシステム」なのかもしれないけど、現実的に、朝会、誘拐(夕会?)とか、とくに立って会議をするような状況において、バグトラッキングシステムでネット上でバグ報告をみるっていうのは、きついんじゃないかなあ。。

 紙にだすんだったら、Excelのほうが、きれいで早いし、見やすいしね。。

 また、各社と協業でする場合、ファイヤーウォールを越えてバグトラッキングシステムをみせるっていうのは、やっぱ”やばさ”があると思う。それより、各社の管理台帳、バグ票をメールでやり取りして、集配信したほうが、Excelマクロですむから、らくなわけっすよ。

 ってことで、ウィリアムのいたずら、個人的にやる場合は、また、会社でやる場合も、管理台帳はExcelがおおいかなあ。。ふつうのバグトラッキングシステムで必要な内容程度は、すぐにExcelのマクロでつくれるしね。
 っていうか、そのぐらいのマクロが作れないと、テストデータとか、プログラムの自動生成できないもんね(^^;)




あ、ここで意識合わせ。

Wikipediaのバグ管理システムの説明(以下斜体はそこからの説明)には


バグの発見日時や発見者、再現方法、修正担当者、修正履歴、修正方法、重要度、テスト状況などの多くの情報


ってかいてあるけど、これは、おもに3つの情報から成り立つ

<<サマリーデータ>>
バグID、発見日、発見者、バージョン、緊急度(重要度)、ステータス(原因解析中/修正中/修正確認中/リリースまち/リリース/再現不能など)、障害箇所(複数の場合もあるけど)、障害概要、修正担当者(複数の場合もあるけど)、修正日、修正バージョン、

<<詳細データ>>
(サマリーデータにくわえ)
・障害発生手順(再現手順・テスト状況など)
・障害理由
・修正箇所
・横並びチェック事項

<<添付資料>>
・障害発生手順および修正に関する資料
 (バグの帳票、画面、外国人が開発者の場合、操作ムービーが取れるときには、
  それとかもあり。あと、再現不能、再現手順不明の場合はcore dumpとか、
  エラーが出るデータをDBに登録するSQLとか)

●ここで、サマリーデータは管理上必要な情報で、コレは(複数項目があるので、第一正規形にならないけど、Excelなら、カンマうって並べればいいので)、Excelで表であらわせるから、表にして管理する。これが、管理台帳といわれるもので、これは、集中管理する。

 なぜならば、バグのIDをシーケンシャルに振るからである
 (番号を重複させないためには集中管理が必要)

 この管理台帳を元に打ち合わせでは管理する(朝会、プロジェクトマネージャーの誘拐じゃない、拉致じゃない、夕会等は、この表ベースとなる)

●一方、添付資料は電子化できないこともあり(帳票出力のバグの場合、帳票は紙である)、紙ベースで管理することもある。そこで、詳細データを紙で印刷してしまい、その添付資料の表紙につけ、リンクファイルに管理すると便利。

 電子化されている場合は、バグIDのフォルダーをきって、そこにいれておく。
 Excelシートなら貼り込み可能なのだが、そーいうことはあんまりしないなあ。。??

●詳細データは、一般にバグ票といわれているもので、担当者が受け取り、修正したら担当者が記入し、リンクファイルに保存するか、次の担当者に行く。これを、紙ベースでやると、同時に2人が持っていることはない(同じ紙を持つことは物理的不可能なので)ので、修正担当者が1人となり、2人が同時に直すことはなくなる。ただ、逆に言うと、同時並行で2人ガ修正したい場合は、どーするんだということにはなるが、同時に直されるとデグレードするリスクは大きい。




ということで、バグの管理台帳は、Excelや紙で、バグ票も、ExcelやWordや紙などで、添付資料は電子媒体または紙で管理される。

 という前提があって、バグトラッキングシステムは、このうち、管理台帳部分をやる場合、バグ票まで管理する場合、添付資料まで管理する場合、さまざまある。

 どこまでやっているのかを明確にしないと、たとえば、管理台帳の機能しかないのに、バグトラッキングシステムで全部やろうとすれば、添付資料はどうなるんだ?ってことで、情報は欠落し、品質は急激に落ちる(添付資料をどうつけるか、バグ票の手順をどう書くかによって、バグの発見のしやすさや完全性は、大きく変わる)。




 ということで、Excelは、管理台帳作成に良く使う。

 で、ピボットテーブルより、データのオートフィルタをつかって、担当者ごととか、発生箇所ごとやバージョン(これは修正バージョンも、発生バージョンも)ごとに見ることが多いかなあ。。




 あ、で、そのあと信頼度成長曲線の話がでてくるので、これについても書こうと思ったけど、ながくなるので、この辺できるね。

 ちょっと予告しておくと、信頼度成長曲線の話は、むかしのウォーターフォールでは成立した話なんだけど、いま、仕様変更が多く、そうなると、あるところで、発散してしまうケースがあったり、急激にバグが増えてしまう(秘孔をついてしまうんだな)ってことがあって。。ってはなし。ではでは(^^)v

この記事についてブログを書く
« YAHOO Pipesの様子が出ていま... | トップ | Javascriptで、リストの全要... »
最新の画像もっと見る

開発ネタ」カテゴリの最新記事