敏捷的核心就是個“快”字：快速開發(fā)，快速推出，快速驗證產品方向。說白了就是管理每個小目標，保證他們能夠按時完成。
想要運用敏捷方法，要注意幾點：
1、開發(fā)做完一個小功能馬上開始測試，減少等待時間。
2、測試的工作量更加分散，不會出現(xiàn)一段時間無事可做，一段時間忙的要死的情況。
3、每次的bug都是針對剛剛開發(fā)完的功能，開發(fā)處理起來會更得心應手，減少溝通成本。
在與同事溝通中，我還了解到，將bug加入開發(fā)計劃會大大影響他們的目標完成進度，往往問題剛整理出一些思路，就因為某些bug需要處理而被迫中斷了。
所以很多時候，直到deadline臨近，目標中還會存留大量任務。如果測試一味地只管提交bug，而不考慮開發(fā)的工作習慣和目標的可執(zhí)行性，就會導致效率大大降低。
*內容截圖自teamin演示案例，結構略有修改，下同*
解決這個問題，需要將bug單獨管理，同時做到合理分配，有節(jié)制，分緩急。
比較好的做法是，測試根據(jù)當前的開發(fā)計劃設置自己的計劃，將所有bug按緊急、重要、一般3種優(yōu)先級來劃分（分幾級不重要，重要的是如何處理分級不同的bug），優(yōu)先挑選緊急bug放入當前目標，重要bug根據(jù)當前進展情況適量分配，一般bug可以暫時不考慮。
另外，bug最好能建立單獨的項目來管理，保證開發(fā)的任務集中度，避免產生過多冗余信息（屬于當前版本卻優(yōu)先度不高的bug）。
項目、目標、標簽，三位一體
舉個不恰當?shù)睦樱瑴y試與開發(fā)的配合就像父母喂孩子一樣，不能等到孩子餓了才給吃的，這樣容易一次喂太多，引起消化不良；也不能什么都給孩子喂，要注意合理配餐，否則營養(yǎng)失衡影響健康發(fā)育?；仡^心疼的不還是你這個做父母的嗎？（哎！好像哪里不對……）
計劃經(jīng)常需要修改，測試如何應對？
計劃變更頻繁可以說是敏捷開發(fā)的另一大特點。上文提到了將bug單獨管理，并將篩選后的bug加入計劃，那么這種單獨管理bug的方式就可以解決計劃頻繁變更的問題嗎？
顯然不能，因為bug最終還是要加入計劃，計劃出現(xiàn)變更，之前分配好的bug也會隨之發(fā)生變化，這樣之前設定的測試目標豈不亂套了嗎？而且想必大家也會有疑問，我分配到開發(fā)計劃中的bug，相當于從測試項目中移走了，那么修改后我如何得知，又如何統(tǒng)一審核呢？
簡單來說，我需要任務支持跨項目協(xié)同，這樣可以將同一個任務分配給不同的項目，達到測試與開發(fā)既各自獨立、又相互聯(lián)動的效果。這其實比較難實現(xiàn)，好在我用的協(xié)作工具支持我這樣做，具體怎么做我不太好描述，直接上圖吧：
跨項目協(xié)同，任務狀態(tài)共享
這樣一來，我在測試項目中設置的目標計劃，不會隨著開發(fā)計劃的變更而變化，計劃的調整都是自主和可預期的，另一方面，也能解決任務狀態(tài)同步和后期審核的問題。
如何編寫測試用例？
計劃開始階段沒有測試工作，主要就是做測試用例了。我想這也是不少測試小伙伴的心頭大患。測試用例結構復雜，分支眾多，很難做的很詳盡，一開始更是不知道從何寫起。
到目前為止，我還沒有找到一款非常合適的管理工具能夠比excel做的更好，管理工具即使能夠自定義功能，也很難達到excel的靈活性。與其在軟件中記錄分支，我寧愿將需要參考的相關任務導出成excel，然后自己添加情況分支，做優(yōu)化修改。
導出任務列表，便于用excel編寫用例
我一般會在開發(fā)前期就將產品的整體計劃導出，作為總的測試用例大綱；再將開發(fā)當前正在做的計劃導出，作為版本測試的用例大綱。
經(jīng)常寫測試用例的測試小伙伴可能都深有體會，用例最頭疼就是整理結構大綱，而產品的整體計劃本身就是一個結構性很強的需求大綱，相當于一個全部功能點的索引目錄。
我們只要導出，稍作修改和補充，用例的完成度就會相當高。而且這樣做還省去了與產品、開發(fā)一條條對接溝通的麻煩，減少了大量的溝通成本。
這種看似“投機取巧”的方法會讓測試的用例編寫工作事半功倍，效率大大提升。
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
重慶分公司
重慶分公司
