敏捷開發中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可以參加晨會，根據自己的觀察提出問題。
結對程式設計：兩位程式設計師在一臺電腦前工作，一個負責敲入程式碼，而另外一個實時檢視每一行敲入的程式碼；操作
敏捷開發中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可以參加晨會，根據自己的觀察提出問題。
結對程式設計：兩位程式設計師在一臺電腦前工作，一個負責敲入程式碼，而另外一個實時檢視每一行敲入的程式碼；操作