That’s actually the biggest problem. Many companies do say they want to introduce automated testing (and yes, they want to), but in practice it appears as impossible. When teams are spending days fire-fighting and already working over-time, it isn’t possible to introduce automated testing.
When introducing automated testing, I recommend:
Retroactive tests: Choose a small subset of main business scenarios (e.g. top 5 critical business scenarios) and automate them. Thorugh this, it will both help the team setup the Four Layer Model (Dave Farley) and simulatenously they’re covering the highest priority business scenarios.
Then, from next sprint onwards, take one User Story, and do it with ATDD (note that prior to doing ATDD on the User Story, you’ll need to retroactively write Acceptance Tests & External System Contract Tests for the base functionality that exists prior to implementing that User Story). The other User Stories you can do it the old way (e.g. no testing at all). Then over next sprints, increase number of User Story & Bug tickets that you’re doing with ATDD.
In this way, by moving incrementally, applying ATDD to new User Stories, we help maximize the ROI of the testing (and it’s way more realistic than trying to play catch-up in trying to cover 100% of old functionality with Acceptance Tests).
If a team is already overwhelmed by legacy code and tight deadlines - how can they realistically introduce automated tests?
That’s actually the biggest problem. Many companies do say they want to introduce automated testing (and yes, they want to), but in practice it appears as impossible. When teams are spending days fire-fighting and already working over-time, it isn’t possible to introduce automated testing.
When introducing automated testing, I recommend:
Retroactive tests: Choose a small subset of main business scenarios (e.g. top 5 critical business scenarios) and automate them. Thorugh this, it will both help the team setup the Four Layer Model (Dave Farley) and simulatenously they’re covering the highest priority business scenarios.
Then, from next sprint onwards, take one User Story, and do it with ATDD (note that prior to doing ATDD on the User Story, you’ll need to retroactively write Acceptance Tests & External System Contract Tests for the base functionality that exists prior to implementing that User Story). The other User Stories you can do it the old way (e.g. no testing at all). Then over next sprints, increase number of User Story & Bug tickets that you’re doing with ATDD.
In this way, by moving incrementally, applying ATDD to new User Stories, we help maximize the ROI of the testing (and it’s way more realistic than trying to play catch-up in trying to cover 100% of old functionality with Acceptance Tests).