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
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.