Business Impact of Automated Testing
How to influence managers to move away from Manual QA Regression Testing?
Welcome to the free edition of Optivem Journal. I write about Modern Test Pyramid & Modern TDD practice to help you escape the nightmare of Legacy Code. I know you're stressed & don’t have time, and you don’t want to wait for several years. If you want support on your TDD journey, join our paid community of 160+ senior engineers & engineering leaders. Get instant access to group chat & live Q&As:
I tried to convince my managers to adopt Automated Testing.
However, the Managers see Automated Testing as just an overhead. They think Manual Testing is enough.
If you want to influence your management, you can’t speak about Automated Tests per se, but about the business outcomes.
System Level Testing
Reducing Regression Bugs: Guarantee complete test execution, preventing bugs from escaping to production (unlike manual QA regression testing, where typically QA Engineers are forced to skip regression tests to meet delivery deadlines, causing bugs to escape to production)
Reducing Delivery Time: Developers get feedback within one hour, lowering rework costs (unlike manual QA regression testing that takes days or weeks, hence higher rework cost for developers)
Component Level Testing
Reducing Regression Bugs: Don’t reduce user-facing bugs (that’s handled by System Tests) but do reduce regression bugs at team level
Reducing Delivery Time: Each development team (frontend, backend) can verify their components work correctly, hence less communication and debugging across teams, less integration issues, hence faster total delivery
Unit Level Testing
Reducing Regression Bugs: Don’t reduce user-facing bugs (that’s handled by System Tests) but do reduce developer-level regression bugs in business logic, presentation logic and infrastructure logic
Reducing Delivery Time: Developers get feedback within seconds/milliseconds, hence are able to fix code while changes are fresh, minimizing rework effort; as well as enabling incremental refactoring to make the code cleaner which reduces the maintenance costs, making future changes even cheaper
📢 On Wed 9th July 17:00 CET, I’m hosting TDD & Unit Tests - Part 4 (Live Q&A):
P.S. If you’re a Paid Member, you’ll receive a 100% discount (see Event Description for instructions on how to redeem your 100% discount).
Summary
Automated System Level Tests are mandatory because they reduce user-facing Regression Bugs, i.e. ensuring that we deliver software that works. They also reduce Delivery Time by eliminating Manual QA Regression Testing and providing faster feedback loops to developers whether they broke business-facing functionality.
We can reduce Delivery Time further by writing Component Level Tests, which provide feedback loops to each time in isolation, helping teams work effectively in parallel and minimizing inter-team debugging and minimizing late integration issues.
For components with high business logic complexity, we can reduce Delivery Time even further by writing Unit Level Tests, which provide fastest possible feedback loops to developers, leading to lowest rework cost as well as ability to refactor the code to clean code to make future changes even cheaper.
If a team is already overwhelmed by legacy code and tight deadlines - how can they realistically introduce automated tests?