敏捷開發，QA面臨的10個挑戰
敏捷開發，QA面臨的10個挑戰
1.沒有MRD，如何管理好需求？
2.沒有需求評審，怎麼保證需求質量？
3.研發模式變更，怎麼把握進度？
4.沒有詳細設計如何保證設計沒有問題？
5.沒有測試設計如何保證測試質量？
6.何時提測？提測頻繁，如何降低提測成本？提測時間不固定，如何分工？
7.如何提高RD程式碼質量？
8.沒有準入，怎麼保證提測質量？
9.如何避免新增story影響已有功能造成質量問題？
10.上線頻繁，如何降低上線的成本？
1.沒有MRD，如何管理好需求？
（1）使用story模式來管理需求，將龐大的MRD劃分為一個個合適粒度，且可獨立交付的story（通常每個story能在1~5天內完成，包括設計、開發、測試），需求清晰明瞭，易達成一致，且可節省大量的需求評審時間。
（2）要求PM在第i個迭代上線前一天，完成所有第i+1迭代的需求拆分，和RD、QA達成理解一致，且輔助QA一起補充完驗收標準，在第i個迭代啟動前完成所有story的相關工作。
（3）每個story都有自己的優先順序、估點（即預計花費時間），以此為依據判斷是否納入某迭代。
（4）PM隨時待命，快速響應，答疑解惑、修改設計不足。
2.沒有需求評審，怎麼保證需求質量？
challenge：需求不評審了？開發時遇到一堆問題怎麼辦？測試時發現一堆問題怎麼辦？作為質量的監督者，QA面臨著很大的衝擊和挑戰！
雖然沒有需求評審會議，但每個story都是經過仔細推敲和溝通過的。
（1）首先，一個story被PM提出時，需寫好使用者故事卡片和詳細描述；
（2）接著，PM會找RD、QA的leader進行講解，並交review，review人提出問題及改進意見；
（3）然後，PM和負責具體開發RD、測試QA進行講解和討論，RD、QA提出問題、疑問，PM解答，並對詳細描述進行修改。
（4）最後，所有參與者覺得沒有問題後，PM輔助QA補充詳細的驗收標準，RD對其進行review，並作為自測和自動化case編寫的參考。
（5）此外，在開發和測試的過程中，若發現新問題，PM隨時響應，答疑解惑，修改設計的不足。
上述每一個步驟都被落實後，不僅需求質量被保證了，QA也成了需求管理的核心。即使有未考慮到的問題，敏捷團隊也能夠很快消化，在下個迭代迅速優化。
3.研發模式變更，怎麼把握進度？
challenge：沒有詳設計劃？沒有開發計劃？什麼，連測試計劃都木有？QA怎麼保證專案保質保量按時上線？
（1）定期釋出
定期釋出上線，把整個專案劃分為一個個迭代，每個迭代時間大小固定，迭代結束時上線交付一次。
（2）迭代規劃
迭代規劃相當於整個迭代的計劃，幫助我們管理並保證每個迭代的交付。
A.迭代規劃的前提：
story溝通及驗收條件的補充完成。
PM給出story的優先順序
RD、QA給出story的估點，估點可取範圍為（1、2、3、5），若有大於等於5點的story，儘量拆分成更小的story。
B.迭代規劃
估算團隊交付能力（通常經歷幾個迭代，團隊的交付能力就會很明瞭了）：基於“昨天的天氣”（很可能他們在當前迭代完成的工作量與上一個迭代相同，除非工作環境或是團隊構成發生重大變化）和常識，估算自己能夠在當前迭代中完成多少工作。然後團隊就會基於自己的工作交付能力，選擇當前迭代要開發的工作。
有了團隊交付能力值，便進行以下步驟安排本迭代的工作：
- 按照優先順序順序，列出story，並註明它們的故事點數大小。
- 判斷一個迭代中可以交付多少故事點數。
- 考慮團隊需要完成的非使用者故事工作可能產生的影響，比如在早期的迭代中，由於工具和工作環境不到位，工作效率會受到影響。
- 向計劃中加入一個新的迭代。
- 向迭代中加入故事，直到用掉所有的工作能力。
- 詢問：是否所有的故事都已經解決、版本釋出目標是否達成。
- 如果沒有，那麼向計劃中加入新的迭代，並重復步驟5和步驟6.
- 一旦所有的故事都已經分配完成，與大家就計劃進行交流，並徵求他們的反饋，看看這些計劃是否現實並且可以完成。
PS：通常只會進行到第五步，剩餘的stroy放入需求池，下個迭代啟動時再規劃。
（3）每日站會
站會的目的有三個：
（1）周知進度
僅從使用者故事和任務的層面周知進度，任務進度只有兩種狀態：完成或未完成（完成百分比）。
（2）周知計劃
你將會在下次會議之前做哪些工作？
（3）丟擲問題
哪些東西阻礙你的進度？（“沒有問題”，意味著你能夠交付自己當前的任務，而且符合估算的時間範圍）如果遇到需要解決的問題，可以在每日立會之後處理。
實現一專案的必要前提：
1.站
2.敏捷專案必須提供能夠“安全失敗”的環境，團隊成員不會因為沒有達成任務承諾遭受懲罰。
大家要能夠安全說出任務狀態的真實情況，並且瞭解專案環境的現實情況。有時，我們的估算可能很糟糕（只是估算而已，又不是承諾），又或者某些事情的發生讓某些成員無法完成任務，整體環境必須讓他們能夠說出真實情況，這樣團隊成員就能調整他們的日程表，將任務排序，並調整適應專案的現實。
站會的主要內容：
從PM、RD到QA，每個人發言，內容為：1. 昨天干了什麼，2.遇到什麼問題，3.今天準備幹什麼。如果有想要分享給大家的知識，也可以在此分享。
最後主持人總結一下，然後根據實際遇到的問題，少數人進行線下溝通、跟進、解決。
站會的時間儘量控制在十分鐘左右。
開站會的一些技巧
（1）輪流主持
輪流主持能提高團隊成員的參與度，且如果主持人臨時有事，也不會因此無法開展，通常每次站會結束時指定下次站會的主持人。
（2）解決問題不放在會議中
會議中僅丟擲問題，解決問題放在站會結束後，相關人蔘與。目的是避免浪費大家的時間。
（3）早上舉行
可以讓所有人按時來，按時工作。
可以讓每個人更清楚今天自己該幹什麼。
晚上每個人進度不一，作息時間不一樣，早上說昨天干了什麼更準確。
（4）卡片牆
有了迭代的總體計劃，還需要細化到對每個story進行管理，除了之前的估點外，我們使用卡片牆對其進行管理。
卡片牆如下圖所示：
需求池：所有新建的story（一般為未經過估點的）卡片貼在此處。
待開發：所有待開發的story卡片貼在此處。
需求池->待開發：講解溝通完需求、估完點、補充完驗收標準後，移動。
開發中：所有正在開發的story卡片貼在此處
待開發->開發中：RD將story拆分完task，並給QA講解task實現思路，QA同意後，移動。
待測試：所有開發完成，等待QA測試的story卡片貼在此處。
開發中->待測試：RD開發完成story，且完成單測、整合測試編寫，和經過仔細的自測後，移動。
測試中：所有QA正在測試的story卡片貼在此處。
QA singn off：所有經過QA測試，QA認為可以上線的story卡片貼在此處。
測試中->QA singn off：QA經過仔細測試，bug都被修復驗證，認為story符合上線標準時，移動。
已驗證：所有經過PM驗收，可上線的story卡片貼在此處。
QA singn off->已驗證：PM在驗收環境中驗收，認為符合需求後，移動。
加速區：所有需要加速解決的story卡片貼在此處。如卡片中有block測試的bug急需修復，等。
block區：所有被一些問題block的story卡片放在此處。
卡片：story卡、task卡（story編號、估點數、使用者故事）。
角色卡：FE、RD、QA的名字，以不同顏色區分，分別寫上人名，用於貼在story上。誰在做什麼，誰忙誰閒，有多少剩餘人力，一目瞭然。
上線時間：略。
（5）燃燒圖
使用燃燒圖，計劃及其變化，以及每天進度一目瞭然。
燃燒圖如下：
1、X軸為時間，一般是迭代週期的每一天；
2、Y軸為工作量，根據專案情況，可以用已完成估點或已完成story點數來表示；
3、最開始，計算出本次迭代要完成的所有工作量(作為y軸刻度，迭代天數作為x軸刻度)，然後，每天站立會議時，瞭解前一天已經完成的工作量，並計算出迄今為止完成的工作總量。把其畫在Y軸上，以此類推(並把y點連線成線)。如果計劃比較(理想)準確，燃燒圖的最後一天”燃燒“折線將和總工作量折線相交；
（6）總結
以上五項，簡單易實現，用很低的時間成本就能做出“計劃”，並保證計劃的落實，且能快速適應變化！
4.沒有詳細設計如何保證設計沒有問題？
challenge：如何讓設計上的問題在開發前暴露出來，並解決？
在敏捷開發中，我們認為溝通交流勝過面面俱到的文件，相對於編寫詳細設計文件，RD更願意給相關人員講解他的設計，甚至給QA講解程式碼，因此對詳細設計不做要求。
那麼，沒有詳設，如何讓設計上的問題在開發前暴露出來，並解決？
我的解決方案如下：
增加詳設交流環節，且由RD推動
1）在開發之前，增加詳設交流環節，RD進行task拆分和詳設講解。
2）由RD推動此環節，在開發之前主動給相關QA和關注的leader講解， QA提出需要了解一些複雜邏輯的實現方法，RD進行講解。講解後，卡片才能從待開發移到開發中。
3）story較複雜時，RD會提供簡略的詳設，一方面理清RD思路，一方面便於QA理解達成一致。
此外，在QA測試之前，如有需要，RD還會給QA講解詳細的實現方式，彌補沒有文件的不足。
5.沒有測試設計如何保證測試質量？
challenge：沒有之前那麼嚴密的測試設計，如何保證無漏測？
雖然沒有之前那麼標準的測試設計，但我們摸索出了自己的規避風險的方法：
每個story，都有一個固定的測試設計環節，以自己喜好的方式，如：畫簡圖、腦圖、列list等，仔細考慮等價類、邊界條件、異常分支等，作為實際測試的思路，以便真正理清自己思路，規避測試模式變更帶來的風險。
在每個story中，都會有驗收標準，驗收標準和PM一塊編寫，由RD review，也作為RD自測和編寫自動化測試的依據與要求，一方面提高程式碼質量，一方面保證測試質量。
PS：
1.如果有測試經驗較少的新人加入，可以在初期讓新人和之前一樣編寫測試設計，作為story的附件。待訓練成熟後，再過渡到敏捷的模式，以規避新人經驗不足導致的漏測風險。
2.如果團隊中測試人員較多時，建議編寫簡單的測試設計，以便整個專案的質量可控。
6.何時提測？提測頻繁，如何降低提測成本？提測時間不固定，如何分工？
challenge：沒有固定提測時間？沒有正式提測?隨時提測？
（1）隨時提測
沒有固定的提測時間，RD完成一個story ，滿足上述提測條件，便通知QA提測（無論以什麼方式通知），QA即可部署最新版本進行測試。
（2）自動化部署
隨時提測，就意味著需要更頻繁的部署，此時，不能再依賴手工部署，必須實現部署自動化。
通過在hudson上呼叫編寫的自動化部署指令碼，已可一鍵自動化部署，收益不錯，其他專案也有效仿。
（3）測試分工
因為隨時提測，stroy的完成時間不確定，如果事先分好了誰測什麼，很可能造成QA某時候空著，有時候工作堆積，這樣時間利用率低。
因此，我們需要每個QA熟悉所有模組，迭代開始時不分工，在迭代中臨時分工。這無疑也是對QA的一個很大的挑戰。
7.如何提高RD程式碼質量？
challenge：提高程式碼質量、降低RD和QA的人力比！
提高RD程式碼質量對QA來說是一個亙古不變的問題，路漫漫而修遠兮。。。
目前我們的解決方案就是：要求並監督RD做單測和整合測試。最終目標為測試驅動開發（TDD）。
在敏捷團隊中，QA的負擔已經很重了，此時應該果斷把之前從RD那邊分擔過來的整合測試自動化（IT）再還回去，並且推動RD把單測（UT）落地，從而提高RD的程式碼質量，降低bug率，減少迴歸時間，最終降低RD、QA人力比，成為真正的敏捷QA。
A． UT
完全由RD編寫，目前QA正在對RDs進行一對一的單測培訓，將對RD整體的單測水平有很大提升，目前已有RD為提高程式碼可測性進行了程式碼重構。培訓完成之後，將對RD單測覆蓋率會有一定要求。後續所有單測將會被加入到quick build中。
B． IT
新增程式碼的IT將全部由RD編寫，QA對其進行review，有時間的話會幫助RD設計一些case，由RD來實現。
IT被作為story達到提測質量的一個必要條件，RD必須對story中新增功能的驗收條件達到全覆蓋。
C． ST
ST由QA負責，目標是覆蓋所有的主幹流程，既可彌補自動化覆蓋不到前端程式碼的不足，又能減少QA迴歸工作量。
8.沒有準入，怎麼保證提測質量？
challenge：沒有準入，RD提測質量太差怎麼辦？
以前的瀑布流程，為保證提測質量，QA會做一個准入冒煙，通常一個模組幾個case，如果case pass率小於85%，則會打回。QA在准入測試也會花費比較大的時間成本。
如今story粒度相對較小，提測太頻繁，做准入是不太現實了，但提測質量還是得保證，經過不斷地摸索，我們的應對措施為，限定卡片從開發中移動到待測試必須滿足的前提條件，具體如下：
- ＱＡ將提測ｓｔｏｒｙ的驗收條件分為兩部分（ａ．新增功能、ｂ．原有相關功能）
- ＲＤ提測之前，需保證所有驗收條件100%通過，否則視為提測質量不合格，產生的ｂｕｇ在迭代回顧會議中進行總結學習。
- ＲＤ提測之前，需保證驗收條件中所有新增功能的ｓｅｒｖｉｃｅ層程式碼，都被自動化整合測試ｃａｓｅ覆蓋，若有特殊情況，提測時需做特殊說明。若ＱＡ ｒｅｖｉｅｗ時不滿足新增功能全覆蓋，將在迭代回顧會議上進行ｃａｓｅ ｓｔｕｄｙ，後續還得使用工具保證。
- RD提測前，需完成必要的單測（還待完善）
- RD提測前，需要進行復雜邏輯的CR，CR規則還在試行中。
使用以上的5條，不僅保證了提測質量，且QA幾乎不再需要為準入投入時間，同時，整合測試被落地後，後續的迴歸工作也會慢慢減少。
經過兩個迭代的試行，bug量顯著降低了，取得了不錯的效果。
9.如何避免新增story影響已有功能造成質量問題？
challenge：沒有全面迴歸，如何保證質量？
基於Story的敏捷，要求每個story測試完成都可直接上線，也就是說story從測試中移動到QA sign off後，質量達到上線標準，且須保證不破壞已有功能。
如果QA在sign off每個story之前，都對前面的story和已有的功能做全面迴歸的話，估計很快就會被累死。
怎麼解決此問題呢？
臨時解決方案：
（1）code frees環節
RD在主幹上開發（減小大量merge產生的風險），在上線之前，會有一個code frees環節，從主幹上拉出一個release branch（簡稱RB），用於本迭代的上線。
根據敏捷的經驗，在所有story都移到QA sign off區後，再拉RB，因為RB拉得太早，QA的工作量會double，敏捷週期本不太長，測試和開發在stroy間也是並行的，因此 開發完所有story的時間點和QA測試完所有stroy之間的時間不會很長，因此原則上在所有story都移到QA sign off區後，再拉RB，如果情況特殊，也要等QA大致過一遍stroy後，QA點頭後再拉RB。否則RB上提交次數太多，工作量和風險都相對較大，拉RB的意義就不明顯了。
（2）迭代迴歸
RD繼續在主幹上開發下一迭代的story，QA在此RB中迴歸本迭代的內容及可能影響到的原有功能，並測試上線步驟。
用迭代迴歸，而不是每個story完成之後都回歸，減少迴歸工作量，作為臨時方案。
長遠目標：
推動RD完成UT、IT，QA完成ST，使自動化測試覆蓋已有功能，最終將QA從迴歸中解放出來。
10.上線頻繁，如何降低上線的成本？
challenge：每次上線都會花時間去測上線步驟，上線頻繁，如何降低成本？
答案當然是自動化上線。
將web和server這種每次上線除配置檔案修改，其餘操作都一樣的上線做成自動化上線。
將檔案替換這樣的上線步驟做成指令碼，QA測試指令碼，上線執行指令碼即可。