讓我們回顧一下QA與QC的區(qū)別：

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ā)流程的各個環(huán)節(jié)，且涉及到每一位參與研發(fā)的人員绅这，但質(zhì)量保證工作又不涉及具體的軟件研發(fā)細(xì)節(jié)，側(cè)重于整個流程吐葵。

QC則側(cè)重于點(diǎn)，利用各種方法去檢查某個功能是否滿足業(yè)務(wù)需求桥氏。

ThoughtWorks 的QA則是這兩者的混合體温峭，既要保證開發(fā)流程的質(zhì)量，又要保證Story的功能正確字支。

我來ThoughtWorks已經(jīng)3年了凤藏，當(dāng)過BQConf講師與主持人，參加過公司內(nèi)各類測試相關(guān)活動堕伪，也閱讀過郵件中分享的關(guān)于測試的話題揖庄，大部分人關(guān)注點(diǎn)都離不開自動化測試，面試的QA也說想到ThoughtWorks來學(xué)習(xí)高深的自動化測試欠雌，仿佛自動化測試代表了整個QA界蹄梢，我反對盲目的自動化測試，確切的說反對盲目的UI自動化測試富俄。很多QA在自動化測試海洋里迷失了自己禁炒。

我要強(qiáng)調(diào)自動化測試：真的沒有銀彈而咆。

image.png

QA的最終價值體現(xiàn)

Faster Delivery Of Quality Software From Idea To Consumer

確保項(xiàng)目的正確性

所以自動化測試只是其中的一小部分。

如上圖頂部和底部的文字是對一個QA所能帶給項(xiàng)目的總結(jié)：“我們在開發(fā)正確的產(chǎn)品嗎幕袱？如果是暴备，那么我們開發(fā)的產(chǎn)品正確嗎？”所以QA首先需要在整個項(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é)望迎，而是整個團(tuán)隊(duì)的職責(zé)障癌。但QA如果自己都不注重，不督促組內(nèi)成員改進(jìn)質(zhì)量擂煞，再將責(zé)任強(qiáng)加于整個團(tuán)隊(duì)混弥，那么產(chǎn)品質(zhì)量又何談提升與保證。

中間的圖片從一個QA的角度表明了一個用戶故事的生命周期以及QA如何參與其中每個環(huán)節(jié)对省。

image

首先BA和客戶將要開發(fā)的用戶故事列出之后，BA與QA可以一起結(jié)對編寫具體用戶故事的內(nèi)容晾捏，場景與驗(yàn)收條件蒿涎，利用自己對業(yè)務(wù)以及系統(tǒng)的熟悉度，盡量配合BA將用戶故事中坑排除掉惦辛。

image.png

所有參與用戶故事kick off的角色劳秋，都應(yīng)該提前了解用戶故事內(nèi)容。在kick off過程中胖齐，提出自己對用戶故事的疑問玻淑，盡量在這個階段解決掉業(yè)務(wù)需求上的問題。

image.png

在完成kick off后呀伙，QA可以和開發(fā)人員一起結(jié)對編寫unit test以及Automated Acceptance Tests补履，身為一個敏捷QA，我們起碼要了解團(tuán)隊(duì)選用的單元測試工具剿另，熟悉項(xiàng)目的技術(shù)架構(gòu)箫锤，這樣更好的便于我們把控整個項(xiàng)目質(zhì)量，在與開發(fā)人員結(jié)對的過程中雨女，幫助開發(fā)人員分析業(yè)務(wù)場景的分支谚攒，來確保單元測試覆蓋的是正確的場景，而不是為了交代上級隨便亂寫的單元測試氛堕，這也可以幫助QA熟悉代碼馏臭，提高編碼能力。

image.png

當(dāng)開發(fā)人員完成編碼工作后讼稚，這時QA括儒、UX浪耘、BA、開發(fā)人員一起檢查用戶故事塑崖，是否按照用戶故事來檢查是否完成對應(yīng)的功能七冲。UX也可發(fā)表對用戶故事UI以及交互的一些看法，有任何問題及時討論后规婆，將問題盡早的反饋給客戶澜躺。

image.png

當(dāng)開發(fā)人員交付一部分功能之后，QA就可以做常規(guī)的用戶故事測試抒蚜，幾個迭代之后掘鄙，QA開始進(jìn)行跨功能需求測試和探索性測試等。根據(jù)探索性測試的結(jié)果嗡髓，QA可能會調(diào)整測試策略操漠，調(diào)整測試優(yōu)先級，完善測試用例等等饿这。

