Lisa Crisplin 訪談：測試的現狀與未來

敏捷是近年來的一大熱門話題，但相關的爭議也很多。有一種聲音質疑敏捷能否面對測試的挑戰。敏捷測試嘗試從多個層面回答這個問題，包括組織、人員、流程、工具、溝通和協作等。Lisa Crispin 和 Janet Gregory 寫過一些敏捷測試著作，還開設了一些在線課程。他們還為想要貢獻和學習的人們建立了一個敏捷測試社區。他們的貢獻幫助了敏捷知識、技術和文化在敏捷世界中普及傳播。

Xiaoqian（Christina）Geng：你和 Janet Gregory 是敏捷測試的第一批布道人，還撰寫了著名的書籍《敏捷測試：面向測試人員和團隊的實用指南》，以及《更多敏捷測試：整個團隊的學習之旅》。敏捷測試與成功的敏捷開發密不可分，并且應該成為后者的一部分。你認為成功實現敏捷轉型的最大挑戰是什么？

Geng：開發團隊希望轉向敏捷開發的原因之一是，人們認為它可以幫助提升新功能的交付速度。大多數情況下，如果在開發周期的一開始時沒有做好測試工作，那么到了周期末尾時測試就會成為瓶頸。如果開發人員的優先事務列表里沒有測試，那么他們也很難認同測試應該是開發工作的一部分。

Crispin：即使他們同意你的意見也不會照做，因為任務優先級不夠高。所以我說管理層必須出來說話，

拿我上一個團隊舉例——開發總監明白我們需要各種自動化流程，也需要探索性測試。我們有許多自動化測試，但在投入生產時卻遇到了問題，因為我們需要進行探索性測試。因此，他將其作為各個級別的開發人員的職業要求的一部分——他們需要特定的能力和探索性測試技能。然后他要求我們的測試人員在研討會上教開發人員學習探索性測試。我們還定期與他們對接，讓他們了解我們是如何測試的。我們還可以幫助他們編寫測試：比如說你做這件事情會發生什么，或者應該對這件事情做負面測試之類；然后開發人員就會開始思考與測試相關的這些事情了。我們為他們提供了一些啟發式檢查清單，并使用了 Elizabeth Henderson 的測試備忘單。我們做的事情就是為他們的工具箱提供了一些新工具。他們很喜歡這樣，因為這樣一來他們就能盡早發現錯誤，也就看到了其中的好處。

Geng：有人說，一個 3 歲的男孩可以在視頻游戲中找到錯誤，而一家制造公司的 CEO 也可以在金融應用程序中找到一些錯誤，諸如此類。這是否意味著每個人都可以進行測試？或者說，你認為開發人員可以代替測試人員完成后者的所有工作嗎？

Crispin：顯然，他們可以發展自己的能力并掌握許多測試技能。你知道 Alan Page 和 Brad Jensen 做了一個 AB 測試播客，過去幾年里他們提出了所謂的“ 現代測試原理 ”。他們的愿景是讓測試人員成為教練教授他們的團隊，直到團隊不再需要指導為止。這種做法可以在某些風險較低的業務領域中使用。但對于諸如金融服務之類的事務來說，其中金錢對于業務或生活是至關重要的，這種時候我認為你仍然需要專家來提供深層次的知識。你知道我已經做了 30 年的測試工作，難道我能將所有這些技能都傳授給別人嗎？我們需要測試專家。打個比方，我們可以學到一些有關用戶體驗設計的知識，但是對于大多數應用程序而言，我們的團隊都需要設計專家。

Johanna Rothman 幾周前寫了一篇博文，她說在敏捷時代的早期人們會說：" 好嘛，我們都會成為通才；我們都會掌握這些技能。”然后她寫道：“你知道后來發生了什么事嗎？ 我們有了知道該如何協作的專家；他們學會了如何合作和良好地溝通，因此我們可以相互傳遞各自的技能。但我們還是會有專家，他們也沒有被冷落在哪個角落。我們把所有專家都聚在了一起，這才是關鍵所在。 ” 我同意這一點。我們讓專家們盡可能分享自己所有的技能。但你不可能在所有領域都是專家。我不認為大家都可以做到全知全能。

Geng：大型分布式平臺可能具有數千種配置和高度可定制的部署。開發人員會花時間了解組件的依賴項，但是像客戶一樣理清所有頭緒是需要開發人員花很多精力學習的事情。它需要深入的分析和對產品的全面理解。

Crispin：我認為領域知識是必不可少的。我真正深入到業務領域中后也獲得了許多價值。開發人員必須專注于他們正在編寫的一小段代碼。他們必須集中精力。他們沒有時間退一步來理解背后的業務整體。如果有我在，我可以幫助他們取得成功。

