臨近年末，各家公司都進入了緊張的年前項目衝刺階段，我們也不例外。每天開完早會，就聽大家在抱怨任務太多做不完、一個月都沒正常過週末了云云。
據開發部門的同事說，他們的任務列表的長度都快趕上老婆雙十一的購物清單了，而作爲與開發組聯繫最緊密的測試組，我們的處境也好不到哪去，畢竟用的都是一款協作工具。
爲了提高測試與開發的協作效率，個人在嘗試方法過程中也總結了幾條小技巧，在這裏和大家分享一下，歡迎互相探討。
如何用敏捷方法做測試？
敏捷的核心就是個“快”字：快速開發，快速推出，快速驗證產品方向。說白了就是管理每個小目標，保證他們能夠按時完成。
想要運用敏捷方法，要注意幾點：
開發做完一個小功能馬上開始測試，減少等待時間。
測試的工作量更加分散，不會出現一段時間無事可做，一段時間忙的要死的情況。
每次的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編寫用例
我一般會在開發前期就將產品的整體計劃導出，作爲總的測試用例大綱；再將開發當前正在做的計劃導出，作爲版本測試的用例大綱。
經常寫測試用例的測試小夥伴可能都深有體會，用例最頭疼就是整理結構大綱，而產品的整體計劃本身就是一個結構性很強的需求大綱，相當於一個全部功能點的索引目錄。
我們只要導出，稍作修改和補充，用例的完成度就會相當高。而且這樣做還省去了與產品、開發一條條對接溝通的麻煩，減少了大量的溝通成本。
這種看似“投機取巧”的方法會讓測試的用例編寫工作事半功倍，效率大大提升。