image.png

上面這些QA實(shí)踐貌似已經(jīng)很完美,其實(shí)還差最重要的一環(huán)：uality Analysis 浊伙。每次發(fā)布后，我們總以為我們發(fā)布了一個完美的產(chǎn)品长捧，但卻總能在新迭代開發(fā)過程中發(fā)現(xiàn)之前存在的問題嚣鄙，歷史總是驚人的相似，為什么串结，沒有分析總結(jié)問題哑子，以及相應(yīng)的預(yù)防手段，那么同樣的問題只會重現(xiàn)肌割。

同時我們也要回顧下自己在工作中真的將這些敏捷實(shí)踐都應(yīng)用到工作中了嗎卧蜓？我想或多或少的都有所欠缺。對于一個QA來說把敞，不應(yīng)循規(guī)蹈矩照搬敏捷實(shí)踐弥奸。例如，在kick off中先巴，發(fā)現(xiàn)開發(fā)人員其爵、UX對用戶故事涉及的場景以及內(nèi)容了解不清楚，QA也可能漏掉一些測試場景伸蚯，那么我們可以在kick off之前摩渺，加入一個pre-kick off的實(shí)踐，留出時間剂邮，讓每個角色都能夠完整了解用戶故事摇幻。在kick off之中，UX沒有辦法完整的確認(rèn)頁面的字體大小或者顏色等是否正確，那么在sign off之后绰姻，我們也加入一個UX-test實(shí)踐枉侧，幫助UX更好解決這些問題。

所以每個項(xiàng)目也應(yīng)都有適合自己項(xiàng)目的敏捷實(shí)踐狂芋，發(fā)現(xiàn)項(xiàng)目存在的問題榨馁，持續(xù)改進(jìn)才是最佳實(shí)踐。

再來談?wù)勛詣踊瘻y試

image.png

上面的測試金字塔對于大家來說再熟悉不過了帜矾，對于自動化測試來說最有價值的仍然是單元測試翼虫，但對于QA來說無疑最復(fù)雜的。

大部分QA或者tester屡萤，仍然以UI自動化為重心珍剑。之所以反對盲目的UI自動化測試，是因?yàn)樽兓l繁的UI設(shè)計(jì)死陆，投入產(chǎn)生比極低招拙，這都應(yīng)該讓我們重新思考下UI自動化的價值。

我們需要一個實(shí)施UI自動化的正確方式：

• 能不用UI自動化測試就不用措译，梳理業(yè)務(wù)主線别凤，只保留用戶操作最頻繁、交互最多的場景瞳遍。
• 根據(jù)面向?qū)ο笤O(shè)計(jì)的原則闻妓，構(gòu)建適合項(xiàng)目的UI自動化框架，無論自己編寫框架掠械，還是采用開源框架。
• 盡量采用獨(dú)立測試數(shù)據(jù)注祖，確保運(yùn)行測試不受影響猾蒂。例如采用mock數(shù)據(jù)庫或者每次運(yùn)行時還原測試數(shù)據(jù)庫。

回到正題是晨，面對自動化測試的大潮肚菠，QA應(yīng)該關(guān)注什么？

• 編碼規(guī)范罩缴。這是個真實(shí)例子蚊逢，開發(fā)人員對于類名命名沒有用Camel-Case，造成在Linux系統(tǒng)中部署不成功箫章，Python中亂使用縮進(jìn)等烙荷。其實(shí)這些都可以避免，例如開發(fā)工具加入自動檢查檬寂，或者在CI上加入校驗(yàn)編碼規(guī)范的步驟终抽，采用一些工具就可以達(dá)到目的，比如jshint，RuboCop等昼伴。
• 結(jié)對完成單元測試或API測試等匾旭，一方面可以提高QA的編碼能力，另一面可以給出開發(fā)人員一些建議圃郊，將單元測試覆蓋到更多的場景价涝。

例如，如果你們項(xiàng)目采用React作為前端框架持舆，如果你不能理解React virtual dom 與jsx色瘩，當(dāng)我們在寫UI自動化腳本時，你會發(fā)現(xiàn)根本無法進(jìn)行下去吏廉，日常中我們需要定位的元素全是這樣：