Geng：所以，我們不應該對開發人員抱有這種期望嗎？

Crispin：對！

Geng：隨著時間的流逝，測試自動化往往變得效率低下且昂貴。持續交付中最好的測試自動化策略是什么？

Crispin：Nicole Forsgren、Jez Humble 和 Gene Kim 合著的《 Accelerate 》一書是根據 "DevOps 現狀調查 " 的前四年結果編寫的，這是一項科學調查。Forsgren 博士是一位專家，擅長使用此類數據并找出相關性，提出正確問題并找出聯系背后的成因——成功做到持續交付的團隊、客戶滿意的團隊、團隊成員熱愛自己工作的團隊往往是高績效的團隊。他們發現與開發團隊高績效相關的一個預測因素，是開發人員可以實現測試自動化；這樣他們就可以自己在本地計算機上運行這些測試。他們可以在開發流程中處理持續集成中的測試失敗。

而且他們與測試人員攜手合作，所以兩種角色你都需要。開發人員必須實現自動化，但他們也需要測試人員來幫助實施自動化并處理人工測試任務。這是我的經驗之談。當測試人員和開發人員攜手實現自動化時，我們將獲得最佳結果。我從過去二十年來的經驗總結出了這一點?，F在他們的科學數據支持了我的經驗總結，這讓我很高興?，F在你知道了這不只是某人的理論，而是事實。因此，我希望這一事實能幫助說服更多開發人員和他們的管理層，讓他們意識到開發人員需要的不僅是自動化。許多開發人員不想做的不僅是服務級別或 API 測試，還有通過 UI 進行的 UI 測試。協作是必不可少的，因為測試人員擅長指定測試用例。我們需要將這些技能很好地結合在一起。

Geng：經過多年積累，自動化測試將成為一項巨大的測試資產，全都非?？煽壳液糜?。但這條路有時走起來很困難。

Crispin：是的，這非常艱難，我們也為此感到掙扎。我們需要確保測試是正確的，需要確保我們有足夠的覆蓋范圍。我們一定不能說：“那項測試總是通不過，干脆忽略掉整套測試吧。” 這非常危險。沒那么重要的測試就不要去做。必要的測試就要讓它足夠可靠。我們應該對測試充滿信心。 我們一定要做好分析和試驗，找出效果足夠好的自動測試數量最少是多少，然后我們就可以騰出時間，通過探索性測試之類的方法涉足高風險領域了 。有些測試最好是人工完成的，我們可以手動測試它們。我們應該搭配各種方法。對于持續交付來說，顯然我們不可能那么快地手動測試完所有內容來支持持續交付，但是我們可以使用發布功能切換之類的東西，告訴大家：“好的，我們準備部署它了，先關掉它，或者只為我們開啟它；我們會做好測試，稍后會為大家重新開放它的。” 我們有一大堆新技術可以用來做到這一點，這很令人鼓舞。但是我們仍然必須讓專家在需要的地方提供幫助和協作，提供我們所需的所有技能。

Geng：我在 testingindevops.org 中看到了一個新詞“DevTestOps”。能幫我們解釋一下嗎？

Crispin：一開始我們使用的是“DevTestOps”一詞，過去也有人用過。我喜歡這個叫法，因為對我而言測試是開發運維的核心。你可以看看 Jez Humble 和 David Farley 寫的《持續交付》之類的著作，那本書是 2009 年出版的。他們出版之前請我對草稿做了技術審查。當時我說：“我的團隊做過這些實踐，但我不是這些方面的專家。”

然后他們說：“不，我們就想讓你來審。”所以我讀了這本書。這本書實際寫的都是關于測試的。這就是持續交付的核心。Jez Humble 非常支持我的說法。“DevTestOps”這個詞，有些人喜歡它，有些人說這是在搞特殊，因為測試是開發的一部分——這一點我很清楚。 測試人員需要學習 DevOps 實踐、DevOps 文化和部署中的持續交付。這就是軟件的發展方向。因此我們必須不斷發展，我們的確需要這些技能 。諸如風險分析之類的東西，我們作為測試員都很擅長。我們擅長識別模式，因此在使用 Splunk 這樣的工具監視生產時，我們可以開始注意到其他人可能會忽略的模式，這就是我們的思維模式。我們可以使用可觀察性指標來查看生產中發生的情況。人們如何使用我們的產品？我們需要將測試重點放在這里。我們可以使用許多工具來確定測試的位置，但是測試人員需要參與其中；而且我認為許多測試人員都會害怕聽到 DevOps 這個詞，他們覺得 DevOps 中沒有測試的立足點。在持續交付中，我們是否有時間進行人工測試？人們不想去開發自動化測試，但卻想要做測試。他們覺得如果只有自動化的測試，自己是不會參與進去的。我們需要向他們展示：“不，所有這些測試活動仍然是必要的。”我們只是在使用某些技術來換一種做法。這個 網站 的目的就是如此，是幫助人們了解這些內容。因此我們提供了一大堆文章、書籍、視頻和播客的鏈接。然后我們會收到訪客很棒的留言，我們希望能看到更多留言。我們歡迎大家提供幫助。我們會幫助大家提高認知水平、傳授知識并讓更多人為之雀躍。

