篇前話

經(jīng)歷過傳統(tǒng)的軟件測(cè)試工作卧蜓，每天的任務(wù)就是寫測(cè)試用例，跑測(cè)試用例把敞，改測(cè)試用例弥奸，報(bào)bug，驗(yàn)bug奋早。測(cè)試用例和bug成了工作的核心盛霎，圍繞它可以做很多學(xué)問，各種類型的測(cè)試也可以在此衍生耽装。進(jìn)入2011年愤炸，開始接觸scrum的工作方式，也開始接觸story规个，sprint挥萌，迭代周期等等的枉侧，慢慢的測(cè)試用例開始淡出引瀑。2015年元旦，加入ThoughtWorks榨馁，開啟了真正敏捷QA的體驗(yàn)，一直聽說敏捷軟件開發(fā)，也一直認(rèn)為之前的工作方式也算是敏捷的屡萤，實(shí)則不然。

結(jié)合之前的測(cè)試積累掸宛，以及在現(xiàn)在的項(xiàng)目中各種敏捷實(shí)踐的應(yīng)用死陆，這里，我想跟大家分享的是項(xiàng)目中體會(huì)較深的幾個(gè)敏捷QA實(shí)踐措译。

Story Review

通常需求由BA客戶反復(fù)的商討饰序，并做基本的整理和拆分后，會(huì)以story的形式產(chǎn)出塌衰。一個(gè)story會(huì)分別經(jīng)過BA蝠嘉，UX，客戶是晨，以及QA的review，反復(fù)修改填充.

QA在這個(gè)環(huán)節(jié)中蚊逢，通過review story對(duì)業(yè)務(wù)進(jìn)行理解和分析箫章，review story的AC，UI mockup终抽，結(jié)合和現(xiàn)有系統(tǒng)的設(shè)計(jì)桶至，對(duì)story的AC填充，加入相應(yīng)的驗(yàn)證圃郊，錯(cuò)誤處理女蜈，安全相關(guān)的驗(yàn)證點(diǎn)持舆。

同時(shí)添加QA Notes，相關(guān)開發(fā)部署的環(huán)節(jié)的內(nèi)容居兆，或者經(jīng)常出的bug提前標(biāo)記在story里竹伸。

舉個(gè)例子 story review 前和review 后：

在這個(gè)實(shí)踐中勋篓，QA想的是：如何站在質(zhì)量的角度，保證業(yè)務(wù)的完整性生巡，補(bǔ)充業(yè)務(wù)之外的相關(guān)內(nèi)容。

敏捷團(tuán)隊(duì)中的BA和QA一樣甸陌，經(jīng)常是一個(gè)人負(fù)責(zé)一塊內(nèi)容盐股，這樣使得BA和QA在工作中經(jīng)常出現(xiàn)結(jié)對(duì)，互相補(bǔ)充和backup牲尺。

Tasking

在你現(xiàn)在的項(xiàng)目中幌蚊，是否有為每一個(gè)story做tasking溢豆？

在你做tasking的過程中，是否有involve QA漩仙？

Tasking - 是在story kickoff之后，把story拆解成可以逐步實(shí)現(xiàn)的步驟卷仑，可以采用SBE的方式麸折，保證每一步的實(shí)現(xiàn)都是可交付的，當(dāng)然也有steps的方式私爷。這兩種方式都無可厚非膊夹，兩種方式不做過多比較放刨，畢竟story已經(jīng)是客戶可接受的最小交付對(duì)象了，story開發(fā)中进统，不同的dev開發(fā)方式和習(xí)慣不一樣是可以理解的。

第一種眉菱，拆解成steps的方式：

? 1. 包含了前后端的驗(yàn)證

? 2. 同時(shí)包含了一部分dev 設(shè)計(jì)的步驟（藍(lán)色標(biāo)記框）

? 3. 基本是遵照從前端到后端逐步開發(fā)的思路

? 4. 按照用戶的基本操作習(xí)慣掉分，全面考慮各種case酥郭。

第二種，類似SBE的方式：同樣的上面的例子惜姐，tasking之后的表現(xiàn)形式會(huì)是這樣的：

每一條tasking item都有交付價(jià)值

每一條tasking都有自己獨(dú)立的steps做分解

這樣做的好處在于每做完一條都能體現(xiàn)出交付的意義

同樣涵蓋了上面一種方法的所有條目椿息，只是組織方式和切入點(diǎn)不同。

QA和DEV pair tasking中達(dá)到的效果：

整理需求的邏輯宇攻，達(dá)到需求理解的一致倡勇。通常kickoff中會(huì)提到特別多的點(diǎn)，需要整理輸出夸浅。

涵蓋了所有story相關(guān)的測(cè)試point

在tasking過程中扔役，跟dev pair亿胸，指出了在開發(fā)中可能遇到的坑预皇，可能忽略到的點(diǎn)

同開發(fā)一起婉刀，站在質(zhì)量的角度，從設(shè)計(jì)上考慮潛在的風(fēng)險(xiǎn)鲁豪，提前預(yù)防律秃，比如performance，security的問題糙申，API的設(shè)計(jì)

了解開發(fā)的設(shè)計(jì)思路船惨，幫助QA理解story的測(cè)試難度以及測(cè)試量

若遇到組里新來的開發(fā)，可以通過tasking pair幫助開發(fā)理解業(yè)務(wù)細(xì)節(jié)

在這個(gè)實(shí)踐中粘室，QA想的是：如何站在質(zhì)量的角度卜范，規(guī)避可能遇到的或者常被忽視的點(diǎn)。

也就是說QA在開發(fā)開始工作前锦爵，就已經(jīng)把可預(yù)見的問題奥裸，bug，都已經(jīng)在tasking的過程中規(guī)避了樟氢。同時(shí)侠鳄，即使開發(fā)switch pair，也不擔(dān)心細(xì)節(jié)的丟失碴开，Tasking有效的保證了story沒涉及到的細(xì)節(jié)點(diǎn)的不被遺漏。Tasking實(shí)踐中眶掌，要求QA要有軟件開發(fā)設(shè)計(jì)的理解力巴碗，可以跟開發(fā)溝通設(shè)計(jì)中的不足，理解開發(fā)遇到的難點(diǎn)痛點(diǎn)，并一起想辦法蒿叠。

Review Test

Unit Test, API Test, Contract Test都是屬于測(cè)試的一部分市咽，位于測(cè)試金字塔的下層，專注手動(dòng)測(cè)試的QA很少會(huì)接觸施绎。UT谷醉，API測(cè)試，Contract Test都是屬于內(nèi)部質(zhì)量保障俱尼，也就是代碼質(zhì)量的保障遇八。QA關(guān)注產(chǎn)品的質(zhì)量，除了外部質(zhì)量刃永，也包括軟件的內(nèi)部質(zhì)量斯够。UT，API測(cè)試读规，Contract Test是由開發(fā)人員編寫的測(cè)試代碼掖桦，也是QA關(guān)注的范圍。所以也鼓勵(lì)QA對(duì)底層測(cè)試進(jìn)行了解枪汪。那么Review Test是怎么做呢：

Story signoff階段，業(yè)務(wù)signoff之后宿稀，留下QA與DEV一起進(jìn)行Review Test

QA driven祝沸，從前到后，充分掌握UT測(cè)試的邏輯鏈條罩锐，把控內(nèi)建質(zhì)量

對(duì)比UT測(cè)試和tasking list涩惑，是否每一條check point都有測(cè)試cover

前后端的測(cè)試同時(shí)需要根據(jù)需求做validation，例如字段不為空

Review之后跛蛋，產(chǎn)出TODO list痊硕，需要修改的測(cè)試，或者遺漏的測(cè)試此衅，或者需要重構(gòu)的測(cè)試都是review之后的產(chǎn)出亭螟。

測(cè)試舉例：

好的UT具備：

名字mi較強(qiáng)的可讀性预烙，傳達(dá)的是業(yè)務(wù)意義。

清晰的數(shù)據(jù)準(zhǔn)備翘县，不相互依賴

清晰的測(cè)試點(diǎn)谴分，verify point和description相符

整體結(jié)構(gòu)清晰，一個(gè)UT一個(gè)測(cè)試點(diǎn)忘伞，一組UT相互結(jié)構(gòu)清晰。

