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