close
今天整理一些東西, 看到一個名詞: Shift Left Testing. 平時自己為對測試懂得不少, 沒想到居然完全不曉得這是什麼, 並且從字面上也猜不出來. 只好乖乖 google, 來學學新東西.
在傳統開發方式, 測試活動的開始, 通常是在開發階段的後期. 那時候才開始進行測試, 不但錯誤不容易找, 找到之後修復所要花的代價也不低, 因為都忘了以前在寫什麼, 系統也變得複雜了. 更糟糕的是, 如果開發延遲了, 測試的時間便完全被壓縮了, 測試是需要時間去認識系統, 花時間去挖出更深入的問題, 時間太短是無法找出太多的問題. 所以傳統測試方式, 是有很多問題存在.
因此, 所謂的 Shift Left Testing 的觀念, 就是希望測試的提早發生, 並且能夠能夠經常舉行. 目前來說, 常見的 Shift Left Testing 有以下作法
1. 傳統的 Shift Left 測試
以前進行測試時, 比較強調用戶驗收測試, 或者是進行系統測試來處理非功能的部分. 如果是 shift left 就是朝向 unit test 和 integration test 來進行(V model 的右側下方). 目前, 大多數的團隊已經能做到這件事情.
2. 漸進式的 Shift Left 測試
目前很少團隊是標準的瀑布式開發, 也就是完全依序進行. 現在大多是會夾雜著增量的概念, 也就是在發佈前, 會有個 2-3 次的里程碑. 每次的里程碑, 便可以用前面一種方式, 來進行 shift left 測試, 讓你可以對每個增進早點進行測試. 這種做法, 也不少團隊能夠做到.
3. 敏捷/Devops 的 Shift Left 測試
敏捷/Devops 的開發方法, 就是要求更多更小的迭代, 所以第二種 shift left 測試的做法會被用得更徹底. 並且, 開發人員使用 TDD 或是 test first 等作法, 開始朝向 V model 的左側發功. 目前第三種做法, 是現今最流行, 可能還會火紅一陣子.
4. 模型為主的 Shift Left 測試
在這個方式中, 針對可執行的需求(executable requirements), 架構, 或是設計的模組進行測試, 因此在程式沒有真的寫出來之前, 開始確認其正確性. 這種做法太高級了, 應該很少團隊有這種能力吧!!
那到這裡, 你有沒有覺得老外好會發明新的名詞, 或許本意沒差太多, 但是總是有新說法. 嗯, 讀書好累.
那有沒有人問說, 有 Shift left, 那有 Shift right 嗎? 當然有, 不過不想寫了, 自己去 google 吧 XDD
參考資料
全站熱搜
留言列表
