如何用輕量協做工具作bug管理

對於一個團隊來講，工做效率的高低很大程度上取決於團隊的管理。

而做爲一名剛接觸測試職位的新人來講，如何把一堆堆雜亂不堪的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中比較特別的功能，接下來我就與你們分享一下。

一、如何作版本管理

第一個要說的，就是「目標」功能了。之因此把它放在第一位說，就是由於它完美解決了我在其餘在線管理工具中一直沒有解決的問題——版本管理。

而一開始，對於這個功能的出現我是很困惑的：這樣一排tab頁同樣的東西是用來作什麼的？這不是和標籤功能重複了嗎？（teamin的任務自己是能夠設置標籤的）

用了一段時間後，當我想要將建立的任務進一步整理歸類的時候，忽然發現「目標」功能的真正價值……這不就是一個版本管理神器麼！

目標是一個獨立於項目與任務間的管理層級，不一樣於標籤，它可以帶給我管理上更多發揮的空間。對於測試而言，目標很是適合作bug的版本管理。

顯示目標後會出現兩個默認標籤，「所有」和「無目標」。

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

• 調出項目目標，按不一樣的版本建立好目標，將任務添加到項目中。

• 進入「無目標」中，將其中的bug分配到各自的版本目標中。

這種方式能夠幫助我將冗長的「bug清單」進行瘦身，相比其餘管理工具那種上千條bug混在一塊兒的bug表單來講，「列表+目標」這一功能組合無疑是更好的選擇。

你想一想，當一個開發MM懷揣着以往與測試GG種種工做上不愉快的回憶戰戰兢兢來到這裏時，卻碰見了我這樣一個如此爲她着想，把bug計劃安排的層次分明的SunshineTestBigBoy，不免不會產生崇拜之情，不免不會……

哼哼，我纔不會讓大家發現個人真正意圖~

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

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

你們都知道，看板模式的優勢就是便於查看任務進度，但卻不擅長作總體計劃，而teamin是我試用過的全部工具中，惟一擁有列表和看板兩種模式的管理工具。

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

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

除此以外，日曆中的任務也是相連通的。

三、如何與開發進行協做

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

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

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

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

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

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

而在teamin中，卻徹底不一樣。任務能夠屬於多個項目，也就是說不一樣的項目共同擁有一條任務，並且支持狀態同步。通俗一點說呢，就是心靈感應，你在那邊幹了什麼我都知道哦~

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

一點建議

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

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

其次，但願能有相似垃圾箱的功能：被刪除的項目或團隊能夠被恢復，以避免誤刪或數據丟失。

總體感受

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

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

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

它就像一塊七巧板，看似平淡無奇，但當你真正深刻其中，卻發現它能夠憑藉玩家的發揮，變換出千種形狀。這一點尤其可貴，也是我最終選擇它的緣由。

寫在後面的話

其實沒有什麼規定說，bug管理就必定要用bug管理工具，那只是人們的一種固有思惟，有時咱們須要撕下它們的標籤，才能看清咱們探求問題的本質。

選擇管理工具的惟一標準，是它可否讓個人工做提升效率，而非它的標籤。

若是你們有什麼問題，或是有更好的工具和管理方法，也歡迎一塊兒探討。