Geng：" 現代測試原理 " 由 Alan Page 和 Brent Jensen 創建；他們稱其為敏捷測試者的進化。借助現代測試的這七項原則，測試人員可以從質量的負責人轉向使者的角色，帶領團隊提供可交付質量、提供價值并改善團隊的質量文化。你怎么看待這件事？

Crispin：我認為這在許多業務領域都不會成為現實。團隊中至少需要一名顧問來做一些專業測試。不同的開發人員有不同的視角。他們同一時間內只會專注于手頭的工作。必須有人來把握全局。為此我們的團隊需要測試人員，但可能不需要那么多。在我的上一個團隊中，我們有 30 名開發人員和 3 名測試人員。我們不可能測試所有開發人員的所有輸出，但是我們可以幫助開發人員學習在自己的故事級別內做探索性測試。因此，我們的測試人員會在功能級別上編寫探索測試章程。當已經完成的故事足夠多，可以開始測試功能時，我們可以讓測試人員與產品負責人、設計師或開發人員結對，并在更高級別進行探索性測試。

我認為，如果團隊的其他成員更進一步，正在提升他們的工作質量，則可以減少測試人員的數量。如果開發人員沒有進行測試驅動的開發，或者至少沒有自動化單元測試，那么一切都會徒勞無功。即使你在其他級別上實現了完全自動化，也無法替代一般單元測試中的自動化。開發人員必須有提高質量的意愿，然后他們才能做到這一點。我知道每個開發人員都希望提供高質量的產品，但是如果給他們壓力，只要求他們把功能搞出來甚至更糟：“那么在下一個版本發布之后，我們將開始強化功能并開始自動測試。”這就像是在說我總是溺水所以沒時間學習游泳一樣。我們不應該成為質量的使者，而應該是推動者。我們的角色是幫助提醒大家，然后也幫助他們實現目標，讓他們擁有能夠實現這一質量水平的各種技能，但這需要整個團隊發自內心的支持。他們必須自己有這樣的意愿才行。

Geng：你認為團隊中開發人員與測試人員 / 質量檢查人員之間的正常比例應該是多少？

Crispin：從來沒有哪個固定比例適用于所有團隊。我認為團隊需要問自己：“我們最大的問題是什么？”你遇到的最重要的問題是關于質量的——也許測試就是瓶頸。你需要搞清楚如何做測試。你可以找來更多的測試人員，也可以找來其他類型的測試人員。2003 年到 2012 年，我在一家金融服務公司工作，我們團隊開發的是一種高風險軟件。軟件涉及的是人們的金錢； 我們的軟件用來銷售和管理雇主為其雇員提供的退休帳戶。我們是一個很小的團隊，但是業績十分出色。編寫代碼并不難，但是要確保它能正常工作，并且每一個邊緣狀況都能處理就非常有挑戰性了。我們談論的是金錢；你必須計算到小數點后六位，一切都必須精確。因為如果你搞亂了什么東西，很難回退并撤銷操作。我最后參與的一個團隊開發的是項目跟蹤工具；不管是誰的項目跟蹤工具崩潰一段時間都不會出什么大問題。這并不是業務的關鍵角色，只是出問題會很煩人。它會讓人不爽，但并不可怕。為 30 名開發人員配備兩到三名測試人員是可以的，主要是因為這種文化非常注重質量。這種文化中還有結對編程；有測試驅動開發；還有人關心探索性測試。他們希望每個人都有旺盛的求知欲。在這種情況下，減少測試人員的數量沒什么問題。我知道有些團隊的開發人員很擅長測試，他們用不著測試人員。所以說還是具體案例具體分析。

Geng：應該怎樣使用數據來衡量產品質量？

