Takeaways from the topic:
Engineering teams around the globe have very differing views of what test automation should look like
1. Common pitfalls that engineering teams fall into:
- The “How can we go faster?” mentality. We should instead ask “How can this automation make a developer’s life easier?”
- Starting test automation off with only UI automation that frequently breaks instead of covering API/Unit test scenarios first. Will elaborate on Martin Fowler’s Test Pyramid and how it fits into automation planning
- Teams use ineffective, outdated, or broken automation tools due to the ‘sunk cost fallacy’ instead of questioning whether they should use something new. We should always question tools/frameworks if they don’t suit our needs
- Some teams don’t believe in automation at all which results in a completely manual test process that stifles speed, innovation, and quality. Focus on making automation a priority instead.
- Teams that try to automate EVERYTHING. Try instead to only focus on the specific test scenarios that will provide the most value to your engineering team. Avoid just checking boxes for better KPI metrics.
2. Some best practices to keep in mind when building automation:
- When planning out your automated framework, you should first look at the ROI (Return on Investment) of the test cases/use cases you want to automate.
- You should also have a clear picture of your application (end-to-end). Avoid jumping into automation without first fully understanding your application for the sake of “moving faster”.
- While developing your automation, try to follow “Martin Fowler’s Testing Pyramid” to guide your approach. Will describe the pyramid and how it fits into automation with specific examples
- Best UI Automation Practices (Page Object Model Design pattern, independent tests, sturdy locators, inheritance structure, simplicity, & only use BDD where absolutely necessary, etc…)
- Best API Automation Practices (Tooling i.e. Postman or Cypress.io are great tools, simplicity, status code assertions, key/value pair assertions, follow CRUD format (create, read, update, delete))
- You’re end-goal should be to integrate that automation you built with the build management tool your team uses so that CI-CD can be achieved with you’re testing (shift-left)