<div class="styles__formField___1fyGy">
    <input type="text" placeholder="Email">
    <svg class="styles__formIcon___37VGd" viewBox="0 0 24 24" style="display: inline-block; fill: rgba(0, 0, 0, 0.870588); height: 24px; width: 24px; user-select: none; transition: all 450ms cubic-bezier(0.23, 1, 0.32, 1) 0ms;">
        <path d="M12 12c2.21 0 4-1.79 4-4s-1.79-4-4-4-4 1.79-4 4 1.79 4 4 4zm0 2c-2.67 0-8 1.34-8 4v2h16v-2c0-2.66-5.33-4-8-4z">
        </path>
    </svg>
</div>
`</pre>

所有的頁面都是js渲染出來的泞遗，如果你懂jsx，就知道只需要在對于的Component render方法中更改加入id等元素就可以搞定席覆。
<pre>`render() {
    return (
        &lt;div&gt;
            &lt;input type="text" placeholder="Email" id="Email"&gt;
        &lt;/div&gt;
    )
}

控制單元測試覆蓋率史辙，100%的單元測試覆蓋率當(dāng)然是最好的，但如果交付壓力大佩伤，和客戶商量后聊倔，我們可以盡量覆蓋業(yè)務(wù)主線，而不是為了達(dá)到覆蓋率延誤了交付周期生巡。

再來談?wù)勝|(zhì)量分析

作為一個QA耙蔑，我們不僅要檢測項(xiàng)目中存在的問題，也要改進(jìn)團(tuán)隊(duì)的實(shí)踐活動孤荣，更重要的是預(yù)防問題的發(fā)生甸陌。

• 每次bug bash或相應(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)我們對某些模塊的前端代碼進(jìn)行了重構(gòu)雾棺，但缺乏相應(yīng)的單元測試與集成測試工秩，造成了我們沒有及時發(fā)現(xiàn)bug。之后我們就對應(yīng)的采取措施防止問題再現(xiàn)。
• 總結(jié)分析報(bào)告克伊，及時反饋這些信息給團(tuán)隊(duì)季春∧旒眨總結(jié)分析是一個長期的任務(wù)逞刷，每次bug數(shù)量的變動夸浅，都會直接體現(xiàn)整個團(tuán)隊(duì)上次迭代的開發(fā)質(zhì)量，例如bug數(shù)量減少了，可以鼓勵成員再接再厲÷澈溃或者某幾次迭代某些模塊bug呈上升趨勢，那么就需要組織團(tuán)隊(duì)一起討論問題根源洋丐，采取措施防止問題重現(xiàn)呈昔。
• 利用代碼質(zhì)量分析工具，幫助我們盡早預(yù)防問題的發(fā)生友绝。例如Sonar代碼質(zhì)量管理平臺堤尾，可以幫助我們從代碼復(fù)雜度，重復(fù)代碼迁客，單元測試覆蓋率郭宝，編碼規(guī)范等緯度來分析代碼所存在的問題。當(dāng)然也有其他的開源工具掷漱，像RubyCritic粘室，/plato不同的語言都會有相應(yīng)的工具。
• 在線監(jiān)控卜范，利用像newrelic衔统，airbrake等監(jiān)控工具對部署在本地或在云中的Web應(yīng)用程序進(jìn)行監(jiān)控、故障修復(fù)海雪、診斷锦爵、線程分析以及容量計(jì)劃。這樣不管產(chǎn)品環(huán)境有任何問題奥裸，我們都能及時響應(yīng)险掀，盡早修復(fù)，減低損失湾宙。

最后讓我們再看看QA應(yīng)具有那些能力與技能

image.png

image.png

軟技能方面包括風(fēng)險控制樟氢、輔導(dǎo)他人冈绊、溝通能力、分析定位等埠啃。技能方面則包括缺陷管理死宣、流程改進(jìn)、測試分析霸妹、可用性測試十电、性能測試、安全測試等叹螟。

寫在最后

回顧上述實(shí)踐鹃骂，其實(shí)我們可以做的更好，而不是把團(tuán)隊(duì)的質(zhì)量全都交給自動化罢绽，回歸QA的應(yīng)有的初心畏线，讓我們從各個方面改進(jìn)質(zhì)量，帶給團(tuán)隊(duì)更好的未來良价。