近期看到文章中提到「Shift Left」的名詞，好奇的研究了一下這個概念，也跟幾位開發工程師和測試工程師討論了一下，這篇文章用來記錄這次學到的一些東西，如果有理解錯誤的地方，還請不吝指正。
要解決的問題
在傳統的軟體開發生命週期(SDLC)中，測試環節在開發完畢後才開始進行，可能會導致一些不得不修改的Bug到了這時候才發現，而這時候Debug的時程壓力就會非常大，難免有些疏漏，甚至無法顧及程式碼品質先趕鴨子上架再說。
有個做測試的朋友分享了他的經驗，他曾經在測試時才發現工程師開發的功能與需求幾乎不符，而這時才發現這個問題相當頭痛，也需要付出額外的時間修改甚至要打掉重練，若能提早發現就能避免問題繼續擴大。
左移測試 (Shift left testing)
強調在SDLC的早期進行測試活動，而不是等到最後階段，是一種主動測試的方法，越早發現問題可以越早解決，降低未來發現問題的修復成本，並提升產品的品質。
如何進行
團隊需要對產品效能、客戶需求及使用者期望做透徹的研究。
以及QA Team和Dev Team：
QA Team
- 在開發前的規劃階段就請QA參與，以了解需求並設計測試案例
- 參與介面與架構設計階段
- 在考慮可測試性的情況下給予Coding的建議
Dev Team
- 導入自動化測試如單元測試、整合測試
- API測試
- Code Review
- CI / CD
- 測試驅動開發(TDD)
- 行為驅動開發(BDD)
右移測試 (Shift right testing)
在產品上線後才進行測試活動，主要關注在線上環境中的監控與回饋，深入瞭解解可用性與使用者體驗，以提升使用者體驗與線上產品穩定。
灰度測試和A/B測試
用來確定使用者偏好哪一個版本
金絲雀測試
只讓少部分使用者當白老鼠^_^
兩者是否能同時進行呢?
Shift left和Shift right並不互相衝突，兩者相輔相成
左移可以更有效地促進開發人員和測試人員之間的協作
右移有助於縮小測試人員、開發人員與維運團隊之間的差距
目前團隊的作法
我們是用Scrum來實現敏捷開發的團隊，由於目前沒有測試工程師，所以測試工作都是由開發工程師兼任。
- Design Sprint由工程師與UI/UX設計師一起進行設計，所以有參與設計的工程師都清楚客戶需求與使用者的期望。
- 開發階段通常是由原本參與設計的工程師進行開發，Spec文件也是由工程師撰寫，最後會再跟PO和所有DT成員確認有沒有遺漏。
- 開發時撰寫單元測試，有些工程師甚至用TDD的方式進行
- 開發完成後進行Code Review
- 後端和網頁端有跑CI / CD的流程 (APP目前還沒有)
- 接著再由團隊內的工程師依照Spec進行測試
在我了解測試左移之後才發現原來我們團隊一直都在實踐這個概念，但常常還是覺得到了測試的時候有些瓶頸的感覺，需要花蠻多時間進行人工測試，而且通常也都是到了Sprint最後幾天，也還是有點時程壓力。
不知道有沒有其他團隊也遇到相同問題？又是如何解決的呢？如果可以的話，可以和我分享你們團隊的做法嗎？
