真的需要自動化測試嗎你？

啊～久久寫一次，一次寫一大篇 XDD

以前我上課在講敏捷測試或是實際在帶敏捷團隊的時候，常常被問到說，Sprint 這麼短， 一個禮拜或兩個禮拜就結束了，測試跟不上啊！是的，如何用測試確保品質，是很多測試人員進入 scrum 後遇到的常見問題。

我都會用這個當例子，我的師父也是這樣教我的：

假設1. 開發人員每個 Sprint 開發 5 個 PBI。

那麼測試人員在第一個 Sprint 需要測試五個 PBI。 很直覺麻，要確保 DoD 有符合麻。還是有人覺得開發出來的東西不用測試？

那第二個 Sprint 呢？ 開發人員仍然開發出了五個 PBI，測試人員要測幾個？ 五個嗎？錯！ 應該要測 10 個，因為測試人員需要知道第一個 Sprint 的五個 PBI 有沒有被改壞啊。所以第二個 Sprint，測試人員要測 10 個 PBI。

第三個 Sprint 呢？ 理論上要測15個。

這兩個的關係我們可以做出以下的圖：

可是一個測試人員， 在一個 Sprint 內，肯定沒辦法這樣子測啊，總有個上限吧。於是，我們做了第二個假設：

假設2. 測試人員只有一個，他每個 Sprint 只吃得下 30 個 PBI 的測試。

在假設1, 跟假設2, 的情況下，現在我們的要解決的問題是：在第七個 Sprint 之後， 測試人員會跟不上開發的腳步。

解法呢？

我這邊提出一些解法給各位參考：

解法一： 大聲宣佈這種迭代式的開發是不能保證品質的，然後回瀑布式開發。

大家回到瀑布式的開發，抓出測試的時程，其中包括 system integration test 以及 user acceptance test，在這兩個階段都要做回歸測試。這段測試時間的長度，取決於這一次 release 的大小或是產品的複雜程度，通常會建議是半個月到兩個月不等的時間。

這個解法的好處是真的可以確保品質，讓測試人員把關，而且管理者(比如說 PM、主管)， 可以看得到測試時期的數字，比如說測試通過率等等。

壞處當然顯而易見的是，在測試時期會花掉一些時間，導致整個 schedule 往後，實務上的經驗是，通常在前面的計劃以及開發階段花去很多時間，擠壓到測試的時間，導致測試人員的時間壓力非常的大，甚至有可能造成開發部門跟測試部門之間的對立。

解法二： 使用自動化測試

讓測試人員撰寫自動化測試，讓每一個 Sprint 完成的那五個 PBI，都有對應的自動化測試， 這樣一來，測試人員只需要專注在那一個 Sprint 的測試，以及撰寫對應的自動化測試。

這個解法的好處是，因為要撰寫自動化測試，所以開發與測試人員必須在 Sprint 緊密的合作，不然自動化測試是很難寫出來的，更不可能趕上每一個 Sprint 的開發步調，這會讓團隊更凝聚。 另外自動化測試，應該是很方便執行的，實際執行應該也是很快的，電腦也不會累，可以重複的執行自動化測試，對於回歸測試或是查找問題上面會有很大的幫助。

壞處當然顯而易見的是，很吃測試人員的能力， 另外，這樣的想法也的確有點太過於理想，不太可能自動化的進度能夠跟上開發的進度，因為開發人員通常都很多，測試人員在 scrum 團隊裡面，可能就一個， 一個測試人員要打六個七個八個開發人員，當然很難跟上。

是啦，要 cross functional，但...

葉師父說「試著攻他中路」，洪師父坐在板凳上，氣喘吁吁地回說「沒這麼簡單」。

黃小琥也唱過這首歌。

安心亞是 MV 女主角。

解法三： 由測試人員的經驗，決定哪些要測試哪些不要測試

其實隨著產品的演進，測試人員大概知道哪些其實已經穩定了，不大需要一直重複的去測試他。

這個解法的好處是，實際、可行，如果能搭配合適的自動化測試，其實測試的進度就有機會可以趕上開發的進度了。 

但缺點是，很吃測試人員對產品的 domain know-how 和經驗，也讓管理者不容易知道測試人員是在打混摸魚，還是真的在測試上做了專業的取捨。

解法四：增加測試人員

