敏捷開發中QA如何做質量管理？
敏捷開發中QA如何做質量管理？
經常有人會問我，敏捷模式下，QA的職責是什麼？QA有什麼價值？我們還需要QA嗎？敏捷轉型中遇到的問題，QA能幫助解決嗎？這些問題以前也思考過，筆者就是QA出身的，曾經在中興通訊做過兩年多的PQA，在中興通訊的敏捷轉型中也遇到過這些問題。
先總結一下敏捷轉型中遇到的問題吧,QA的工作也是要圍繞這些問題展開的：
-
很多公司希望採用敏捷，但是又沒有把握
-
傳統的瀑布式開發流程在公司已根深蒂固，雖無法滿足快速發展的需要，但大規模改動又不現實，老闆也不願意花太多的成本
-
缺少敏捷軟體開發專家和人才
-
研發人員需要觀念的轉變和方法培訓
-
缺乏相應的質量控制方法
-
需要經常的和及時的質量度量
-
自動化測試不能落到實處，持續整合發揮不出作用
-
人員水平參差不齊，有人支援有人反對
筆者也先後參加過多次華為、騰訊、平安科技等公司的敏捷推行者的分享活動，也參加過Thoughtwork、康仕誠、ScrumCN等專業機構的培訓，對國內敏捷專案的質量管理有一些想法，結合筆者這幾年的質量管理經驗，總結一下：
1）QA角色的轉變
QA以往主要還是作為警察的角色，從事各種稽核活動，要從警察轉變成教練。傳統專案裡，QA習慣拿著事先準備好的檢查單，對專案一條條做稽核，發現問題開不符合報告，給團隊的感覺就是一個監工。雖然筆者自己也不喜歡人家這麼說我，但確實我們給專案成員你的印象就是監督。
中興通訊從2014年開始，各研究院都大力推行敏捷轉型，剛開始覺得有點失落，都敏捷了，都不知道該怎麼下手了，稽核不能叫稽核，要叫觀察，稽核報告也要叫觀察記錄。經過幾個月基本上適應了，QA、專案管理員都往敏捷教練的方向上轉，在外界專業教練的指導下，引導專案開展各類敏捷活動。
比如該如何開站立會議，該怎麼去做迭代的計劃等等指導性的工作，不過以前的專案團隊劃分成十多個特性團隊，一個人要跟十幾個PO、SM打交道，對於QA的溝通能力增加很多，每天奔赴各個團隊。
2）QA參與各項活動，如需求梳理會、計劃會、早會、持續整合看板、演示、回顧會等，各項持續整合結果也都推送到QA，這樣便於及時獲取團隊的資訊，也便於QA
3）自動化迴歸測試。敏捷團隊沒有自動化會成功嗎？可能也會成功，但我們所知道的成功團隊都依賴於自動化迴歸測試，如騰訊和支付寶公司的Selenium框架，阿里巴巴和淘寶網的QTP框架。筆者諮詢認為，敏捷開發利用測試來指導開發，為了編寫的程式碼使測試通過，需要快速而簡單地執行測試，沒有短期反饋週期和安全的迴歸測試，團隊將很快陷入技術債務，缺陷不斷增加，速度越來越慢。
4）提供並獲取反饋
反饋是敏捷的核心價值，敏捷的短期迭代可以提供持續的反饋以幫助團隊正常運轉，測試人員則通過自動化測試結果、探索性測試的發現和系統實際使用者的觀察結果的形式幫助提供支饋。如你怎麼知道客戶手裡拿到了預期行為的正確示例？你怎麼知道編寫的測試用例正確地反映了這些示例？開發人員通過檢視測試用例能夠理解應該編寫什麼程式碼嗎？QA和測試人員應該詢問開發人員是否得到了足夠的資訊以理解需求並是否能夠指導編碼，詢問客戶是否理解質量標準，應花時間參與迭代計劃會議和回顧會議以討論這些問題並提出改進方案。
5）構造核心的敏捷實踐活動
軟體行業有一句老話是：軟體質量是設計出來的。對於敏捷開發也是如此，筆者認為沒有一些基礎的實踐活動，無法產生出高質量的軟體。
-
持續整合：持續整合（CI）是一項軟體開發實踐，其中團隊的成員經常整合他們的工作，通常每人每天至少整合一次，每次整合通過自動化構建完成。利用持續整合可以讓缺陷在引入的當天就被發現並解決，降低缺陷修改成本；將整合工作分散在平時，通過每天生成可部署的軟體；避免產品最終整合時爆發大量問題。QA可以關注這些持續整合發現的問題分佈情況、解決情況、構建週期，及時度量出相關資料。
-
看板：最便宜的敏捷工具，可實現價值流、視覺化、拉動、限制在製品、找出瓶頸等多個作用。使用者故事可以用看板，QA自己的任務同樣可以用看板管起來，便於QA之間互相溝通、對齊資訊。
-
自動化測試：持續整合的前提是有自動化測試用例，以及程式碼靜態檢查、程式碼行覆蓋率、程式碼複雜度等各種工具，如果這些沒做起來，只是持續構建，並沒有太大意義。自動化測試屬於防禦性測試，把所有的質量風險用窮舉法列出測試用例，然後測試用例提前寫好，然後寫程式碼幫你執行，預防缺陷的洩露。但是成本同樣非常大，是否能推行起來，就看領導的魄力了。
-
每日晨會：每個團隊每天大概花15-30分鐘，回顧昨天做了什麼、昨天有些什麼問題、同時也會介紹每個人今天計劃做些什麼工作（特點：是站著開會）。一般主持人由敏捷團隊的成員輪流擔任，這個時候可以瞭解每天發生的問題。QA可以參加晨會，根據自己的觀察提出問題。
-
結對程式設計：兩位程式設計師在一臺電腦前工作，一個負責敲入程式碼，而另外一個實時檢視每一行敲入的程式碼；操作鍵盤和滑鼠的程式設計師被稱為“駕駛員”，負責實時評審和協助的程式設計師被稱為“領航員”；領航員檢視的同時還必須負責考慮下一步的工作方向，比如可能出現的問題以及改進等。有助於提升程式碼設計質量；研究表明結對生產率比兩個單人總和低15%，但缺陷數少15%，考慮修改缺陷工作量和時間都比初始程式設計大幾倍，所以結對程式設計總體效率更高，同時結對程式設計能夠大幅促進團隊能力提升和知識傳播。不過這個實踐也是最難推行的，往往只有進度不緊的時候才會嘗試。
-
使用者故事：使用者故事是站在使用者角度描述需求的一種方式；每個使用者故事須有對應的驗收測試用例；使用者故事是分層分級的，在使用過程中逐步分解細化；典型的描述句式為：作為一個XXX客戶角色，我需要XXX功能，帶來XXX好處。使用者故事的好處是：使用者故事站在使用者視角便於和客戶交流，準確描述客戶需求；使用者故事可獨立交付單元、規模小，適於迭代開發，以獲得使用者快速反饋；使用者故事強調編寫驗收測試用例作為驗收標準，能促使需求分析人員準確把握需求，牽引開發人員避免過度設計。QA可以引導專案團隊如何編寫使用者故事、驗收標準。
-
迭代回顧會議：在每輪迭代結束後舉行的會議，目的是分享好的經驗和發現改進點，促進團隊不斷進步。會議需要Team全員參加，氣氛寬鬆自由，暢所欲言，頭腦風暴發現問題，共同分析根因；會議關注重點是Team共同討論優先順序，將精力放在最需要的地方（關注幾個改進就夠了）；會議結論要跟蹤閉環。QA同樣可以參加回顧會議，引導團隊如何召開，並跟蹤改進事項。
總之，筆者認為，質量是整個敏捷團隊的職責，團隊中的每一個人都應該關注手邊的一個任務或者故事，敏捷模式下的質量管理更具有挑戰性，但與傳統瀑布模式相比，其在應對需求變化、提升產品質量、加快需求響應、縮短交付週期、提前暴露風險、及時激勵員工以及平滑人力資源的使用等方面具有明顯優勢。敏捷的焦點在於交付有價值的軟體，一直到客戶滿意為止。在這個“快魚吃慢魚”時代，要想交付好而快的產品，不防用敏捷模式試試。
（為偷懶，本文有些內容為網上抄襲）