CTO's ATDD Roadmap - Sandbox Project
CTOs face regression bugs & slow delivery in Legacy Projects. Solution - Part 1: introduce Acceptance Tests & ATDD across your teams. Create a Sandbox Project for learning.
🔒Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. This article is part of the TDD in Legacy Code series. To get these articles in your inbox every week, subscribe:
The problem of regression bugs & slow delivery
As a CTO, you’re seeing the following problems:
Customers are reporting more bugs, customers are getting frustrated, you’re worried they’ll switch to competitors and your company will lose revenue
Delivery is slower and slower, business is frustrated why your teams can’t deliver fast, the company is losing in the market, and can’t keep up with competitors
Developers are spending majority of their sprint bug fixing, and not much time for feature delivery, QA regression testing is taking longer and longer
Do NOT start with Unit Testing & Code Coverage!
How do most CTOs try to solve the problem of regression bugs and reduce the need for Manual QA?
They introduce code coverage targets - e.g. 80% code coverage, 100% code coverage!
The developers try to achieve the Code Coverage targets, but they have no previous experience in writing effective Unit Tests, nor do they have any mentoring/coaching support, so this is the outcome:
Achieved 80% code coverage, thus making the Engineering Manager happy
BUT regression bugs did not decrease AND there’s increased maintenance cost
Consequently, these tests have net negative value
I’ve explained why Code Coverage Targets result in disaster - they fail to protect us against regression bugs, and are a maintenance nightmare:
Note: For further reading, see Dave Farley (Modern Software Engineering) and Vladimir Khorikov (Unit Testing).
Note II: Above, I described the case where the team has no previous experience in effective Unit Testing and just tries to achieve Code Coverage targets, in that case the unit tests don’t protect against any regression bugs. But what if the team has experience in Unit Tests? Well, then the Unit Tests will protect them at against regression bugs at the developer level, but Unit Tests will NOT protect the team against user-facing regression bugs, e.g. regression bugs caused due to mismatches in communication between Frontend & Backend, regression bugs in integration with the database and other sources of I/O, and also the case where code might work in isolation but not together. Even though the team is practicing Unit Testing effectively, they’ll still need to do Manual QA Regression Testing. Thus, we haven’t solved the original problem we tried to solve.
Start with Acceptance Tests & ATDD
So what’s the solution? We should start with End User-facing tests to achieve the highest ROI and to get feedback on whether the User-facing scenarios have any regression bugs, thus eliminating Manual QA Regression Testing. This helps us:
Reduce customer-facing bug reports, enabling customer satisfaction
Faster delivery, so that we can release more frequently
Enable developers to spend more time on features rather than regression bugs
The progression involves introducing Smoke Tests and E2E Tests, and migrating them to Acceptance Tests. Then, for new User Stories & Bug Fixes, we’d be applying ATDD.
Let’s work together to help your teams
I help CTOs & Engineering Managers introduce ATDD in their teams. Let’s talk about how we can help your teams practice TDD in their day-to-day work, reduce bugs, reduce stress & accelerate delivery:
After our call, you can check out my roadmap for CTOs, a step-by-step guide for getting your teams to start building the ATDD Sandbox Project, and helping them apply ATDD to their Real Life Project.
Here’s the roadmap for CTOs: ⬇️⬇️⬇️