Test automation - put on the brakes so you can go fast
Download as PPTX, PDF1 like87 views
The document discusses the importance of test automation for ensuring software reliability and safety. It uses the analogy of car brakes to represent the role of test automation in allowing developers to release software fast while maintaining confidence that defects will be caught. The document urges readers to consider whether their tests are sufficiently robust and efficient before deploying new software versions.
Test automation - put on the brakes so you can go fast
- 1. Test automation: put on the brakes so you can go fast⊠Bas Dijkstra bas@ontestautomation.com www.ontestautomation.com
- 2. How fast would you drive a car that has no brakes? (*) on the open road, that is⊠(*)
- 9. Release fast and with confidenceâŠ
- 10. âŠbecause you know your brakes work
- 14. âAre we comfortable with not having the information provided by this test?â
- 15. âAre we comfortable with not having the information provided by this test before we deploy?â
- 18. âIs this the most efficient way to get the information weâre looking for?â
- 20. 100% code coverage! False negative: exhibit A still
- 30. How fast do you dare to drive with your brakes?
- 31. Contact _Email: bas@ontestautomation.com _Website: https://www.ontestautomation.com/training _LinkedIn: https://www.linkedin.com/in/basdijkstra
Editor's Notes
- #3: In the first 8 years of my career I wrote an awful lot of horrible automation
- #4: In the first 8 years of my career I wrote an awful lot of horrible automation
- #5: In the first 8 years of my career I wrote an awful lot of horrible automation
- #6: In the first 8 years of my career I wrote an awful lot of horrible automation
- #7: We see a desire for speed in software development as well (CI/CD, rapid deployments, âŠ)
- #8: What we donât want is mistakes, though (no matter how easy it is to fix them)
- #9: Thatâs why we install brakes in our pipeline > automated tests
- #10: In the first 8 years of my career I wrote an awful lot of horrible automation
- #11: In the first 8 years of my career I wrote an awful lot of horrible automation
- #12: I see quite a few problems in practice, though
- #13: Too many tests (every feature should have tests, lots of added maintenance)
- #14: Too few tests (failures in production)
- #17: Inefficient tests (Blu, Orange)
- #20: Reliable / trustworthy tests â false positives / false negatives
- #23: Review / refactor / remove your tests periodically â tell story of brake pads here
- #24: Craftsmanship - training
- #25: Itâs about the right tools
- #26: Itâs about the right knowledge
- #27: In the first 8 years of my career I wrote an awful lot of horrible automation
- #28: In the first 8 years of my career I wrote an awful lot of horrible automation
- #29: Test automation does not protect you from all risks
- #30: Test automation does not protect you from all risks
- #31: In the first 8 years of my career I wrote an awful lot of horrible automation