<aside> 💡 Hola friends! We recently created a Discord for Software Automation where we discuss these kinds of topics on a bi-weekly basis.

Responses range from people with 0 to 30+ YOE in the industry and wanted to share this with the community!

</aside>

Stefan Ayala (Basecase_) shares:

Pro tips don't immediately come to mind, but I can tell you how we worked at one place where it was smooth like butter but took many years to get to this point (5+ years):

• Every code change required a pull request on a feature branch.
• Every pull request required 2 code reviewers, 1 QA stamp of approval, and the full test-suite to pass before being merged into the latest main branch (usually by QA or Dev who wrote it).
• There was a suite of thousands of automated tests from Unit/Integration/E2E that closely resembled the Testing Pyramid but with most emphasis on Integration tests.
• A stable/reliable test-suite, this means having reduced flakiness to nearly 0 so people trust the test-suite.
• When there was a problem in CI/CD, someone immediately addressed it (flaky/broken test for example).
• The tests were parallelized and never took too long (this is subjective but 15-30 minutes is OKAY in web land).
• Tests were easy to read and extend.
• SDET/QAE/QA were part of the scrum ceremonies which meant discussion of testing happened as early as possible.
• Caching CI/CD artifacts (this is such a huge resource and time saver that many people don't do).
• Properly creating and tearing down state, many people re-use state which is like re-using a hospital needle.
• Error reporting setup for the test environment.
• Isolating your testing environment (shared DB for example), if you don't you end up with ghost issues that are created from outside of the test-suite.
• Code coverage would fail your pull request if you reduced coverage when introducing code.
• All newly added tests were stress tested in parallel, to make sure we weren't introducing a poorly written test.
• The whole team was writing tests, not just the testers.
• As little friction as possible for devs writing tests, this means really good internal test automation frameworks to setup state for example.