Mantisについてのメモ

技術

2/17（木）に某所でJIRA vs Redmine vs Tracなるものが開催されるようですが、Mantisのことを書いてみたいと思います。Mantisという名前はバグ（虫）を食べる昆虫カマキリから来ているようです。

ちなみに僕のMantis実戦経験は製品開発で２週間ぐらいQAの人と２人で使ったぐらいです。

ただ最近ちょろちょろ調べてみたのでメモとして書いておきたいと思います。

参考

Mantisの特徴は以下のような感じかな。

  • バグ一覧がステータス毎にはっきり色が分れていて見やすい。Tracでも色分けされるけど、あれよりはっきりしていて見やすい気がする。
  • バグの「最大放置日数」や「平均完了日数」のように時間をもとにした統計データがとれる。TracやRedmineでもチケットのステータスごとの統計データとかはとれても時間ベースのものは無かったような気がする。
  • バグ管理に特化している。フィールドやステータスにバグの再現性に関するものがある。
  • ワークフローが重厚。new（新規） → feedback（要追加情報） → acknowledged（内容確認済） → confirmed（再現済） → assigned（担当者決定） → resolved（解決済） → closed（完了）という流れ。よく考えるとassignedの前にconfirmedがあるのは変な感じ。一時切り分けみたいなものを想定しているのかも。普通は担当者がアサインされて、調査して、バグを再現させて（場合によってはテストデータや手順を最小化（リダクション））、ソース修正して、解決して、報告者による確認待ちって感じだよね。実際に使ったときはQAがバグを起票して、僕が修正して、QAが確認してクローズという流れで、ステータスはnew,resolved,closedの３つしか使わなかった。
  • 項目が多く画面がごちゃごちゃしてる感じ

2011/02/11追記　

http://www.mantisbt.org/bugs/view_all_bug_page.php
を見る限りWikiあるね。。。いつできたんだろう。僕が使ったのは1.0.8だったけどその時点では無かったような気がする。

TracやRedmineがある今となっては古い感じは否めませんが、大規模プロジェクトの結合試験以降のバグ管理にフィットしそうな感じです。ただしかなりかっちり運用する必要があるでしょう。チケットのように抽象化されたものを扱うにはかなりカスタマイズしないとフィットしないでしょう。



ちなみにMantisに限らずBTS（もしくはCIとか、SCMとか、スクラムとか、かんばんとか、etc）に興味ある方は2/18（金）に開催予定のShibuya.trac第10回勉強会に参加したり、発表したり、スタッフしたりすると良いと思いますw