本文要點

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

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

　　把工作分解成更小的任務(wù)可以幫助你更快地發(fā)布。

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

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

　　介紹

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

　　預(yù)防缺陷

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

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

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

　　我們的測試自動化之旅

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

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

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

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

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

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

　　起初，自動化幫助很大，因為我們現(xiàn)在可以快速可靠地運行簡單的場景，并得到我們想要的快速反饋。但是隨著時間的推移，在最初找到一組 Bug 之后，所能發(fā)現(xiàn)的問題就越來越少了，除非我們再實打?qū)嵉厝ゾ帉懩切ふ宜鼈兊淖詣踊瘻y試用例。

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

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

　　調(diào)查我們的開發(fā)生命周期

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

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

　　我們學到了什么

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

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

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

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

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

　　可以先考慮建立一個團隊視頻俱樂部，這是開始這些討論的一個有用的方法。這讓團隊能夠從日?；顒又谐槌鲆恍r間來學習構(gòu)建軟件的新工具或新方法。在每次會議結(jié)束時，由會議負責人 (項目經(jīng)理、技術(shù)負責人或?qū)⑾敕◣Ыo團隊的人) 組織團隊討論，以探索他們?nèi)绾问褂眠@些概念來幫助推動團隊嘗試新事物。

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

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