身處在需求做不完，客戶一個比一個兇的前線，書亂看、招亂學、說敏捷說了快一年，結果所屬的 Mission Team 仍是 Waterfall 的代表，身為測試人員怎能再繼續被動？ 作為一個最能看見全貌的測試人員，自主開始做起敏捷測試的第一個迭代。從實際遭遇的問題發起，講述著一個小小測試人員思考與掙扎的過程。最後，透過高人指點得來的《敏捷軟件測試》與《深入敏捷測試》這兩本書，加上個人在實踐過程中依據經驗的應變，僅管只有兩個月不到的時間，仍執行了需求回顧、自動化測試，以及探索性測試。 此次分享適合產品、開發、測試人員，或是未來有志投入軟體業的新鮮人。期望在這短短的幾分鐘內，讓大家能瞭解敏捷測試實際上會遇到什麼困難，設想如何避免讓自己深陷其中。

1. 初入敏捷測試的困境
師孝
S.H. Peng
2019-09-26

2. 講者簡介
● 資訊傳播 & 資訊管理
● 看書
● 到處聽聽看看
● 91APP - QA
● 自許為 Agile Tester
● 為了讓自己發揮所有的才能

3. 講題簡介
• Waterfall 下的敏捷
• 測試人員思考與掙扎
• 敏捷測試實踐與應變
• 實際上遇到什麼困難
• 設想如何避免深陷其中
black car stuck on mud

4. ● 如何避免深陷其中
○ 更多學習與反思
○ 下一步：改善
● 實踐與困難
○ 測試計畫
○ 需求審查
○ 自動化測試
○ 探索性測試
● 思考與掙扎的過程
○ 瀑布下的敏捷
○ 問題 問題 問題
○ 煩惱
● 故事背景
○ Mission Team
○ QA
○ Waterfall
大綱
● Agile Testing
○ 敏捷軟宣言與敏捷測試
○ 敏捷測試與實務
○ 如何做到敏捷測試
● 結論
● Q&A

5. 瀑布 Waterfall
Requirement
Design
Development
Testing
Deployment
Maintenance

6. 瀑布 Waterfall
Scope
Resources Time
Quality
Fixed
Estimated

7. 瀑布 Waterfall
Scope
Resources Time
Quality
Fixed
Estimated Limited

8. 思考與掙扎的過程
做事之前，還是得要先做人 —— 我說的

9. Scope
Quality
敏捷 Agile
Resources
Time
Fixed
Estimated
迭代
增量

10. Scope
Quality
敏捷 Agile
Resources
Time
Fixed
Estimated
迭代
增量
？？？
要我怎麼說服客戶？
客戶要滿意
(謎一樣的需求)
？？？
要我怎麼說服客戶？
客戶要驗收
(壓 Deadline)

11. Scope
Quality
瀑布下的敏捷
Resources
Time
Fixed
Fixed
Sprint
(2 weeks)
？？？
要我怎麼說服客戶？
客戶要滿意
(謎一樣的需求)
？？？
要我怎麼說服客戶？
客戶要驗收
(壓 Deadline)
Scope

12. 然而
QA
只有一個

13. 問題來了
壓力
缺陷
技術債

14. 壓力
CLD (Causual Loop Diagram, 因果循環圖)
缺陷
技術債
生產力
增強
(Reinforce)
原 則
O (-)
信 心
S (+)

15. 壓力
CLD (Causual Loop Diagram, 因果循環圖)
缺陷
技術債
生產力
增強
(Reinforce)
原 則
O (-)
信 心
S (+)

16. 煩惱

17. QA的煩惱

18. Q
A
P
OR
D
測試?
？
One Test-Man

19. No!
可惡啊 ——
是不是在搞我啊 ——

20. Agile … hmm…
Agile Testing …?
Until one day…

22. 從開始到交付
協作測試的實踐
支持頻繁交付
為客戶增加業務價值的優質產品
著重於缺陷預防而不是缺陷檢測
加強並支持團隊對品質負責的想法
敏捷測試

23. 通過具體實例指導開發
透過問題來檢驗想法與假設
自動化測試
探索性測試
其他品質屬性
(性能、可靠性、安全性等)
敏捷測試的實務

24. 如何做到敏捷測試
有沒有一種方法，能在目標與實踐之間比較不容易有誤差呢?

25. Impact Mapping
WHY
缺陷預防
－－－－－－－
壓力
短期內無法消除
技術債
更是固定在那

26. Impact Mapping
WHO
QA
－－－－－－－
RD, PO
他們已水深火熱
WHY
缺陷預防
－－－－－－－
壓力
短期內無法消除
技術債
更是固定在那

