Shift-Left Testing (測試左移) 這個詞我們追朔到 2001 Larry Smith 在 Dr.Dobb’s 期刊刊登的一篇文章. 提到很多時候 QA 總是用手動測試完成任務, 並且需要通過 QA Process 才能知道 Code Quality.
Bugs are cheap when caught young — Larry Smith
測試左移並非要剔除所有的測試人員, 它背後的概念更多的是越早且頻繁地發現軟體缺陷, 因此開發人員可以更容易地修復問題. 且成本跟壓力都是小的. 同時它也回答了在不影響品質下, 加速軟體開發的方法. 但這是什麼意思呢?
回顧 1970–1990 年代, 典型的開發模型 (SDLC) 是有順序性的, 從計畫 -> 分析 -> 設計 -> 實作 -> 測試和整合 -> 維護, 測試加入的時間都會在 pipeline 後期, 或這是整條 pipeline 的最後一項.
同場加映: 談談最早的測試
即使在今日, 很多團隊還是會將測試放在開發流程的最後, 這也會造成很多潛在的問題:
- Delay in release cycle and late feedback.
- Low-quality products.
- Increased development and testing costs.
- Testing is the bottleneck.
在傳統的開發流程中, 我們同時也會意識到發現 bug 的成本會隨者時間而增加. 因此, 在測試左移的實踐, 嘗試將測試往開發流程的左邊推送, 在 Pipeline 的早期就加入測試.
測試左移的概念, 不只是只有增加測試人員跟開發人員之間的合作, 也同時反映出測試應該在更早期就導入. 接下來我們談談測試左移帶來的好處吧!
測試左移帶來的好處
- 增加發佈的速度
增加發佈的速度不太代表你/妳可以像火箭科學一樣快速開始跟結束, 假如你可以在開發前期就找到一個嚴重的 Bug, 你/妳可以更有效率且容易的修復, 最顯著的就是減少發佈時間, 反之就是增加發佈時間.
2. 加強測試的覆蓋率
當你/妳開始將測試考慮再開發前期的時候, 自然而來你/妳也會考量到功能的可測試性, 並且增加 Unit Test / Functional Test / Performance Test 等. 這無形間也是加強了整個產品的測試覆蓋率, 間接的影響到整體的產品品質.
3. 簡化流程
老實說, 測試左移不是一件簡單的事情, 但非常值得花時間跟精力來投資. 對於整個測試團隊來說, 有更多的時間去深入了解產品, 並且發想測試策略及改善測試方法. 而且, 還可以幫助測試團隊更容易的導入測試工具及技術.
提早測試也可以加更牢固地來鞏固產品的商業邏輯跟測試 Script, 並且驅動整個團隊投入自動化測試.
4. 減少開發跟測試的成本
除錯其實在軟體開發裡面是一項挑戰, 越後期發現的 Bug 有時候越難處理, 間接地投入成本也會提高. 舉個例子來說, 如果是一個 payment 的 SDK, 在預計上線前期發現一個嚴重的安全性問題, 公司勢必要投入更多的金錢人力精力來修復這個缺陷. 複雜的線上產品, 更難去除錯及修復, 更別說是後期維護所附上的代價.
5. 在真實世界修 bug 的代價.
我的偶像 Jserv 老師的 HackMD 有一篇很有名的資料整理, (軟體缺失導致的危害). 最有感的應該是 2017 年證交所異常熔斷. 短短一小時, 大立光觸發了交易系統 22 次熔斷. 原因是變數值超過了 UInt32 型別的限制. 進而產生記憶體溢位. 倘若我們在前期就能夠考慮 boundary Test, 並且將設定標準的 Benchmark. 就不用唱芭比Ｑ了.
這只是其中一個案例, 更別說是一秒鐘幾十萬上下的線上公司了.
同場加映: 軟體缺失導致的危害
https://hackmd.io/@sysprog/software-failure
6. 改善產品品質
當 Bug 以及問題都能夠在早期被討論, 發現及修復. 這也意味者測試人員, 開發人員及 Product Stackholder 有者密切的溝通及反饋. 這也確保在交付給客戶的產品是一個高品質且穩定的版本.
測試左移的最佳實踐
- 良好的 Planning
當產品需求都塵埃落定的時候, 開發及測試人員應該要盡可能地在前期開始計劃, 並且良好的規劃如何讓產品好測試, 例如將元素補上 data-test-locator. 讓整體的產品的易測試性提升.
2. 完整的了解產品需求
透過 Sprint Planning 我們盡可能的釐清產品需求跟知識, 確保團隊成員在產品開發環節不會有錯誤的認知, 發生認知誤差的低級錯誤如需求誤解、設計不當, 團隊沒對齊等.
3. 定義品質的標準
由於 Developer 並不是那麼深厚的測試基礎, 因此測試團隊應該要明確的定義品質的標準, 因此 developer 在執行測試時可以釐清 bug 的類型及狀態.
4. 擁抱測試自動化
開發團隊應該盡可能地將測試自動化, 這不僅能夠快速地知道 Code 的品質, 也能夠確保功能的正確性. 測試自動化是一個測試左移其中一個很重要的因子.
5. 導入測試工具
俗話有說, 工具善其事, 必先利其器. 嘗試去認識更多的工具, 幫助團隊建立起 CI/CD, 往偉大的航道前進.
總結:
測試左移在軟體測試已經是一個顯學, 筆者在目前的工作環境中也注重這個測試方法的實踐. 特別是筆者工作的環境中, 需要面對跨區域及跨時區的團隊協作, 任何把測試提早的事情, 都有助於公司減少成本, 並且幫助團隊前進. 改變是痛苦，但不改變會更加痛苦. 正在閱讀此篇文章的你/妳早點開始嘗試這個方法吧!
Bugs are cheap when caught young — Larry Smith
參考文獻:
值得品味:
