掃二維碼與項(xiàng)目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
萬萬沒想到!沒過多久,當(dāng)我上到一個項(xiàng)目之后,TL跟我說,我們有些項(xiàng)目確實(shí)是沒有QA的,隔壁項(xiàng)目組有一個QA,但是在整個開發(fā)流程中也沒有專門的測試階段。聽完之后,我眼睛瞪得像銅鈴(夸張修辭):那誰來做測試策略呢?在什么階段測卡了?什么時候做探索式測試呢?TL顧及我作為QA的尊嚴(yán),立馬跟我強(qiáng)調(diào):“我覺得QA還是非常重要的,我是反對他們那樣做的!太危險啦!”。但是,她善良的勸慰并沒有撫平我的震驚,打消我的思考。這次我知道,“去QA化”可能真的來了。

創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)平?jīng)?10余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18982081108
那在“去QA化”的項(xiàng)目中,我能做什么來為團(tuán)隊(duì)提供價值呢?我?guī)е@樣的思考來到了項(xiàng)目上,并得出了一些自己的思考。
因地制宜地制定測試策略,這個是QA到了新項(xiàng)目必須要做的一個事情。在了解項(xiàng)目的上下文之后,我們需要及時去做這個事情,它的優(yōu)先級是非常高的。測試策略是一個非常重要的指導(dǎo),它涵蓋了功能,性能,Accessibility,兼容性,安全等方面都需要測什么,也明確了如何去測試的問題。在敏捷開發(fā)流程下,推薦大家可以參考“敏捷測試四象限”去思考設(shè)計(jì)自己的測試策略。
如果這個項(xiàng)目不是一個全新的項(xiàng)目,已經(jīng)有了現(xiàn)成的測試策略,我們需要在加入項(xiàng)目時去理解現(xiàn)在的測試策略,并在后續(xù)對項(xiàng)目背景、技術(shù)架構(gòu)、軟件功能有了更深入的了解之后,看是否需要去改進(jìn)當(dāng)前測試策略。每個項(xiàng)目的測試策略,其實(shí)都應(yīng)該跟隨項(xiàng)目變化不斷演進(jìn)。
QA為什么要在項(xiàng)目上推進(jìn)質(zhì)量內(nèi)建?首先,我們想想缺陷是被測試出來的嗎?不,它是在生產(chǎn)過程中產(chǎn)生的,所以我們需要在生產(chǎn)的過程中去提升產(chǎn)品的質(zhì)量,減少缺陷。
在敏捷開發(fā)的流程中,我們有需求分析、架構(gòu)設(shè)計(jì)、Kick off、Desk Check、In QA這一系列的環(huán)節(jié),質(zhì)量內(nèi)建其實(shí)就是要求我們做好每個環(huán)節(jié)的質(zhì)量保障,努力避免缺陷,盡早發(fā)現(xiàn)缺陷,而不是期望在測試環(huán)節(jié)發(fā)現(xiàn)所有缺陷,然后再修復(fù)。缺陷發(fā)現(xiàn)得越晚,修復(fù)得成本就越高。并且,缺陷發(fā)現(xiàn)越多,就越可能存在更多的缺陷。
我們在每一個階段都需要有質(zhì)量保障策略,團(tuán)隊(duì)的每個人都需要為質(zhì)量負(fù)責(zé)。比如:
除此以外,質(zhì)量內(nèi)建還包括其它的方面,需求管理,風(fēng)險管理,提高團(tuán)隊(duì)的質(zhì)量意識等。
制定自動化測試策略,并跟團(tuán)隊(duì)達(dá)成一致。搭建E2E和API自動化測試框架,編寫自動化測試代碼,并經(jīng)常給項(xiàng)目小伙伴們科普洗腦(我不是,我沒有)自動化測試的重要性,逐步提高項(xiàng)目的自動化覆蓋。
除了UT、E2E、API這些自動化測試以外,其實(shí)任何經(jīng)常重復(fù)執(zhí)行的動作,都可以嘗試自動化,比如準(zhǔn)備測試數(shù)據(jù),重復(fù)填寫冗長的表單等工作。自動化測試可以減少人工重復(fù)點(diǎn)點(diǎn)點(diǎn),解放QA的一部分勞動力,并且自動化測試的及時反饋,可以讓團(tuán)隊(duì)和客戶對產(chǎn)品質(zhì)量更有信心。
需求分析是開發(fā)流程當(dāng)中非常重要的一環(huán)(不局限于敏捷開發(fā)),QA應(yīng)該更早地介入需求分析,更多去關(guān)注業(yè)務(wù)需求,以QA的獨(dú)特視角去分析需求的合理性,以及一些邊界場景。在需求分析階段,多與客戶進(jìn)行溝通,理解客戶的真正訴求。跟BA一起pair完成寫卡,補(bǔ)充業(yè)務(wù)場景。并盡量在Kick off之前,確定好這張卡哪些testcase需要API自動化覆蓋,哪些需要在e2e自動化覆蓋,哪些是需要UT測試來覆蓋。
在故事卡進(jìn)入開發(fā)階段前,通過當(dāng)面溝通、ACs、testcases的各種方式(根據(jù)自己項(xiàng)目情況來),確定并澄清需求,達(dá)成一致理解。減少因?yàn)樾枨蟛缓侠?,需求分析不充分,需求理解不一致?dǎo)致的問題。
在一個項(xiàng)目開始或比較混亂的時期,QA總是有很多重要的事情要去做,如前文提到的,制定測試策略、提高自動化覆蓋、提高team的質(zhì)量意識等等工作。但是,當(dāng)項(xiàng)目進(jìn)入一個穩(wěn)定期,團(tuán)隊(duì)小伙伴們已經(jīng)有較好的質(zhì)量意識,測試覆蓋率也達(dá)到較高的標(biāo)準(zhǔn),這個時候我們可以去做什么呢?
首先,我們知道質(zhì)量內(nèi)建是一個持續(xù)的長期的概念,讓大家適應(yīng)了各個角色在各流程承擔(dān)的質(zhì)量職責(zé)之后,QA需要保持觀察,對質(zhì)量守護(hù)工作保持敏感性,持續(xù)推進(jìn)質(zhì)量內(nèi)建;
另外在新版本發(fā)布后,通過User Testing,收集用戶反饋,或者分析終端用戶的行為,收集分析生產(chǎn)環(huán)境的數(shù)據(jù),持續(xù)進(jìn)行改進(jìn);
QA還需要收集線上問題、UAT問題,進(jìn)行缺陷分析,并組織團(tuán)隊(duì)一起共同制定質(zhì)量改進(jìn)方案。在項(xiàng)目的演進(jìn)過程中,持續(xù)的思考是否需要改進(jìn)我們的質(zhì)量保障方案、測試策略。
質(zhì)量內(nèi)建以及高度的自動化測試,偶爾讓我們看起來不再需要QA,可是誰來做質(zhì)量內(nèi)建呢?誰來輸出質(zhì)量保障方案呢?誰來寫自動化測試呢?誰來做持續(xù)改進(jìn)呢?是QA,或者是戴上QA帽子的人。
總結(jié)下來,其實(shí)QA在項(xiàng)目上能做的東西有很多,包括但不限于:
除了以上幾個點(diǎn),QA還可以多關(guān)注提升效能,面向客戶等方向。
我覺得,所謂“去QA化”只是在某些項(xiàng)目中去掉了單獨(dú)的一個QA角色,但是總有人會戴上QA的帽子,或者人人都戴上了QA的帽子,人人都擁有很高的質(zhì)量意識,這其實(shí)是QA的理想國。

我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流