二月份，因為案子需求，公司內部的 Bug tracking system 功能不夠，所以要另外架設，怎麼說功能不夠? 第一，沒有英文界面；第二，無法開放公司網路之外的使用者登入 (用 AD 方式管理)，以上兩點，可能有些人會覺得有些好笑，其實我自己心裡也是很想笑。因為一個百分之八十以上都是做國外客戶的 ODM/OEM 廠怎麼會搞出個沒有英文界面的 Bug tracking system? 而第二點，用 AD 做為管理，也是有點匪疑所思，如果今天的案子完全是公司內部自行開發，我想這沒什麼問題，可是事實上，公司的主力其實都在於代工的客戶，所以用這樣的系統架構，真的是很讓人無言。
既然問題出現了，總是要解決的，剛好這次案子我又有參與，以前也有點 maintain network server 的經驗，那就只好跳出來，主動負責這個 system 的架設。
由於 cost down 的關係，公司目前政策是不可能買外面那種要 license 的 bug tracking system，所以我就朝自由軟體授權的方向去找，如果有錢買，我倒是覺得 HP 的 Test Director(Mercury Quality Center) 相當好用了，不過沒錢，想想就算了，我找了很多，其中我挑出兩套做為候選，分別是 Mantis and Bugzilla。後來採部門內部投票，選出 Mantis。
其實我心裡也想著要用 Mantis 來架，雖然我以前玩 Firefox 時有碰過 Bugzilla，界面對我而言不陌生，但是仍然有許多因素讓我想用 Mantis。
- Friendly user interface - 使用者通常會希望易懂的操作界面，易讀的 bug list。
- Maintain - Mantis 用 PHP 寫成的，這對我或者對於日後要接手的人而言，都是比較容易進入狀況的語言，Bugzilla 用 perl 寫的，perl 雖然簡單，但是比起 C-like 的 PHP 而言，大部份的人對 PHP 的 source code 還是比較容易上手。( Perl 的 source code 其實不算是易讀性很強的 code，我被毒過...:P)
- User training - 可能很少人想到這點，如果用 Bugzilla，要寫的 SOP 絕對會比 Mantis 多，如果有新進人員，那麼要讀這些 SOP 也是個負擔。Mantis 基本上不太需要什麼 SOP 的，雖然還是有 PM 跟我要，但是比起寫 Bugzilla 的 SOP，我覺得輕鬆很多。
總之，一套 Bug tracking system 如果能設計到讓 User 一碰就馬上上手，那樣是最好的。像 HP 的 Test Director (Mercury Quality Center)，我們當初接觸時，完全沒有 Training，界面一摸，就可以直接 key bug 了。所以，這套 Mantis 架起來，我也朝這個目標去架設，界面和欄位名稱是一定改的，Workflow 也是必改的項目。接下來就是內部的一些特殊需求，例如一些特別的 QC 評估分數之類的，因為是 PHP 所以我改起來也比較好上手，所以，其實也沒碰到什麼大問題。
不過 Mantis 的權限控制一直蠻讓我 Care 的，Mantis 並沒有對於使用者的 Role 定義切換 bug status 的權限，例如：RD 不能將 bug 的 status 切換成 Closed，這應該是要 QA verify 過後，由 QA 來切換才對，但是 Mantis 本身沒有這樣的機制，所以，這部份變成要修改 source code，有大改的方法，也有小改的方法，重點是，我實在懶得改...=_=|||
我事情也是很多的吶 (公司又不加薪 XD)，而且這樣的問題，其實內部協調好就好，應該不會有人故意亂切，而且又有 History 可以查，亂切的話，很容易查，查出來就扣 KPI !! 呵呵!
談到 KPI ( Kill Person Indicator )，不談也罷，也是個拉賽的東西...
最後結論就是，Mantis 好用啦!!
