高效的敏捷测试第三课 测试人员的选择
第06講：敏捷團(tuán)隊究竟要不要專職的測試人員？
問題的提出及各方理由
隨著 Fackbook 和 Google 在商業(yè)上取得的巨大成功，他們的開發(fā)模式引起了廣泛的討論，并且和敏捷掛上了鉤，同時引來了“敏捷團(tuán)隊需不需要專職的測試人員？”這樣有爭議的問題。人的問題是最關(guān)鍵的問題，所以我們有必要在這里討論一下。
首先要澄清的是，這里要討論「需不需要專門做測試（測試計劃、分析 / 設(shè)計、執(zhí)行）的人？」，和頭銜無關(guān)。因為我知道現(xiàn)在很多公司開發(fā)和測試都叫“軟件工程師”，但有一部分就是專職做測試工作的，還有一些公司叫 QA（Quality Assurance），但做的是測試的活兒。
很多人認(rèn)為需要，也有很多人認(rèn)為不需要。在敏捷和 DevOps 實踐中，也都能找出支持這些不同觀點的成功案例，看起來似乎要形成兩大陣營。
Etsy 公司在 2009 年開始引入 DevOps，建立了持續(xù)交付的全自動化部署管道，這家公司既有專職的 QA 人員又有專門的 QA 團(tuán)隊，他們做具體的測試工作。
微軟和 Facebook 只在有些業(yè)務(wù)線保留了少量的專職測試人員，多數(shù)業(yè)務(wù)線則根本沒有，測試團(tuán)隊更不存在。Google 則把測試團(tuán)隊改造為 Engineering Productivity（工程效能）團(tuán)隊，不為產(chǎn)品做測試，而是為開發(fā)人員提供測試工具和技術(shù)。
那么，軟件測試行業(yè)一些大師級人物的觀點如何呢？
Alan Page 和 Brent Jensen 提出了現(xiàn)代測試七大原則（Modern Testing Principle）。其中第七條：把測試的方法和能力擴(kuò)展到整個團(tuán)隊，并認(rèn)同團(tuán)隊會逐漸減少或取消專職的測試專家存在。他們認(rèn)為測試人員的責(zé)任是指導(dǎo)團(tuán)隊建立更成熟的質(zhì)量文化，專職的測試人員將會減少甚至取消。
而 Lisa Crispin，也就是《敏捷測試》這本書的作者之一，雖然也認(rèn)同敏捷團(tuán)隊中專職的測試人員可以減少（她給出的例子顯示，開發(fā)和專職測試的比例是 10:1），但是至少要保留一位測試專家做一些專業(yè)性強(qiáng)的測試，因為開發(fā)人員思考問題的角度和測試不同。而國內(nèi)有很多關(guān)于這個問題的討論文章，大多數(shù)會根據(jù)自己的切身體會表示贊同或反對。
對于“不需要專職的測試人員”這個觀點，理由大概有以下幾點：
質(zhì)量不等于測試，質(zhì)量是內(nèi)建的，不是測出來的，開發(fā)應(yīng)該對自己的代碼質(zhì)量負(fù)責(zé)。
我們不需要不懂軟件開發(fā)的手工測試，因為不懂開發(fā)就做不好測試。
測試和開發(fā)分開會造成工作效能的低下，開發(fā)人員自行做相應(yīng)的測試會提高效率。
很多偉大的產(chǎn)品都是出自沒有或很少測試人員的團(tuán)隊。
自動化程度低的活就是體力勞動，開發(fā)很快就能掌握測試用例設(shè)計的技能。
而反方觀點的理由大致如下：
需要測試領(lǐng)域?qū)＜?#xff0c;一個人不可能什么都會。
開發(fā)做測試有思維障礙和心理障礙，做不好測試。
開發(fā)人員太“貴”，讓開發(fā)做測試的活兒，公司會增加比較大的成本。
存在即合理，護(hù)士的活兒醫(yī)生肯定可以干吧？為啥醫(yī)院還要那么多護(hù)士？
企業(yè)級軟件一般都很龐大、復(fù)雜，功能、業(yè)務(wù)邏輯太多，而每個開發(fā)做的東西都比較小、比較窄，缺乏業(yè)務(wù)視野的廣度和深度。
到底要不要專職的測試人員
我的觀點是：要基于上下文來決定要不要專職的測試人員，需要根據(jù)具體情況來分析。
“敏捷團(tuán)隊究竟要不要專職的測試人員？”答案不只是：“要”或“不要”，否則會落入問題的陷阱。我經(jīng)常會問學(xué)生，“結(jié)構(gòu)化測試方法中，判定覆蓋強(qiáng)呢？還是條件覆蓋強(qiáng)呢？”，許多學(xué)生會脫口而出“條件覆蓋強(qiáng)”，也有回答“判定覆蓋強(qiáng)”。這樣問其實很容易讓人上當(dāng)，或者說，不應(yīng)該這樣問。
要不要專職的測試人員？不能簡單說，手機(jī) App 之類的應(yīng)用都不需要，電信、銀行、航天 / 航空、醫(yī)療等系統(tǒng)則一定需要；也不能簡單說，團(tuán)隊給力、人員素質(zhì)好，而軟件產(chǎn)品本身質(zhì)量要求又不高，就不需要什么專職的測試人員。
首先要看開發(fā)愿不愿意做測試、能不能做測試？不愿做、不能做，那自然需要專職的測試人員。強(qiáng)迫開發(fā)做測試是不行的，這樣做效果也不好，人們常說：上有政策下有對策。過分強(qiáng)迫的話，開發(fā)會走人的。
其次，要看系統(tǒng)是不是關(guān)鍵系統(tǒng)？有些系統(tǒng)是性命攸關(guān)的，不能有半點閃失，關(guān)鍵業(yè)務(wù)系統(tǒng)對質(zhì)量風(fēng)險的容忍度近乎等于零，即使開發(fā)素質(zhì)高、責(zé)任心強(qiáng)、能做測試，一般還是需要獨(dú)立專職的測試工程師，以增加一道防線。
最后，還要看這個系統(tǒng)是否要部署到客戶那里？如果是，則版本更新很困難，出了問題也無法回滾，無法支持灰度發(fā)布，這時對質(zhì)量會苛刻很多，類似上面情形，一般也需要專職的測試人員。所以，至于要不要專職的測試人員，則需要綜合考慮下列主要因素：
團(tuán)隊情況：組織文化、人員素質(zhì)和技能等；
產(chǎn)品運(yùn)營模式，是 2B 還是 2C，是 SaaS 模式還是傳統(tǒng)產(chǎn)品模式；
是否為關(guān)鍵業(yè)務(wù)系統(tǒng)，即是否是使命攸關(guān)系統(tǒng)（如金融、電信等核心處理系統(tǒng)）或性命攸關(guān)系統(tǒng)（如航空、航天、核工業(yè)等核心系統(tǒng)）。
有時還需要考慮系統(tǒng)是否強(qiáng)耦合、是否是大規(guī)模的復(fù)雜系統(tǒng)等。
其實不論有沒有專職測試，都不違背敏捷價值觀和敏捷原則。根據(jù)國際敏捷聯(lián)盟（Agile Alliance）的定義，敏捷團(tuán)隊?wèi)?yīng)該具備軟件交付所需要的所有能力，而角色和責(zé)任的劃分與團(tuán)隊輸出結(jié)果——“快速交付可工作的軟件”相比并不重要，開發(fā)人員可以做測試，業(yè)務(wù)分析師或領(lǐng)域?qū)＜铱梢蕴岢鲫P(guān)于技術(shù)實現(xiàn)的想法。同樣，測試人員也可以做開發(fā)或需求分析。
敏捷模式下強(qiáng)調(diào)的是整個團(tuán)隊對可交付軟件的質(zhì)量負(fù)責(zé)、對測試負(fù)責(zé)，強(qiáng)調(diào)團(tuán)隊協(xié)作，發(fā)揮團(tuán)隊的作用。當(dāng)團(tuán)隊越來越具有很強(qiáng)的敏捷思維方式和相應(yīng)的能力時，可以考慮逐漸減少專業(yè)測試人員。
什么情況下可以考慮沒有專職的測試人員呢？
團(tuán)隊質(zhì)量內(nèi)建的文化已經(jīng)形成，敏捷測試思維 / 價值觀構(gòu)建完畢，團(tuán)隊成員技術(shù)能力和責(zé)任感表現(xiàn)優(yōu)秀；
軟件運(yùn)營模式是 SaaS 模式，并擁有灰度發(fā)布機(jī)制，能做到快速部署、快速回滾；
不屬于關(guān)鍵的業(yè)務(wù)系統(tǒng)。
如果沒有專職的測試人員應(yīng)該如何做
接下來我們先討論沒有專職的測試人員應(yīng)該如何做，已經(jīng)購買專欄的你應(yīng)該是專職的測試工程師了，對于我們討論的這個話題，不知道作何感想，歡迎留言討論。
首先，想請你回顧一下第 3 講中的“成長性思維”，你的能力是可以通過努力培養(yǎng)的，而敏捷團(tuán)隊對成員個人的能力要求更高。這對個人發(fā)展是好事。
我想到一個比喻：一個團(tuán)隊里集合了一群內(nèi)外兼修的武林高手，團(tuán)隊需要十八般武器都有人會，而且每個人至少要會幾種，這難不倒這群高手，有人原來會使劍，但通過訓(xùn)練，他也能用刀，甚至是棍。雖然他最擅長的還是使劍，但需要用刀的時候，對付一般人也綽綽有余，沒有刀劍怎么辦？在路邊隨手找一個棍，也能參與戰(zhàn)斗。之后，他發(fā)現(xiàn)自己的劍術(shù)更加精進(jìn)，已經(jīng)可以做到一劍封喉的地步。
這就像測試人員掌握了編程能力，在測試方面可以更加自如地選擇不同測試技術(shù)和測試工具，而開發(fā)人員通過參與測試，在代碼開發(fā)階段就會想到如何避免缺陷的產(chǎn)生。所以，沒有技術(shù)上的廣度，也就達(dá)不到技術(shù)上的深度。
相比傳統(tǒng)測試，敏捷模式對整個團(tuán)隊測試能力的要求也會更高，讓開發(fā)做測試，或讓整個團(tuán)隊做測試是可以，但不能不管做的如何。如果開發(fā)做測試效率低、質(zhì)量沒有保證，那這種改變就不是進(jìn)步，而是倒退。在沒有專職測試的情況下，我們需要關(guān)注的是敏捷團(tuán)隊的整體測試能力。測試和開發(fā)的融合意味著測試的能力將成為整個團(tuán)隊的內(nèi)在能力，敏捷測試思維和文化將成為整個團(tuán)隊的共同文化。
我在《全程軟件測試》（第3版）第 4 章中，曾經(jīng)討論過如何建立整個研發(fā)團(tuán)隊的測試能力，這在敏捷團(tuán)隊里仍然有效。現(xiàn)在簡單回顧一下 Google 所描述的團(tuán)隊“測試認(rèn)證”模型，如表 1 所示，這個模型帶有 Google 的特色，比如將測試分為三級：小型測試（類似單元測試）、中型測試和大型測試。不過，研發(fā)團(tuán)隊仍然可以按照這種測試能力模型的思路去規(guī)劃如何提高。
表1 Google 測試能力認(rèn)證的 5 種級別
這個模型側(cè)重要求了對測試的認(rèn)知、冒煙測試、集成測試、單元測試等，但對 TDD / ATDD 沒有要求，對團(tuán)隊測試要求也不算很高，到了級別 5，單元測試覆蓋率要求也只是“不低于 40%”，整體測試覆蓋率不低于 60%。而且這種覆蓋率如何度量？是指代碼行覆蓋率嗎？其次，靜態(tài)測試拖到級別 5 才做要求，這也是這個模型的問題之一。
需要注意的是，上面介紹的測試能力認(rèn)證模型是 Google 基于 2013 年以前的測試實踐總結(jié)的，如今 Google 已經(jīng)成功引入了 DevOps，情況應(yīng)該和 8 年前的不一樣了。
單元測試和靜態(tài)測試
我們在后面的內(nèi)容里會講 TDD / ATDD，這里先講一下單元測試和靜態(tài)測試，這兩個都屬于軟件測試最基本的實踐。單元測試是指對軟件基本組成單元進(jìn)行的測試，而且和編程同步進(jìn)行，可以盡早發(fā)現(xiàn)程序問題；而靜態(tài)測試的對象不僅是代碼，還包括需求定義和設(shè)計文檔等。兩者都可以有效地幫助團(tuán)隊盡早發(fā)現(xiàn)軟件缺陷，但是目前根據(jù)調(diào)查結(jié)果可知，二者在很多研發(fā)團(tuán)隊中推進(jìn)的效果仍然不太理想。
ThoughWorks 公司官方公眾號有一些文章介紹了他們關(guān)于單元測試和靜態(tài)測試的實踐：“在 ThoughtWorks，先寫單元測試是程序員的基本素養(yǎng)，代碼走查形式多樣，但成熟團(tuán)隊一般都從單元測試開始。敏捷開發(fā)對回歸測試考慮不多，質(zhì)量內(nèi)建意味著不希望最后靠測試把質(zhì)量關(guān)。”這說明單元測試和靜態(tài)測試做好了，系統(tǒng)測試和回歸測試就可以少做、甚至不做。
另外，前面說過的 Etsy 公司每次在部署前都需要自動運(yùn)行 30 個測試集（單元測試、集成測試、功能測試、冒煙測試……），而所有這些測試在 5 分鐘內(nèi)完成，以確保開發(fā)人員得到快速反饋。每天在 CI 環(huán)境里要運(yùn)行超過 14000 個測試集，而且他們的 QA 也不做回歸測試。
這個案例在下一講中還會繼續(xù)討論，因為我們正好要講敏捷團(tuán)隊有專職測試人員的情況。
最后，給你出一道思考題：你認(rèn)為敏捷團(tuán)隊需不需要專職的測試人員呢？你的理由是什么？歡迎留言討論。
第07講：如果有專職的敏捷測試人員，他們的職責(zé)是什么？
我們第 6 講討論的是沒有專職測試人員的情況，這一講主要討論有專職測試人員的情況。相信購買這個專欄的同學(xué)，大多數(shù)是專職測試人員，所以大家對這個話題會更感興趣，對吧？
Etsy 公司的優(yōu)秀實踐：測試人員能做、應(yīng)該做的事
關(guān)于敏捷測試人員的職責(zé)，讓我們先來看一下來自 Etsy 公司 QA 團(tuán)隊在這方面的優(yōu)秀實踐。Etsy 公司創(chuàng)建于 2005 年，是美國的一家電商平臺，以手工藝品買賣為主要特色，在初創(chuàng)期經(jīng)歷了 IT 架構(gòu)和組織架構(gòu)的摸索，直到 2008 年，新來的 CTO 開始引入 DevOps 和社區(qū)文化。經(jīng)過幾年的打磨，Etsy 在 2014 年英國的 QCon（全球軟件開發(fā)）大會上曾經(jīng)介紹他們是如何做到一天完成 50 次線上部署的（這在當(dāng)時已經(jīng)很了不起了），可以說一戰(zhàn)成名。
那么他們是怎么做到的呢？
首先，公司建立了優(yōu)秀的工程師文化：他們的口號是“代碼即藝匠（Code as Craft）”，認(rèn)為工程師是一個有創(chuàng)造力的群體，互相鼓勵交流、協(xié)作，鼓勵學(xué)習(xí)。公司定期舉行技術(shù)沙龍，邀請各行業(yè)的專家進(jìn)行交流分享。
其次，公司建立了優(yōu)秀的質(zhì)量內(nèi)建文化：開發(fā)階段的測試由開發(fā)負(fù)責(zé)。 通過一鍵式部署管道，開發(fā)人員可以直接部署代碼到生產(chǎn)環(huán)境上，但在部署前需要保證自己的代碼是穩(wěn)定的。在公司的 CI 環(huán)境里集成了超過 30 個自動化測試集。另外公司還建立了 KPI 面板量化跟蹤自動化測試的代碼覆蓋率。
和 Facebook、Google 這些公司的實踐不同的是，Etsy 有獨(dú)立的 QA 團(tuán)隊，為所有項目提供了服務(wù)。到這里我想問問你平時都做什么具體測試呢？開發(fā)階段的測試、回歸測試、為得到測試通過率指標(biāo)進(jìn)行的測試、維護(hù)測試用例集，這些應(yīng)該都是你的日常工作吧？但 Etsy 的 QA 團(tuán)隊這些都不做！
下面才是這個團(tuán)隊要做的事情：
針對新功能和新產(chǎn)品進(jìn)行探索式測試、集成測試及跨平臺的兼容性測試；
針對移動端的發(fā)布進(jìn)行驗證測試；
驗證用戶可感知的改變。
QA 團(tuán)隊還建立了團(tuán)隊的價值觀：價值驅(qū)動、目標(biāo)賦能和社區(qū)文化。
對此我的解讀是這樣的：
價值驅(qū)動，就是做 QA 該做的事，不為測試而測試，不會為了出統(tǒng)計數(shù)據(jù)而做測試；
目標(biāo)賦能，全公司范圍內(nèi)以業(yè)務(wù)為共同目標(biāo)，維護(hù)共同的質(zhì)量文化，業(yè)務(wù)驅(qū)動測試；
社區(qū)文化，鼓勵學(xué)習(xí)型文化，促進(jìn)公司范圍內(nèi)的溝通和交流，共同學(xué)習(xí)、共同進(jìn)步。
可以說 Etsy 公司從企業(yè)文化、價值觀，再到技術(shù)、工作流程、基礎(chǔ)設(shè)施都建立了一整套行之有效的敏捷及敏捷測試實踐方法，確實值得學(xué)習(xí)。
敏捷測試人員的責(zé)任和具體任務(wù)
對照?Etsy?公司的 QA 團(tuán)隊，我們來總結(jié)一下，測試人員在敏捷團(tuán)隊中需要承擔(dān)的責(zé)任和具體任務(wù)主要有以下 4 點。
（1）幫助敏捷團(tuán)隊提升質(zhì)量文化，持續(xù)關(guān)注質(zhì)量和用戶需求，持續(xù)向相關(guān)利益者提供質(zhì)量反饋
用戶需求是軟件測試非常重要的上下文之一，測試人員要幫助團(tuán)隊開發(fā)出客戶真正需要的產(chǎn)品，避免陷入過多的、從技術(shù)方面思考問題的誤區(qū)。不知是否還記得微軟曾經(jīng)在 Windows 8 上面拿掉了左下角的開始按鈕和開始菜單，很多用戶因此根本找不到關(guān)機(jī)和重啟電腦的地方，在用戶的強(qiáng)烈抗議下，微軟最終還是徹底召回了大家平時習(xí)慣的開始菜單。這就是從技術(shù)角度而非用戶角度開發(fā)產(chǎn)品的一個失敗案例。
另外，對產(chǎn)品的質(zhì)量要求也是一個重要的測試上下文，不僅要清楚每次交付的質(zhì)量要求是什么，而且還要清楚每次迭代相比上一次有什么變化。
在具體的測試任務(wù)方面，測試人員更側(cè)重從用戶角度對產(chǎn)品進(jìn)行質(zhì)量評估，采用探索式測試方式執(zhí)行功能交互測試和貫穿業(yè)務(wù)流程的 E2E 測試，并開展易用性、兼容性和可靠性、性能和安全性等方面的專項測試。
測試人員可以不參與開發(fā)階段的測試，但是需要對產(chǎn)品的每一迭代版本進(jìn)行驗收測試。例如，Zoom 公司的開發(fā)完成新功能測試，而回歸測試則由專職測試人員來做，相當(dāng)于代碼凍結(jié)后進(jìn)行最后的回歸測試——驗收測試。
這項責(zé)任對應(yīng)的具體任務(wù)包括：
獲取和明確用戶的質(zhì)量期望
建立合適的系統(tǒng)測試、驗收測試的質(zhì)量標(biāo)準(zhǔn)
（和 PO）完成每個迭代的驗收測試
保持質(zhì)量度量結(jié)果的可視性
發(fā)現(xiàn)值得關(guān)注的測試切入點，持續(xù)提供質(zhì)量反饋
在線日志分析、在線測試
拜訪客戶、用戶調(diào)查等活動
（2）制定測試計劃，指導(dǎo)團(tuán)隊使用合適的測試技術(shù)和方法，不斷收集反饋，改進(jìn)、推廣測試技術(shù)和方法，積累軟件測試實踐
敏捷測試人員（第 8 講將會介紹 Test Owner 角色）負(fù)責(zé)為團(tuán)隊制定測試計劃。敏捷測試中測試計劃可以短，但不能沒有，比如只有一頁紙，其形式可以靈活，比如用思維導(dǎo)圖等。我在模塊 5 中會詳細(xì)講。
測試人員需要負(fù)責(zé)向團(tuán)隊傳授測試技術(shù)和經(jīng)驗，以幫助整個團(tuán)隊持續(xù)提高測試能力，比如指導(dǎo)開發(fā)在單元測試和系統(tǒng)測試中使用合適的測試技術(shù)和方法。需求、設(shè)計、代碼評審需要全體成員參與，并且收集反饋，持續(xù)改進(jìn)。
這項責(zé)任對應(yīng)的具體任務(wù)包括：
制定測試計劃模板、風(fēng)險列表（Checklist）和常見的測試策略
探索新的測試方法，引入新的測試技術(shù)
開發(fā)更有效的測試工具，持續(xù)改進(jìn)自動化測試（TA）
通過缺陷根因（Root Cause）分析獲得避免缺陷的信息，設(shè)立規(guī)則和實踐避免缺陷引入
（3）幫助團(tuán)隊構(gòu)建自動化測試基礎(chǔ)設(shè)施，提供必要的測試工具
這項工作你應(yīng)該比較熟悉了，很多公司熱衷招聘測試開發(fā)崗位，主要承擔(dān)的就是這項工作。敏捷測試人員不僅為團(tuán)隊構(gòu)建了自動化測試環(huán)境，還要考慮自動化測試框架和持續(xù)集成（CI）環(huán)境以及 DevOps 工具鏈的集成。
這項責(zé)任對應(yīng)的具體任務(wù)包括：
推進(jìn)單元測試、開發(fā)測試，盡量將測試推動到上游
建立 CI 框架以及基于 CI 的質(zhì)量控制和發(fā)布規(guī)則
創(chuàng)建更高效的工具，持續(xù)改進(jìn)自動化測試（TA）
（4）可測試性把關(guān)，包括需求、設(shè)計和代碼的可測試性檢查
可測試性的檢查也是敏捷測試人員的一項重要責(zé)任，而且要從需求、設(shè)計開始抓起。產(chǎn)品需求文檔過于簡單，沒有明確的驗收標(biāo)準(zhǔn)、軟件設(shè)計沒有考慮給自動化測試提供接口、代碼的結(jié)構(gòu)復(fù)雜以至于發(fā)現(xiàn)缺陷后很難快速定位問題所在等，這些都會影響軟件產(chǎn)品的可測試性。
敏捷模式有利于可測試性的提高，因為開發(fā)要對自己的代碼進(jìn)行測試，在代碼編寫時，需考慮可測試性。如果先實現(xiàn)單元測試代碼，再開始編寫代碼，就更進(jìn)一步，也就是實現(xiàn) UTDD（單元測試驅(qū)動開發(fā)），但前提是需求的驗收標(biāo)準(zhǔn)是完備和明確的。敏捷開發(fā)模式對文檔不重視，需求文檔和設(shè)計文檔潛在的問題就比較多，測試人員需要在測試計劃中考慮靜態(tài)測試、組織并參加相應(yīng)的評審，和團(tuán)隊成員一起明確用戶故事的驗收標(biāo)準(zhǔn)，提出設(shè)計和代碼方面的可測性需求。
這項責(zé)任對應(yīng)的具體任務(wù)包括：
建立合適的系統(tǒng)測試、驗收測試質(zhì)量標(biāo)準(zhǔn)；
定義需求 / 設(shè)計評審的檢查表（Checklist）；
持續(xù)推動可測試性的提高。
表2 敏捷測試人員責(zé)任和具體任務(wù)（有的任務(wù)放在兩個責(zé)任范圍內(nèi)都合適）
測試人員和開發(fā)的分工
另外，我們再總結(jié)一下敏捷測試人員和開發(fā)人員對測試任務(wù)的具體分工（第 8 講也有一些補(bǔ)充），可以看一下表3，雖然角色及其責(zé)任不一樣，但能更好地幫助你理解這張表。
表3 敏捷測試人員和開發(fā)人員的分工
測試敏捷化對測試組織 / 團(tuán)隊意味著什么
講完測試人員的職責(zé)后，我們再來講一下測試敏捷化對測試組織意味著什么。敏捷模式下，獨(dú)立的測試團(tuán)隊可以取消，測試人員真正變成敏捷團(tuán)隊中的一員，這樣更有利于開發(fā)和測試的融合。
但是，也要根據(jù)具體情況，如果某些專項測試對于業(yè)務(wù)系統(tǒng)來說是非常關(guān)鍵的質(zhì)量指標(biāo)，則可以考慮成立專門的性能性測試團(tuán)隊。例如，大型復(fù)雜的軟件系統(tǒng)，對性能和安全的質(zhì)量要求很高，性能測試和安全測試涉及的技術(shù)層面又都很廣很深，需要單獨(dú)的測試計劃、測試技術(shù)和方法，由專門的團(tuán)隊來負(fù)責(zé)也是合理的。
你可能會擔(dān)心：取消測試組織會造成測試人員的孤立和公司對質(zhì)量的忽視。對此，企業(yè)可以建立測試社區(qū)（Test Community）這種虛擬的組織形式來代替測試團(tuán)隊，通過定期舉辦活動給所有員工提供一個交流質(zhì)量文化和測試技術(shù)的平臺，這樣更能意識到質(zhì)量是我們大家的事。不少公司都有類似的實踐，比如前面講的 Etsy 公司。
敏捷測試人員的成長 / 職業(yè)發(fā)展
最后簡單講一下敏捷測試人員的成長和職業(yè)發(fā)展。聽了前面的內(nèi)容，你應(yīng)該已經(jīng)理解了，敏捷模式下測試人員要承擔(dān)的責(zé)任和任務(wù)有很多，但是干不好也容易被邊緣化，因為很多任務(wù)不是那么具體和可量化，比如指導(dǎo)團(tuán)隊成員做測試，推廣質(zhì)量文化，不僅需要技術(shù)能力，還需要很多軟技能，比如溝通和領(lǐng)導(dǎo)力。這必然會給測試人員帶來巨大的挑戰(zhàn)，但對于具有成長性思維的人來說，這又是非常好的機(jī)遇，促使你我通過多種方式快速成長，讓自己在職場上更有競爭力。
學(xué)習(xí)的方式有很多：比如參加公司組織的技術(shù)沙龍、測試社區(qū)；通過論壇、活動建立與公司外部測試同行的聯(lián)系；或者通過書籍，線上 / 線下課程的學(xué)習(xí)充實自己。這個我會在接下來的內(nèi)容中很快會講到。
最后，給你出一道思考題：做為敏捷團(tuán)隊中的測試人員，你應(yīng)該如何在團(tuán)隊中推廣質(zhì)量文化？你期望團(tuán)隊建立什么樣的質(zhì)量文化呢？歡迎留言討論。
總結(jié)
以上是生活随笔為你收集整理的高效的敏捷测试第三课 测试人员的选择的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： HTML文本格式化标签详解
- 下一篇： Industry personnel q