チケットという資産を有効活用する
ソフトウェアの開発プロジェクトが終わると、Tracには大量のチケットが生み出される。やれやれ、一件落着、こんな障害情報なんて見たくもないという人が多いかも知れないけれど、実はこの情報は次の開発に生かすべきヒントを含む重要な情報だと思っている。こんな貴重で、しかも面白い情報を見捨ててしまうのは非常に勿体ない話だ。
例えば、wikiページに障害のまとめを載せて大凡の傾向や注意すべき点などを整理しておき、振り返りの時の反省材料に使ったり、チェックリストやガイドライン更新時の参考材料にしている。もちろん、Tracのチケットはずっと残っているのでいつでも誰でも参照出来るけれど、たくさんのチケットを一度に見せられてもなかなか理解出来ないし、全体像を把握するのは難しい。そんな時にこそ、このような要約ページが有ると有り難い。
下記は、障害の原因をキーとした分類例であり、なぜなぜ分析の如くさらに深く追求しても良いし、あるいは別の切り口で分類しても良い。また、そのような分類そのものをテンプレート化しておくと、いつも同じ形式で分類することが可能になる。チケットとして蓄積された障害情報は、様々な見方で分類、分析が出来ると思う。
- ソースコード関連
- nullポインタ例外：
#181,#189- if分の条件判断漏れ：
#187,#18,#186- 配列の範囲外アクセス：
#22,#78- 仕様書関連
- 仕様の記載が曖昧：
#16,#17,#43- 仕様の記載漏れ：
#114,#143,#44,#14,- 仕様が矛盾：
#89
このようにチケット情報を整理してみると、興味深い事実が浮かび上がってくる。全くの経験則で何の理論的な裏付けも無いのだけど、一例として、こんな傾向を示すことが多いようだ。
- ある開発者が作った不具合は、場所を変えて何度も発生する。（個人の癖のようなものは、なかなか直らない）
- 不適切な仕様書やコードは、次に作業する人が真似るので問題の拡大再生産を引き起こす。（昔から存在するからと言って、必ずしも正しいとは限らない）
- 類似の問題は、開発者やプロジェクトが異なっても同じように発生する。（つまづく箇所は皆同じ）
- 出来の悪いコード（クラス、コンポーネント等）は、何度も繰り返し修正が入る。（素性が悪いとフォローが大変）
もちろん、全てのチケットを残さず整理しようとすると（悲しいことに）膨大な手間暇がかかってしまいがいなので、そのような場合には適当にサンプリングしたり、特に注目すべき項目を取り出して使っている。個々のチケットを評価して集計するのは少々大変だけど、ほんの少しの手間を掛けるだけで問題の全般的な傾向がハッキリと見えてくるのは面白いと思う。
細川さんは、これまでに見つけたバグについて、メモを取っているそうです。メモして覚えておけば、一度見たことがあるバグに次に出くわしたとき、「これ前に見たことがある」と分かります。それだけでもだいぶ違うそうです。
「JaSST'10 Hokkaido」参加レポート（その2）――銀の弾丸と欠陥管理：オブリガート ～元テストエンジニアの過去と現在～：エンジニアライフ
細川さんは、個人的にメモするだけでなく、誰でも参照できるバグのデータベースのようなものでバグ情報を共有できるようにすることが、テストやレビューの専門家の育成に必要なのではないか、と話しました。
関連
