Recommended
More Related Content
What's hot
What's hot (19)
Similar to Defect free development - QS Tag2019
Similar to Defect free development - QS Tag2019 (20)
More from Arnon Axelrod
More from Arnon Axelrod (11)
Recently uploaded
Recently uploaded (20)
Defect free development - QS Tag2019
- 1. Organisator: imbus AG www.qs-tag.de Expanding Horizons Getting towards Zero Defects Arnon Axelrod Sela Group, Israel
- 2. Arnon Axelrod Expert for: Test Automation eXtreme Programming Defect-free software development ArnonAxelrod @ArnonAxelrod @ArnonAxelrod 2
- 3. Agenda Defect-free software: Are you kidding me? The cost of quality Maintaining Defect-free software development Getting to Defect-free state 3
- 4. Zero Defects… Is it possible ?! 4
- 5. 5
- 6. Defect is any behavior of the system that doesn’t meet the user’s expectations 6
- 7. Defects by area Regression New behavior Missing behavior 7
- 8. Our Goals Prevent Regressions Minimize defects in new behavior Respond quickly 8
- 9. The Cost of Quality Quality Features Delivery Speed 9
- 10. The Cost of Quality Quality Features Delivery Speed Quality Features Delivery Speed Good Eng. SkillsBad Engineering Skills 10
- 11. “High performers understand that they don’t have to trade speed for stability or vice versa, because by building quality in they get both.” “Astonishingly, these results demonstrate that there is no tradeoff between improving performance and achieving higher levels of stability and quality. Rather, high performers do better at all of these measures.” 11
- 12. Maintaining a Defect-Free Software 12
- 14. Defects in New Features Coding Mistakes Design/Architectural flaw Misunderstood requirements Requirements don’t meet user expectations 14
- 15. Clean Code and Simple Design 15
- 18. Clean Code and Simple Design 18
- 20. 20
- 22. 22
- 23. User Stories 23
- 24. The Connextra format As a <Role> In order to <Achieve a goal> I want <a behavior of the application> 24
- 25. The ATDD Process PO defines the problem (User Story) PO & team collaborate on simplest solution Define Acceptance Criteria Implement automated test Implement Code & Refactor Exploratory testing Get customer feedback 25
- 26. Eliminating Defects with ATDD Coding mistakes Design or architectural flaw Misunderstood requirements Requirements don’t meet user expectations Test coverage Refactoring Collaborative Acceptance Criteria Fast feedback cycle 26
- 27. Handling Escaping Defects 1.Top Priority! 2.Create an automatic test to reproduce 3.Fix the bug 4.Perform a RCA and Apply to prevent similar issues 27
- 28. Root Cause Examples Miscommunication Human errors Coding practices Naïve assumptions / lack of awareness Complicated and brittle design 28
- 29. Mitigations Examples Reviews Automated processes Static code analysis Adding additional test types Formal processes Refactoring Remove duplication Error prevention Fail-fast 29
- 30. Some things are beyond our control… 30
- 31. Regressions due to external dependencies Availability issues Changed behavior Including bugs 31
- 32. Other Important Practices Retrospectives Reviews Pair/Mob Programming 32
- 33. Getting to Defect Free State 33
- 34. One Step At a Time… 34
- 35. Low Hanging Fruits Collaborate on User Stories and Acceptance Criteria Root-Cause Analysis Write Automatic tests before fixing a defect Write new tests according to Acceptance Criteria 35
- 36. Low Hanging Fruits Retrospectives Run tests more often Move responsibility to developers Experiment with ATDD on new and isolated features 36
- 37. Gradually… Cover loosely-coupled components Refactor Remove duplication Break dependencies Simplify Add production monitoring Deeper Root-Cause Analysis and Retrospective… Learn, measure and adapt 37
- 38. Regressions can be eliminated (almost) completely ATDD ensures full coverage Full coverage enables refactoring and evolving the design Simple design eliminates defects Perform Root-Cause Analysis and Retrospectives Measure and adopt Investing in Quality improves Delivery speed Summary 38
- 39. Questions 39
Editor's Notes
- (3min) Senior consultant Author Before that I worked in a team that applied most of the practices
- 4min
- 6min Well, it depends on the definition…
- Broadly speaking… It is subjective, but we all know a defect when we see it
- New behavior Missing functionality are actually opportunities
- (10min) Note that even *preventing regression” in our own code base seems to most people as not feasible! (If you’ll get something out of this session and it would be to prevent regression in your own codebase at all price – it will be a great breakthrough). Most teams I know are far from achieving that goal.
- 10min There’s a very common misconception that quality costs time and money. “In order to get higher quality we need to invest more in testing”. The truth is the opposite: good engineering practices and supportive culture, drive both higher quality and improves delivery, which saves time and money.
- This is demonstrated very clearly by the most thorough study that was done on this subject, which is described in the book Accelerate.
- thorough scientific research 2014-2017 23,000 people 2000 organizations
- 13min
- thorough automated testing suite We’ll discuss how to reach there
- Minimizing defects in new and changed features, and reaching full regression suite Coding mistakes Design or architectural flaw Misunderstood requirements Requirements don’t meet user expectations We’ll discuss mitigations
- 17min Design is rarely attributed to defects Defects hide in dirty places We must keep our code and design clean
- Components, micro-services (only if architected correctly!) Minimum inter-dependencies Higher confidence in changes Less, simpler and faster tests
- Examples: strong-typing (e.g. TypeScript vs. JavaScript), correct use of Encapsulation (private/public), Immutability, Generics
- This is all cool and nice in theory, but…
- Theory vs. reality… (This is more like what my house look like. I failed to teach my kids defect-free behavior ) Reasons: Changing requirements (and our understanding of the business) The knowledge we gain over time about the technology The evolution of the technologies we use Lack of discipline (due to time pressure, lack of awareness, etc.) This is the source for many defects difficult to fix It’s costly to add and modify features
- 22min Series of small steps
- Refactoring allows to evolve the design and improve it over time while adding new features
- 25min ATDD is a key technique in Zero Defects. One that is very under utilized… One key element of ATDD is the way user stories are defined
- Misconceptions Many people believe that the PO should define the user stories in a very detailed and clear way, so that the developers can understand exactly what they need to do, and the testers will know exactly what to test. Most people also believe that in order to come up with the best architecture, the entire feature should be planned, and only then be split into user stories, as a mean to project planning.
- The essence: Problem definition The team should collaborate on the solution
- And as you can see, it covers all the faults.
- 33min Consider this event and all the next steps as top priority! Create an automatic test to reproduce Fix the bug Perform a RCA and apply the learning to prevent similar issues
- Examples of RCA learnings can be: Process improvements (e.g. who should review what and when) Improve coding practices and guidelines (e.g. avoid returning null from functions). As much as possible automate these validations using Lint/Code analysis tools Missing Code inspections – could be mitigated either by code review or by Static Code Analysis Naïve assumptions – mitigate using reviews, knowledge sharing, etc, and other types of tests Improve and simplify the design: Remove duplication and coupling Separate concerns into different classes or components
- Error prevention: strong-typing, single source of truth Fail fast: assertions, mainly in initialization. But we should not wait only for detected defects in order to improve our codebase and apply these kinds of improvements. Assuming we have a thorough automated testing suite, we can (and should) constantly refactor to make these kinds of improvements, especially as we add new features.
- 37min Hardware failures (not exactly a defect!) 3rd party components and services
- Hardware issues HA is a feature Changed 3rd party behavior should be rare, due to backward compatibility run some tests in production + monitoring Treat production = escaping defects (see previous process)
- 50 ways… Important: Action items and follow-up
- 40 min (5 left) This all sounds great in theory, assuming we start the project using these practices. But in the real world, even projects that are considered “green field” start as a Q&D POC. So how do we reach this defect-free state in a legacy project?
- If you apply these practices very early on in a new project, it may be easier Otherwise, Don’t try to get it all at once
- Here are some low hanging fruits that you can start with more easily: Collaborating on user stories and acceptance criteria RCA on chosen defects. Mainly in new components Write automated tests to reproduce defects before fixing them Write new tests according to acceptance criteria (or alike)
- Here are some low hanging fruits that you can start with more easily: Retrospectives Run tests more often (by developers) Experiment with ATDD, on isolated features
- Cover with automated tests loosely coupled components and refactor Refactor/re-architect to break direct dependencies Add monitoring to production Perform deeper RCA and act upon them accordingly Continue to learn from retrospectives and improve your processes
- Contact me if you want me to help you!
- Contact me!