Iakiv Kramarenko: “Quality Driven Development”
•
1 like•46 views
This document discusses Quality Driven Development (QDD), an approach where quality is a dynamic and conditional subset of attributes driven by business value. It emphasizes building the right product through general team responsibility for quality assurance reflected in daily development practices. Verification and automated testing are used to ensure work meets requirements, while exploration testing validates if the right software was built. Quality assurance practices are incorporated to increase confidence and reduce risks and testing needs.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Iakiv Kramarenko: “Quality Driven Development”
Similar to Iakiv Kramarenko: “Quality Driven Development” (20)
More from Dakiry
More from Dakiry (20)
Recently uploaded
Recently uploaded (20)
Iakiv Kramarenko: “Quality Driven Development”
- 5. ISO25010
- 7. Idea Value Product Development Quality as dynamic and conditional subset of attributes driven by business value
- 10. Quality Assurance as a general team responsibility reflected in the team's daily practices to build the right product (from BA, design, development to deploy and maintain in prod)
- 11. Quality Assurance as a general team responsibility reflected in the team's daily practices to build the right product (from BA, design, development to deploy and maintain in prod)
- 12. QA = JUST DO IT RIGHT
- 13. QA = … prevention
- 14. QA = … prevention Tu run longer, run a bit each day ;) sports is cheaper than rehab
- 15. Simplest example of QA Practice… • Verification • As a direct check of work planned and expected as done • ~ do it right according to requirements • As a part of QA-minded dev process • Pretty obvious, based requirements
- 16. Another pretty natural example… • Verification++ = Automated Verification • As a direct check of work planned and expected as done • ~ do it right according to requirements • As a part of QA-minded dev process • Obvious, based requirements
- 17. Price we pay for it?
- 18. Price we pay for it? • Maybe expensive if "too much sports, and less work" • As a direct check of work planned and expected as done • ~ do it right according to requirements • As a part of QA-minded dev process
- 19. … should be balanced. How? When to stop? • when we are confident in the acceptable level of quality, i.e. we built the right software • are we confident? how to “validate" = assess whether we built the right software? ➡ 1. ask users (free, risky) ➡ 2. ask testers (paid, reduces risks) Here goes Testing... ;)
- 20. … should be balanced. How? When to stop? Maybe you can stop at 0 level;) E.g., on the stage of building a prototype, you have 0 users. And you might have small budget. So your first answer is – everything is fine:) No need to do any QA;)
- 21. … should be balanced. How? When to stop? • when we are confident in the acceptable level of quality, i.e. we built the right software • are we confident? how to “validate" = assess whether we built the right software? ➡ 1. ask users (free, risky) ➡ 2. ask testers (paid, reduces risks) ➡ Here goes Testing... ;)
- 22. Testing?
- 23. “Testing” ;) • as an exploratory measuring quality and sharing results with stakeholders... • Assessing what we do not know about our system ➡ Non-obvious ➡ Expensive
- 24. Testing – Why? • to validate "whether we built the right software", • where "right software" = software of expected quality level • and so... to close potential potential gaps in current QA practices • i.e. improve the development process to assure final quality
- 25. Testing – Why? • to validate "whether we built the right software", • where "right software" = software of expected quality level • and so... to close potential potential gaps in current QA practices • i.e. improve the development process to assure final quality – … to “not test” ;)
- 26. Testing – When and How much? • depends... based on risk and resources available • usually • a bit – regularly… (per feature) • more per milestone (~release) • thorough per significant risk, often dedicated, like "security testing", "performance testing", etc.
- 27. Testing – How to economize/do less? :) • Incorporate QA practices • to increase confidence in product quality and so reduce risks and the need of extensive and thorough testing
- 28. Testing – How to economize/do less? :) • Incorporate QA practices (as prevention;) • to increase confidence in product quality and so reduce risks and the need of extensive and thorough testing
- 29. QA as a prevention smartly tuned by Testing • Start with basic hygiene toolbox chosen by • gut feeling, common sense • comparison to similar projects • Then tune through regular smaller Exploratory Testing sessions • planned extended/tuned/based on • gut feeling • user feedback (regularly collected)
- 30. Summary
- 31. Summary – Terms Development = JUST DO IT QA = DO IT RIGHT! Testing (Exploratory) = HAVE WE DONE THE RIGHT THING?
- 32. Summary – Process (QDD) just DO IT; while(true) { have we done THE RIGHT THING? // test do IT RIGHT! // qa }
- 33. More examples of QA practices
- 34. Common ones to consider for “Start” • Verification • Automated verification • Pyramid levels based • Risk based • Continuous Integration • DoR, DoD
- 35. Common ones to consider for “Start/Build” • Verification (+automated) by developers ~ improves discipline • Outside-in • Verification (i.e. TDD) ~ improves correctness, anti-compromised • Requirements definition ~ common sense planning... first plan, then do • Ubiquitous language • 3 amigos meetings to align/plan/define • Tests as docs • Tests as specification • Behavioral tests and reqs
- 36. Common ones to consider for “Start/Build” • Verification (+ automated) by developers ~ improves discipline • Outside-in • Verification (i.e. TDD) ~ improves correctness, anti-compromised • Requirements definition ~ common sense planning... first plan, then do • Ubiquitous language • 3 amigos meetings to align/plan/define • Tests as docs • Tests as specification • Behavioral tests and reqs BDD ;)
- 37. Advanced ones to consider for “Grow” • Continuous Delivery • Trunk Based Development • “feature flags” • a/b testing • gradual feature rollout • Change Management • WiP limit • etc. • …
- 39. Requirements!
- 40. Requirements!
- 41. Requirements! Devs = QAssurance Testers = qASSITesters
- 42. Requirements! Devs = QAssurance Testers = qASSITesters Testing Exploration Validation
- 43. Requirements! Devs = QAssurance Testers = qASSITesters
- 44. Requirements! Devs = QAssurance Testers = qASSITesters DoR
- 45. Requirements! Devs = QAssurance Testers = qASSITesters DoR Acceptance Criteria
- 48. DoR Acceptance Criteria Necessary, Non-redundant Attainable Testable Unambiguous Complete Consistent Concise Traceable Understandable Implementation-free Match criteria? 3 Amigo Meetings Requirements
- 49. DoR Necessary, Non-redundant Attainable Testable Unambiguous Complete Consistent Concise Traceable Understandable Implementation-free Match criteria? 3 Amigo Meetings / Grooming Requirements Acceptance Criteria
- 50. DoR Necessary, Non-redundant Attainable Testable Unambiguous Complete Consistent Concise Traceable Understandable Implementation-free Match criteria? 3 Amigo Meetings / Grooming Ubiquitous Language Requirements Acceptance Criteria
- 51. DoR Necessary, Non-redundant Attainable Testable Unambiguous Complete Consistent Concise Traceable Understandable Implementation-free Match criteria? Draft Test Plan / Checklists 3 Amigo Meetings Draft Dev Plan Pre-Planning / Grooming Ubiquitous Language Requirements Acceptance Criteria
- 52. Devs = QAssurance Testers = qASSITesters Do it! Acceptance Criteria DoR
- 53. Devs = QAssurance Testers = qASSISTANCE DoR QA? Doing Acceptance Criteria
- 54. DoR QA? Devs = QAssurance Testers = qASSISTANCE Doing Acceptance Criteria
- 55. Devs = QAssurance Testers = qASSISTANCE Testing Verification DoR Devs write Tests Doing Acceptance Criteria
- 56. Devs = QAssurance Testers = qASSISTANCE Testing Verification DoR Design/ Provide Tools Devs write Tests Doing Acceptance Criteria
- 57. Devs = QAssurance Testers = qASSISTANCE Testing Verification DoR Design/ Provide Tools Devs write Tests Review and improve coverage Doing Acceptance Criteria
- 58. Devs = QAssurance Testers = qASSISTANCE Testing Verification DoR Design/ Provide Tools Devs write Tests Review and improve coverage Exploration Doing Acceptance Criteria
- 59. Devs = QAssurance Testers = qASSISTANCE Testing Verification DoR Design/ Provide Tools Devs write Tests Review and improve coverage Exploration Doing Acceptance Criteria
- 60. Devs = QAssurance Testers = qASSISTANCE Testing Verification DoR Design/ Provide Tools Devs write Tests Review and improve coverage Exploration DoD Doing Acceptance Criteria
- 61. Acceptance Criteria Devs = QAssurance Testers = qASSISTANCE Testing Verification Exploration DoR DoD Doing Sum m ary
- 62. Collaboration Rules Devs verify Testers explore
- 63. Food for the brain…
- 64. Technical Feng shui vs Team & Processes - food for the brain
- 65. Doing sports vs Medicaments - food for the brain
- 66. Tips
- 67. There are good practices in context, but there are no best practices. (c) Cem Kaner, James Bach
- 68. Best practices do not work if a team does not understand/support them (team's support is part of context;)
- 69. when in doubt... - wait, fuck “when", ever! – do it by smaller steps
- 70. when in doubt... - wait, fuck “when", ever! – do it by smaller steps
- 71. Q&A