27. Impact Mapping
HOW
關注全局
測試左移
快速反饋
－－－－－－－
期望讓 QA(我)
能達到缺陷預防
的目標
WHY
缺陷預防
－－－－－－－
壓力
短期內無法消除
技術債
更是固定在那
WHO
QA
－－－－－－－
RD, PO
他們已水深火熱

28. WHY
缺陷預防
－－－－－－－
壓力
短期內無法消除
技術債
更是固定在那
Impact Mapping
WHO
QA
－－－－－－－
RD, PO
他們已水深火熱
HOW
關注全局
測試左移
快速反饋
－－－－－－－
期望讓 QA(我)
能達到缺陷預防
的目標
WHAT
- 測試計畫
- 需求審查
- 自動化測試
- 探索性測試
－－－－－－－
藉由具體可行的
實務來促進關注
全局、測試左移
與快速反饋

29. 實踐與困難
關注全局、測試左移、快速反饋

30. 關注全局：測試計畫
範例：不同於現金折抵，可藉由打折促進購物的折價券
疑問
● 專案的脈絡？
● 測試的目的？

31. Agile Testing Quadrants
Functional Tests
Examples
Story Tests
Prototype
Simulations
Exploratory Testing
Scenarios
Usability Testing
User Acceptance Testing
Alpha/Beta
Unit Tests
Component Tests
Performance & Load Testing
Security Testing
“ility” Testing
Auto. &
Manual
Auto.
Manual
Tools
Business Facing
Technology Facing
SupportingtheTeam
CritiqueProduct

32. Agile Testing Quadrants
Business Facing
Technology Facing
SupportingtheTeam
CritiqueProduct

33. Agile Testing Quadrants
Functional Tests
Examples
Story Tests
Prototype
Simulations
Exploratory Testing
Scenarios
Usability Testing
User Acceptance Testing
Alpha/Beta
Unit Tests
Component Tests
Performance & Load Testing
Security Testing
“ility” Testing
Business Facing
Technology Facing
SupportingtheTeam
CritiqueProduct

34. Agile Testing Quadrants
Functional Tests
Examples
Story Tests
Prototype
Simulations
Exploratory Testing
Scenarios
Usability Testing
User Acceptance Testing
Alpha/Beta
Unit Tests
Component Tests
Performance & Load Testing
Security Testing
“ility” Testing
Auto. &
Manual
Auto.
Manual
Tools
Business Facing
Technology Facing
SupportingtheTeam
CritiqueProduct

35. Agile Testing Quadrants
Functional Tests
Examples
Story Tests
Prototype
Simulations
Exploratory Testing
Scenarios
Usability Testing
User Acceptance Testing
Alpha/Beta
Unit Tests
Component Tests
Performance & Load Testing
Security Testing
“ility” Testing
Auto. &
Manual
Auto.
Manual
Tools
Business Facing
Technology Facing
SupportingtheTeam
CritiqueProduct
檢查.
預期輸出.
分析.
未定義的、
未知的、
意料之外的.

36. 範例：
不同於現金折抵，
可藉由打折促進
購物的折價券
疑問
● 專案的脈絡？
● 測試的目的？
Mindmap (by Coggle)

37. Document (by Spreadsheet)

38. 關注全局：測試計畫
範例：不同於現金折抵，可藉由打折促進購物的折價券
疑問
● 專案的脈絡？
● 測試的目的？
困難
● 視覺化不足
● 深度與廣度的拿捏

39. 測試左移：需求審查
範例：可由打折促進購物的折價券，各種禮別與前台都要支援
疑問
● 客戶最想要的是什麼？
● 所有的需求都有價值嗎？

40. User Story Mapping
高
低

41. 測試左移：需求審查
範例：可由打折促進購物的折價券，各種禮別與前台都要支援
疑問
● 客戶最想要的是什麼？
● 所有的需求都有價值嗎？
困難
● 缺乏領域知識
● 需求難割捨
● 地下需求

42. 快速反饋 1：自動化測試
範例：為促進部分商品業績，可指定折價券的可使用範圍
疑問
● 功能正常的狀況？
● 是否有副作用？
Unit
API
GUI
Manual

43. 範例：為促進部分商品業績，可指定折價券的可使用範圍
快速反饋 1：自動化測試
既有新增折價券頁面
1. 基本設定：活動名稱、活動說明、活動目的、領取方式 ... 等, 共 10 項
2. 領取序號設定：多張共用、每張單獨 …, 共 2 項
3. 折價券使用設定：可使用通路、核銷券號類型、券號條碼設定 ... 等, 共 10 項
4. 折價條件設定：折扣類型、面額、張數 … 等, 共 6 項

44. 範例：為促進部分商品業績，可指定折價券的可使用範圍
快速反饋 1：自動化測試
既有新增折價券頁面
• 路徑組合參考
– 10 x 2 x 18 x 6 = 2,160
– 去除重複路徑
• 對後台：僅需 8 組
• 加上前台開發測試需求：33 組
• 價值：
• 確保業務、測試資料快速建立、
投入更有價值的探索測試

