關於敏捷開發(Agile Development)網路上的技術資源已經相當完整

本篇主要會專注在QA工程師怎麼在開發團隊中提供價值的心法。

隨便google一搜，能看到很多敏捷原則最佳實踐等等的文章

由於每個團隊產品都不盡相同，我相信敏捷絕對不是像WordPress網站套版

各種需求都要套進敏捷這個框架去跑各種開發流程與測試細節

有時候不是好不好，而是適不適合的問題。

我自己的經驗，團隊大多使用的是優化版的瀑布開發(Waterfall)

簡單說就是強調軟體開發過程會經過完整的規劃、分析、設計、測試各階段週期

來有效確保系統與產品的品質，期間可能會拉到數個月甚至是數年來完成開發。

而優化版的瀑布開發也被稱為迷你瀑布(mini-waterfall)

基本上就是把需求切小，開發時間能夠縮短到兩週到一兩個月。

而敏捷開發不是不注重產品的品質，而是只做最重要的事

用持續開發與向客戶蒐集反饋來不斷改進，對客戶提供有價值的產品

敏捷開發時間可以短至兩週至一個月就能完成一個開發週期

近年最流行的是Scrum這個敏捷流程架構

聰明的你看到這邊就會問

像敏捷或是迷你瀑布這麼短的開發時程，QA要怎麼去塞進必要的測試工作？

至此，自動化測試才應運而生。

測試金字塔

從金字塔最下層的單元測試(Unit test)與組件測試(Component test)

通常可能是由RD寫code時排入開發時程一起完成的

而從API功能驗收測試(Acceptance test)到UI、手動測試一般都會是QA包辦

測試金字塔把不同種類的測試分層

越接近下層越接近程式邏輯，也越容易自動化，執行速度快又有效率。

越上層通常測試場景越複雜，所需測試人力成本大且執行測試也需要較長時間

金字塔也代表著下層的基礎測試覆蓋率要足夠多，讓上層複雜的使用者場景能順利測試

而以上都是理想的狀態。

測試冰淇淋

實際上我們可以把自己想成一個產品的負責人

如果今天這個產品下個月要出，功能要到位，產品品質也要達到一定的程度

對測試團隊來說，就是要確保在達到品質目標的同時，在期限內完成測試。

在時間的壓力之下，開發團隊必須生出功能，而可以投資在單元測試的時間也會變少

在單元測試不完備的情況下，QA容易陷入全手動測試的誘惑之中

因為通常一個新功能的驗證，最快的方式一定是透過手動測試。

但軟體開發是一個持續且可以說是無止盡的進程（如果產品有活下來的話）

隨著功能越加越多，手動測試的時間會依靠測試人員的經驗甚至是數量來完成測試

所以長期來看才不能用短期思維去救火，這樣測試團隊會容易引火自焚。

從冰淇淋測到金字塔

綜上所說，我們有個現況（冰淇淋）跟理想狀態(金字塔)

那我們要怎麼改變現況，出發向理想前進？

除了幫團隊健檢目前產品測試環節各階層的測試比例之外，

QA也能提供實際的數字來證明，如果接下來做了某某自動化測試的投資

之後的測試就可以少一週手動測試的時間（PM喜歡這則留言）

或是去檢視目前產品的測試有哪些是真正對使用者是有價值的測試

不是為了測試覆蓋率而做的「假測試」，而是使用者會遇到的「有效測試」

除了評估短期可達成的成效之外，也要長期投資，慢慢建造可持續的測試金字塔。

那什麼才是「有效測試」呢？

下一篇來聊聊什麼是使用者場景測試(User Scenario Testing)