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