我的軟件測試轉型之路(2)

　　在此期間，我還看過@架構師Jack原創的《功能測試用例基礎設計模型》，這個文檔2天轉發已超過150次，我也向所有同行推薦該測試設計模型實例化的測試用例，供大家消化該設計模型。想要的朋友可以去微盤下載《功能測試基礎設計模型(24個設計方法的實例化用例)》。

　　我當時還借鑒了@季哥來自淘寶的《探索式測試》系列文章，包括：《探索式測試的秘密——記在淘兩年》、 《組合測試法中的全對偶測試法》、《探索式測試實踐之缺陷大掃除和結對測試》。

　　當然這么多東西，我覺得自己還需要時間來消化。

　　繼續測試之路——路上的風景

　　也許會有人問：有沒有后悔做tester?

　　我過去也常問自己：做得開心嗎?產品質量提升了嗎?看到自己的前景了嗎?找到high點了嗎?

　　現在我可以回答：OK，我做到了，并且還可以持續做得更好。

　　可能有很多測試人員會問：測試人員的價值到底何在?在這里，我套用和整合@朱少民老師的一些術語，給出我的回答。

　　我認為，Scrum中測試人員價值應當體現在：

　　預防缺陷的手段，提高洞察力，增強業務知識。

　　缺陷在需求、開發前期就已經存在了，關鍵是用什么手段去挖掘出來預防。在sprint前獲取到的需求，測試人員可以站在客戶角度上來闡述自己的觀點，與開發人員進行充分交流和討論，使自己在用戶體驗、業務邏輯等等方面的經驗充分體現出來。

　　在開發過程中，測試人員除了站在客戶的角度進行測試，還應當提供更全面的質量反饋，包括代碼質量的檢查，這個可以通過redmine與 SVN雙向關聯來做檢查依據。目前整個過程測試人員尚未參與代碼編寫，應當參與并推進代碼評審，將代碼問題及時反饋出來;并且參與或者推進單元測試，檢查單元測試狀態(確保單元測試達到80%以上覆蓋率，幫助開發人員開發出具有良好可測試性的代碼)，自始至終將質量問題及時反饋出來，保證在sprint的整個過程中質量受到足夠的關注，提高質量改進的持續性和可視性。

　　隨著版本任務的增加，每個版本回歸測試的成本增加，可以適當考慮部分穩定功能進行自動化測試。當然，這是遠景。

　　持續改進、反饋，充分發揮每個版本統計報告的作用，對缺陷進行分析，總結出一些規律，幫助開發人員建立良好的習慣，改進代碼的質量。

　　測試人員，應當在自己的道路上看到風景，以前作為開發，寫好一個功能，很high;測試人員也要有這種心境，提高了產品質量，預防了缺陷，很high。找到自己的high法，才可以把測試玩得更爽 ，我知道@朱少民老師、@季哥來自淘寶、@段念-段文韜、@架構師Jack，都玩得很爽，但是有一點：要爽得靠自己，多跟高手交流，有利于提升自己，但是不要刻意復制別人成功的經驗，因為每個團隊的模式和環境不大相同。

　　總結

　　每個人離開自己熟悉的領域，投入到新的領域中(說實在軟件測試也囊括了開發領域)，必然存在一些迷茫，不知如何入手，身邊如果有一個靠譜的高手，指點一下，眼前將會一片明亮?？上?，現實總是殘酷的，往往很多時候，都要靠自己去摸索，只有經歷了、深刻體會了，才知道如何改變，以及如何迎接新挑戰，調整到恰到好處的心態。這樣子，才能夠穩健進入轉型的軌道。不要害怕改變和投入，一定要堅定信念，在前進的道路上，多參考同行的成功經驗：@朱少民老師、@段念-段文韜、@季哥來自淘寶、@架構師Jack、@Aullyxiao，迎合團隊價值，不斷修正自己的偏差，走出一條華麗的直路!

　　我很慶幸，經歷了一個測試團隊從無到有的創建，同時也幫助開發人員掌握了一些測試的基本技能，用于推進質量保證，讓整個團隊達到共識?，F在的我，只是剛過了轉型的痛苦期，測試工作也僅僅是剛剛開始，還有很多有意義的事情需要去做。

　　路漫漫其修遠兮，吾將上下而求索!

　　給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博(@InfoQ)或者騰訊微博(@InfoQ)關注我們，并與我們的編輯和其他讀者朋友交流。

原文轉自：http://www.infoq.com/cn/articles/transformation-way-software-testing