敏捷QA對職業(yè)發(fā)展的擔(dān)憂

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

[[206293]]

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

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

敏捷QA的測試職責(zé)

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

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

在這個框架下，很容易讓人產(chǎn)生這樣的誤解：

1. 開發(fā)負責(zé)單元測試，不需要QA參與

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

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

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

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

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

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

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

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

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

敏捷團隊越來越多的應(yīng)用行為驅(qū)動開發(fā)(BDD)來覆蓋基于服務(wù)和UI的測試。

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

故事的模板：

• 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有可能會有不同的場景，可以用下面的模板來描述在什么環(huán)境下發(fā)生了什么事情，結(jié)果如何。

• Given [上下文]
• And [更多的上下文]
• When [事件]
• Then [結(jié)果]
• 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一起合作來實現(xiàn)這些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. 開發(fā)交互進行基于UI的測試就行了，不需要專門的QA進行測試

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

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

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

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

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

敏捷QA存在的價值

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

• 審查單元測試的覆蓋率
• 和開發(fā)結(jié)對搭建基于服務(wù)和UI的測試
• 探索性測試

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

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

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

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