本文要點

　　自動化 UI 測試被人們吹捧得神乎其神，然而真實并非如此。

　　相比自動化測試，探索性測試仍然具有很多好處。

　　把工作分解成更小的任務可以幫助你更快地發布。

　　了解敏捷的含義可以幫助團隊做出更好的決策。

　　讓團隊在工作時仍有時間學習，這是一種在組織中培養持續學習文化的更好方法。

　　介紹

　　往往很多團隊都認為自動化測試是一種加速軟件交付的方式，這通常是團隊內部感知到的瓶頸，但如果他們將開發實踐作為一個整體更加深入地看待它，可能會得到更好的認知。

　　預防缺陷

　　測試(特別是在 UI 級別的測試自動化)往往都發生在軟件交付流水線的末端，通常試圖捕獲那些可能溜進現場環境并對最終用戶產生不利影響的 Bug(就像病菌一樣!)。測試在此檢測 Bug 的癥狀，由開發人員部署修復的補丁。這差不多類似我們等著系統生病之后，再試圖做些什么。

　　這種方法對于團隊來說是行之有效的，然而，當前的工作環境迫使我們用更少的人做更多的事情，而且還經比以前做得更快。因此，從長遠來看，這種方法就支撐不起來了。這就是預防的用武之地了，而不是事后治療。

　　通過調整構建系統的方式，我們能夠在問題發生之前就檢測到 Bug，或者更好情況的是，使它們一開始就更不容易被開發出來 (預防)。這意味著我們正在預防錯誤的發生，而不是試圖在以后的某個時間去治療它。常言道，預防勝于治療。

　　我們的測試自動化之旅

　　我是與構建和管理我們的點播 (視頻點播) 產品的移動團隊一起開始的。在那個時候，我們所有的測試都是手工執行的，我們平均每年只在每個平臺上發布 2 到 3 次。我們知道，我們想要加快速度，而最明顯的瓶頸是測試。每個回歸測試周期將花費近兩周的時間，而且那是在沒有發現任何問題的情況下。如果發現了問題，那么開發團隊將需要理解問題，確定一個修復方案，然后去執行它。那么已經執行的所有測試可能就無效了，因此需要重新啟動該過程，導致整個測試周期要花費兩倍的時間。

　　所以我們開始著眼于自動化更多的 UI 測試。我們希望從小處著手，看看這是否會將我們引向所希望的方向，所以選擇只自動化新功能。一旦證明和希望一致，我們將尋求將系統的現有部分或或已知存在問題的部分自動化。

　　我們使用“3 個朋友”作為一個團隊來理解我們想要構建什么，以及該特性的關鍵驗收標準應該是什么。這為我們提供了一個出發點，讓我們了解如何分解該特性以及哪些用戶旅程需要自動化。

　　在此基礎上，我們確定了可以用來自動化測試的工具 (Calabash 和最終的 Appium)，并在實際環境中運行測試。對我們來說，這是在真實的手機上，而不是仿真器或模擬器，為此我們建立了自己的設備測試場，以更好地利用我們的移動設備，但也允許它跨整個組織予以擴展。

　　在我的博客上可以找到更多的細節，自動化 BBC iPlayer 移動測試第一部分：用 3 個朋友來識別用例，第二部分：自動化過程，第三部分：遺留系統與新特性。

　　測試自動化帶給我們的好處

　　起初，自動化幫助很大，因為我們現在可以快速可靠地運行簡單的場景，并得到我們想要的快速反饋。但是隨著時間的推移，在最初找到一組 Bug 之后，所能發現的問題就越來越少了，除非我們再實打實地去編寫那些尋找它們的自動化測試用例。

　　我們還注意到有些問題仍然存在，因為有些場景我們無法自動化。例如，任何與可用性相關的東西都必須手工測試。因此，我們最終拿出了一個混合的解決方案，其中自動化將快速運行一些關鍵場景，例如讓團隊知道他們沒有明顯破壞掉任何東西，然后對任何新特性進行探索性測試，待時機成熟了，這些測試也可以自動化。因此，測試很有難度。我們在嘗試測試時很容易出錯，或者手工測試花費的時間太長。

　　但是，也出現了一個意想不到的好處，它與我們的自動化之旅間接相關，當我們開始更快地發布時，它使我們更加關注我們想要實現的目標。這促使我們將新功能分解成可以獨立工作的小塊，以便實現自動化。這樣，我們就能夠更快地將這些小塊發布到現場環境中，并開始從最終用戶那里獲得真實的反饋。起初大家都沒有注意到，因為我們仍在嘗試確定自動化場景。只是在事后，團隊才看到他們無意中做到的這一點。總之，我們開始將工作分解為一小批最終用戶價值了。

　　調查我們的開發生命周期

