Section 1. 如果重來, 我會這樣導入持續測試
什麼是持續測試?
持續測試是一個過程, 它將自動化測試放進軟體開發之中, 不斷的反覆進行, 以期儘早的業務風險的回饋。
ref:
持续测试与自动化测试的区别是什么？
Automation Test 不是敏捷導入所要做的第一件事
- 應該先改 Test Flow
- 縮短回饋時間 Lead time, cycle time
- 了解流程全貎
在產品設計時就提供實例化規格
Why?
How?
- Example for Spec.
- PM/PO/Team 的訓練
讓 User 做測試
這一點是有趣的地方,提到利用金絲雀部署 -> Monitor (建立指標) -> Feedback --> Fix
- 與其卡在 QA 出不去, 不如讓使用者幫忙測試
- 金絲雀部署, 5% 的 user 也比整個 QA Team 還多
- 沒人用的功能, 錯了也沒人知道
用原生的測試框架
測試人員的技術與 Develop 重疊, 彼此能有正向的聯結 (減少 solio)
ATDD
對 Develop Team 的技術及能力要求很高, 不容易做到
目標先不對準 Live Documents, 而是做好 acceptance criteria
Git Branch Flow
Git Flow 的問題是 Long-lived branches, 不利整合
用 tunk branch 可以強迫團隊合併持續整合
導入樂高建構法, 寫完什麼就 commit 什麼, Feature 如果不要發, 就藏在 debug mode 裡
持續測試的週期
<–需求–|--產品設計–|--開發–|--測試–|--監控結果–|--維護–>
- 需求階段: 測試人員參與討論
- 產品設計階段: 一起寫 user story, 用 example spec.
- 開發階段: 與 Developer 用共同語言的測試框架
- 測試階段: 自動化測試
- 監控結果: 建立監控指標, 每次發佈都有指標可以比較
- 維護階段: 建立回饋機制
Section 2. 從工程角度, 挖出產品風險
讓團隊了解指標的意義
- 先視覺化業務的結果 (report, dashboard 像1111一樣)
- 建立指標 (了解 dashboard 上的數字高低對系統的意義是什麼)
平常時不監控, 事情發生就無感
做這些事的過程:
經驗流程化 -> 流程工具化 -> 主動發現問題
不要指望明星球員
- 明星球員離職對團隊影響大
- 明星球員在場, 團隊會依賴明星球員, 團隊不會成長
我想的是: 如果讓每個人都是備選的明星球員, 隨時都能補位?
吃狗食
QA 角色定位是指出測試不足之處, 不是幫 Developer 寫測試 code
流程導入的建議
- 了解大家不用的原因
- 把門檻降低
- 大家願意之後, 刻意練習
- 同步大家的水平, 減少不必要的紛爭
Section 3. Agile UX
設計帶來改變
設計用來協助解決 Fuzzy Problem ===> Innovative Solutions
1. Mind the Gap 全區思考, 留意間隙
有意識的留意 Gap
- Business vs User
- MVP vs Holistic UX
MVP 也要是 end to end 的體驗
如何消除 Gap?
- 同理心之旅
- 溝通要二方都被尊重, 在對意見投票時, 留給 Stakeholder 較大的決策權, 避免被霸凌
辦 Workshop 的方式
- 為什麼辦?
- 對象是誰?
- 辦了之後, 可能會有什麼問題?
辦 Workshop 要成功的關鍵在前期規劃
2. Run with Brian 謀定而後動, 知止而有得
- Discover & Define (Sprint 0, 用來探索)
- Design & Deliver, 設計與開發像麻花捲, 前後 sprint 滾
3. Close the Loop 反覆打磨, 止於至善
- 持續得到回饋(讓外部 user 持續來用)
- Real retro
幾個推薦的 Process or User Group
Section 1. 如果重來, 我會這樣導入持續測試
什麼是持續測試?
持續測試是一個過程, 它將自動化測試放進軟體開發之中, 不斷的反覆進行, 以期儘早的業務風險的回饋。ref: 持续测试与自动化测试的区别是什么？
Automation Test 不是敏捷導入所要做的第一件事
在產品設計時就提供實例化規格
Why?
How?
讓 User 做測試
這一點是有趣的地方,提到利用金絲雀部署 -> Monitor (建立指標) -> Feedback --> Fix用原生的測試框架
測試人員的技術與 Develop 重疊, 彼此能有正向的聯結 (減少 solio)ATDD
對 Develop Team 的技術及能力要求很高, 不容易做到目標先不對準 Live Documents, 而是做好 acceptance criteria
Git Branch Flow
Git Flow 的問題是 Long-lived branches, 不利整合用 tunk branch 可以強迫團隊合併持續整合
導入樂高建構法, 寫完什麼就 commit 什麼, Feature 如果不要發, 就藏在 debug mode 裡
持續測試的週期
<–需求–|--產品設計–|--開發–|--測試–|--監控結果–|--維護–>Section 2. 從工程角度, 挖出產品風險
讓團隊了解指標的意義
- 先視覺化業務的結果 (report, dashboard 像1111一樣)
- 建立指標 (了解 dashboard 上的數字高低對系統的意義是什麼)
平常時不監控, 事情發生就無感做這些事的過程:
不要指望明星球員
- 明星球員離職對團隊影響大
- 明星球員在場, 團隊會依賴明星球員, 團隊不會成長
我想的是: 如果讓每個人都是備選的明星球員, 隨時都能補位?吃狗食
- 自己的東西自己測試
QA 角色定位是指出測試不足之處, 不是幫 Developer 寫測試 code流程導入的建議
Section 3. Agile UX
設計帶來改變
設計用來協助解決 Fuzzy Problem ===> Innovative Solutions1. Mind the Gap 全區思考, 留意間隙
有意識的留意 Gap
MVP 也要是 end to end 的體驗如何消除 Gap?
辦 Workshop 的方式
- 為什麼辦?
- 對象是誰?
- 辦了之後, 可能會有什麼問題?
辦 Workshop 要成功的關鍵在前期規劃2. Run with Brian 謀定而後動, 知止而有得
3. Close the Loop 反覆打磨, 止於至善
幾個推薦的 Process or User Group