BTS（バグトラッキングシステム）を使用する際に意識している事

はじめに

どーも、はるねこです。

今回はBTSを使う際に、自分が意識している事について
お話しようと思います。

BTS（バグトラッキングシステム）ってなーに？

バグトラッキングシステムというのは
デバッグする際に便利なツールの事で

・バグをチケットという形で登録し
・バグが修正されて完了するまでを追跡（トラッキング）できる

といったものになります。

今まで使った事のあるものでいうと

・Mantis
・Redmine
・自社開発のもの

といったものを使ってきました。

意識している事1：状況を細かく書いておく

だいたいのBTSには「ステータス」という項目があって
そのチケットの状況を表す事ができるようになっていると思います。

例えばこんな感じ
・新規
・作業中
・修正済み
・修正確認完了（クローズ）

これだけでも、チケットの状況は把握できると思うのですが
バグ修正する際には
調査した内容、過程などをチケットに記載しておく
という事を意識しています。

こうしておく事で、リーダーの方などから
「あのチケット、今どういう状況なんだろう」
とチケットを覗いた際に
より詳細に状況を把握できますし
作業状況的に、手こずっているのか、順調なのか
とかもわかると思います。

意識している事2：
プルリクやコミット番号などを書いておく

修正対応を行った際
GitHub の場合であれば、プルリクのURLを貼っておいたり
SVN の場合であれば、コミット番号を記載したりして

どのコミットによって修正したのか

がわかるようにしておくと、後で改めて確認する際に
追いやすくなるかと思います。

コミットログにチケット番号を記載する
とかも合わせてやっておくとよいかもですね。

意識している事3：対応結果を書いておく

こちらのバグを修正しました。

たまに、これだけ書かれている場合があったりするのですが
これではもったない使い方だな、と個人的には思います。

できるだけ情報を詰め込んでおくと
後から見返した際、またリーダーの方にとって
大事な情報になると自分は考えています。

・原因
・対応
（・影響範囲）
・結果

自分の場合
この4つ（3つ）を必ず書くようにしています。

「原因」を書く理由

何が原因でそのバグが起きたのか。
これはすごく重要な情報です。

もしかしたら、他のバグも
報告内容は違えど、根っこの原因は同じ可能性があります。
その場合、その原因を修正できれば
複数のバグチケットを一気に片付ける事が可能になります。

またデバッグする側からすれば

こういう原因でバグが起きるなら
じゃあ、こういうパターンでもバグが起きるのでは？

という手がかりになります。

実際デバッガーさんは
そういう穴をガンガンついてきます。

「対応方法」を書く理由

そのバグを修正するにあたって
どういった対応を取ったのか、というのを記述します。

これを書いておくとエンバグが出た時の手がかりになります。
その対応を行った事によって
エンバグが発生したんだと思われるので
エンバグからしたら「原因」にあたります。

その際に、どういう対応をしたんだっけ？
というのを確認できるように
書いておいた方がよいかなと思います。

ちなみにエンバグというのは
バグ修正によって、別のバグが発生してしまう事をいいます。

「影響範囲」を書く理由

これは、デバッグ序盤は書かなくてもいいかもです。
（なので（）にしてあります。）

あと、これは自分用に書く、というより
プログラマリーダーの方やディレクターの方用に書く感じです。

「影響範囲」の大きさが
「修正する」「修正しない」の判断材料になるからです。

そのバグを修正する事で影響を受ける範囲が大きい場合
再度その部分をチェックし直すコストもかかってきますし
エンバグの危険性も上がります。

デバッグ序盤は、あまり気にしなくてもいいかもですが
終盤になるにかけて、影響範囲は重要になってきます。

修正する側としては、できるだけ影響範囲が少ない形で
修正できるようにしましょう。

「結果」を書く理由

修正した結果
「どうなっていれば直ったとい言えるのか」
というのを記載します。

というのも
バグ報告をして下さった方が修正確認して頂ければ
いいのですが

その方が、他に優先する作業があり
なかなか修正確認はできない、という事があったりします。

その場合、他の方が修正確認を行う事もなくはないです。

そうなると、バグの細かな詳細をわかっていない人間が
修正確認する事になるので

結果として「どうなっていれば正解か？」「直ったといえるのか」
というのが書いてあると、難しい事は考えなくてよくて
「結果」に書かれている状態にになっているかどうか
をチェックすればいいだけですので
修正確認しやすくなりますし
他の方でも修正確認できますので
なかなかバグチケットがクローズできない。
という事も無くなるかと思います。

おわりに

お疲れ様でした、今回は以上になります。

規模の大きめなプロジェクトになってくると
こういったBTSを利用したデバッグというのは
必須になってくると思います。

その際、チケットに「バグを修正しました」
とだけ記載するのではなく
いろいろな情報を詰めておく事で
よりよいデバッグ運営ができるのではないかと思います。

参考になれば幸いです。

ではまた。