Our UI automation was developed on a lag of at least one sprint. The test code being written at that point in many cases – was for a code change that has been in production for weeks or months.

Our tests were super slow, data dependent and we happened to spend more time in maintaining the scripts than actually increasing our test coverage.

In this session we’ll discuss how we implemented in-sprint automation and how we managed to spend more time writing new tests.

We’ve adopted a strategy for UI automation and part of integration testing that has helped us propel features forward into production faster.

We found that this strategy and approach is very crucial for teams that want to deliver software in a cadence that approaches Continuous Delivery.