Iakiv Kramarenko: “Quality Driven Development”

1. Quality Driven Development

2. yashaka @
About
Consulting Director @

3. Quality Driven Development?

4. Quality Driven Development?

5. ISO25010

6. Quality Driven Development?

7. Idea
Value
Product
Development
Quality as dynamic and conditional subset of attributes driven by business value

8. Quality Driven Development?

9. Quality Assurance Development?

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.
• …

38. Lessons Learned
@yashaka

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

46. DoR
Acceptance Criteria

47. DoR
Acceptance Criteria
Necessary, Non-redundant
Attainable
Testable
Unambiguous
Complete
Consistent
Concise
Traceable
Understandable
Implementation-free
Requirements

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

72. Thank you!
k-expert.com
yashaka @

73. https://leanpub.com/intro-to-software-development
https://leanpub.com/intro-to-software-development-uk
https://leanpub.com/intro-to-software-development-ru
Thank you!
yashaka @