# 在 DevOps 的路上測試該怎麼進行 - David Ko 敏捷三叔公

{%hackmd @DevOpsDay/BJXaW1_k6 %}

## 調查：

開發：較多
測試：較少

## 自我介紹：

- 接觸 Scrum
- 2009 年成立社群
- 2012 辦活動到現在

## 大綱

- 產品開發流程趨勢
- 測試所帶來的影響
- 新新測試流程
- 關鍵的測試策略

## 新技術接受度高

AI/Cloud 相關技術成熟 --> 你用我用大家都在用

## 商業要滿足三種角色

- 客戶
- 問題可即時反應
- 更快獲得解法
- 投資者
- 黏著度較高 (訂閱制)
- 收入可預測
- 員工
- 瞭解客戶用法
- 不用維護舊版


## 開發流程的目標

- **善用資料**
- **更快**交付**高品質**的解法
- **幫助客戶成功** (賺不到錢，講再多都沒用)

## 沒空寫自動化測試

(當下確認大多是兩週一次迭代)

開發代碼(手動測試) => 開發代碼(手動測試) => 開發代碼(手動測試)
Sprint N-1 Sprint N Sprint N+1
自動化測試?? 自動化測試??

迭代時間短，只能開發完程式


## 回歸測試次數變多

- 隨著迭代的次數越多，測試人員要測試的項目越來越多

## 測試環境組合變多

- Windows/Linux/MacOS
- AWS/GCP/Azure
- 裝置
## 沒空進行其他測試

- 效能測試
- 安全測試
- 靜態測試
- 設計檢視
- 程式碼檢視
- 驗收測試
- Beta 測試

## 換手遊戲

產品經理 -> [ (開發人員 測試人員) -> 運維人員 ]

工作不變，只有職稱變

---

多人接手、換手，導致資訊失真
- 開發和測試合在一起，想辦法開發測試一條龍

- 只是名稱換、工作不變，並不互相協作

## 沒有全局觀

SA/PM 談需求通常是黑洞

- 大部分的人只看到局部，沒有看見全貌，開發只有一點時間，前面的需求探索是一個黑洞，需求/開發測試/部署監控，不知道各自做到哪一塊，這樣的過程中，很難取得回饋

- 狀態黑洞
- 不同管理工具
- 沒有統計資料
- 無法相互回饋

## 大綱

- 產品開發流程趨勢
- 測試的部分跟開發怎麼做結合
- Scrum 會先進行一個會議 Product Backlog，開發前，先了解需求
- 對測試帶來的影響
- 新測試流程
- 關鍵的測試策略

## Scrum 開發流程與測試活動範例

1. PBR - Product Backlog Refinement
確認需求 & 撰寫AC
2. Sprint Planning
PM確定需求，和RD討論可完成的項目
3. 問題提出 & 同步資訊
持續測試設計，執行
設計/程式的檢視
故事的驗收測試
版本的驗收測試
功能/非功能/回歸/探索測試
5. 持續測試設計, 執行 UT, TDD, BDD,CI
6. 設計/程式的檢視
7. 故事的驗收測試
8. 版本的驗收測試
9. 功能/非功能/回歸/探索測試
10. 展示
11. 測試交付＆反思

---

## Sprint 內的自動化測試活動範例

一個迭代裡面，會分成兩種測試路徑

## Sprint 之間的測試活動範例


通常單元測試會包含在該迭代，由開發人員執行，測試人員在與開發人員同一個迭代時，測試人員的責任是快速的提供反饋給開發人員，下個迭代才開始進行自動化測試的建立，跨功能型的測試會擺在比較後面的迭代去進行。

## 測試階段與活動

Hardening Sprint: 後面會有一些迭代專門用來做測試

Sprint Demo -> 自吃狗食 -> External Beta

## 端對端過程的測試實踐


- 測試左移
- 迭代中的持續集成(CI)
- 迭代中的持續測試
- 測試右移

## 整體原則

- 團隊負責重於 ＱＡ 負責
- 持續測試重於最後測試

> 今天要做的測試有這麼多事情，不太可能把所有事情都壓在測試人員身上，應該是所有團隊成員一起參與。

## 團隊人員的技藝

梳型人 (提升技術廣度)

- 基礎知識要廣 (X軸)

- 獨門技術要深 (Y軸)

- 多多益善維運, 自動化

## 要學/做你不會的

- 在認養工作的時候，要做一些你之前沒有做過的事情
- 測試人員
- 要會自動化，否則就殺頭
- 開發者建議去開 test case
- 要會有用的測試個案

80/20 法則，至少開始學習一些之前不會的事情

## 母雞帶小雞

- 資深測試人員
- 80% 手動 20 自動
- 擅長做測試
- 資淺測試/ 開發人員
- 80% 自動 20 手動
- 擅長寫程式
- 顧時程

## 持續測試重於最後測試

## 善用靜態測試(測試左移)

- 想辦法要在前面在 review 的過程中，就找到問題
- 後面在做測試的時候，盡量一次就過關
- 如果找到很多 bug，後面要花很多時間去修改
- 前面盡量討論，避免後面才找到很多錯誤

## 安排安東繩機制(提早處理機制)

- 如果遇到哪一個地方有問題，就會拉繩子，會把生產線整個停掉，把問題修正之後，才又重新開始生產
- Ref: https://zh.wikipedia.org/zh-tw/%E5%AE%89%E7%81%AF%E7%B3%BB%E7%BB%9F

安東繩 = CI管道 + 紅色警戒 + 紀律

- 靜態分析
- 建構
- 安裝
- 冒煙測試

## 有計畫書不重要

- 去做規劃的時候，不太可能一開始就去想對想清楚
- 要測試一個 test 要五分鐘，修一個 bug 要十分鐘
- 如果測試估不準，都是 RD 害的

不太可能靠測試把關，應該在前面盡可能的不要犯錯。

## 自動化策略

- 把自動化視為軟體開發
- 自動化的代價在啟動與維護
- 後面可能會改 A 錯 B
- 很吃架構師的技能

- 功力強的開發人員 - 開發模版、訂開發規則及架構
- 功力弱的開發人員，照著做，增加測試個案/資料數量

## 全民皆兵

## 要開始而非追求完美

## 及早開始及時回饋

- 瀑布式是在後期才會有大量bug (因為開發完才開始測試)
- 敏捷則是一邊寫一邊測試, 因此數量很平均
- 功能寫好，就開始測試

## 結果要有代價

- 重點不在多，在於準

---

## 測試金字塔

Unit Test(越多越好) -> Service Test -> UI Test

## 聖杯比例


---

價值導向 重於 做好做滿

## 新新測試策略

- 整體原則
- 團隊負責
- 持續進行

- 視為軟體開發
-

## 如何開始第一步

1. CI 先建起來，每天至少兩次，加自動化測試會更好
- 及早建構
- 每天至少兩次
- 加自動化測試更好
2. 實例化需求，一旦規格錯，後面怎麼做都是假的，及早對需求共識，並讓不同角色加入討論。
- 及早找出共識
3. 探索測試
- 用較少的時間，想辦法找到最多的 Bug，讓開發可以加入

----

## 聊天室

跪求前排幫拍投影片, 後排太遠惹