來源：李樂@infoq
2010年12月31日，在網易從事了多年開發之後，依依不捨地離開，面臨的是一個完全從零開始的全新職位：SQA，也就是tester。
當時對為什麼被選擇做軟體質量保證，而不是繼續在研發上進取，持有保留態度：憑什麼要我轉，不是別人？這個時候，多年的夥伴、領隊——雷叔就把我的優點暴露出來了：認真、心細、負責；好吧，基於以上幾點，只有“我行”，只能給力了。
從心底裡，對質量管理、SQA等概念，我並沒有多想，因為根本想不了，腦子裡面沒有太全面的認知，即使雷叔講過一些，我還是覺得不夠全面，不知道業界是如何做的？所以心裡多多少少有點擔心！
幾個人成立一個新團隊，什麼都是從零開始，關鍵還是要有一些流程，這幾年開發中也積累了些經驗，總結了些問題。在12月底，我提交了《軟體質量保證第一季度計劃》，這個計劃後來也成為了整個質量保證體系的核心，大概 綱要如下：
1、搭建專案管理平臺
2、搭建持續整合平臺
3、規範開發流程
4、制定軟體質量保證規範流程
5、建立缺陷管理
6、建立風險管理庫、經驗教訓庫（長遠計劃）
2011年1月25日，苦於沒有規範的流程，做起事來還是不夠順暢，在奮戰多日之後，制定了《產品研發質保流程手冊》，簡單來說，劃分了：需求、開發、釋出三個階段，每個階段定義驗收的產物。為什麼要制定這個？必須有章可依，否則步伐不穩健，走的再遠，也會亂。
道路上，難免遭遇坎坷，要不斷提升自己，也有三點切身體會：
1、如電影《熱血教練》中卡特教練所說，先把基本功練紮實了，才能有勝算。既然從零開始，就不要被困惑不已的瑣事所糾纏著，下決心突破，可以研讀：質量管理、缺陷預防、軟體測試、持續整合等書籍，並且通過網際網路瞭解一些公司是如何開展測試和質量管理的方方面面。
2、個人價值迎合團隊價值，果斷取捨，為團隊利益著想。
3、堅定信念，避免浮躁，把握遠景，不要急於尋求成就感。
同時，在調研期間，我意識到持續整合很重要，並按照當前的需求，重點關注以下幾點：持續測試、持續審查、持續反饋。
圖：早期的開發、測試流程原型圖
無悔選擇測試之路——路上的抉擇、進取
有了流程規範，接下來是實施和持續改進。這些規範運用在一個專案上，先做了三個月，不停地測試，編寫功能測試用例，也走了2條彎路：
1、用例花了大量時間編寫，就連開啟瀏覽器、輸入xx、點選登入，這些也記錄了（這種是早期狀況）。 我居然還請纓加入開發，因為看到一些任務完成不了。後來雷叔也指明，測試做測試應該去做的，如果我當時幫忙做開發，那麼很多測試都完成不了，一樣保證不了質量。
2、所以，測試人員除了要了解業務，使用簡單、清晰的語言結構來進行測試之外，還應該準確定位自己，明白自己在整個版本迭代中，控制質量的位置！
事後想想，那段日子鍛鍊了什麼？那三個月無法忘記，每天高強度測試，用的最多的就是：功能測試（邊界值、場景法），白盒測試。其實就是鍛鍊了測試的基礎技能和流程管理。
後來測試管理流程逐步建立起來，但是在測試過程中，應當如何提高程式碼質量？這個階段我們參考了敏捷開發中高質量 Java 程式碼開發實踐，做了一些適合團隊的改進，見下圖：
圖：質量提升的模式
這種迭代版本中java程式碼質量提升的模式，已經採用了將近一年，非常有效。
同年Q2，我們對測試管理進行了改進，其中是受到 @段念-段文韜《組織敏捷測試》影響，採用類似“一頁紙計劃”的測試文件（在此要感謝@段念-段文韜）在redmine進行管理。之前每次整理測試計劃，傳送給開發人員，實際上耗費了一些時間，並且成效不大，現在的任務：需求、開發、測試，全部交給redmine管理，所有事情一目瞭然，對任何人都是可見的，有沒有完成，進度如何，非常清晰。
為了規範整個開發測試流程的管理，包括開發、測試的互動，我們又制定了輕量級的 SQA框架，見下圖：
圖：最初制定的SQA框架
不過此後這個框架也發生了比較大的變化，做得更好、更輕量級。無獨有偶，我偶然的機會買了一本@朱少民老師的：《全程軟體測試》，發覺這個SQA框架也是滲透到目前的每個環節，更適合目前團隊的scrum模式，在此也要感謝@朱少民老師，真是相見恨晚，不然可以少走很多彎路！！！
大家可能會問：Scrum模式、使用者故事，測試人員怎麼利用？為什麼想到這個？如果遺漏了測試場景，團隊會很不爽，怎麼避免呢？結合@Aullyxiao的《軟體測試之魂》提到分層測試的想法，想了想，還可以這麼整：
圖：分層測試圖
對於目前的開發架構來說，一個使用者故事，涉及這四個點，可以從這四個點入手來進行質量保證。如何做呢？單元測試就開發人員處理了；程式碼審查，測試人員可以參與和監督，其實就是要保證：將開發任務與提交到SVN的程式碼進行關聯。這樣一來，當測試人員檢查開發任務的時候，就可以找到改變過的程式碼。我曾經試過從這些程式碼裡面檢視邏輯，找到分支場景，補充到測試用例裡面。
在此期間，我還看過@架構師Jack原創的《功能測試用例基礎設計模型》，這個文件2天轉發已超過150次，我也向所有同行推薦該測試設計模型例項化的測試用例，供大家消化該設計模型。想要的朋友可以去微盤下載《功能測試基礎設計模型（24個設計方法的例項化用例）》。
我當時還借鑑了@季哥來自淘寶的《探索式測試》系列文章，包括：《探索式測試的祕密——記在淘兩年》、 《組合測試法中的全對偶測試法》、《探索式測試實踐之缺陷大掃除和結對測試》。
當然這麼多東西，我覺得自己還需要時間來消化。
繼續測試之路——路上的風景
也許會有人問：有沒有後悔做tester？
我過去也常問自己：做得開心嗎？產品質量提升了嗎？看到自己的前景了嗎？找到high點了嗎？
現在我可以回答：OK，我做到了，並且還可以持續做得更好。
可能有很多測試人員會問：測試人員的價值到底何在？在這裡，我套用和整合@朱少民老師的一些術語，給出我的回答。
我認為，Scrum中測試人員價值應當體現在：
1、預防缺陷的手段，提高洞察力，增強業務知識。
缺陷在需求、開發前期就已經存在了，關鍵是用什麼手段去挖掘出來預防。在sprint前獲取到的需求，測試人員可以站在客戶角度上來闡述自己的觀點，與開發人員進行充分交流和討論，使自己在使用者體驗、業務邏輯等等方面的經驗充分體現出來。
2、在開發過程中，測試人員除了站在客戶的角度進行測試，還應當提供更全面的質量反饋，包括程式碼質量的檢查，這個可以通過redmine與SVN雙向關聯來做檢查依據。目前整個過程測試人員尚未參與程式碼編寫，應當參與並推進程式碼評審，將程式碼問題及時反饋出來；並且參與或者推進單元測試，檢查單元測試狀態（確保單元測試達到80%以上覆蓋率，幫助開發人員開發出具有良好可測試性的程式碼），自始至終將質量問題及時反饋出來，保證在sprint的整個過程中質量受到足夠的關注，提高質量改進的持續性和可視性。
3、隨著版本任務的增加，每個版本回歸測試的成本增加，可以適當考慮部分穩定功能進行自動化測試。當然，這是遠景。
4、持續改進、反饋，充分發揮每個版本統計報告的作用，對缺陷進行分析，總結出一些規律，幫助開發人員建立良好的習慣，改進程式碼的質量。
測試人員，應當在自己的道路上看到風景，以前作為開發，寫好一個功能，很high；測試人員也要有這種心境，提高了產品質量，預防了缺陷，很high。找到自己的high法，才可以把測試玩得更爽 ，我知道@朱少民老師、@季哥來自淘寶、@段念-段文韜、@架構師Jack，都玩得很爽，但是有一點：要爽得靠自己，多跟高手交流，有利於提升自己，但是不要刻意複製別人成功的經驗，因為每個團隊的模式和環境不大相同。
總結
每個人離開自己熟悉的領域，投入到新的領域中（說實在軟體測試也囊括了開發領域），必然存在一些迷茫，不知如何入手，身邊如果有一個靠譜的高手，指點一下，眼前將會一片明亮。可惜，現實總是殘酷的，往往很多時候，都要靠自己去摸索，只有經歷了、深刻體會了，才知道如何改變，以及如何迎接新挑戰，調整到恰到好處的心態。這樣子，才能夠穩健進入轉型的軌道。不要害怕改變和投入，一定要堅定信念，在前進的道路上，多參考同行的成功經驗：@朱少民老師、@段念-段文韜、@季哥來自淘寶、@架構師Jack、@Aullyxiao，迎合團隊價值，不斷修正自己的偏差，走出一條華麗的直路！
我很慶幸，經歷了一個測試團隊從無到有的建立，同時也幫助開發人員掌握了一些測試的基本技能，用於推進質量保證，讓整個團隊達到共識。現在的我，只是剛過了轉型的痛苦期，測試工作也僅僅是剛剛開始，還有很多有意義的事情需要去做。
路漫漫其修遠兮，吾將上下而求索！