我的測試之旅：（9）行動——簡化測試文件和流程

現有的各種測試相關文件都很齊備，但是已經有較豐富經驗的我感覺到其中的資訊有很多都是不必要的冗餘，老早就想把它們給簡化簡化。因為我這個人總覺得，如果是沒有必要的或者不需要的資訊，為何一定要放在文件裡呢，直接不寫不就行了麼？放在那裡總會吸引人去看一眼，然後心想“哦，N/A。”，這也是時間和精力的浪費啊！保持文件乾淨整潔，只記錄有意義的資訊，不是很好麼。而且，在原來的測試管理工具中，測試用例和測試計劃，都有很多不同的版本，針對的是不同的產品釋出版本。版本多也好的，但問題就是有的時候時間上最新的版本不一定是資訊最新的，對於後續的測試人員來說，這會增加他們的工作量。還有就是每一份測試計劃所描述的都有侷限，所有的資訊都是針對當時的那個版本測試任務，針對其中所要驗證的功能，而這只是被測物件所有功能的一個子集，看不到一個整體的景象。

Scrum試點專案提供了這樣的一個機會，可以去操作這種簡化，因為我是第一個，也是專案團隊數量擴張前的唯一一個測試出身的團隊成員，一定程度上享有一錘定音的權力。而Scrum這種開發模式，要求測試用例的全集必須能持續地體現被測系統的全景，因為每一個迭代所新開發出來的功能都要進行驗證，而之前已經存在的功能也需要進行迴歸測試（其實在敏捷的方式下，“迴歸”這個說法已經沒有了意義），因此我們必須隨時都掌握著當前最新的測試用例集合。而另一方面，增量式的開發需要頻繁地迴歸驗證以前的功能，對手工測試的方式來說這是不可能完成的任務，必須秉持100%自動化的思想，而這也正是我的堅持。不過當時我和Scrum Master以及專案經理在100%自動化上的意見有些出入，為此交流過無數次，我記得最後我們還是堅持了100%自動化的想法，因為我確確實實就做到了。

自動化的地位得到提升，間接地使得另一個問題浮出水面，也即測試計劃。在傳統的模式中，由於測試工作大多根據模組或者領域來劃分，以單個專案的形式來進行管理，持續時間較長， 每一個測試專案所要驗證的功能數目也比較多，因而需要安排一個單獨的測試計劃環節，還需要產生出測試計劃文件，並且由相關人士來評審。但是在Scrum這種迭代增量式開發方式下，每一個迭代所開發的功能數量都不會很多，而要執行的測試用例卻呈現不斷增加的趨勢，因為它要執行新功能測試用例加舊功能迴歸測試用例。對於測試計劃這個活動來說，如果每一個迭代都要開測試計劃評審會議，產生測試計劃文件並且得到批覆的話，將會是一筆非常大的管理性開銷，而且每一個測試計劃的重複資訊量都很大，還會產生很多的版本。因而測試計劃這個活動在Scrum模式下必須得改變才行。

還有一個收到影響的就是缺陷追蹤實踐。我們也就是4個人的團隊，而且都坐在同一個會議室裡，面對面肩並肩。如果發現一個缺陷，還得開啟IE瀏覽器（呃，其實我用FireFox更多一點），開啟缺陷追蹤系統的網頁，輸入各種資訊提交缺陷報告，等待鄰座的開發人員在專心寫程式碼的時候收到通知郵件，開啟網頁，研究分析缺陷相關的資訊，然後再給我提要求，然後我們再通過網頁來回幾個回合？當然這樣做很沒有必要，我們自然是可以面對面交流的，但是交流完解決了問題，我們是否還需要記錄呢？將這樣的問題記錄到缺陷追蹤系統中去，到底有沒有意義，畢竟記錄資訊也還是要花時間的，而這樣的問題可能在一個迭代裡會遇到很多，還有可能很多缺陷並不是什麼大問題，幾分鐘可能就改好了，要記錄嗎？

還有一個問題就是，在傳統的模式中，等到測試人員開始工作，通常都是程式碼已經開發完畢，有較穩定的產品版本供測試人員使用。但是在Scrum的模式中，在一個月的迭代週期裡，我們是否也應該如此操作？這樣做的問題在於，在迭代剛開始的那一段時間裡，開發人員很忙，測試人員卻很空，空得無事可做，到了迭代快結束的時候卻是忙得不得了。更讓人擔心的是，如果這麼晚才開始測試，測試又發現了不少的軟體缺陷的話，剩下的時間根本就不夠給開發人員用來修復缺陷。這樣的開發過程必須得有變化。還有就是，每一個迭代都會拿到不同的新功能開發任務，但這些新功能的情況會有不同，有的功能開發任務相對較輕鬆卻需要花不少功夫測試，有的功能則是開發很困難測試很容易。因此必然會出現在一個迭代當中，開發測試工作所需要的工作量比例不同，但此時開發測試人員的比例在一個團隊中確實保持不變的，在Scrum保持團隊穩定的原則前提下，如何處理這樣的情況呢？

這些都是我想要利用Scrum試點專案這個機會，或者是作為Scrum試點專案中的測試人員必須要思考解決的問題。

檢視更多“我的測試之旅”文章
1. 起點——作為軟體開發人員
2. 轉變——作為專職測試人員
3. 同期——加入測試自動化小組
4. 並行——自動化迴歸測試
5. 難點——功能改進的測試
6. 跳轉——追逐新鮮事物的探險者
7. 啟程——Scrum中的測試工作者
8. 困難——沒有現成的測試工具
9. 行動——簡化測試文件和流程
10. 貢獻——開發項流程（Development Item Process）
11. 嘗試——Scrum Master
12. 機遇——測試自動化培訓師和教練
13. 轉型——敏捷教練

敬請關注 《大測大悟——測試的敏捷之道》開放出版過程

聯絡方式：
- 新浪微博
- 谷歌郵箱 kaverjody @gmail.com
- LinkedIn