Crispin：衡量質量一直都是一項巨大的挑戰。我一直在思考這個問題。Anne-Marie Charrett 在這方面做了一些非常有趣的工作。在不同的領域，不同的數據圖所描繪出來的質量狀況是不一樣的。我認為，現在我們有了這么多出色的分析工具和所有這些數據，一種衡量的方法是問一個問題：人們是不是在使用某項功能？如果他們沒在使用它，是因為他們不想要，還是因為它難以使用？還是說他們很難找到這個功能？我們可以使用學習型版本來判斷。當我們開始研究新功能時，可以先做一個非常初級的最小可行產品（MVP）或學習型版本發布出去，觀察用戶使用它的情況，然后采訪他們以獲得反饋。我們發現如果能有一個反饋小部件（我說的是 Web 的應用）就很有用了——用戶在這樣一個小部件應用中輕點就能提交反饋。這些反饋對我們來說確實很有價值。我們跟蹤的另一件事是“憤怒的點擊”。就是說如果有人生氣了，他們就會點啊、點啊、點……

我們團隊的測試人員每周都會收集指標，并將其放在辦公室的大型顯示器上。這樣我們就可以同時觀察很多狀況：收到多少張客戶票，多少次憤怒點擊，不同功能的使用率是多少，等等；并將它們組合為一系列指標。我們團隊要做的一件事是經常給客戶打電話，特別是打給新客戶。比如說昨天他們聯系了一家公司，后者對我們說他們需要在移動設備上使用我們的應用。我們尚不支持移動設備，所以召集了很多人來聽客戶的需求。如果產品人員來找我說“我需要這個新功能”，我會問：“我們怎么能知道它在生產中是不是能成功？”現在我們就來考慮一下該如何衡量它吧。很多時候他們甚至無法回答這個問題。

Geng：你認為諸如人工智能（AI）和機器學習之類的技術可以幫助我們的測試工作嗎？

Geng：研究人員已經在使用 AI 來做一些開發工作了。這個話題你能多談一些嗎？

Crispin：開發人員告訴我，與測試人員的工作相比，AI 更有可能承擔開發人員的工作。舉個例子，因為當我們使用機器學習時，我們使用的是數據；我們必須測試數據來驗證它能否用來訓練。我們必須測試機器學習算法。測試還是必要的，但是你可以為機器提供 2 萬個編程示例，它就可以學習如何去編程。那是可行的。但是，你能讓它獲得人類的判斷力嗎？

Geng：最后一個問題，你對新測試人員有何建議？

Crispin：我認為重要的是，你要知道無論你的發現是什么——也許是錯誤？所有這些都可能是溝通問題：業務方沒有很好地表達他們的需求；另一方面，開發團隊誤解了業務需求，因此看起來像是缺陷的東西其實只是因為溝通不暢造成的。因此，我會告訴測試人員提高你的溝通技巧。我曾多次聽到人們說軟件開發中編碼技能占 20%，溝通和協作（所謂的軟技能）占 80%。發展你的軟技能，因為它們是最難學習的技能，例如溝通、聆聽、觀察技能，批判性思維技能等；并且有很多方法可以提升自己的軟實力。你還需要注意自己的無意識偏見。測試人員非常脆弱，有時我們會測試我們期望看到的內容。我們必須能夠注意到未知的事物，了解未知的事物。經常思考的能力對于測試人員是至關重要的。不用擔心你的技術技能，這些很容易學習。

Geng：謝謝，這是對所有測試人員的普遍建議？

Crispin：我認為是的。我們學習了測試自動化或編程，或者其他很多很棒的東西。但是，我可以教任何人怎樣去編碼，但不一定可以教別人如何做到批判性思考。我可以給他們練習，幫助他們改進并努力。但具體該怎樣做到這一點我也不能給出明確的答案。

Geng：Lisa，謝謝你花時間分享你的想法。與你交流真是一種榮幸。

受訪者介紹

Lisa Crispin與 Janet Gregory 合著了《敏捷測試：簡要介紹》《更多敏捷測試：整個團隊的學習之旅》（2014 年），《敏捷測試：測試人員和敏捷團隊實用指南》（2009 年）， 還制作了 "LiveLessons 敏捷測試基礎知識視頻課程 "，以及 " 整個團隊的敏捷測試方法 "，并通過敏捷測試獎學金提供了為期 3 天的培訓課程。最近，Lisa Crispin 和 Janet Gregory 出版了新書《 敏捷測試精華 》。Lisa 在2012 年敏捷測試日被同行評選為最具影響力的敏捷測試專業人??士。她是mabl 的一名測試倡導者，致力于探索軟件社區中領先的測試實踐。請訪問 Lisa Crispin 的網站 和 敏捷測試網站 了解更多信息。

采訪人介紹

Christina Geng是位于舊金山的 Splunk HQ 的 QA/SDET 總監。她從事軟件測試已經十多年了。Christina 對 SDLC 的持續改進和測試技術 / 流程發展、風險控制和客戶至上等主題充滿熱情。

原文轉自：https://www.infoq.com/articles/current-future-testing/