迄今為止，敏捷開發(fā)方法在各個公司都有了長足的發(fā)展，曾經(jīng)的測試人員慢慢的在向QA職能過渡，但依然很多人不了解QA和測試的區(qū)別是什么。

敏捷實踐不斷地演化過程，使項目中各個角色不斷弱化，同時，對每個成員的要求也越來越高?！叭δ軋F隊”的提出，不單單是對開發(fā)的要求，對QA來說，想要在快速變革中具備競爭力，就現(xiàn)在所具備的技能來說，還是遠遠不夠的。

簡單聊聊我所經(jīng)歷的“QA發(fā)展史”

QA 1.0 —— 機械化流水線作業(yè)

在我實習的那年，軟件領(lǐng)域還很少提及QA，伴隨著瀑布模型的興起、軟件工程規(guī)模的不斷擴大以及市場對軟件質(zhì)量要求的提高，催生出了“測試工程師”這樣一個角色。那時他們的職能很單一，每天的工作就是在各種測試環(huán)境中按照詳細設(shè)計的文檔，編寫測試用例，并逐條測試，檢查功能完整性，發(fā)現(xiàn)軟件中可能出現(xiàn)的功能缺陷，并進行追蹤。

這個時期是軟件測試的原始時期，對測試人員的技能要求不高，只要對文檔理解透徹，做事細心，是很容易勝任的。此時的產(chǎn)出和交付物可度量，雖然如此，測試工程師只是執(zhí)行者，能力和價值都無法最大化，卻被每天重復(fù)的工作所累。

QA 2.0 —— 過程化帶來不同的工作內(nèi)容和價值體現(xiàn)

我畢業(yè)的時候，開始接觸敏捷方法，團隊規(guī)模從百人變成了僅有十人左右，信息平等取代了逐級傳遞，分散的信息源（ 客戶的每一封郵件和每一句對話都可能是我們將要做的功能 ）取代了幾十甚至百頁的文檔，測試不再僅是提出軟件缺陷和編寫、執(zhí)行測試用例，而是成為了團隊的數(shù)據(jù)庫和字典。

當用戶提出一個功能的時候，測試人員可以快速的進行需求分析，回顧并確定是否與此前的功能有沖突。當開發(fā)人員對某一塊業(yè)務(wù)不了解的時候，測試人員也可以組織會議進行闡明。由于對業(yè)務(wù)和客戶的深入了解，測試人員可以為客戶提出建設(shè)性意見和功能，有時也會是做出決策的人。

高效、頻繁的溝通，大大提升了QA的軟技能。此時的測試人員已經(jīng)過程化，對軟件質(zhì)量的理解，從“發(fā)現(xiàn)缺陷”提升到“對軟件開發(fā)過程的質(zhì)量控制和風險預(yù)估”，我們定義這樣的測試工程師為QA。

QA 3.0 —— 自動化技能提高生產(chǎn)力

隨著工程實踐的日益成熟，QA的角色和工作日益復(fù)雜，這使得他們在大量重復(fù)、繁雜的工作與更有意義的角色之間頻繁切換，這對軟件質(zhì)量也產(chǎn)生了一定影響。

QA從開始的手工測試、探索性測試等手段，逐漸發(fā)展成為可以利用工具和程序?qū)y試進行快速的回歸，對軟件性能進行有效監(jiān)控，無論是前端還是后端、web應(yīng)用還是移動平臺。這使得自己從繁雜的重復(fù)性工作中解脫出來，去做更有意義的事情。他們通過項目的積累以及團隊成員的幫助，對測試技術(shù)有了一定的認識。

QA 4.0 —— 角色向多技能、服務(wù)化轉(zhuǎn)型

記得幾年前，前公司領(lǐng)導對我說，“不管開發(fā)換了什么技術(shù)棧，你做的自動化框架都可以繼續(xù)使用，對你來說沒有任何影響?！碑敃r我也贊同，認為框架已經(jīng)足夠好，可以適用于任何場景和業(yè)務(wù)。

從某個角度來說確實是這樣， 測試相對于開發(fā)技術(shù)的指數(shù)級發(fā)展，平穩(wěn)的太多。不論是在互聯(lián)網(wǎng)還是移動互聯(lián)網(wǎng)時代，緩慢的發(fā)展速度給了我們一種太平盛世的錯覺，似乎我們掌握的技術(shù)足夠坐吃幾年。

