測試如何在敏捷團隊中工做？

臨近年底，各家公司都進入了緊張的年前項目衝刺階段，咱們也不例外。天天開完早會，就聽你們在抱怨任務太多作不完、一個月都沒正常過週末了云云。

據開發部門的同事說，他們的任務列表的長度都快遇上老婆雙十一的購物清單了，而做爲與開發組聯繫最緊密的測試組，咱們的處境也好不到哪去，畢竟用的都是一款協做工具。

爲了提升測試與開發的協做效率，我的在嘗試方法過程當中也總結了幾條小技巧，在這裏和你們分享一下，歡迎互相探討。

如何用敏捷方法作測試？

敏捷的核心就是個「快」字：快速開發，快速推出，快速驗證產品方向。說白了就是管理每一個小目標，保證他們可以按時完成。

想要運用敏捷方法，要注意幾點：

開發作完一個小功能立刻開始測試，減小等待時間。
測試的工做量更加分散，不會出現一段時間無事可作，一段時間忙的要死的狀況。
每次的bug都是針對剛剛開發完的功能，開發處理起來會更駕輕就熟，減小溝通成本。

在與同事溝通中，我還了解到，將bug加入開發計劃會大大影響他們的目標完成進度，每每問題剛整理出一些思路，就由於某些bug須要處理而被迫中斷了。

因此不少時候，直到deadline臨近，目標中還會存留大量任務。若是測試一味地只管提交bug，而不考慮開發的工做習慣和目標的可執行性，就會致使效率大大下降。

內容截圖自teamin演示案例，結構略有修改，下同

解決這個問題，須要將bug單獨管理，同時作到合理分配，有節制，分緩急。

比較好的作法是，測試根據當前的開發計劃設置本身的計劃，將全部bug按緊急、重要、通常3種優先級來劃分（分幾級不重要，重要的是如何處理分級不一樣的bug），優先挑選緊急bug放入當前目標，重要bug根據當前進展狀況適量分配，通常bug能夠暫時不考慮。

另外，bug最好能創建單獨的項目來管理，保證開發的任務集中度，避免產生過多冗餘信息（屬於當前版本卻優先度不高的bug）。

項目、目標、標籤，三位一體

舉個不恰當的例子，測試與開發的配合就像父母喂孩子同樣，不能等到孩子餓了纔給吃的，這樣容易一次喂太多，引發消化不良；也不能什麼都給孩子喂，要注意合理配餐，不然養分失衡影響健康發育。回頭心疼的不仍是你這個作父母的嗎？（哎！好像哪裏不對……）

計劃常常須要修改，測試如何應對？

計劃變動頻繁能夠說是敏捷開發的另外一大特色。上文提到了將bug單獨管理，並將篩選後的bug加入計劃，那麼這種單獨管理bug的方式就能夠解決計劃頻繁變動的問題嗎？

顯然不能，由於bug最終仍是要加入計劃，計劃出現變動，以前分配好的bug也會隨之發生變化，這樣以前設定的測試目標豈不亂套了嗎？並且想必你們也會有疑問，我分配到開發計劃中的bug，至關於從測試項目中移走了，那麼修改後我如何得知，又如何統一審覈呢？

簡單來講，我須要任務支持跨項目協同，這樣能夠將同一個任務分配給不一樣的項目，達到測試與開發既各自獨立、又相互聯動的效果。這其實比較難實現，好在我用的協做工具支持我這樣作，具體怎麼作我不太好描述，直接上圖吧：

跨項目協同，任務狀態共享

這樣一來，我在測試項目中設置的目標計劃，不會隨着開發計劃的變動而變化，計劃的調整都是自主和可預期的，另外一方面，也能解決任務狀態同步和後期審覈的問題。

如何編寫測試用例？

計劃開始階段沒有測試工做，主要就是作測試用例了。我想這也是很多測試小夥伴的心頭大患。測試用例結構複雜，分支衆多，很難作的很詳盡，一開始更是不知道從何寫起。

到目前爲止，我尚未找到一款很是合適的管理工具可以比excel作的更好，管理工具即便可以自定義功能，也很難達到excel的靈活性。與其在軟件中記錄分支，我寧願將須要參考的相關任務導出成excel，而後本身添加狀況分支，作優化修改。

導出任務列表，便於用excel編寫用例

我通常會在開發前期就將產品的總體計劃導出，做爲總的測試用例大綱；再將開發當前正在作的計劃導出，做爲版本測試的用例大綱。

常常寫測試用例的測試小夥伴可能都深有體會，用例最頭疼就是整理結構大綱，而產品的總體計劃自己就是一個結構性很強的需求大綱，至關於一個所有功能點的索引目錄。

咱們只要導出，稍做修改和補充，用例的完成度就會至關高。並且這樣作還省去了與產品、開發一條條對接溝通的麻煩，減小了大量的溝通成本。

這種看似「投機取巧」的方法會讓測試的用例編寫工做事半功倍，效率大大提高。