ATDD — Acceptance test driven development at ASOS

At ASOS, software development is all about speed, achieving continuous delivery, and deploying a few times a day to enable the innovation our customers strive for.

But going too fast without a seat belt is dangerous, so how can we safely deliver on a quick and regular basis?

We must have a good test suite, which is fast and reliable. So, this post is going to explain why and how to implement our ATDD strategy.

The division

Traditional Dev and QA separation — Image Source

This is how QAs and developers interacted in the past, where the devs would finish a feature, deploy to a test environment and only then would QAs start manually testing. This may work for some teams, but, in general, it has a lot of drawbacks:

• Devs get into the mindset that they are not responsible for ensuring the quality of their work, as the QA is the safety net.
• QAs become heavily reliant on devs for configuring environments.
• What does the QA do while the developers are still working on a feature?
• How do we regression test a system after each change?
• Not forgetting the huge manual test suites maintained in excel spreadsheets with 100+ cases that can take over a week to complete.