敏捷QA對職業發展的擔憂

最近和組內的QA聊起以后的職業發展，發現一個有意思的事情，有說想轉BA的，有說想轉開發的，有說想轉型作PM的，還有想以后往咨詢方向發展的。很少有說想在團隊里面繼續作QA的。QA這個角色難道就這么沒有吸引力么?為什么都想轉型或者自己出去單干呢?和組里幾個QA聊了之后，發現主要因素在于對QA職業發展的擔憂，覺得敏捷團隊對專職QA的需求并不大。

[[206293]]

記得我剛工作的時候還是有獨立測試團隊的，那個時候分工很明確，我就負責windows mobile(現在叫windows phone)上應用的自動化測試，我的這個職位叫做SDET，說通俗點就是自動化測試工程師。我們這個團隊大概有10人，測試完畢后將結果匯報給測試經理。由于產品復雜，需要大量的測試工程師以保證產品能順利發布。隨著更多功能的加入，測試團隊的人數也在增加，這段時間是QA最有價值感的時候，產品的發布最終都由你來把關，你可以根據興趣來選擇以后做一個性能測試或者安全測試工程師等等，有明確的發展路線。

但現在越來越多的公司選擇了敏捷轉型，適應變化和快速交付可工作的軟件成為了團隊的關注點。從開發和用戶的角度看，他們會很樂意接受這個變化，客戶可以不斷看到新功能，開發可以把精力從繁瑣的文檔和流程上釋放出來，發揮想象和創意來提供更好的解決方案。可對于QA來說，敏捷帶來了什么好處呢?之前定期有一個可測的穩定版本，詳細的需求文檔就是我們參考的對象。現在要對一個不斷變化著的對象來進行驗證，也沒有一大段時間來設計自動化框架。我們怎么來保證質量呢?

敏捷QA的測試職責

在敏捷的團隊中，質量是由團隊所有人來保證的，我剛開始聽到這句話就像聽到敏捷宣言一樣，知道這有道理，但具體怎么做呢?如果質量是團隊的責任，那么專職的QA干什么呢?

首先我們來看在敏捷團隊經常用來保證測試用例達到平衡狀態的測試金字塔，簡單來說我們可以把更多的測試放在單元和服務級別，因為這些用例更易維護和執行，運行效率也更高，可以參照Martin Fowler的TestPyramid。

在這個框架下，很容易讓人產生這樣的誤解：

1. 開發負責單元測試，不需要QA參與

跟組里的開發討論過“是否需要QA參與到審查單元測試覆蓋率”的問題，開發通常會覺得用處不大，因為有專門的工具比如：Cobertura， Jacoco, Istanbul等。這些工具的檢查范圍通常包括：

• 行覆蓋率(line coverage)：是否每一行都執行了?
• 函數覆蓋率(function coverage)：是否每個函數都調用了?
• 分支覆蓋率(branch coverage)：是否每個if代碼塊都執行了?
• 語句覆蓋率(statement coverage)：是否每個語句都執行了?

而QA的檢查可以彌補單純的代碼級別的覆蓋。比如異常處理和邊界值的情況，代碼級別的覆蓋會檢查語句是否執行了，但是不能檢查這段邏輯是不是寫了。下面列舉出幾種常用的檢查方法：

• 等價類：把程序的輸入域(所有可能的輸入數據)劃分成若干部分，然后從每個部分中選取少數有代表性的數據作為測試用例。每一類的代表性數據在測試中的作用等價于這一類中其他值。
• 邊界值：邊界值分析法是對等價類劃分的補充，它是對輸入或輸出的邊界值進行測試的一種測試方法。我們這里所指的“邊界值”是相對于“輸入等價類”和“輸出等價類”而言的，稍高于其邊界或低于其邊界的一些特殊情況。
• 決策表：在一些數據處理問題當中，某些操作的實施依賴于多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作，判定表很適合于處理這類問題。
• 因果圖：是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。

有的QA會發現這些通常是用在黑盒測試里的方法，其實把這些覆蓋盡可能的在單元或者服務級別來實現是一種既有效率，結果反饋又快，又可以直接作為回歸測試的一種很好的途徑。

在項目的實踐中我們可以看到QA參與到單元測試的審查有以下好處：

