こんにちは！　やまもと＠テスト番長です。

最近gihyo.jpで連載させていただいている関係で、BTSについて考える機会が多くなっています。

思えば今までのエンジニア人生で色々なBTSを使ってきました。
今まで経験したことから、幾つか記事には出ないような四方山話をしてみたいと思います。

Bugzillaの蟻?画像が辛い

Bugzillaを使ってシステムテストをしていたとき、ふとTOPページの蟻?画像の話になりました。 使ったことのある方はご存知かと思いますが、昆虫の頭部の顕微鏡写真のようなあいつです。 忙しいだけでも辛いのに、アレを見るとゲンナリする！ということになり 急遽ほのぼの画像に差し替えたところ、相当印象が変わって見えました。 プロジェクトの雰囲気も若干良くなったように思います。

チケットがよく壊れるBTSもある

rubyで出来た某軽量BTS的なものを使っていたとき、チケットが1000件を越える頃から 段々ページが重くなり、頻繁にチケットが壊れるようになりました。 バグを取り扱うシステムに不都合が出るのはなんとも切ないものです。BTSの耐久性や安定性は大事ですね。 オープンソースで歴史のあるBTSはその点信頼性が高いものが多いようです。

ローカルルール色々

バグの取り扱いについての情報はあまり表に出ないように思います。 上手く行ってないけれど台所事情は人に相談しづらいというのが本音でしょう。 正式なお作法はどうなのかという話もそれほどなく、皆さんケースバイケースということのようです。

個人的な経験の中でも特に処理フローはまちまちでした。開発チームの体制に影響されるのが大きいです。

• スキルの低いテスターが参加する場合は、チケットが有効か判定するフローを作る


• リリース段階（ステージ→本番、など）に合わせて、確認段階を細かく作る


• 場合によりクローズの確認を管理者のみ出来るようにする

などはすぐ思いつくところですね。

インストールが嫌

BTSのインストールは面倒なので出来ればやりたくありません。 全般に日本語の情報が少なく、バージョンが変わると以前の情報が役に立たなかったりして、なんだかんだで一日潰れたりします。 ここは皆さん苦労しているはずなので、もっと情報共有すべきなのかもしれません。

私製BTSでの運営は結構多い

既製品のカスタマイズの不便さや不具合を恐れて内製のBTSを使ってらっしゃるところも結構多く、2割くらいあるようです。 色々なものがあるようなので、表に出てきて比較できたら面白いのに。。とつい思ってしまいます。

BTSはコミュニケーションツールかもしれない

バグを管理してくれるBTSですが、結局人間が関わるものですので 「バグを抱えた人々のためのコミュニケーションツール」なのかもしれないと思うことが多々あります。 受託開発で顧客とBTS越しにやりとりする時などは特にそうですね。 バグを記録することだけに注目していると上手く回らないように思います。

取り留めのない話になりましたが、皆さんのご苦労話もあればお聞かせください。
連載記事のほうもお時間のあるときにでもお読みいただき、ご意見をいただけますと幸いです。

ソフトウェア開発の必須アイテム,BTSを使ってみよう