前幾天，筆者與一位在大型網際網路公司從事質量保證的朋友交談，作為網際網路產品質量和測試的負責人，他最近負責的質量管理方面遇到了很多困難。主要有：1）測試團隊在敏捷開發模式下的價值非常有限；2）開發人員只顧自已寫程式碼，沒有任何文件，測試人員無從下手，3）由於進度的原因，測試人員測試的時間非常有限，上線後出現很多問題；4）由於測試人員得不到開發團隊的認可，離職率非常高；5）質量部門無法收集到資料，不能進行質量度量；6）測試團隊也有一批自動化測試專家，但派不上用場…..這些問題可能很多開發團隊都會遇到，總結一下，大致是這幾個方面：

}越來越多的企業希望採用，但沒有把握

}習慣於傳統的瀑布式產品開發流程已不滿足快速發展需要，但大規模改動不現實

}缺少敏捷軟體開發專家和人才

}技術人員需要觀念的轉變和方法培訓

}缺乏相應的質量控制方法

}需要經常的和及時的質量度量、測試、決策

}自動化測試不能落到實處，每日構建仍是紙上談兵

在現在行業中，需求變化太快，不管我們怎麼努力去做，發現還是不能滿足客戶的需要，不管需求搞得多麼細，到交付產品給客戶的事情，總是有這樣那樣的問題，這個時候就不得不去修改我們的軟體，這是目前很多企業尤其是網際網路公司面臨的一個挑戰，如何解決這個問題？

筆者先後在華為、阿里巴巴軟體質量部門任職，最近也深入研究了騰訊敏捷開發平臺TAPD（騰訊敏捷產品開發）和IGD（整合遊戲開發）一些資料，對國內敏捷專案的質量管理有很多獨到的見解，結合共創力諮詢公司多年的專案經驗，總結如下：

1）QA角色的轉變

QA要從警察的角色轉變到一個教練的角色。在以前，團隊實施CMM的時候，QA更多的是一個警察的角色，他整天拿著一個checklist、報告什麼的到處去團隊裡面看，你是否ok，不ok就要怎麼怎麼樣，整天就幹這個活，但是引入敏捷之後，QA就覺得有點失落，都敏捷了，我都不知道該怎麼下手了，在著名的通訊企業華為的做法是將QA轉變了一下，將QA更多的充當教練的角色，充當SCRUM Master的角色，他去指導專案團隊該如何去開這個站立式會議，該怎麼去做迭代的計劃等等指導性的工作，這樣QA也覺得挺好，這樣他能參與到在不同的團隊中去，QA的角色更多的偏向於全過程的敏捷活動指導，以提高產品開發效率和質量。QA在這個過程中也能得到一些資料，如程式碼缺陷率，版本的不良率，上線遺留問題數，團隊成員配合度等等。

      2）要使敏捷團隊整體參與

   QA和測試人員也是敏捷團隊的一部分，作為敏捷教練，要向他提供支援和訓練，以使作們適應開發的快節奏。比如，如果你是敏捷團隊中的測試人員，並且計劃會議和設計討論沒有邀請你，或者業務使用者正在獨立定義故事和需求，那你應該主動站出來和團隊的其他成員交流，並償試“三方協作”，即測試人員、開發人員和業務專家。騰訊公司把業務專家稱為BA，即

   Bussiness Analyst, BA和開發人員DE、測試人員TE組成了敏捷開發團隊，這些成員不僅僅把都在忙著最終的交付而努力，他們還樂於收集和分享資訊，與客戶或者產品負責人協作以幫助他們充分展示自已的需求，從而得到他們的需要的功能，同時向所有人提供專案進展的反饋。

3）自動化迴歸測試。敏捷團隊沒有自動化會成功嗎？可能也會成功，但我們所知道的成功團隊都依賴於自動化迴歸測試，如騰訊和支付寶公司的Selenium框架，阿里巴巴和淘寶網的QTP框架。漢捷諮詢認為，敏捷開發利用測試來指導開發，為了編寫的程式碼使測試通過，需要快速而簡單地執行測試，沒有短期反饋週期和安全的迴歸測試，團隊將很快陷入技術債務，缺陷不斷增加，速度越來越慢。

4）提供並獲取反饋

反饋是敏捷的核心價值，敏捷的短期迭代可以提供持續的反饋以幫助團隊正常運轉，測試人員則通過自動化測試結果、探索性測試的發現和系統實際使用者的觀察結果的形式幫助提供支饋。如你怎麼知道客戶手裡拿到了預期行為的正確示例？你怎麼知道編寫的測試用例正確地反映了這些示例？開發人員通過檢視測試用例能夠理解應該編寫什麼程式碼嗎？QA和測試人員應該詢問開發人員是否得到了足夠的資訊以理解需求並是否能夠指導編碼，詢問客戶是否理解質量標準，應花時間參與迭代計劃會議和回顧會議以討論這些問題並提出改進方案。把反饋的結構可表示為如下：

