Stop! you're testing too much
Download as PPTX, PDF•0 likes•370 views
The document discusses the advantages of test automation, particularly acceptance test automation, which includes benefits such as increased efficiency, improved product quality, and better alignment with priorities. It emphasizes the importance of collaboration, identifying what to automate, and understanding the impact of automated testing on system design. Additionally, it provides practical steps for getting started and managing test data effectively.
Stop! you're testing too much
- 1. STOP! You’re automating too much! (and other tales from the field)
- 2. My name is Shawn and I’m a software developer
- 4. Why is test automation a good idea?
- 5. Our existences are about precise communication...and communication is about feedback loops
- 6. Our existences are about precise communication...and communication is about feedback loops
- 7. Why Acceptance Test Automation? • Implementing changes more efficiently • Shortened feedback loop • Higher product quality • Less rework • Better work alignment to priority • Helps make systems easier to modify
- 8. Why Acceptance Test Automation? • Implementing changes more efficiently • Shortened feedback loop • Higher product quality • Less rework • Better work alignment to priority • Helps make systems easier to modify
- 10. Part of the process…
- 11. Can my team benefit? We can improve design going forward The goal is writing working code/providing value
- 13. How do I get started?
- 14. How do I get started? 1. Test KEY use cases 2. Test defects 3. Test new features
- 16. What should I automate? • You are testing the behavior of your system • What do you need to test to determine if your system is behaving? • Regression is a side-effect
- 17. Don’t forget your testing triangle
- 18. • Deliberately test your system at the physical boundaries • Know what your system does and how it works • Collaborate! Collaborate! collaborate!
- 19. Where does automation fit in with our process?
- 20. WWTDDD We define our Acceptance Criteria AND Encode them as Acceptance Tests
- 21. What solution and architectural dependencies am I driving?
- 22. • Poorly designed or implemented systems tend to be hard to test • Code under test might need to be refactored • Test suite could be inefficient
- 23. Case Study in Pain • Huge Automated Functional Test Run • 5500+ Scenarios • 550+ Hours to Execute
- 24. Case Study in Pain • Huge Automated Functional Test Run • 5500+ Scenarios • 550+ Hours to Execute
- 25. mated Functional Test Running Infrastruc
- 27. Test code IS code
- 28. Testing takes time and resources and requires a skill- set you might not have yet.
- 29. How will I run my tests?
- 30. How will I run my tests?
- 32. What do I do with all of the data?
- 33. What do I do with all of the data? • Test automation generates a ton of data…not all good • Need a way to store, filter and make visible
- 35. Do I always run ALL of my tests?
- 36. DEVELOPMENT PRODUCTION MAINLINE Merge Merge Run subset of all automation Run entire suite Run smoke tests
- 37. Do I need to keep my tests forever?
- 38. ATDD tells us that you do…
- 39. Practically, some tests are better for development than for regression
- 40. How will I know if I’m doing a good job?
- 42. What does success mean in your environment?
- 44. That’s all…
- 47. Q&A For more information... • This Presentation on GitHub – https://github.com/shawnewallace/testing_too_much_presentation • cukes.info • Gojko Adzic – cuke4ninja.com – Specification by Example • https://github.com/aslakhellesoy/cucumber/wiki • http://groups.google.com/group/cukes • http://www.cheezyworld.com • The Cucumber Book, Matt Wayne, Aslak Hellesøy: http://pragprog.com/book/hwcuc/the-cucumber-book • The Rspec Book, David Chelimsky: http://www.pragprog.com/titles/achbd/the-rspec-book
Editor's Notes
- #2: There is a lot here for... devs, qa, ba and project leadership Meant to wet your whistle. “WHAT IS YOUR PAIN?”
- #3: I used to be a tester in my first job. I work for Centric Consulting Why does a developer care about our functional test automation suite?
- #4: Standard disclaimer, your mileage may vary. These are just my own experiences and conclusions. Your ideas are probably better than mine. Your process, team, backlog, organization make a difference.
- #6: Which means feedback is important
- #7: Which means feedback is important
- #11: BDD is how we encode the failing ACCEPTANCE test
- #17: Talk to your customer
- #19: remember your testing triangle
- #21: When we work for a time, we’ll see if this is practical at scale later on in the talk…
- #25: THIS IS WHY I CAME UP WITH THE TITLE FOR THIS TALK
- #26: This is our test running environment needed to get the test run down to 12 hours.
- #28: It must be often tested and Maintained. It requires similar software development disciplines.
- #39: BDD is how we encode the failing ACCEPTANCE test
- #44: beware of overconfidence in your test suite