本文要點
- 自動化UI測試被人們吹捧得神乎其神，然而真實並非如此。
- 相比自動化測試，探索性測試仍然具有很多好處。
- 把工作分解成更小的任務可以幫助你更快地發佈。
- 瞭解敏捷的含義可以幫助團隊做出更好的決策。
- 讓團隊在工作時仍有時間學習，這是一種在組織中培養持續學習文化的更好方法。
介紹
往往很多團隊都認爲自動化測試是一種加速軟件交付的方式，這通常是團隊內部感知到的瓶頸，但如果他們將開發實踐作爲一個整體更加深入地看待它，可能會得到更好的認知。
預防缺陷
測試（特別是在UI級別的測試自動化）往往都發生在軟件交付流水線的末端，通常試圖捕獲那些可能溜進現場環境並對最終用戶產生不利影響的Bug(就像病菌一樣！)。測試在此檢測Bug的症狀，由開發人員部署修復的補丁。這差不多類似我們等着系統生病之後，再試圖做些什麼。
這種方法對於團隊來說是行之有效的，然而，當前的工作環境迫使我們用更少的人做更多的事情，而且還經比以前做得更快。因此，從長遠來看，這種方法就支撐不起來了。這就是預防的用武之地了，而不是事後治療。
通過調整構建系統的方式，我們能夠在問題發生之前就檢測到Bug，或者更好情況的是，使它們一開始就更不容易被開發出來(預防)。這意味着我們正在預防錯誤的發生，而不是試圖在以後的某個時間去治療它。常言道，預防勝於治療。
我們的測試自動化之旅
我是與構建和管理我們的點播(視頻點播)產品的移動團隊一起開始的。在那個時候，我們所有的測試都是手工執行的，我們平均每年只在每個平臺上發佈2到3次。我們知道，我們想要加快速度，而最明顯的瓶頸是測試。每個迴歸測試周期將花費近兩週的時間，而且那是在沒有發現任何問題的情況下。如果發現了問題，那麼開發團隊將需要理解問題，確定一個修復方案，然後去執行它。那麼已經執行的所有測試可能就無效了，因此需要重新啓動該過程，導致整個測試周期要花費兩倍的時間。
所以我們開始着眼於自動化更多的UI測試。我們希望從小處着手，看看這是否會將我們引向所希望的方向，所以選擇只自動化新功能。一旦證明和希望一致，我們將尋求將系統的現有部分或或已知存在問題的部分自動化。
我們使用“3個朋友”作爲一個團隊來理解我們想要構建什麼，以及該特性的關鍵驗收標準應該是什麼。這爲我們提供了一個出發點，讓我們瞭解如何分解該特性以及哪些用戶旅程需要自動化。
在此基礎上，我們確定了可以用來自動化測試的工具(Calabash 和最終的Appium)，並在實際環境中運行測試。對我們來說，這是在真實的手機上，而不是仿真器或模擬器，爲此我們建立了自己的設備測試場，以更好地利用我們的移動設備，但也允許它跨整個組織予以擴展。
在我的博客上可以找到更多的細節，自動化BBC iPlayer移動測試第一部分：用3個朋友來識別用例，第二部分：自動化過程，第三部分：遺留系統與新特性。
測試自動化帶給我們的好處
起初，自動化幫助很大，因爲我們現在可以快速可靠地運行簡單的場景，並得到我們想要的快速反饋。但是隨着時間的推移，在最初找到一組Bug之後，所能發現的問題就越來越少了，除非我們再實打實地去編寫那些尋找它們的自動化測試用例。
我們還注意到有些問題仍然存在，因爲有些場景我們無法自動化。例如，任何與可用性相關的東西都必須手工測試。因此，我們最終拿出了一個混合的解決方案，其中自動化將快速運行一些關鍵場景，例如讓團隊知道他們沒有明顯破壞掉任何東西，然後對任何新特性進行探索性測試，待時機成熟了，這些測試也可以自動化。因此，測試很有難度。我們在嘗試測試時很容易出錯，或者手工測試花費的時間太長。
但是，也出現了一個意想不到的好處，它與我們的自動化之旅間接相關，當我們開始更快地發佈時，它使我們更加關注我們想要實現的目標。這促使我們將新功能分解成可以獨立工作的小塊，以便實現自動化。這樣，我們就能夠更快地將這些小塊發佈到現場環境中，並開始從最終用戶那裏獲得真實的反饋。起初大家都沒有注意到，因爲我們仍在嘗試確定自動化場景。只是在事後，團隊纔看到他們無意中做到的這一點。總之，我們開始將工作分解爲一小批最終用戶價值了。
調查我們的開發生命週期
我們開始意識到自動化UI測試並沒有真正給我們所希望的回報。正因爲如此，我們開始研究開發過程中的其他領域，看看是否可以做出什麼改進。但作爲一個團隊，我們的問題之一是，我們太接近流程了，以至於無法客觀地看到哪些是有效的，哪些是無效的。考慮到當局者迷，旁觀者清，所以我們請來了一位敏捷教練來幫助我們的團隊，以克服這個問題。準確來說，我們請來了兩個：一個幫助團隊理解他們正在使用的流程，另一個幫助我們更好地理解我們實際上是如何構建我們的系統的。
由於他們身處團隊之外，使得他們可以觸及我們系統中某些部分的痛處，而不用擔心冒犯什麼人，通過問一些簡單的問題，以讓我們瞭解我們工作方法背後的原因，並將我們從“我們一直都是這樣做的”慣性思維中解脫出來。例如，用於管理我們工作的站立板通常有待辦事項、接下來、開發、等待測試、正在測試和完成等列，但是我們從來沒有想過問問爲什麼我們有接下來和等待測試列。我們的教練能夠提供幫助的是，我們爲什麼讓工作在這些欄中積壓，爲什麼開發和測試被視爲兩個不同的活動。教練的方法並不是簡單地改變我們的過程，而是幫助我們明白正在導致些什麼問題(未發佈的價值戴着“接下來”和“等待測試”的面具呆在那裏排起長龍)，讓團隊看到，通過消除開發和測試列，以一個簡單的和自解釋的“正在進行”列取而代之，令工作更簡潔明瞭地直到“完成”。您可以在我的專欄文章《在測試列中》中找到更多關於使用這種方法的好處。
我們學到了什麼
我們發現的最大問題之一是，就敏捷開發實踐而言，我們的團隊中存在大量的貨物崇拜。僅僅因爲我們有站立會，在小型團隊中工作，並在迭代結束時發佈些什麼，並不意味着我們實際上是敏捷的。這只是意味着我們有一些儀式，讓我們看起來像是“敏捷”的。事實證明，並不是每個人都很清楚我們爲什麼要這麼做，甚至不清楚我們在哪裏能得到什麼好處。我們所做的第一件事就是澄清什麼是敏捷。它更多的是基於客觀反饋的可持續軟件交付，而不是試圖儘可能快地發佈你所能發佈的任何東西，並期望最好的結果。我們通過讀書俱樂部和組織團隊討論來使團隊內部達成共同的理解。這有助於團隊成員更好地掌握敏捷實踐背後的原則，並在他們的工作方式中做出更好的決策。
我們還開始研究我們在代碼層實際上是如何構建系統的，並試圖可視化開發人員是如何在哪裏提交代碼的、提交的頻率有多少頻繁，以及提交的規模有多大。這並不是試圖讓開發人員感到羞恥，而是幫助他們理解作爲一個團隊，他們是如何影響代碼庫的，並試圖鼓勵開發人員養成更高效的習慣，比如定期進行較小規模的提交，而不是在一天結束時提交一大堆。如果他們確實做了大量的提交，那也可以，但是要讓其他開發人員知道他們爲什麼這樣做，從而瞭解其中的原委。
我們對團隊最大的改變之一是鼓勵結對編程，因此沒有一個開發人員單獨開發一個特性。這不僅加快了代碼評審的速度，而且當大家被要求承擔責任時，他們也不太可能走捷徑。它還有助於更快地提高我們團隊中較年輕成員的技能和知識，相比於在虛擬項目上做一做，再由更資深成員把關的傳統方法，他們能更快地提高生產能力。
我對更有成效和更健康的開發生命週期的建議
作爲一個團隊開展工作，並且在這個團隊中確定一個高效、健康的開發過程是什麼樣的。
可以先考慮建立一個團隊視頻俱樂部，這是開始這些討論的一個有用的方法。這讓團隊能夠從日常活動中抽出一些時間來學習構建軟件的新工具或新方法。在每次會議結束時，由會議負責人(項目經理、技術負責人或將想法帶給團隊的人)組織團隊討論，以探索他們如何使用這些概念來幫助推動團隊嘗試新事物。
然後選擇一個概念，對應該有什麼樣的結果有一個清晰的想法，在此基礎上開展工作。那麼，如果我們以更好的單元測試爲例，就要先弄清楚單元測試對團隊意味着什麼?更好的單元測試會給團隊帶來什麼?一旦你對這些問題有了答案，就可以想出達到這個目的的多種方法，這樣你就可以選擇一個可以讓你快速而客觀地檢驗結果的方法。你需要弄清楚，你所使用的新過程或新技術是否真的幫助你在規定的時間內實現了你的目標。如果做到了，那就太好了。如果沒有，你需要停止嗎?還是要繼續做得更多?或者需要做些調整?您還需要決定由誰來實際運行這個實驗，以及他們將如何與團隊的其他成員進行溝通。
記住，如果你想讓任何新流程或想法在團隊中站穩腳跟，那麼它們都需要大家的參與。否則，一旦露出困難的跡象，這個想法將被停止或舉步維艱，只有投身其中，大家才能得到回報。
作者簡介
Jitesh Gosai 擁有超過15年的測試經驗，曾與各種各樣的公司合作，從移動製造商到操作系統構建者和應用程序開發人員。他目前是電視和廣播部門的首席測試人員，與BBC的移動、電視和Web平臺團隊合作，幫助他們確定測試方法，以及這些團隊如何遷移到DevOps以及後續工作。