對于一個團隊來說，工作效率的高低很大程度上取決于團隊的管理。

而作為一名剛接觸測試職位的新人來說，如何把一堆堆雜亂不堪的bug管理得井井有條，無疑是最重要的。

我之前一直覺得測試是一份很個人化的工作，每個人有每個人做測試的思路，尤其是編寫測試用例，需要大量的自定義字段來充實整個測試體系。在bug管理上，交給任何一個管理工具，我覺得都不如自己手動編輯測試邏輯更加高效。

因此，除了excel，我之前基本沒有接觸過其他工具。

工作了一段時間，我漸漸發現還是自己太年輕，測試其實是一份非常需要配合溝通的工作。由于excel在協作上實在辦法不多，我每次只能把excel文件發給開發妹子們(沒錯，我們公司的開發都是妹子)。

但excel中的是個整體計劃，每個開發負責的部分都是不同的，所以只能在全部信息中尋找自己需要做的那部分，這很難保證不會有遺漏。而計劃一旦需要修改，我也很難與她們在第一時間達成同步。因此，很需要找一款能夠在不同角色間溝通的bug管理工具。

于是，我將工作內容做了一個匯總，好幫助自己理清bug管理方面的需求：

• 編寫測試用例(經測試，還是excel最好用)
• 記錄并做好版本、功能、優先級相關bug分類
• 與開發溝通，及時反饋bug完成情況
• 一些個人的事務管理

帶著這些需求，我開始試用bug管理類的工具。

起初，同事給我推薦了幾款bug管理類的工具，像bugzilla，mantis，redmine，QC，jira等。但這些工具的使用體驗真的很不友好：我連安裝都沒學會。

你要下載一個安裝包，解壓，在一群格式不明的文件中尋找一個尾部有.exe的文件，如果有好幾個，那么你還要看看他們的名字哪一個更像是安裝啟動文件了，當然，你也可能根本找不到exe……(血淚史如圖)

 

對我這種軟件小白來說，一次安裝和配置就要花上好久，還加上各種看不明白的英文。最可怕的是，一旦不能用了還不知道是什么原因，網上各種找解決的帖子，想想都覺得挫敗感滿滿……

隨后，我將目標轉向了中文化的在線團隊協作工具，諸如teambition、worktile這種，希望能用更簡單直接的方式解決我的問題。至少，我不用再花時間和exe文件做斗爭了!

但tb和wt的問題是，這種以“項目+看板”為基礎的管理模式，雖然能夠更直觀的展現bug的處理進度。但對于測試管理這種動輒1000+的bug量來說，前期制定版本計劃會變得非常麻煩。

“使用管理工具的目的不就是提高效率么?為什么會比excel表格還難用?”這是我在試用過一大堆管理工具后產生的最大困惑。

接下來我又試用了幾款小眾軟件，在這個過程中，偶然發現了一款叫做teamin的團隊協作工具(這里吐個槽：開始看名字，還以為是teambition的精簡版，teamin團隊表打我!>_< )。

秉持著是騾子是馬拉出來溜溜的心態，我注冊賬號試用了一下……

他給我的第一印象是簡單

和teambition，worktile這些團隊協作工具一樣，teamin也是一款基于Saas的在線管理工具，沒有在一開始就讓我的“安裝包恐懼癥”發作。

他的界面很干凈，沒有那么多復雜的功能干擾我，如果不是左側的菜單，第一眼會讓我以為這是一款像evernote、石墨那種類型的文檔管理工具。

 

它創建任務的方式也很像是在做筆記：寫完一條任務，回車，開始記錄下一條，我覺得這種記錄bug的方式讓我覺得很舒服。

他有很自由的使用體驗

經過一段時間的使用，我發現teamin的層級結構很特別。它一共分為3層：組織、團隊和項目;項目中又分為列表、看板、日歷、進展和文件五個模塊;“我的任務”和“我的消息”作為個人事務管理獨立于項目，信息范圍覆蓋整個組織;任務可以不斷向下創建不止一層子任務。

這個結構縱向和橫向的延展度都很好。簡單來說呢，就是自由度很高。在這個結構下，我嘗試出了一些與其他管理工具不太一樣的新用法。

舉個栗子來說：

teamin中，“我的任務”支持創建獨立于組織之外的私人任務(只有創建者可以查看并編輯)，并且可以通過設置任務所屬項目與組織內任務進行相互轉化。

如此一來，我就可以在自己的任務列表中隨手記錄下一些問題或是建議，也不會干擾到其他人。而一旦這些東西得到驗證，我可以直接將它們轉化成任務分配到項目中去。也就是說，記錄與管理可以分開來做了。

這一點讓我感覺很自在。

無論發現了什么問題，我都可以先記錄下來，而不必擔心打亂已有的bug清單，之后找個時間統一進行進一步的篩選與管理。這就比以往那種把任務從頭設到尾的管理方式輕松多了，優先級設置也更精確……

個人管理的便利性和人性化讓我漸漸愛上了這款工具。而且越使用，你就越會覺得，好像所有事都變得得心應手起來……很奇怪，它沒有太多限制，也沒有太復雜的功能，卻很有控制力。

這種讓人奇怪的感覺不僅體現在結構上，功能上teamin也秉承了“去邊框化，去功能化”的特點，讓我可以根據自己的實際需要，快速嘗試出適合自己的那套管理方式。

他如何解決我的問題

上文提到了我在工作中遇到的一些問題。為了解決這些問題，我漸漸總結出了一套用法，涉及到一些teamin中比較特別的功能，接下來我就與大家分享一下。

