建站
咨詢
售后
建站咨詢
新聞中心
敏捷QA對(duì)職業(yè)發(fā)展的擔(dān)憂
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：國(guó)際域名空間、網(wǎng)絡(luò)空間、營(yíng)銷(xiāo)軟件、網(wǎng)站建設(shè)、鷹手營(yíng)子網(wǎng)站維護(hù)、網(wǎng)站推廣。
最近和組內(nèi)的QA聊起以后的職業(yè)發(fā)展，發(fā)現(xiàn)一個(gè)有意思的事情，有說(shuō)想轉(zhuǎn)BA的，有說(shuō)想轉(zhuǎn)開(kāi)發(fā)的，有說(shuō)想轉(zhuǎn)型作PM的，還有想以后往咨詢方向發(fā)展的。很少有說(shuō)想在團(tuán)隊(duì)里面繼續(xù)作QA的。QA這個(gè)角色難道就這么沒(méi)有吸引力么?為什么都想轉(zhuǎn)型或者自己出去單干呢?和組里幾個(gè)QA聊了之后，發(fā)現(xiàn)主要因素在于對(duì)QA職業(yè)發(fā)展的擔(dān)憂，覺(jué)得敏捷團(tuán)隊(duì)對(duì)專(zhuān)職QA的需求并不大。
記得我剛工作的時(shí)候還是有獨(dú)立測(cè)試團(tuán)隊(duì)的，那個(gè)時(shí)候分工很明確，我就負(fù)責(zé)windows mobile(現(xiàn)在叫windows phone)上應(yīng)用的自動(dòng)化測(cè)試，我的這個(gè)職位叫做SDET，說(shuō)通俗點(diǎn)就是自動(dòng)化測(cè)試工程師。我們這個(gè)團(tuán)隊(duì)大概有10人，測(cè)試完畢后將結(jié)果匯報(bào)給測(cè)試經(jīng)理。由于產(chǎn)品復(fù)雜，需要大量的測(cè)試工程師以保證產(chǎn)品能順利發(fā)布。隨著更多功能的加入，測(cè)試團(tuán)隊(duì)的人數(shù)也在增加，這段時(shí)間是QA最有價(jià)值感的時(shí)候，產(chǎn)品的發(fā)布最終都由你來(lái)把關(guān)，你可以根據(jù)興趣來(lái)選擇以后做一個(gè)性能測(cè)試或者安全測(cè)試工程師等等，有明確的發(fā)展路線。
但現(xiàn)在越來(lái)越多的公司選擇了敏捷轉(zhuǎn)型，適應(yīng)變化和快速交付可工作的軟件成為了團(tuán)隊(duì)的關(guān)注點(diǎn)。從開(kāi)發(fā)和用戶的角度看，他們會(huì)很樂(lè)意接受這個(gè)變化，客戶可以不斷看到新功能，開(kāi)發(fā)可以把精力從繁瑣的文檔和流程上釋放出來(lái)，發(fā)揮想象和創(chuàng)意來(lái)提供更好的解決方案。可對(duì)于QA來(lái)說(shuō)，敏捷帶來(lái)了什么好處呢?之前定期有一個(gè)可測(cè)的穩(wěn)定版本，詳細(xì)的需求文檔就是我們參考的對(duì)象?，F(xiàn)在要對(duì)一個(gè)不斷變化著的對(duì)象來(lái)進(jìn)行驗(yàn)證，也沒(méi)有一大段時(shí)間來(lái)設(shè)計(jì)自動(dòng)化框架。我們?cè)趺磥?lái)保證質(zhì)量呢?
敏捷QA的測(cè)試職責(zé)
在敏捷的團(tuán)隊(duì)中，質(zhì)量是由團(tuán)隊(duì)所有人來(lái)保證的，我剛開(kāi)始聽(tīng)到這句話就像聽(tīng)到敏捷宣言一樣，知道這有道理，但具體怎么做呢?如果質(zhì)量是團(tuán)隊(duì)的責(zé)任，那么專(zhuān)職的QA干什么呢?
首先我們來(lái)看在敏捷團(tuán)隊(duì)經(jīng)常用來(lái)保證測(cè)試用例達(dá)到平衡狀態(tài)的測(cè)試金字塔，簡(jiǎn)單來(lái)說(shuō)我們可以把更多的測(cè)試放在單元和服務(wù)級(jí)別，因?yàn)檫@些用例更易維護(hù)和執(zhí)行，運(yùn)行效率也更高，可以參照Martin Fowler的TestPyramid。
在這個(gè)框架下，很容易讓人產(chǎn)生這樣的誤解：
1. 開(kāi)發(fā)負(fù)責(zé)單元測(cè)試，不需要QA參與
跟組里的開(kāi)發(fā)討論過(guò)“是否需要QA參與到審查單元測(cè)試覆蓋率”的問(wèn)題，開(kāi)發(fā)通常會(huì)覺(jué)得用處不大，因?yàn)橛袑?zhuān)門(mén)的工具比如：Cobertura， Jacoco, Istanbul等。這些工具的檢查范圍通常包括：
- 行覆蓋率(line coverage)：是否每一行都執(zhí)行了?
- 函數(shù)覆蓋率(function coverage)：是否每個(gè)函數(shù)都調(diào)用了?
- 分支覆蓋率(branch coverage)：是否每個(gè)if代碼塊都執(zhí)行了?
- 語(yǔ)句覆蓋率(statement coverage)：是否每個(gè)語(yǔ)句都執(zhí)行了?
而QA的檢查可以彌補(bǔ)單純的代碼級(jí)別的覆蓋。比如異常處理和邊界值的情況，代碼級(jí)別的覆蓋會(huì)檢查語(yǔ)句是否執(zhí)行了，但是不能檢查這段邏輯是不是寫(xiě)了。下面列舉出幾種常用的檢查方法：
- 等價(jià)類(lèi)：把程序的輸入域(所有可能的輸入數(shù)據(jù))劃分成若干部分，然后從每個(gè)部分中選取少數(shù)有代表性的數(shù)據(jù)作為測(cè)試用例。每一類(lèi)的代表性數(shù)據(jù)在測(cè)試中的作用等價(jià)于這一類(lèi)中其他值。
- 邊界值：邊界值分析法是對(duì)等價(jià)類(lèi)劃分的補(bǔ)充，它是對(duì)輸入或輸出的邊界值進(jìn)行測(cè)試的一種測(cè)試方法。我們這里所指的“邊界值”是相對(duì)于“輸入等價(jià)類(lèi)”和“輸出等價(jià)類(lèi)”而言的，稍高于其邊界或低于其邊界的一些特殊情況。
- 決策表：在一些數(shù)據(jù)處理問(wèn)題當(dāng)中，某些操作的實(shí)施依賴于多個(gè)邏輯條件的組合，即：針對(duì)不同邏輯條件的組合值，分別執(zhí)行不同的操作，判定表很適合于處理這類(lèi)問(wèn)題。
- 因果圖：是一種利用圖解法分析輸入的各種組合情況，從而設(shè)計(jì)測(cè)試用例的方法，它適合于檢查程序輸入條件的各種組合情況。
有的QA會(huì)發(fā)現(xiàn)這些通常是用在黑盒測(cè)試?yán)锏姆椒?，其?shí)把這些覆蓋盡可能的在單元或者服務(wù)級(jí)別來(lái)實(shí)現(xiàn)是一種既有效率，結(jié)果反饋又快，又可以直接作為回歸測(cè)試的一種很好的途徑。
在項(xiàng)目的實(shí)踐中我們可以看到QA參與到單元測(cè)試的審查有以下好處：
- QA可以審查單元測(cè)試的覆蓋率，來(lái)調(diào)整單元測(cè)試以及后續(xù)接口測(cè)試和回歸測(cè)試的覆蓋率。之前做的項(xiàng)目都是開(kāi)發(fā)獨(dú)自寫(xiě)單元測(cè)試和接口測(cè)試，QA也獨(dú)自寫(xiě)自動(dòng)化回歸測(cè)試，后來(lái)發(fā)現(xiàn)有很多的重復(fù)覆蓋，這也是種浪費(fèi)。如果能結(jié)對(duì)來(lái)做單元測(cè)試，是種更高效的方式。
- QA可以更清楚代碼對(duì)各個(gè)模塊的影響，這樣可以有針對(duì)性的設(shè)計(jì)回歸測(cè)試，比如之前項(xiàng)目有個(gè)小的改動(dòng)，QA沒(méi)能在很短的時(shí)間進(jìn)行回歸測(cè)試，導(dǎo)致產(chǎn)品發(fā)布后遇到了問(wèn)題。有人會(huì)說(shuō)自動(dòng)化覆蓋所有回歸測(cè)試不就行了么?理論上是這樣的，但現(xiàn)實(shí)中有很多限制，只能通過(guò)手動(dòng)驗(yàn)證來(lái)完成回歸測(cè)試。這種情況下，精確定位回歸測(cè)試的范圍變得尤為重要了。
- QA對(duì)系統(tǒng)構(gòu)架、開(kāi)發(fā)語(yǔ)言能有一個(gè)學(xué)習(xí)的過(guò)程，這有利于自動(dòng)化回歸測(cè)試的搭建。
2. 開(kāi)發(fā)更適合設(shè)計(jì)自動(dòng)化測(cè)試框架和接口測(cè)試，因?yàn)樗麄儗?xiě)代碼更有效率
如果說(shuō)自動(dòng)化測(cè)試和接口測(cè)試的目的是比誰(shuí)寫(xiě)代碼的效率更高，那么的確這些事情應(yīng)該由開(kāi)發(fā)去做，但是作為QA，參與其中的作用在于分析需求以及從客戶的角度來(lái)設(shè)計(jì)用例。
敏捷團(tuán)隊(duì)越來(lái)越多的應(yīng)用行為驅(qū)動(dòng)開(kāi)發(fā)(BDD)來(lái)覆蓋基于服務(wù)和UI的測(cè)試。
QA會(huì)和PO，BA，DEV，UX一起合作，分析軟件的需求，然后將這些需求寫(xiě)成用戶故事。開(kāi)發(fā)者負(fù)責(zé)填充這些故事的內(nèi)容，測(cè)試者負(fù)責(zé)檢驗(yàn)這些故事的結(jié)果。通常，會(huì)使用一個(gè)故事的模板來(lái)對(duì)故事進(jìn)行描述。
故事的模板：
- 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
每一個(gè)story有可能會(huì)有不同的場(chǎng)景，可以用下面的模板來(lái)描述在什么環(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會(huì)和DEV一起合作來(lái)實(shí)現(xiàn)這些story的自動(dòng)化測(cè)試，常用的工具:
- 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. 開(kāi)發(fā)交互進(jìn)行基于UI的測(cè)試就行了，不需要專(zhuān)門(mén)的QA進(jìn)行測(cè)試
如果說(shuō)基于UI的測(cè)試就是執(zhí)行測(cè)試用例，那么的確不需要專(zhuān)職QA來(lái)做，但是在敏捷的團(tuán)隊(duì)中基于UI的測(cè)試大部分是以探索性測(cè)試來(lái)完成的。怎么設(shè)計(jì)好的探索性測(cè)試用例才是專(zhuān)職QA的價(jià)值所在。
有人說(shuō)探索性測(cè)試就是手動(dòng)測(cè)試，有的說(shuō)是隨機(jī)測(cè)試，有的說(shuō)就是把自己當(dāng)用戶來(lái)使用軟件的測(cè)試。
什么是探索性測(cè)試?下面是wikipedia上面的定義：
| Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. Cem Kaner, who coined the term in 1984,[1] defines exploratory testing as "a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project. |
看完這個(gè)解釋更迷惑了，探索性測(cè)試到底是什么東西?
舉個(gè)簡(jiǎn)單的例子，我們聚餐的時(shí)候有時(shí)候會(huì)玩猜數(shù)字的游戲，主持會(huì)寫(xiě)下一個(gè)數(shù)字，大家輪流猜，主持會(huì)提示大了或者小了。那么下一個(gè)人會(huì)根據(jù)這個(gè)提示來(lái)繼續(xù)猜，直到有人猜中這個(gè)數(shù)字。這其實(shí)就是探索測(cè)試的原理，每次都會(huì)根據(jù)之前的結(jié)果來(lái)設(shè)計(jì)下次的數(shù)字，那個(gè)被猜數(shù)字就是defect，每一次猜測(cè)都是測(cè)試用例。如果你想用最少的次數(shù)來(lái)猜中這個(gè)數(shù)字，就需要有高效的方法，探索測(cè)試也是如此。
敏捷QA存在的價(jià)值
以上簡(jiǎn)單的描述了在敏捷團(tuán)隊(duì)中，QA在測(cè)試中的職責(zé)：
- 審查單元測(cè)試的覆蓋率
- 和開(kāi)發(fā)結(jié)對(duì)搭建基于服務(wù)和UI的測(cè)試
- 探索性測(cè)試
其實(shí)QA還有很多面向客戶的職責(zé)，比如需求澄清以及產(chǎn)品演示，會(huì)在后續(xù)的文章去討論。
隨著敏捷的項(xiàng)目越來(lái)越多，對(duì)QA的需求不是越來(lái)越少，而是越來(lái)越高，QA需要像一個(gè)好的家庭主婦一樣，能里能外，在團(tuán)隊(duì)內(nèi)部能更好的平衡測(cè)試設(shè)計(jì)，在外部能更好的體現(xiàn)產(chǎn)品價(jià)值。在一個(gè)快速變化的時(shí)代，在持續(xù)快速交付的情況下保證質(zhì)量是一件很困難的事情，解決這個(gè)問(wèn)題就是QA存在的價(jià)值。
【本文是專(zhuān)欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
戳這里，看該作者更多好文
網(wǎng)站題目：敏捷團(tuán)隊(duì)需要專(zhuān)職QA么？
標(biāo)題來(lái)源：http://m.5511xx.com/article/cdcodee.html