45. 快速反饋 1：自動化測試
範例：為促進部分商品業績，可指定折價券的可使用範圍
疑問
● 功能正常的狀況？
● 是否有副作用？
困難
● 與開發不同步
● 測試不透明
● 本身就不完美
Unit
API
GUI
Manual

46. 快速反饋 2：探索式測試
範例：為促進部分商品業績，可指定折價券的可使用範圍
疑問
● 需求範圍未定義的？
● 潛在風險？

47. 範例：為促進部分商品業績，可指定折價券的可使用範圍
快速反饋 2：探索式測試
● 前提：購物車 UAT（手動）
● 目標：折扣金額攤提與購物流程
● 接續採用 Session-based Test Management 的探索測試
○ 主題 (Charter)：
■ 購物流程中，使用或不使用折價券，以發現任何阻礙購物的缺陷
○ 時間盒 (Time Box)：1 小時
■ 發現：需求遺漏了折價券預選邏輯

48. 範例：為促進部分商品業績，可指定折價券的可使用範圍
疑問
● 需求範圍未定義的？
● 潛在風險？
困難
● 麻痺
● 缺乏領域知識
● 看重個人資質
(後來被測出其他缺陷)
快速反饋 2：探索式測試

49. ● 關注全局
○ 測試計畫
回顧
● 測試左移
○ 需求審查
● 快速反饋
○ 自動化測試
O 專案脈絡、測試目的 X 視覺化不足、深度與廣度
O 優先序與MVP、
確認需求價值
X 缺乏領域知識、難割捨、
地下需求
O 確保功能正常、
增加探索測試時間
X 不同步、不透明、不完美
O 降低風險、增加信心、
回顧與改善測試
X 麻痹、缺乏領域知識、
看重個人資質
○ 探索式測試

50. ● 關注全局
距離「缺陷預防」似乎有一段路
● 測試左移
● 快速反饋
O 專案脈絡、測試目的
O 優先序與MVP、
確認需求價值
O 確保功能正常、
增加探索測試時間
O 降低風險、增加信心、
回顧與改善測試

51. 而且很累
X 視覺化不足、深度與廣度
X 缺乏領域知識、難割捨、
地下需求
X 不同步、不透明、不完美
X 麻痹、缺乏領域知識、
看重個人資質

52. 如何避免深陷其中
才剛開始就放棄，這樣子實在是太可惜了。

53. 更多學習與反思
回去翻第二遍

54. 這次經驗過後最有感觸的
● 測試是一種活動，而不是一個階段。
● 以團隊的方式來解決問題。
● 角色之間的界線是模糊的，所有人都關注品質。
● 專注於交付結果和影響，而不是功能。
● 告訴管理者我們事實上可以完成什麼，並幫他們優先考慮具最高價值的工作。

55. 回過頭來看
X 視覺化不足、深度與廣度
X 缺乏領域知識、難割捨、
地下需求
X 不同步、不透明、不完美
X 麻痹、缺乏領域知識、
看重個人資質

56. WHY
缺陷預防
－－－－－－－
壓力
短期內無法消除
技術債
更是固定在那
Impact Mapping
WHO
QA
－－－－－－－
RD, PO
他們已水深火熱
HOW
關注全局
測試左移
快速反饋
－－－－－－－
期望讓 QA(我)
能達到缺陷預防
的目標
WHAT
- 測試計畫
- 需求審查
- 自動化測試
- 探索性測試
－－－－－－－
藉由具體可行的
實務來促進關注
全局、測試左移
與快速反饋

57. 下一步：改善
培養攻守兼具的團隊，打通內外痛覺的傳遞。

58. －－－ 協助↓－－－
支持MVP與增量
拆好 Story
痛覺往上帶
Impact Mapping 2.0
－－－ 協助↓－－－
思考如何測試
支持MVP與增量
WHY WHO HOW WHAT
缺陷
預防
QA
RD
PO
Manager
關注全局、測試
左移、快速反饋
測試計畫、需求審查、
自動化測試、探索式測試
－－－ 促使↓－－－
一起討論如何測試
提出可能的 MVP
－－－ 促使↓－－－
引導區分必要和需要
一起討論商業需求優先序
勇敢提出問題與行動
－－－ 協助↓－－－
痛覺擴散
減少固定 Scope
－－－ 促使↓－－－
指出捷徑的風險與代價
呈現真實的 Story 數量

59. 結論
1. 品質不是測出來的

60. 結論
2. 沒有什麼神奇的敏捷測試實踐能保證取得成功

61. 結論
3. 保持正向與積極

62. Q&A