在整個(gè)review的過程中氓奈，開發(fā)和測(cè)試充分的溝通實(shí)現(xiàn)和測(cè)試case的設(shè)計(jì)舀奶，一方面幫助開發(fā)設(shè)計(jì)合理的測(cè)試，一方面幫助QA理解哪部分測(cè)試已經(jīng)在底層做過了但荤。

在這個(gè)實(shí)踐中涧至，QA想的是：如何站在質(zhì)量的角度，組織有效的內(nèi)部質(zhì)量測(cè)試潜慎。構(gòu)建合理的測(cè)試體系蓖康，把測(cè)試重心往底層推垒手。

Review Test實(shí)踐中科贬，要求QA要有一定的代碼能力，了解開發(fā)的設(shè)計(jì)模式优妙，讀懂測(cè)試代碼憎账，能夠在Review Test中起到指導(dǎo)測(cè)試的作用。

構(gòu)建QA checklist

你有沒有發(fā)現(xiàn)kickoff的時(shí)候邪意，有那么幾個(gè)問題反砌，或者幾個(gè)點(diǎn)會(huì)重復(fù)提，例如：performance相關(guān)的用戶量策菜，例如是否要event(使用event store的話)，相信每個(gè)組都有自己組特殊的但是common的點(diǎn)冒晰。你有沒有發(fā)現(xiàn)在signoff的時(shí)候竟块，有一些common的問題被反復(fù)的在不同的story暴露，例如：button 顏色不對(duì)蒋情，忘記了排序耸携，對(duì)齊問題等等夺衍。這個(gè)時(shí)候，敏銳的QA就會(huì)根據(jù)這樣的反饋機(jī)制河劝，建立一個(gè)checklist矛紫，把這些經(jīng)常出現(xiàn)的問題搜集整理共享出來∥裆可以添加到story的模版里喳篇，用來保證每個(gè)story都會(huì)過一遍這個(gè)list，把質(zhì)量保障往前推挺尿。Checklist 可以包括：

Performance相關(guān)的AC: support how many user/data

安全相關(guān)的AC: evil user story etc

是否有部署配置相關(guān)的要求：新的DB票髓，新的site铣耘，數(shù)據(jù)migrate等

是否需要feature toggle

Error handle

兼容性問題

UI 問題

項(xiàng)目業(yè)務(wù)相關(guān)：類似與不同角色的權(quán)限控制

這個(gè)列表可以不斷的擴(kuò)展，可以來源于開發(fā)環(huán)節(jié)之后的任何一個(gè)環(huán)節(jié)多次出現(xiàn)的問題裆操，也可能是經(jīng)常出現(xiàn)的bug，也可以是技術(shù)的requirement昆烁。這個(gè)list如同九陰真經(jīng)缎岗，可以幫助團(tuán)隊(duì)提供一個(gè)反饋平臺(tái)，把后期發(fā)現(xiàn)的問題提前預(yù)防鼠渺，避免一個(gè)問題多次出現(xiàn)眷细，也避免寶貴的大腦資源記這些繁瑣的零散的點(diǎn)溪椎。

如果你還沒有這樣一份checklist，建議構(gòu)建一個(gè)沼侣，作為一個(gè)活文檔地熄，存活在每一個(gè)story中芯杀。

像這樣揭厚，但不僅僅包含這些：

總結(jié)

敏捷QA筛圆，在敏捷軟件開發(fā)實(shí)踐中有自己的關(guān)注點(diǎn)，除了build quality in software,還需要build quality sense in everyone. 在團(tuán)隊(duì)中闽晦，QA需要參與到從需求到交付的每個(gè)環(huán)節(jié)提岔，做到把質(zhì)量構(gòu)建在軟件開發(fā)活動(dòng)中的每一步碱蒙。如果你還在天天做手動(dòng)測(cè)試夯巷，跟bug打交道哀墓，那不妨開始想想，怎樣把現(xiàn)在做的手動(dòng)測(cè)試推到測(cè)試金字塔的合適位置后雷，怎樣減少bug的產(chǎn)生吠各。

這篇文只列了四個(gè)敏捷QA實(shí)踐：Story Review, Tasking, Review Test, 構(gòu)建QA checklist走孽。來自項(xiàng)目實(shí)踐真知，希望對(duì)大家有幫助盒齿。