敏捷QA，從入門到放棄

做敏捷QA五年多，看到了很多人加入，也看到了很多人放棄。其中有經驗豐富的測試人員，也有剛剛步入職場的新人。雖然“從入門到精通”是大多數人選擇進入這個行業的初衷，但是敏捷QA一些特有的工作方式和要求，會讓很多人不適應或者不喜歡，所以很多時候我們看到的是一個個“從入門到放棄”的過程。

那麼什麼樣的人應該不要選擇或者儘早放棄敏捷QA這條路呢？本文試圖給大家提供一些參考。

敏捷QA入門

QA（Quality Assurance）通常指的是質量保障，也有一種說法是質量分析（Quality Analysis），在敏捷軟體開發團隊中，我們強調所有成員（業務分析師、開發人員、專職QA）為質量負責，所有人蔘與跟質量相關的活動，所以從巨集觀意義上來說，人人都是QA，很多文章都有相關的介紹，這兒不再繼續探討。本文提到的敏捷QA，指的是敏捷團隊中專職的QA角色，他們的主要職責是主導並促使跟質量相關的活動在團隊內發生，包括但不僅限於測試。

敏捷QA的入門階段除了要有基本的測試知識外，必須要熟悉一些敏捷相關的基本概念以及實踐，比如使用者故事、迭代、迭代計劃、回顧會議等等。敏捷QA幾乎會參與整個使用者故事的生命週期，從分析，啟動，開發，驗收，測試到最後的展示，尤其在啟動，驗收和測試這三個環節發揮著非常重要的作用。

另外，敏捷QA會同時工作在多個迭代當中，在進行當前迭代使用者故事的測試驗收等活動的同時，也經常需要做前一個迭代的收尾工作以及下一個迭代的準備計劃等。

敏捷QA放棄

瞭解了基本的敏捷QA知識後，我們來看看放棄敏捷QA的四個理由。

不愛說話？別做敏捷QA了

如果你之前是安安靜靜專心找軟體缺陷的工作模式，那麼進入敏捷團隊你可能會經歷很長時間的不適應。

因為敏捷QA不能被動地等待軟體完成交到你手裡再做測試，不能發現缺陷後不管不顧等著開發人員自發地去修復。你需要從軟體的源頭開始介入，在軟體的整個生命週期中全程參與。

敏捷軟體開發強調質量內建，在使用者故事的生命週期中，作為質量保障的主要負責人，你需要在每個階段跟不同的角色反覆確認和驗證，確保團隊對需求理解一致，還要保證跟質量相關的活動發生，比如確保開發人員新增了相關的自動化測試等，所以你需要和團隊的每一個成員以及客戶有非常多的交流，而最直接有效的方式就是說話，沉默寡言是行不通的。

所以，如果你不喜歡說話，那麼Tester也許比敏捷QA更適合你。

心態不好？趁早放棄

不知道你是否經歷過這樣的場景，在某些小餐廳等位嚴重的情況下，你需要站在某個快要結束用餐的客人邊上等空位，而有些人卻可以在用餐結束後無視旁邊焦急等待的人群一直佔著座位專注地聊天。

雖然這種行為不是很好但也無可厚非，換個角度想，這種人的心理是非常強大的，因為很少有人能夠不顧及別人而我行我素。而這種“能力”對敏捷QA是非常有用的，比如在故事驗收環節，這個階段就是業務分析師、開發人員和QA三種角色一起在開發人員的機器上驗證使用者故事是否被正確地實現。當然任何角色都可以主導這個環節，但效果最好的是由QA來主導，因為可以提前發現缺陷並快速修復。

但是因為這個階段所有角色都會參與，大家關注點又有所不同，所以心態不好難免就會有各種顧慮，比如，自己會不會太慢了？會不會耽誤太多人的時間了？別人會不會很著急？

太多顧慮就會影響你做驗收測試，尤其驗收階段的探索性測試。從而使你不能充分發揮QA的作用，而這個環節對於敏捷開發模式下的質量保障來說非常重要，這時候如果具備前面提到的強大的心理素質，就能專注地按照你的想法測試你的場景，當然可以配合一些解釋讓別的角色瞭解你的思路，而不是左顧右盼思前想後影響這個階段的發揮。

所以，如果沒有強大的心理素質，也許應該考慮趁早放棄做敏捷QA。

對業務、程式碼沒興趣？敏捷QA不適合你

相信很多人進入測試這個行業，是因為對測試領域的技術和方法論有濃厚的興趣，但是對於敏捷QA來說，僅僅對測試感興趣是不夠的。

敏捷QA需要對整個系統以及業務足夠熟悉，這樣才能從QA的視角幫助業務分析師和團隊發現業務不合理或者缺失的部分（可以在故事審查或者啟動階段幫團隊澄清需求）。

另外如果可以具備一些編碼能力，對於做敏捷QA也是非常有幫助的。當然，術業有專攻，並不要求每個QA都會寫程式碼，但是要對程式碼有一定的興趣，願意聽開發人員講解他們的邏輯和實現，並通過提問題了解他們的思路，至少了解他們編寫的測試程式碼。因為在驗收階段，敏捷QA會通過審查開發人員的自動化測試是否合理和全面，來幫助團隊建立對自動化的信心。

所以如果對業務、程式碼沒有絲毫興趣，那麼也許敏捷QA不太適合你。

不會管理工作的優先順序？做敏捷QA很難

敏捷QA最大的挑戰是，每時每刻都同時工作在很多事情上，我們可以細數一下敏捷QA的活動：當前迭代的故事審查、故事啟動、故事驗收、故事測試用例準備、部署、缺陷管理、缺陷分析，前一個迭代的故事收尾，後一個迭代的測試計劃、故事審查、故事啟動等等。

另外敏捷QA希望可以做的更多，比如日誌分析、效能監控、安全測試等等。

可以看到，敏捷QA的工作是非常雜亂瑣碎的，而且大多活動是和團隊中不同成員一起進行的，我聽過很多剛剛加入敏捷QA的新人抱怨沒有自己思考的時間，忙亂沒有目標；也見過很多優秀的測試人員轉做敏捷QA後因為不適應這種多執行緒的工作選擇了放棄。確實，在這樣一種工作模式下，如果QA不能清晰定義自己工作的優先順序，就會被各種雜事牽著鼻子走。

不擅長管理自己的工作任務、不會劃分優先順序，做敏捷QA會非常難。