1、如何做版本管理

第一個要說的，就是“目標”功能了。之所以把它放在第一位說，就是因為它完美解決了我在其他在線管理工具中一直沒有解決的問題——版本管理。

而一開始，對于這個功能的出現我是很困惑的：這樣一排tab頁一樣的東西是用來做什么的?這不是和標簽功能重復了嗎?(teamin的任務本身是可以設置標簽的)

用了一段時間后，當我想要將創建的任務進一步整理歸類的時候，突然發現“目標”功能的真正價值……這不就是一個版本管理神器么!

目標是一個獨立于項目與任務間的管理層級，不同于標簽，它能夠帶給我管理上更多發揮的空間。對于測試而言，目標非常適合做bug的版本管理。

顯示目標后會出現兩個默認標簽，“全部”和“無目標”。

“全部”就是查看項目內所有bug;而沒有被指定目標的bug，會被統一歸入“無目標”中，這里我更喜歡叫它“bug需求池”;除此之外，我還需要新建幾個目標用來管理具體版本：

調出項目目標，按不同的版本創建好目標，將任務添加到項目中。

進入“無目標”中，將其中的bug分配到各自的版本目標中。

這種方式可以幫助我將冗長的“bug清單”進行瘦身，相比其他管理工具那種上千條bug混在一起的bug表單來說，“列表+目標”這一功能組合無疑是更好的選擇。

你想想，當一個開發MM懷揣著以往與測試GG種種工作上不愉快的回憶戰戰兢兢來到這里時，卻遇見了我這樣一個如此為她著想，把bug計劃安排的井井有條的SunshineTestBigBoy，難免不會產生崇拜之情，難免不會……

哼哼，我才不會讓你們發現我的真正意圖~

2、如何制定計劃、跟蹤進展

teamin的第二個功能特點，就是他看板+列表的雙模式管理方式。

大家都知道，看板模式的優點就是便于查看任務進度，但卻不擅長做整體計劃，而teamin是我試用過的所有工具中，唯一擁有列表和看板兩種模式的管理工具。

不僅如此，teamin中的列表看板任務信息是互通的。也就是說，我在列表中做的所有操作和修改，都會實時反映在看板中。

這樣一來，我可以先在列表中做好計劃，再到看版中管理bug進度。兩種模式分別對應兩種管理需求，使制定計劃與控制進度都能達到效率最大化。 

除此之外，日歷中的任務也是相連通的。

3、如何與開發進行協作

很多時候，測試和開發間最大的問題就是溝通，我們無法即時將bug推送到開發面前，往往過了幾個月，查看bug清單時，才發現仍然后很多bug沒有被處理過，相信很多測試都遇到過這種問題。

為了能讓bug得到及時解決，我一開始的做法是直接將bug提到開發項目中，但結果反而效率更低了。

在與開發妹子交換意見時，我了解到，其實bug與任務放在一起會使項目列表顯得紛亂不堪，任務也會變得更難區分。

于是，我換了一種方式，把測試項目獨立出來，將bug和開發項目分開，需要在當前開發計劃中修改的bug才通過任務跨項目的方式分配給她們。這樣的好處是可以防止開發陷入bug的汪洋大海中，可以有條不紊地安排開發的bug修改計劃。

當然，想要做到這一點，和任務跨項目協同是分不開的。

其他管理工具在解決跨項目任務協同的問題時，一般都用任務復制，或是任務關聯，將一條bug分成兩條不同的任務，測試一份，開發一份。但實際上，他沒有真正解決信息同步這個問題，即便開發那邊完成了bug的修改，測試這里的bug狀態也不會隨之更新。

而在teamin中，卻完全不同。任務可以屬于多個項目，也就是說不同的項目共同擁有一條任務，而且支持狀態同步。通俗一點說呢，就是心靈感應，你在那邊干了什么我都知道哦~ 

這樣的處理方式，最終得到了廣大妹子們的一致好評，她們紛紛表示喜聞樂見，人民幸福指數也有了顯著提高，朕心甚慰。

一點建議

講完了獨特用法和優點，我對teamin還有幾點小建議。

首先，希望能夠添加信息導入導出的功能：之前光是將測試項目搬到teamin中，就花費了我大半天的時間。對于想要入駐teamin的用戶來說，這也算是個不大不小的門檻了。

其次，希望能有類似垃圾箱的功能：被刪除的項目或團隊可以被恢復，以免誤刪或數據丟失。

整體感覺

總體來說，teamin是一款體驗流暢、功能強大的管理工具。雖然略有不足，但同時也給了我很多使用上的驚喜。

而且，它和同類管理工具相比，有個最大的不同點：

我感覺teamin一直在跟著我的思維走，它不會束縛我，讓我可以隨意發揮、創造。很多需求都能找到很多種解決辦法，我只需要在其中選擇一個最優的，無須擔心它在功能上會不會支持。隨著使用的不斷深入，又會發現更多讓人眼前的一亮的點。

它就像一塊七巧板，看似平淡無奇，但當你真正深入其中，卻發現它可以憑借玩家的發揮，變換出千種形狀。這一點尤為難得，也是我最終選擇它的原因。

寫在后面的話

其實沒有什么規定說，bug管理就一定要用bug管理工具，那只是人們的一種固有思維，有時我們需要撕下它們的標簽，才能看清我們探求問題的本質。

選擇管理工具的唯一標準，是它能否讓我的工作提高效率，而非它的標簽。

如果大家有什么問題，或是有更好的工具和管理方法，也歡迎一起探討。