Quality Assurance :The planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled.
Quality Control :The observation techniques and activities used to fulfill requirements for quality.
QA的工作涉及軟件研發(fā)流程的各個(gè)環(huán)節(jié)，且涉及到每一位參與研發(fā)的人員，但質(zhì)量保證工作又不涉及具體的軟件研發(fā)細(xì)節(jié)，側(cè)重于整個(gè)流程。
QC則側(cè)重于點(diǎn)，利用各種方法去檢查某個(gè)功能是否滿足業(yè)務(wù)需求。
thoughtworks 的QA則是這兩者的混合體，你既要保證開發(fā)流程的質(zhì)量，又要保證story的功能的是否正確。
來thoughtworks已經(jīng)2年了，當(dāng)過bqconf講師與主持，參加過公司內(nèi)各類測(cè)試相關(guān)活動(dòng)，也閱讀過g郵件中分享的關(guān)于test的話題，大部分人關(guān)注點(diǎn)都離不開自動(dòng)化測(cè)試，面試的QA也說想到thoughtworks來學(xué)習(xí)高深的自動(dòng)化測(cè)試，仿佛自動(dòng)化測(cè)試代表了整個(gè)QA界，我反對(duì)盲目的自動(dòng)化測(cè)試，確切的說反對(duì)盲目的UI自動(dòng)化測(cè)試。很多QA在自動(dòng)化測(cè)試海洋里迷失了自己。
我要強(qiáng)調(diào)自動(dòng)化測(cè)試: 真的沒有銀彈。
Faster Delivery Of Quality Software From Idea To Consumer
所以自動(dòng)化測(cè)試只是其中的一小部分。
如上圖頂部和底部的文字是對(duì)一個(gè)QA所能帶給項(xiàng)目的總結(jié)：“我們?cè)陂_發(fā)正確的產(chǎn)品嗎？如果是，那么我們開發(fā)的產(chǎn)品正確嗎？”所以QA首先需要在整個(gè)個(gè)項(xiàng)目過程中不斷詢問的所有成員上述問題，確保團(tuán)隊(duì)是在開發(fā)客戶所需的產(chǎn)品，而不是自己YY出來的產(chǎn)品。
Quality is not just in the software but also in the process
質(zhì)量從來都不只是QA的職責(zé)，而是整個(gè)團(tuán)隊(duì)的職責(zé)。但QA如果自己都不注重，不督促組內(nèi)成員改進(jìn)質(zhì)量，再將責(zé)任強(qiáng)加于整個(gè)團(tuán)隊(duì)，那么產(chǎn)品質(zhì)量又何談提升與保證。
中間的圖片從一個(gè)QA的角度表明了一個(gè)用戶故事的生命周期以及QA如何參與其中每個(gè)環(huán)節(jié)。
首先BA和客戶將要開發(fā)的story列出之后，BA與QA可以一起pair編寫具體story的內(nèi)容，場(chǎng)景與驗(yàn)收條件,利用自己對(duì)業(yè)務(wù)以及系統(tǒng)的熟悉度，盡量的配合BA將story中坑盡量排除掉。
所有參與kick off 角色，都應(yīng)該提前了解story內(nèi)容。在kick off過程中，提出自己對(duì)story疑問。盡量將業(yè)務(wù)需求上問題在這個(gè)階段解決。
在完成kick off后，QA可以和dev一起pair完成編寫unit test 以及Automated Acceptance Tests，身為一個(gè)敏捷QA，我們起碼要了解團(tuán)隊(duì)選用的單元測(cè)試工具，熟悉項(xiàng)目的技術(shù)架構(gòu)，這樣更好的便于我們對(duì)整個(gè)項(xiàng)目質(zhì)量把控，在與dev pair的過程中，即幫助dev分析業(yè)務(wù)場(chǎng)景的分支，來確保單元測(cè)試覆蓋的是正確的場(chǎng)景，而不是為了交代上級(jí)隨便亂寫的單元測(cè)試，也幫助QA熟悉代碼，提高編碼能力。
當(dāng)DEV完成編碼工作后，這時(shí)QA UX BA DEV一起檢查story，是否按照story AC來檢查是否完成對(duì)應(yīng)的功能。UX也可發(fā)表對(duì)story UI以及交互一些看法，有任何問題及時(shí)討論后，將問題盡早的反饋給客戶。
當(dāng)開發(fā)交付一部分功能之后，QA就可以做常規(guī)的用戶故事測(cè)試，幾個(gè)迭代之后，QA開始進(jìn)行跨功能需求測(cè)試和探索性測(cè)試等。根據(jù)探索性測(cè)試的結(jié)果，QA可能會(huì)調(diào)整測(cè)試策略，調(diào)整測(cè)試優(yōu)先級(jí)，完善測(cè)試用例等等。
上面這些QA實(shí)踐貌似已經(jīng)很完美,其實(shí)還差最重要的一環(huán) quality analysis 。每次release后，我們總以為我們發(fā)布一個(gè)完美的產(chǎn)品，但卻總能在新迭代開發(fā)過程中發(fā)現(xiàn)之前問題，歷史總是驚人的相似，為什么，沒有分析總結(jié)問題，以及相應(yīng)的預(yù)防手段,那么同樣的問題只會(huì)重現(xiàn)。
同時(shí)我們也要回顧下自己在工作中真的將這些敏捷實(shí)踐都應(yīng)用到工作中嗎，我想或多或少的都有所欠缺。對(duì)于一個(gè)QA來說，不應(yīng)循規(guī)蹈矩照搬敏捷實(shí)踐。例如，在kickoff中，發(fā)現(xiàn)dev，UX對(duì)story涉及的場(chǎng)景以及內(nèi)容了解不清楚，QA也可能漏掉一些測(cè)試場(chǎng)景，那么我們可以在kickoff之前，加入一個(gè)pre- kick off的實(shí)踐，留出時(shí)間，讓每個(gè)角色都能夠完整了解story。在kick off之中，ux沒有辦法完整的確認(rèn)頁面的字體大小或者顏色等是否正確，那么在sign off之后，我們也加入一個(gè)UX-test實(shí)踐，幫助UX能夠更好解決這些問題。
所以每個(gè)項(xiàng)目也都有應(yīng)適合自己項(xiàng)目的敏捷實(shí)踐，發(fā)現(xiàn)項(xiàng)目存在的問題，持續(xù)改進(jìn)才是最佳實(shí)踐。
pyramid
上面的測(cè)試金字塔對(duì)于大家來說再熟悉不過了，對(duì)于自動(dòng)化測(cè)試來說最有價(jià)值的仍然是單元測(cè)試，但對(duì)于QA來說無疑最復(fù)雜的。
大部分QA或者tester，仍然以UI自動(dòng)化為重心。之所以反對(duì)盲目的UI自動(dòng)化測(cè)試，因?yàn)樽兓l繁的UI設(shè)計(jì)，極低投入產(chǎn)生比，都應(yīng)該讓我們重新思考下UI自動(dòng)化的價(jià)值。
能不用UI自動(dòng)化測(cè)試就不用，梳理業(yè)務(wù)主線，只保留用戶操作最頻繁，交互最多的場(chǎng)景。
根據(jù)面向?qū)ο笤O(shè)計(jì)的原則，構(gòu)建適合項(xiàng)目的UI自動(dòng)化框架，無論自己編寫框架，還是采用開源框架。
盡量采用獨(dú)立測(cè)試數(shù)據(jù)，確保運(yùn)行測(cè)試不受影響。例如采用mock數(shù)據(jù)庫或者每次運(yùn)行時(shí)還原測(cè)試數(shù)據(jù)庫。
編碼規(guī)范，真實(shí)例子，dev對(duì)于類名命名沒有用Camel-Case，造成在linux系統(tǒng)中部署不成功，python中亂使用縮進(jìn)等。 其實(shí)都可以避免到，例如開發(fā)工具加入自動(dòng)檢查，或者在CI上加入校驗(yàn)編碼規(guī)范的步驟，采用一些工具就可以達(dá)到目的，jshint，RuboCop等。
pair完成單元測(cè)試或API測(cè)試等，一方面可以提高QA的編碼能力，另一面可以給出dev一些建議，將單元測(cè)試覆蓋到更多的場(chǎng)景。
例如，如果你們項(xiàng)目采用react作為前端框架，如果你不能理解react virtual dom 與jsx，當(dāng)我們?cè)趯慤I自動(dòng)化腳本時(shí)，你會(huì)發(fā)現(xiàn)根本無法進(jìn)行下去，日常中我們定位元素全是這種
,所有的頁面都是js渲染出來的，如果你懂jsx，就知道只需要在對(duì)于的Component render方法中更改加入id等元素就可以搞定
控制單元測(cè)試覆蓋率，100%的單元測(cè)試覆蓋率當(dāng)然是最好的，但如果交付壓力大，和客戶商量后，我們可以盡量覆蓋業(yè)務(wù)主線，而不是為了達(dá)到覆蓋率延誤了交付周期。
作為一個(gè)QA，我們不僅要檢測(cè)項(xiàng)目中存在問題，也要改進(jìn)團(tuán)隊(duì)的實(shí)踐活動(dòng)，更重要的是預(yù)防問題的發(fā)生。
每次bugbash或相應(yīng)迭代完成后，要分析統(tǒng)計(jì)，找出產(chǎn)生缺陷的環(huán)節(jié)，并采取措施防止問題再現(xiàn)。例如每次release或者bug bash之后,我可以按照功能模塊與bug類型進(jìn)行統(tǒng)計(jì)劃分，分析統(tǒng)計(jì)bug的成因，例如某次迭代我們bug數(shù)量激增，經(jīng)調(diào)查，發(fā)現(xiàn)我們對(duì)某些模塊的前端代碼進(jìn)行了重構(gòu)，但缺乏相應(yīng)的單元測(cè)試與集成測(cè)試，造成了我們沒有及時(shí)發(fā)現(xiàn)bug。之后我們就對(duì)應(yīng)的采取措施防止問題再現(xiàn)。
總結(jié)分析報(bào)告，及時(shí)反饋這些信息給團(tuán)隊(duì)?？偨Y(jié)分析是一個(gè)長(zhǎng)期的任務(wù)，每次bug數(shù)量的變動(dòng)，都會(huì)直接體現(xiàn)整個(gè)團(tuán)隊(duì)上次迭代的開發(fā)質(zhì)量，例如bug數(shù)量減少了，可以鼓勵(lì)成員再接再厲?；蛘吣硯状蔚承┠Kbug成上升趨勢(shì)，那么就需要組織團(tuán)隊(duì)一起討論問題根源，采取措施防止問題重現(xiàn)。
利用代碼質(zhì)量分析工具幫助我們盡早預(yù)防問題的發(fā)生。例如sonar代碼質(zhì)量管理平臺(tái)，可以幫助我們從代碼復(fù)雜度，重復(fù)代碼，單元測(cè)試覆蓋率，編碼規(guī)范等緯度來分析我們代碼所存在的問題。當(dāng)然也有其他的開源工具，像RubyCritic，/plato不同的語言都會(huì)有相應(yīng)的工具。
在線監(jiān)控，利用像newrelic，airbnb等監(jiān)控工具對(duì)部署在本地或在云中的web應(yīng)用程序進(jìn)行監(jiān)控、故障修復(fù)、診斷、線程分析以及容量計(jì)劃。這樣就算們產(chǎn)品環(huán)境有任何問題，我們都會(huì)及時(shí)響應(yīng)，盡早修復(fù)，減低損失。
軟技能方面包括風(fēng)險(xiǎn)控制，輔導(dǎo)他人，溝通能力，分析定位等。技能方面則包括缺陷管理，流程改進(jìn)，測(cè)試分析，可用性測(cè)試，性能測(cè)試，安全測(cè)試等。
回顧上面這些實(shí)踐，其實(shí)我們可以做的更好，而不是把團(tuán)隊(duì)的質(zhì)量全都交給自動(dòng)化，回歸QA的應(yīng)有的初心，讓我們從各個(gè)方面改進(jìn)質(zhì)量，帶給團(tuán)隊(duì)更好的未來。
本文轉(zhuǎn)自：開發(fā)者頭條
微信號(hào)：IdeaofSE
聯(lián)系客服
