Melissa Tondi - Automation We_re Doing it Wrong.pdf
0 likes30 views
The document discusses common mistakes made in test automation and provides recommendations to improve practices. It notes that automation should not replace humans but make them more efficient. Common errors include creating large test suites that run overnight and are vetted by few people, focusing only on automation metrics without consideration of test landscape, and treating automation as the sole responsibility of test teams rather than involving developers. The document recommends breaking suites into smaller focused runs, prioritizing types of tests, using standards aligned with development, and providing self-service tests maintained by cross-functional teams. The goal is to apply learnings from failures to drive innovation through a collaborative approach.
Melissa Tondi - Automation We_re Doing it Wrong.pdf
- 1. Automation – We’re Doing it Wrong!
- 2. Why so Negative? Innovation should be at the forefront what we do and It comes when we build on our successes and more importantly, Our failures Even best-laid plans and ideas that make it into our playbook should be re-visited to ensure they: • are still applicable today • align with our industry • are agreed to by those expected to do the work
- 3. A Quote to Ground Us “Test automation makes humans more efficient, not less essential” And we are all human… But raise your hand if you’re not
- 4. Don’t Forget the Humans - a Story I forgot the humans In my quest to “meet the numbers” in automation resulted in Taking action before really thinking it through Managing the team by a metric that didn’t add much value Forgetting (and losing) great humans in the process
- 5. Where did we Go Wrong #1? Monolithic Suites of Tests We run big, multi-hour suites Off-hours/overnight The results are vetted out by a small group And then action is taken by the same and in a silo
- 6. How do we Make it Right #1? “Multiple Runs for Multiple Dones” Smaller, centralized and more efficient suites of tests That provide more concentrated and quicker feedback to the whole team Running in the pipeline Results are available and actioned on by the team
- 7. Where did we Go Wrong #2? Automate Everything A certain percentage/number of test cases automated somehow equates to high quality Focused on automating everything A Numbers Game
- 8. How do we Make it Right #2? Know your Landscape Consider Unit/Integration tests and take action Start with Smoke tests (CRUD) Tie it to Definition of Done/Shippable Measure by A of A (Automated of Automatable)
- 9. Where did we Go Wrong #3? Created a siloed and non-embedded team of Automation Engineers Direction was generally to automate existing test cases • Which have already been executed Resulting in suppressing your creativity and The ability to collaborate on holistic solutions
- 10. How Do we Make it Right #3? Use a “Tests as a Service” approach Organize tests in the same way your SWEs are • Concentrated in specific areas of the code • Centralized (meaning anyone on the team can run them) Stretch Goal: • Apply it to Regression testing • Tests as a Service allows SWEs to validate on their own
- 11. Where did we Go Wrong #4? Automation deliverables are owned, executed and maintained by only the Test folks The Test/Automation Engineers use a tool that Dev is likely not using, familiar with or consulted on Automation deliverables become the responsibility of one practice rather than the team When the time comes to address failures, the Devs can’t or won’t contribute because the perception is that it will take too much time
- 12. How Do we Make it Right #4? Use the “Leave No Trace” approach • Leave things in a state as if you weren’t, or more importantly, can’t be there • Onboard: assess, confirm, build, and deliver • Offboard: backlog, maintain, steady state, and leave Follow Prime Time guidelines • Standards and coding practices are aligned with Dev’s •Agreed to by your committee of technical QEs
- 13. Now What? Where do some of these “wrongs” apply to you? And more importantly, where can you make them right? • Start small – focus on a Smoke test • Tie it to Definition of Done/Shippable • Think like a team member – even if you’re not embedded • Your end goal should be to provide self-service tests for anyone on the team to use- that is ultimately maintained by the team So you can focus on innovation driven by change and right the wrongs!
- 14. Let’s Talk! LinkedIn: Melissa Tondi Twitter: @melissatondi Email: [email protected]