Can You Afford to Not Automate Testing?
Alan Taylor
Unlocking potential for seamless delivery. Supporting leaders and their teams. Consultant | Coach | Facilitator | Trainer | Speaking | Podcast host
Why Not Do Automated Testing
Developers Time is More Expensive than Testers
The average wages for testers is lower than for developers. Surely it's therefore more expensive for a developer to write test code, than for a tester to manually test it?
- If the developer looks at the issue straight away, there is a context switch, that takes on average about 15 minutes(1). So handling it immediately costs 15 minutes of developer time plus 15 minutes to switch back once complete.
This cost alone is perhaps equivalent to the saving by using a tester? - If the developer waits until the latest Story is complete (avoiding extra context switching), there will be:
- Potential delay of 1 or 2 days before resolving the issue
- Other issues may become visible after resolving the first one … and so comes a cycle of fix, wait for tester, test fails, wait for developer, fix,wait for tester …
- Many more good reason to not wait(2)
Development Takes Longer
There is often concern that writing a complete set of tests will be a big overhead, taking more and more time and therefore increasing costs. Admittedly developing good tests is an acquired skill, which at the start will take time and effort.
However, once the team gains experience in TDD, despite the extra work, there are usually significant improvements in productivity(3).
Yes some tests are very likely to require rework, but most tests are at unit level, and are therefore unlikely to change(4).
Why Should Testing be Automated?
Design Improvements
Writing automated testing before starting to code means developers think more about what they are trying to achieve (5).
Reduce Risk
Imagine the code was originally tested and it passed first time. Now six months later enhancements are required. The original developer is on holiday and there are changes elsewhere in the code, which changes the logic, such that the previously perfect code no-longer behaves correctly – it happens. To catch this situation, the specific piece of code needs to be retested, even though it wasn’t modified, which of course is Regression Testing.
Thorough regression testing takes a lot of time, and many avenues are likely to be missed. If the tests are all automated, they will be swift, should catch most scenarios earlier in the cycle and will therefore be resolved with less effort (see the graph at the start of the article). This is safer and costs less.
I could write many more scenarios where risk is reduced, so I'll leave just one addition; a rapid fix is required to a critical situation. The fix is rushed and manual testing half-baked, leaving new errors (I'm sure we have all seen this scenario). Wouldn't it be better to know the full test suite can be run in minutes and provide a higher standard of QA?
Conclusion
There are some additional costs in automating testing, especially in the early days of adoption. But there are many more advantages, which when you consider all the scenarios leading to failure, make automated testing essential:
- Faster development times
- Higher quality code
- Easier to track development progress
- Lower risk of change
- Reduced testing costs
- Ability to turn emergency changes around very quickly and safely
Although automated testing covers so much, and is repeatable at negligible cost, it must not be considered a replacement for manual testing. Human testers will still be required for many reasons. Automation is an excellent tool to assist them in their job and allow you to provide higher quality code quicker at a lower cost.
- Multitasking Gets You There Later
https://www.infoq.com/articles/multitasking-problems - Ten reasons why you fix bugs as soon as you find them
https://www.ministryoftesting.com/2013/06/ten-reasons-why-you-fix-bugs-as-soon-as-you-find-them/ - Empirical Studies Show Test Driven Development Improves Quality
https://www.infoq.com/news/2009/03/TDD-Improves-Quality - The Forgotten Layer of the Test Automation Pyramid
https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid - Introduction to Test Driven Development (TDD)
https://www.agiledata.org/essays/tdd.html#WhatIsTDD
SDET | Performance Engineer | Java Developer | DevOps Practitioner
9 年Good one, But, I think feasibility part is missing. What to automate? following V diagram of testing, automation testing lead to all level of testing. And, automation refers to making a system that test a system which is hard and complex too. unless it is mission critical system, all automation tests are not a part of deliverable(usually). So, like as as Jim said, it is not Auto-magic. Feasible automation tests can make you project successful where bad automation planning leads to no automation. (roughly, a project may need 3.5 time more costs than development , to automate fully).
Software Test Automation Architect and Performance Test
9 年Hmm... As an Automation guy I have some different experience and views on the information. I'll comment later on. But what I've read from other comments I need to warn that Test Automation (at any level) isn't a complete solution like some want. There is still a lot of myth going around that needs to be fixed. As I'm fond to say "It's Automation, Not Automagic".
Free Lance Agile Coach and Trainer
9 年Absolutely. Without test automation it is very difficult to produce quality software , on time and ensure maintenance.
.
9 年I agree on this. Test automation is key to good, effective and efficient software development; I tested it in a small company where cost was key. Implementing Scrum and continuous integration/ continuous deployment with automated testiong increased our overall productivity and quality.
Independent Professional-, Agile & Senior Management Coach | Trusted Advisor | Founder & Co-Author Agnostic Agile (NPO) | Co-Founder & Co-Author Agile 2 | Change Catalyst | SW Developer | 15K+
9 年I would add that test automation has other benefits and goes beyond TDD. I'd rather focus on Test First, which includes TDD, ATDD, BDD, SbE. Using Test First we may actually have more than TDD discoveries early on.