鋪墊：敏捷開發價值觀、原則與實踐
有什麼開發，就有什麼測試，傳統開發就有傳統測試，敏捷開發就應該要推行敏捷測試。在討論敏捷測試前，應該先理解敏捷開發模式，否則理解敏捷測試會很困難。
敏捷開發是一種思想或稱作方法論，通過不斷迭代與增量發布，最終交付符合用戶價值的產品。
書中提到一些敏捷開發的歷史、演進與框架
- PDCA 循環
- 輕量級軟體開發 減少複雜的文件，強調人員的互動
- 敏捷宣言
- XP（eXtreme Programing）：較多是著重在軟體開發，例如 TDD、pair programing、CI 等等。
- BDD（行為驅動開發）：使用「通用語言」來描述測試案例，將 User Story 的細節進行完整地描述。
Feature（特性）: 購物車功能
Scenario（情境）: 添加商品到購物車
- Given（假設）: 用戶已經登錄到購物平台並且正在瀏覽商品
- When（當）: 用戶點擊某個商品的「添加到購物車」按鈕
- Then（那麼）: 該商品應該被添加到用戶的購物車中
- And（並且）: 購物車中的商品總數應該更新
- FDD（特性驅動開發）：使用制式結構來建構特性列表
<action> the <result> <by|for|of|to> a(n) <object>
- Scrum：確保每天、每個階段都向著目標明確進行的一種「方法」。
推薦看 Scrum 提倡者自己寫的
SCRUM：用一半的時間做兩倍的事
DevOps 與敏捷的關係
DevOps 可以看作是敏捷的延伸，打通軟體開發、測試、交付、維護中的層層牆壁。
敏捷宣言
藉著親自並協助他人進行軟體開發，我們正致力於發掘更優良的軟體開發方法。透過這樣的努力，我們已建立以下價值觀：
- 個人與互動 重於 流程與工具
- 可用的軟體 重於 詳盡的文件
- 與客戶合作 重於 合約協商
- 回應變化 重於 遵循計劃
也就是說，雖然右側項目有其價值，但我們更重視左側項目。
敏捷測試之道
敏決測試不是一種測試方法，而是為了適應敏捷開發而設計的一套軟體測試解決方案。
敏捷測試宣言
- Full Lifecycle Testing OVER Isolated Testing Phase
- Team Shared Responsibility OVER Testers Ensure Quality
- Continuous Targeted Automation OVER Widespread Regression Testing
- Quality Built-in OVER Defect Detection
Full Lifecycle Testing
強調測試左移與右移，並非將測試「移動」到兩個端點，而是全程測試的介入。
- 左移：更好的理解需求，減少理解不一致的浪費。
- 右移：充分利用生產環境的數據來最佳化開發、測試流程。
Team Shared Responsibility
強調團隊一起為軟體品質負責。
Continuous Targeted Automation
強調不要一昧的追求程式碼測試的覆蓋率，是要追求精準的業務邏輯覆蓋率。 不讓軟體隨著程式碼的迭代，而被破壞。同時功能的迭代也會需要新增、修改測試的涵蓋。
Quality Built-in
測試是全程參與的，並非到了最後才在驗收。
固定性思維、成長性思維、敏捷思維
The power of believing that you can improve 其實敏捷思維就是（但不完全等同）成長性思維，回歸到測試領域，我們可以切換我們的 Test mindset
| 場景 | 固定性思維 | 成長性思維 |
|---|---|---|
| 被批評測試能力弱 | 我不是一個優秀的測試工程師 | 我目前的能力就是這樣，但我會努力 |
| Mgr 表揚了另一個測試工程師 | 我不如他 | 他是怎麼做得、我應該去問問他如何辦到的、我該如何超越他。 |
| 軟體上線後遇到問題 | 我就爛、或怪給開發人員。 | 我該如何避免再次發生。 |
| 任務太多了 | 我做不完 | 我該如何做得更快 |
Scrum 下的測試流程
持續測試：
- 測試需求分析與定義：確保 Story 是具有「可測試性」。
- 測試計畫：根據上下文調整、完整化測試目標、測試項目。
- 測試設計：粗粒度的測試設計，例如事件流程、狀態變化。
- BVT（版本建構測試）：包含冒煙測試、程式碼弱掃、靜態分析，確保這個程式是能被建構成版本的，通常是能自動執行的。
- 持續測試：PR、單元測試、回歸測試、性能測試等等都涵蓋在這裡面。確保了軟體的品質。
- 版本驗收測試：從業務邏輯出發的 e2e 測試。
- 測試交付與反思：找到測試不足的地方並完整化軟體測試。
其他敏捷測試的通用流程：BDD、TDD、ATDD、FDD 等等，不在此贅述。
不僅要把 bug 回報給開發人員，更要藉此去挖掘品質風險與問題的本質，例如可能是溝通有問題對需求沒有理解等等。
人是決定性因素
敏捷團隊究竟需不需要專職測試人員
Modern Testing Principle 的第七條：把測驗的方法和能力擴展到整個團隊，並認同團隊會逐漸減少或取消專職的測試專家存在。
微軟與 Google 幾乎沒有測試團隊，也很少專職測試人員，取而代之的是 Engineering productivity，不為產品做測試，而是為開發人員提供測試工具和技術。
顯然的答案不是簡單的要或不要。
什麼情況可以考慮沒有專職的測試人員
- 「品質內建」的團隊文化已養成，每個開發人員都為軟體品質負責
- 軟體是以 Saas 發布，具有灰度發布機制、能快速部屬與回滾。
- 軟體並非重要業務（例如金融與電信、航空、核能等等無法回滾的）
回顧「成長性思維」，每個人不是天生的專家，開發人員透過參與測試，便能累積軟體開發實需注意的眉角，回饋到開發上避免缺陷的產生。
測試負責人（Test Owner）
你公司不是 Google，你公司還不是 Google，你公司本來就不是 Google。
Test Owner(TO) 是以敏捷中最流行的 Scrum 方式來定義這個角色的名字 也可以稱為測試教練、測試顧問或者QA 叫什麼不重要，重要的是這個角色要承擔哪些責任：
- 制定軟體產品研發的迭代測試計劃
- 協調測試計劃的執行
- 促進提高軟體的可測試性
- 指導團隊成員進行測試工作
- 承擔部分QA責任
如何創建有強烈品質亦是的學習型團隊
該如何應對有限的專職測試人員的情況
- 擁有共同的目標：品質就是客戶的滿意度。例如阿里巴巴的品質文化就是「讓客戶百分之百放心」
- 營造良好的品質文化氛圍：例如騰訊每週從客服團隊抽 10 則客戶投訴的錄音來播放。
- 創建學習行團隊：要讓團隊成員「永不滿足於現狀」
如何更好地為測試而學習
- 系統性的思維訓練
- 創造性思維訓練
- 借力提昇自己
- 看大神的 blog
- 參與研討、會議、工作坊
產品、測試、開發如何協作
回顧一下敏捷宣言的第一項：「個人與互動 重於 流程與工具」，在談使用什麼工具前，應該先減少團隊內的困難。
達成共識後，溝通的技巧
- 要有勇氣回報品質問題
- 高情商： 比如在需求評估時，發現了需求的問題，不要說「我認為這個地方是不對的」，可以這樣說「假如我們是用戶，在某個場景下，如果碰到這種情況，我們大概會這樣處理，而不會那麼處理，對吧」
- 不要指望團隊會「自然」的更好，要持續努力前進。
建構強大的敏捷測試基礎設施
CI/CD、IaC，對 infra 也要進行測試（針對 IaC 的部份）
虛擬化技術的應用
- containerize
- sidecar
- numa & dpdk
- hoverfly
- molecule
- k8s
- 自動部署
- Ansible & Chef
- IaC 工具：Terrafrom & CloudFormation
- 管道即代碼（PaC）：Concourse & Drone（CI）
- Serverless
其他
如何完成全自動的 BVT 靜態測試與測試報告生成 單元測試框架
測試左移更體現敏捷測試的價值
TDD/ATDD/BDD/DDD
ATDD
Acceptance Test-Driven Development，接受測試驅動開發 並不是什麼高深的技巧，鼓勵團隊成員（包括產品擁有者、開發者和測試者）在開發過程的早期合作，以確定和了解需求。
寫單元測試不一定要採用 TDD，但開發需求不能不採用 ATDD。ATDD 之所以重要是因為大家都遇過：
- 需求分析還沒理解清楚、甚至還沒有定案，就- 進開發。
- 開發到一半發現哪裡怪怪的，才回去問 PM，發現根本開發錯方向。
如果一開始就把事情作對，那成本是最低的。這也是測試左移的精神所在
可測試性
需求的可測試性：在敏捷終究是 User Story 的可測試性，User Story 需要明確的描述，且需求要是可被測試的。
- 差：作為一個註冊用戶，我希望能快速登錄到系統。 問題：究竟快是多快，十個人有十種答案。
- 優：作為一個購物網站的買家，我希望可以查看查詢歷史訂單，以便查看某個訂單的詳細情形。
以下展開細節討論：
- 需要被查詢的歷史訂單是多久以前的？預設是一年的。
- 是否支持模糊查詢？是。
- 如果沒有查到，該如何提示？顯示零筆紀錄。
- 默認排序是？倒序。
不可忽視的設計評估
傳統開發下，測試人員很少參與設計評估，也會導致測試案例與需求與實做大相逕庭 更細一點會關注 Design Doc 內有沒有做冗餘設計、UI 套件能不能支援多數瀏覽器、涉及身份驗證的模組有沒有做權限控管等等
範例
場景：線上圖書館管理系統
假設我們正在開發一個線上圖書館管理系統。其中一個功能是，用戶能夠搜索並借閱書籍。
1. 定義需求
首先，產品擁有者、開發者和測試者共同定義用戶故事。例如，用戶故事可能是：“作為一個圖書館會員，我想要通過書名搜索書籍，以便找到並借閱它。”
2. 創建驗收標準
團隊合作創建驗收測試。這些測試應該是具體的、可測試的標準，它們描述了用戶故事的成功條件。例如，一個驗收標準可能是：“當我輸入‘哈利·波特’並點擊搜索時，系統應該顯示所有與‘哈利·波特’相關的書籍。”
3. 實施驗收測試
在開發功能之前，測試人員或開發人員會根據驗收標準寫出自動化的驗收測試。這些測試最初將會失敗，因為功能尚未實現。
4. 開發功能
開發團隊接下來會根據用戶故事和驗收標準開發功能。他們的目標是使之前編寫的驗收測試通過。
5. 重複測試直到通過
開發過程中，自動化的驗收測試會被不斷地執行，以確保新開發的功能符合需求。一旦所有的驗收測試都通過了，這個用戶故事就被認為是完成的。
6. 交付和回顧
完成的功能被交付給產品擁有者和用戶以進行確認。團隊可能會進行回顧，討論過程中的學習點和改進機會。
敏捷測試的分析與計畫
敏捷測試的主要風險在哪
無論用什麼技術與方法，測試都是不徹底的，我們無法保證經過測試的軟體不存在任何缺陷。
- 需求不清晰 溝通做得不好、沒有定義驗收標準、優先級定義有誤
- 需求頻繁變更 即便敏節能快速面對變更，但仍會需要變更 User Story 與優先順序
- 時間太緊張 再怎麼敏捷也無法只用一個月幹掉 OpenAI
- 自動化測試的有效性 例如 3rd API，若第三方破壞性的變更了 req/res，那測試也會壞掉 自動化時間過長，提供反饋的速度較慢
探索式測試與基於腳本的測試
探索是測試也就是打開 APP/WEB，開始亂點亂按，「自由」的進行測試，最極端的探索性測試就是連猴子都會用。 基於腳本的測試則為照著定義好的路徑走一遍，最極端的 ST 則為程式碼的自動化測試。
敏捷擁抱探索性測試，回歸到敏捷宣言：可工作的產品 勝於 詳盡的文檔，操作起來很怪的產品，即便 unit test 寫的 100% coverage 還是大便。
敏捷測試的設計與執行
這個章節稍微介紹了 DoD
Story：作為購物網站的買家，我要通過商品名稱查詢歷史訂單
驗收標準：
- 預設查詢過去一年的訂單
- 如果沒查到，詢問用戶是否選擇一個查詢的時段，不選擇就退出
- 用戶可以任意選擇起始、結束，以十年內為限，跨度不超過三年。
- 支持模糊查詢
- 按匹配度來排序，其次為時間
- 每頁最多十筆
- 只顯示訂單編號、訂單名稱、價格、日期
- 點擊可以查看訂單詳情
轉換為場景（使用者路徑）
- 什麼都沒輸入
- 輸入關鍵字、選擇了時段（無效時段）
- 輸入關鍵字、選擇了時段（有效時段）
- 輸入關鍵字、沒有選擇時段 -> 沒有查到結果
- 輸入關鍵字、沒有選擇時段 -> 有查到結果 -> 點擊詳細頁面後退出
- 輸入關鍵字、沒有選擇時段 -> 有查到結果 -> 點擊詳細頁面後退出 -> 再點擊另一個
再來介紹了事件流與有限狀態機
探索式測試
主要是來檢驗傳統測試上可能被忽略的測試。
帶著批判性思維來進行探索，這邊的批判性並非是溝通上的尖銳，而是指不斷「提出」問題（質疑系統）並構思使用者會不會被指引到錯誤的路徑。
角色扮演
例如 Udemy 類型的線上課程 APP
- 30 歲 996 單身男工程師，每天大眾交通通勤上下班，消費能力驚人，會購買大量的課程但沒有時間看。
- 16 歲天才男高中生，每天姐一堆數學問題，可能不會花這麼多錢在購買課程上，但會花費大量時間在反覆閱讀艱澀的課程。
- 25 歲黑客，專門在跨過付費牆，即便這是非法的。
探索未知的，自動化已知的
測試右移，從敏捷到 DevOps
線上壓力測試
- 情境
- 雙 11
- 巴魯司
- 流量回放： 模擬真實流量、放大或縮小流量 https://github.com/buger/goreplay
- 調用鏈：tracing
- 混沌工程：例如 Chaos Monkey，隨機中止生產環境的機器，進行災難演練。
敏捷測試的收尾與改進
如何分析測試結果與評估測試工作的品質
從理論上來說有很多面向，覆蓋率、缺漏率、測試效率、驗證週期
以敏捷的角度來說：看重什麼，就度量什麼；想提高什麼，就度量什麼。
- 程式碼覆蓋率
- 功能覆蓋率：所有測試案例分解為子功能、子子功能後，每個小 function 的 function point：test case 的 function point / total function point。
- 業務覆蓋率：使用者路徑的覆蓋率：已覆蓋的場景/需要測試的場景。
- 缺陷分析測試品質：誤報率，無效的 bug / 總回報的 bug
敏捷過程的反思與持續改進
守-破-離：
- 守：固守最佳實踐，也可以照搬成熟的方法、框架。
- 破：慢慢領悟背後的原因，在結合自己的團隊進行改變。PDCA
- Plan
- Do
- Check
- Action
- 離：不斷實踐、創新、再實踐，慢慢形成自己的敏捷測試方法，脫離既有框架。
敏捷測試的展望
人工智能助力敏捷測試
- 基於圖片識別，協助 UI 測試
- 測試數據、測試腳本自動生成
- 程式碼深度分析
敏捷測試工具的未來
- 智能化
- 雲化
- 機器人過程自動化
- 模型化
- 新的技術領域（萬物互聯）
- 無代碼化
- 敏捷化