來到ThoughtWorks之后，我發(fā)現(xiàn)了類似的事情，不論是在交付還是咨詢的過程中，會有意無意中推一些我們認為的最佳實踐，當遭到客戶質(zhì)疑和challenge的時候，我們似乎很沮喪。

在北京出差的日子，有幸做了一次咨詢，雖然只有幾天，讓我學到一件事，我們認為的最佳實踐和方法，并不完全適應(yīng)于所有場合，尤其是在我們這樣的咨詢公司，對客戶實施怎樣的方案，取決于客戶的領(lǐng)域、產(chǎn)品/項目特性、用戶群、技術(shù)水平、政治文化、技術(shù)棧以及目標和期望等等。

如果對于“最佳實踐”過于堅持，也會影響客戶關(guān)系和咨詢效果。之后咨詢同事講的幾個故事也似乎讓我認識到，雖然我們對現(xiàn)在的工作和技能足夠的熟練，但依然不夠。

我們似乎還需要具備以下的能力：

1.嘗試用不同的方法寫“茴”

經(jīng)驗豐富的QA對于測試技術(shù)中的關(guān)鍵點都爛熟于心， 除了我們正在使用的方案和技術(shù)，嘗試用不同的語言、框架去實現(xiàn)關(guān)鍵點和難點。這樣的好處在于，我們可以通過深入的學習和使用，對流行方法、過程和框架進行比較，了解各自的優(yōu)勢和劣勢，不但可以增強自身的技能，當面對不同客戶的時候，也可以給出客觀的分析，為客戶提供精準服務(wù)，同時如果可以對客戶現(xiàn)有的技術(shù)和方案、流程和方法提供有價值的意見，也可以提高在客戶現(xiàn)場的生存率，輕松俘獲客戶。

2.If you cannot test it, dev it.

軟件過程中，QA可以在需求分析和定義階段介入，為項目提供不可估量的價值，但另一方面，QA技能實踐（此處指Tech）是一個相對受限的領(lǐng)域，我們很難繞過未實現(xiàn)的代碼和工程去做更多的事情。

你可能會說，“沒有做過mobile的項目，如何去學習移動端的測試技能？”如果恰好你對行業(yè)的發(fā)展具有前瞻性和敏感度，例如你可能認為IoT和VR是一個趨勢，你卻沒有機會去這樣的項目中做QA。

那么我們是不是可以像開發(fā)一樣，提升自己的學習能力和適應(yīng)力，保持對技術(shù)的敏感度和熱忱，了解不同技術(shù)領(lǐng)域，對該領(lǐng)域的開發(fā)、測試、構(gòu)建和集成部署都有一定的了解？所以，如果你想比其他人走的快那么一點，go dev!

3.真正的全功能

QA的領(lǐng)域雖然相對受限，但幸運的是角色相對不受限。在日常的開發(fā)過程和項目積累過程中，不但能對業(yè)務(wù)有深刻的理解、對用戶行為有獨到的見解，而且對技術(shù)也有一定的認識。

在需求分析過程中，QA總是可以從技術(shù)和業(yè)務(wù)結(jié)合的角度扮演好一個BA的角色，成為一個優(yōu)秀的PM，甚至我們可以在客戶提出一些需求的時候嘗試著從一個UX的角度去設(shè)計原型，如果具備前端的能力，也可以自己去Dev、UI，不斷拓展自己的技能領(lǐng)域，使自己成為真正的全功能。

總結(jié)

真正的全功能，并不是單純意義上讓QA去做Dev，而是最大程度弱化角色的概念，逐步強調(diào)和培養(yǎng)技能多元化。如何把對需求的理解能力強化為業(yè)務(wù)分析能力，把質(zhì)量控制能力強化為項目管理能力。強化自身的優(yōu)勢，跳出自己的舒適區(qū)，使自己能夠輕松勝任。這樣我們才不會在看到去QA和QA消亡之類的觀點后，無所適從。

更多精彩洞見，請關(guān)注微信公眾號：ThoughtWorks