　　我們開始意識到自動化 UI 測試并沒有真正給我們所希望的回報。正因為如此，我們開始研究開發過程中的其他領域，看看是否可以做出什么改進。但作為一個團隊，我們的問題之一是，我們太接近流程了，以至于無法客觀地看到哪些是有效的，哪些是無效的。考慮到當局者迷，旁觀者清，所以我們請來了一位敏捷教練來幫助我們的團隊，以克服這個問題。準確來說，我們請來了兩個：一個幫助團隊理解他們正在使用的流程，另一個幫助我們更好地理解我們實際上是如何構建我們的系統的。

　　由于他們身處團隊之外，使得他們可以觸及我們系統中某些部分的痛處，而不用擔心冒犯什么人，通過問一些簡單的問題，以讓我們了解我們工作方法背后的原因，并將我們從“我們一直都是這樣做的”慣性思維中解脫出來。例如，用于管理我們工作的站立板通常有待辦事項、接下來、開發、等待測試、正在測試和完成等列，但是我們從來沒有想過問問為什么我們有接下來和等待測試列。我們的教練能夠提供幫助的是，我們為什么讓工作在這些欄中積壓，為什么開發和測試被視為兩個不同的活動。教練的方法并不是簡單地改變我們的過程，而是幫助我們明白正在導致些什么問題 (未發布的價值戴著“接下來”和“等待測試”的面具呆在那里排起長龍)，讓團隊看到，通過消除開發和測試列，以一個簡單的和自解釋的“正在進行”列取而代之，令工作更簡潔明了地直到“完成”。您可以在我的專欄文章《在測試列中》中找到更多關于使用這種方法的好處。

　　我們學到了什么

　　我們發現的最大問題之一是，就敏捷開發實踐而言，我們的團隊中存在大量的貨物崇拜。僅僅因為我們有站立會，在小型團隊中工作，并在迭代結束時發布些什么，并不意味著我們實際上是敏捷的。這只是意味著我們有一些儀式，讓我們看起來像是“敏捷”的。事實證明，并不是每個人都很清楚我們為什么要這么做，甚至不清楚我們在哪里能得到什么好處。我們所做的第一件事就是澄清什么是敏捷。它更多的是基于客觀反饋的可持續軟件交付，而不是試圖盡可能快地發布你所能發布的任何東西，并期望最好的結果。我們通過讀書俱樂部和組織團隊討論來使團隊內部達成共同的理解。這有助于團隊成員更好地掌握敏捷實踐背后的原則，并在他們的工作方式中做出更好的決策。

　　我們還開始研究我們在代碼層實際上是如何構建系統的，并試圖可視化開發人員是如何在哪里提交代碼的、提交的頻率有多少頻繁，以及提交的規模有多大。這并不是試圖讓開發人員感到羞恥，而是幫助他們理解作為一個團隊，他們是如何影響代碼庫的，并試圖鼓勵開發人員養成更高效的習慣，比如定期進行較小規模的提交，而不是在一天結束時提交一大堆。如果他們確實做了大量的提交，那也可以，但是要讓其他開發人員知道他們為什么這樣做，從而了解其中的原委。

　　我們對團隊最大的改變之一是鼓勵結對編程，因此沒有一個開發人員單獨開發一個特性。這不僅加快了代碼評審的速度，而且當大家被要求承擔責任時，他們也不太可能走捷徑。它還有助于更快地提高我們團隊中較年輕成員的技能和知識，相比于在虛擬項目上做一做，再由更資深成員把關的傳統方法，他們能更快地提高生產能力。

　　我對更有成效和更健康的開發生命周期的建議

　　作為一個團隊開展工作，并且在這個團隊中確定一個高效、健康的開發過程是什么樣的。

　　可以先考慮建立一個團隊視頻俱樂部，這是開始這些討論的一個有用的方法。這讓團隊能夠從日常活動中抽出一些時間來學習構建軟件的新工具或新方法。在每次會議結束時，由會議負責人 (項目經理、技術負責人或將想法帶給團隊的人) 組織團隊討論，以探索他們如何使用這些概念來幫助推動團隊嘗試新事物。

　　然后選擇一個概念，對應該有什么樣的結果有一個清晰的想法，在此基礎上開展工作。那么，如果我們以更好的單元測試為例，就要先弄清楚單元測試對團隊意味著什么? 更好的單元測試會給團隊帶來什么? 一旦你對這些問題有了答案，就可以想出達到這個目的的多種方法，這樣你就可以選擇一個可以讓你快速而客觀地檢驗結果的方法。你需要弄清楚，你所使用的新過程或新技術是否真的幫助你在規定的時間內實現了你的目標。如果做到了，那就太好了。如果沒有，你需要停止嗎? 還是要繼續做得更多? 或者需要做些調整? 您還需要決定由誰來實際運行這個實驗，以及他們將如何與團隊的其他成員進行溝通。

　　記住，如果你想讓任何新流程或想法在團隊中站穩腳跟，那么它們都需要大家的參與。否則，一旦露出困難的跡象，這個想法將被停止或舉步維艱，只有投身其中，大家才能得到回報。