More Related Content
Viewers also liked (20)
Similar to 我的叠顿顿实践 (20)
More from Huang Bruce (6)
我的叠顿顿实践
- 3. 1. 叠顿顿介绍 2. 我的叠顿顿实践 3. Q&A
- 4. 叠顿顿介绍
- 5. BDD TDD Behavior-driven development 決定好测试案例再開發 從使用者角度 描述系統應有的行為 Test-driven development 從物件角度 描述物件應有的行為 Integration test Unit test
- 6. BDD is ... 一種開發方式 ,用大家都能理解的方式討論使用案例 , 減少彼此之間的代溝 ;
- 7. 我的叠顿顿实践
- 8. that’s talk a story ...
- 9. 過了一段時間 ...
- 10. 目標 事主 手段
- 11. 開發產品的時候，正確的方向，比速度更重要 透過一些工具來協助描述我們要解決的問題 : mind map ,impact mapping… 有效地找出要做的事大概有哪些 example : why : 增加營業額 who : 客戶 how: 增加消費行為 what : 收到促銷折扣資訊
- 12. 让我们再把故事说清楚点
- 16. 看到產品全貌 (Big Picture) User Story Mapping is an approach to Organizing and Prioritizing user stories. 雖然產品的全貌會隨著時間而變動 ,但這是規劃如何執行開發的的起始點
- 17. 故事怎样算完成
- 18. 定義使用場景來滿足這個故事 , 一個故事可以用很多場景來描述 , 每個場景都屬於這個故事驗收的範圍 ,也就是我們所需要的驗收規範
- 19. 测试导向开发
- 20. 確認好待開發需求 (使用者故事-userstory) - Definition of Ready 定義好產品規格 (使用場景-scenario) - Definition of Done 依照規格開發 - BDD (Behavior-driven development)
- 22. UI测试 -可測到的系統功能範圍 non-UI 测试
- 23. 定義良好的規格作為测试案例,協助系統持續整合建構 UI测试主要用於描述使用者如何透過系統達成某些功能,目標 - 適合用來跑過主流程 ,確認系統整合運行正常 - 可有效減少手動测试 ,讓测试人員進行更有價值的测试 ,explore test - demo產品功能 非UI的测试 ,主要用來测试驗證較複雜的商業邏輯 , 例如: - 註冊新帳號時 , 註冊用的密碼強度如何區分 . - 網購時 ,商品根據購買總價和寄送地區要如何收取運費
- 24. 实机顿别尘辞...
- 26. Q&A
- 27. END
Editor's Notes
- #2: 會講到這個主題 ，最初是因為 專案的文件很難反映到系統現況 ,有很多模糊地帶 ; 要開發修改的功能做不完 ,總被老闆追著跑 ,於是就想看別人是怎麼做的
- #3: 如何分析出要实作的使用案例
- #7: 方式 ,包含討論的行為 ,文件的紀錄方法
- #9: 我女朋友是個美髮設計師, 平時就有記帳的需求 ,所以做了個記帳工具 ,使用mind map ,簡單發想了要實作的內容.
- #11: 剛好我在前些日子看了某大師的blog,BDD in action這本書也有提到, 用impact mapping從根本問題找出一些解決方案 (developer我只能幫忙做統計表)
- #12: 我们只要找到真正有价值,值得去做的事就行
- #15: 我們可以想像到這不侷限特定角色 ,讓與這專案有相關或有興趣的人加入,進行討論 , 像是透過統計表得到最近賣最好的產品 ,在現場的業務預期可以進行進一步的推銷活動 ,或是負責採買的人需要將進貨量增加 ,這些環環相扣的事項都可以一併進行討論
- #16: 這概念很簡單 ,把想法用可看見的方式, 拿出來討論(溝通) ,然後達到共識
- #17: userstory mapping是一種組織userstory並排定優先順序的方法
- #19: 有了故事, 可以再更深入得討論每個使用場景 , 需使用give when then格式來記錄 ,就像unit test ,定義初始狀態 , 行為 ,結果 . 作為驗收测试的規格. 在specification by example一書中提及 , 使用"協同制定規格"的說法 ,比制定使用場景或驗收测试案例來得更讓人容易接收.
- #21: 從準備需求到定義產品的scope, 然後就能進行開發了
- #22: BDD就是一種测试导向开发的方式 ,透過BDD TOOL 工具, 將驗收規格變成可執行的测试案例 userstory -> Scenario -> a executable specification
- #23: 從使用者的角度描述系統應有的功能 ,所以测试結果要直接反應系統現況, 這邊簡單區分成UI测试和非UI测试
- #25: Demo後,產生的報表除了反映系統現況 ,也可以做為說明文件作為產品交付的內容 . Living Document