我的軟件測試轉型之路

　　選擇測試之路——路上的迷茫

　　2010年12月31日，在網易從事了多年開發之后，依依不舍地離開，面臨的是一個完全從零開始的全新職位：SQA，也就是tester。

　　當時對為什么被選擇做軟件質量保證，而不是繼續在研發上進取，持有保留態度：憑什么要我轉，不是別人?這個時候，多年的伙伴、領隊——雷叔就把我的優點暴露出來了：認真、心細、負責;好吧，基于以上幾點，只有“我行”，只能給力了。

　　從心底里，對質量管理、SQA等概念，我并沒有多想，因為根本想不了，腦子里面沒有太全面的認知，即使雷叔講過一些，我還是覺得不夠全面，不知道業界是如何做的?所以心里多多少少有點擔心!

　　幾個人成立一個新團隊，什么都是從零開始，關鍵還是要有一些流程，這幾年開發中也積累了些經驗，總結了些問題。在12月底，我提交了《軟件質量保證第一季度計劃》，這個計劃后來也成為了整個質量保證體系的核心，大概 綱要如下：

　　搭建項目管理平臺

　　搭建持續集成平臺

　　規范開發流程

　　制定軟件質量保證規范流程

　　建立缺陷管理

　　建立風險管理庫、經驗教訓庫(長遠計劃)

　　2011年1月25日，苦于沒有規范的流程，做起事來還是不夠順暢，在奮戰多日之后，制定了《產品研發質保流程手冊》，簡單來說，劃分了：需求、開發、發布三個階段，每個階段定義驗收的產物。為什么要制定這個?必須有章可依，否則步伐不穩健，走的再遠，也會亂。

　　道路上，難免遭遇坎坷，要不斷提升自己，也有三點切身體會：

　　如電影《熱血教練》中卡特教練所說，先把基本功練扎實了，才能有勝算。既然從零開始，就不要被困惑不已的瑣事所糾纏著，下決心突破，可以研讀：質量管理、缺陷預防、軟件測試、持續集成等書籍，并且通過互聯網了解一些公司是如何開展測試和質量管理的方方面面。

　　個人價值迎合團隊價值，果斷取舍，為團隊利益著想。

　　堅定信念，避免浮躁，把握遠景，不要急于尋求成就感。

　　同時，在調研期間，我意識到持續集成很重要，并按照當前的需求，重點關注以下幾點：持續測試、持續審查、持續反饋。

　　圖：早期的開發、測試流程原型圖

　　無悔選擇測試之路——路上的抉擇、進取

　　有了流程規范，接下來是實施和持續改進。這些規范運用在一個項目上，先做了三個月，不停地測試，編寫功能測試用例，也走了2條彎路：

　　用例花了大量時間編寫，就連打開瀏覽器、輸入xx、點擊登錄，這些也記錄了(這種是早期狀況)。 我居然還請纓加入開發，因為看到一些任務完成不了。后來雷叔也指明，測試做測試應該去做的，如果我當時幫忙做開發，那么很多測試都完成不了，一樣保證不了質量。

　　所以，測試人員除了要了解業務，使用簡單、清晰的語言結構來進行測試之外，還應該準確定位自己，明白自己在整個版本迭代中，控制質量的位置!

　　事后想想，那段日子鍛煉了什么?那三個月無法忘記，每天高強度測試，用的最多的就是：功能測試(邊界值、場景法)，白盒測試。其實就是鍛煉了測試的基礎技能和流程管理。

　　后來測試管理流程逐步建立起來，但是在測試過程中，應當如何提高代碼質量?這個階段我們參考了敏捷開發中高質量 Java 代碼開發實踐，做了一些適合團隊的改進，見下圖：

　　圖：質量提升的模式

　　這種迭代版本中java代碼質量提升的模式，已經采用了將近一年，非常有效。

　　同年Q2，我們對測試管理進行了改進，其中是受到 @段念-段文韜《組織敏捷測試》影響，采用類似“一頁紙計劃”的測試文檔(在此要感謝@段念-段文韜)在redmine進行管理。之前每次整理測試計劃，發送給開發人員，實際上耗費了一些時間，并且成效不大，現在的任務：需求、開發、測試，全部交給redmine管理，所有事情一目了然，對任何人都是可見的，有沒有完成，進度如何，非常清晰。

　　為了規范整個開發測試流程的管理，包括開發、測試的交互，我們又制定了輕量級的 SQA框架，見下圖：

　　圖：最初制定的SQA框架

　　不過此后這個框架也發生了比較大的變化，做得更好、更輕量級。無獨有偶，我偶然的機會買了一本@朱少民老師的：《全程軟件測試》，發覺這個SQA框架也是滲透到目前的每個環節，更適合目前團隊的scrum模式，在此也要感謝@朱少民老師，真是相見恨晚，不然可以少走很多彎路!!!

　　大家可能會問：Scrum模式、用戶故事，測試人員怎么利用?為什么想到這個?如果遺漏了測試場景，團隊會很不爽，怎么避免呢?結合@Aullyxiao的《軟件測試之魂》提到分層測試的想法，想了想，還可以這么整：

　　圖：分層測試圖

　　對于目前的開發架構來說，一個用戶故事，涉及這四個點，可以從這四個點入手來進行質量保證。如何做呢?單元測試就開發人員處理了;代碼審查，測試人員可以參與和監督，其實就是要保證：將開發任務與提交到SVN的代碼進行關聯。這樣一來，當測試人員檢查開發任務的時候，就可以找到改變過的代碼。我曾經試過從這些代碼里面查看邏輯，找到分支場景，補充到測試用例里面。

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