In many organizations automated tests are executed once the final build candidate is ready or even manually once per release to check for regression. Let’s deep dive into the practical examples of how we can implement running automation tests on every full build. He integrated automated tests as part of the regular CI/CD pipeline to ensure that every build can support minimum happy path functionality, so the Dev team can get live feedback from every squash commits and have a consistent baseline of the core happy path tests to measure any regressions.

Takeaways from the talk:

• The key moment here is to agree with developers to have all builds to maintain happy path functionality or to replace it with plugs that return always true while some major refactoring is in progress. Automation suit runtime can be plotted on the graph to visually indicate any deviations. Finally, time to run full set of tests often takes longer than time between commits. We can solve it by creating new sandbox environment each time, so even if dev team already submitted new version, previous submission results will be still calculated therefore minimizing the time between code change and potential noticeable impact on functional tests.