如何用敏捷方法做測試？

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

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

1、開發做完一個小功能馬上開始測試，減少等待時間。

2、測試的工作量更加分散，不會出現一段時間無事可做，一段時間忙的要死的情況。

3、每次的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編寫用例

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

經常寫測試用例的測試小伙伴可能都深有體會，用例最頭疼就是整理結構大綱，而產品的整體計劃本身就是一個結構性很強的需求大綱，相當于一個全部功能點的索引目錄。

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

這種看似“投機取巧”的方法會讓測試的用例編寫工作事半功倍，效率大大提升。