5）構造核心的敏捷實踐活動

軟體行業有一名老話是：軟體質量是設計出來的。對於敏捷開發也是如此，漢捷諮詢認為沒有一些基礎的實踐活動，無法產生出高質量的軟體。

①持續整合。持續整合（CI）是一項軟體開發實踐，其中團隊的成員經常整合他們的工作，通常每人每天至少整合一次，每次整合通過自動化構建完成。利用持續整合可以讓缺陷在引入的當天就被發現並解決，降低缺陷修改成本；將整合工作分散在平時，通過每天生成可部署的軟體；避免產品最終整合時爆發大量問題。

②灰度釋出。這是網際網路產品的一個特點，說白了，就是對使用者一個逐步放量的一個過程，而且不要求團隊要儘早 的將產品包釋出出來，也就是不要求馬上釋出給所有使用者，而是會分批的去釋出，比如按號段釋出，比如在公司內部先體驗。釋出的時候也有策略，比如釋出時如何放量，對使用者有些什麼樣的實驗，技術上怎樣做一些後臺開關，運營上怎樣跟進，怎樣保證4小時人員的留守，釋出完後怎樣收集使用者反饋等等都會有一些統一的規則。比方實驗室某WEB產品的釋出，可以同時有多個版本，1.1版可能會有100%的使用者在用，1.2版可能只有1%的使用者在用，它們是一個交叉升級的過程，目前騰訊採用了該活動。

③每日晨會：每個團隊每天大概花15-30分鐘，回顧昨天做了什麼、昨天有些什麼問題、同時也會介紹每個人今天計劃做些什麼工作（特點：是站著開會）。筆者在阿里巴巴工作時，就經歷過每日晨會，一般主持人由敏捷團隊的成員輪流擔任，這個時候可以瞭解每天發生的問題。

④結對程式設計：兩位程式設計師在一臺電腦前工作，一個負責敲入程式碼，而另外一個實時檢視每一行敲入的程式碼；操作鍵盤和滑鼠的程式設計師被稱為“駕駛員”，負責實時評審和協助的程式設計師被稱為“領航員”；領航員檢視的同時還必須負責考慮下一步的工作方向，比如可能出現的問題以及改進等。有助於提升程式碼設計質量；研究表明結對生產率比兩個單人總和低15%，但缺陷數少15%，考慮修改缺陷工作量和時間都比初始程式設計大幾倍，所以結對程式設計總體效率更高，同時結對程式設計能夠大幅促進團隊能力提升和知識傳播。

⑤使用者故事。使用者故事是站在使用者角度描述需求的一種方式；每個使用者故事須有對應的驗收測試用例；使用者故事是分層分級的，在使用過程中逐步分解細化；典型的描述句式為：作為一個XXX客戶角色，我需要XXX功能，帶來XXX好處。使用者故事的好處是：使用者故事站在使用者視角便於和客戶交流，準確描述客戶需求；使用者故事可獨立交付單元、規模小，適於迭代開發，以獲得使用者快速反饋；使用者故事強調編寫驗收測試用例作為驗收標準，能促使需求分析人員準確把握需求，牽引開發人員避免過度設計。

⑥迭代回顧會議。在每輪迭代結束後舉行的會議，目的是分享好的經驗和發現改進點，促進團隊不斷進步；圍繞如下三個問題：本次迭代有哪些做得好？本次迭代我們哪些方面還能做得更好？我們在下次迭代準備在哪些方面改進？會議需要Team全員參加，氣氛寬鬆自由，暢所欲言，頭腦風暴發現問題，共同分析根因；會議關注重點是Team共同討論優先順序，將精力放在最需要的地方（關注幾個改進就夠了）；會議結論要跟蹤閉環。

總之，共創力諮詢認為，測試和質量是整個敏捷團隊的職責，團隊中的每一個人都應該關注手邊的一個任務或者故事，敏捷模式下的質量管理更具有挑戰性，但與傳統瀑布模式相比，其在應對需求變化、提升產品質量、加快需求響應、縮短交付週期、提前暴露風險、及時激勵員工以及平滑人力資源的使用等方面具有明顯優勢。敏捷的焦點在於持交付有價值的軟體讓一直到客戶滿意為止。在這個“快魚吃慢魚”時代，要想交付好而快的產品，不防用敏捷模式試試。