• QA可以審查單元測試的覆蓋率，來調整單元測試以及后續接口測試和回歸測試的覆蓋率。之前做的項目都是開發獨自寫單元測試和接口測試，QA也獨自寫自動化回歸測試，后來發現有很多的重復覆蓋，這也是種浪費。如果能結對來做單元測試，是種更高效的方式。
• QA可以更清楚代碼對各個模塊的影響，這樣可以有針對性的設計回歸測試，比如之前項目有個小的改動，QA沒能在很短的時間進行回歸測試，導致產品發布后遇到了問題。有人會說自動化覆蓋所有回歸測試不就行了么?理論上是這樣的，但現實中有很多限制，只能通過手動驗證來完成回歸測試。這種情況下，精確定位回歸測試的范圍變得尤為重要了。
• QA對系統構架、開發語言能有一個學習的過程，這有利于自動化回歸測試的搭建。

2. 開發更適合設計自動化測試框架和接口測試，因為他們寫代碼更有效率

如果說自動化測試和接口測試的目的是比誰寫代碼的效率更高，那么的確這些事情應該由開發去做，但是作為QA，參與其中的作用在于分析需求以及從客戶的角度來設計用例。

敏捷團隊越來越多的應用行為驅動開發(BDD)來覆蓋基于服務和UI的測試。

QA會和PO，BA，DEV，UX一起合作，分析軟件的需求，然后將這些需求寫成用戶故事。開發者負責填充這些故事的內容，測試者負責檢驗這些故事的結果。通常，會使用一個故事的模板來對故事進行描述。

故事的模板：

• As a 角色
• I want 特征
• so that 利益

比如：

As a mobile App user

I want to recharge the Mobile phone number with credit card

so that I can have fee to give a call

每一個story有可能會有不同的場景，可以用下面的模板來描述在什么環境下發生了什么事情，結果如何。

• Given [上下文]
• And [更多的上下文]
• When [事件]
• Then [結果]
• And

比如：

Scenario: Recharge with Credit card successfully

Given I logged into the Mobile App

When I go to Recharge page

Then I can see the recharge option listed

And I can see the Mobile phone number input box listed

When I input the phone number

And I select the recharge option as "Credit card"

And I input the Credit card number

And I click the Recharge Button

Then I can see the "Recharge successfully" message shows

QA會和DEV一起合作來實現這些story的自動化測試，常用的工具:

• Cucumber (Ruby framework)
• SpecFlow (.NET framework)
• Behave (Python framework)
• JBehave (Java framework)
• JBehave Web (Java framework with Selenium integration)
• Lettuce (Python framework)
• Concordion (Java framework)

3. 開發交互進行基于UI的測試就行了，不需要專門的QA進行測試

如果說基于UI的測試就是執行測試用例，那么的確不需要專職QA來做，但是在敏捷的團隊中基于UI的測試大部分是以探索性測試來完成的。怎么設計好的探索性測試用例才是專職QA的價值所在。

有人說探索性測試就是手動測試，有的說是隨機測試，有的說就是把自己當用戶來使用軟件的測試。

什么是探索性測試?下面是wikipedia上面的定義：

看完這個解釋更迷惑了，探索性測試到底是什么東西?

舉個簡單的例子，我們聚餐的時候有時候會玩猜數字的游戲，主持會寫下一個數字，大家輪流猜，主持會提示大了或者小了。那么下一個人會根據這個提示來繼續猜，直到有人猜中這個數字。這其實就是探索測試的原理，每次都會根據之前的結果來設計下次的數字，那個被猜數字就是defect，每一次猜測都是測試用例。如果你想用最少的次數來猜中這個數字，就需要有高效的方法，探索測試也是如此。

敏捷QA存在的價值

以上簡單的描述了在敏捷團隊中，QA在測試中的職責：

• 審查單元測試的覆蓋率
• 和開發結對搭建基于服務和UI的測試
• 探索性測試

其實QA還有很多面向客戶的職責，比如需求澄清以及產品演示，會在后續的文章去討論。

隨著敏捷的項目越來越多，對QA的需求不是越來越少，而是越來越高，QA需要像一個好的家庭主婦一樣，能里能外，在團隊內部能更好的平衡測試設計，在外部能更好的體現產品價值。在一個快速變化的時代，在持續快速交付的情況下保證質量是一件很困難的事情，解決這個問題就是QA存在的價值。

【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】

戳這里，看該作者更多好文