也就是說，每加一個測試人員，團隊可以再多撐六個 Sprint，撐到產品上線了，或是產品有一定的穩定程度了，那這個問題或許也不這麼重要了。

這個解法的好處是，實際、可行，如果你的產品、專案，在-比如說- 18 個 Sprint 內結束，那可以考慮這個解法。

缺點是，增加了管理的、溝通的、各式各樣的成本。測試人員也不可能無限制的往上增長，HeadCount 是有限的。

解法五： 不要有測試人員，讓開發人員做測試

這個解法的好處是，實際、可行，微軟就是這樣做的；把測試人員的 head count 省下，感覺可以降低成本；或是把測試人員的 head count 挪作開發人員使用，感覺可以做出更多產出，自動化測試也是程式，由開發人員寫會超快的。

缺點是，開發人員會有盲點，只由他們做測試可能無法把品質維持在一定的水準；我也沒看過幾個喜歡動手做測試的工程師。

系統會發威、生命會找到出路、你會老，我會大

其實啊，我真的很不想說的是：想太多了，生命會找到出路的。

在第七個 Sprint 之後，測試人員測不完，又怎麼樣，照著 Sprint 的節奏跟規律就上線吧!

• 對於測試人員來說，他們已經很辛苦了，每個 Sprint 都要測試整整 30 個 PBI啊！
• 對於開發人員來說，他們仍然是穩定的輸出，沒有問題。
• 對於 PM、管理人員來說，每個 Sprint 都有東西可以 review、上線，東西是 on schedule 的。

對每個角色來說，都很好啊！但系統的力量會開始發威（誰來畫個 CLD 分析一下吧）：

隨著時間的過去，線上的異常會越來越多，生氣的用戶會越來越多，而處理這些異常和客戶的反饋，會佔去 PM、管理人員以及開發人員的時間，這會慢慢的讓開發的步調慢下來， 最後就會跟測試的步調一致了！

這個現象是一個 B 迴圈。

我認為，除了解法一跟解法二之外， 其他看似「實際、可行」的解法，最終都會導致上面的這個 B 迴圈的現象發生，只是時間或長或短而已，但是必須要強調的是，原本的「在第七個 Sprint 之後， 測試人員會跟不上開發的腳步。」的問題是的確獲得了解決。然後，通常公司的管理層，會再找其他解法來解決那個 B 迴圈的現象。這個叫做副作用，為了解決這個副作用，通常會有另外的副副作用產生，然後管理層再想辦法來解決，如此周而復始。

這個，如果沒記錯的話，在系統思維的 system archetype 裏面，叫做捨本逐末、或是飲鴆止渴。

加上在這個產業，我們必須承認，大部分公司的測試人員處於食物鏈的最末端，通常地位最低，而時間壓力最大。 很多測試人員跟測試主管，在這樣的情況下，常見的副作用是，提升測試人員跟測試部門的地位與存在感，而且全力避免解法五。 對於沒有自動化測試能力的測試部門主管，我的建議是，直接採用解法一，回去用 waterfall 開發，其實，老實說，這樣的決定可能可以拯救全公司。

Scrum Master 呢？

我想，一個還可以的 scrum master，應該要有能力在早期討論解法的時候，就可以看到這些系統。自動化測試是有門檻的，我們也必須承認，除了少部分公司之外，大概大部分的測試人員對於自動化測試的能力是很低的，更何況我們的要求是如上所述的解決問題，要求是這麼的高。

因此，解法五其實真的值得考慮與安排喔！

如果最終還是選了解法二，我覺得 scrum master 需要親自去帶，去把手弄髒，去帶著測試人員進行自動化測試的佈局，這也是需要時間的，或許過程中還是需要加幾個測試人員，但如果真的做到了，可以讓這個 B 迴圈的現象發生的機會小很多，且就算發生了也不嚴重（怎麼覺得跟打疫苗一樣？）。我覺得這是 scrum master 的能力之一，你在 retro 怎麼弄怎麼弄，搞什麼引導、談到團隊抱在一起哭，都沒意義。只要自動化測試做不到位，保護不了產品，那總有一天這個 B 迴圈的現象還是會發生。

反過來說，假如有一天，這個 B 迴圈的現象很嚴重時，代表這間公司已經沒有還可以的 scrum master 了，大概過一陣子也就回去 waterfall 了吧。

結語

聖經說：凡事皆可為，但不一定有益處。

啊～久久寫一次，一次寫一大篇 XDD