Automated testing IS engineering. End of story. It’s not testing, it’s not quality assurance (although it’s done in support of that), it is engineering. And it’s just as valuable as feature development, and worth every penny.
I’ll rant for a moment about a manual testing only strategy. Manual testing only as a strategy is absolute lunacy. Let me get this right…you’re going to pay someone to check the work of somebody else that you paid to do the work? You’re going to do this each and every time you want to release software? This is acceptable? This is a strategy?
Manual testing is slow and time consuming. It’s fraught with error, and it’s not anything vaguely close to consistent. Worse, you are double spending if you’re not actually investing in automated testing…two people, one job…make software.
The thing about automated testing is that its value scales. It saves money over time. Each test automated saves time and money. Does the menu drop down and contain 3 items? 5 minutes of manual testing. Does the search box work? 5 minutes of manual testing. Keep adding manual tests and the minutes pile up into hours. Hours cost dollars, or, worse, delays in getting that software into production. The longer lived a product is, the more that investment is going to be paying itself back over time. Take those hours and multiply times the rate you’d be paying manual testers to check the code you paid someone else to write. That’s the cost of each and every release.
The cost of each and every release I mentioned above? Spend it on building an automated testing framework instead. When that framework is catching bugs every time a build is submitted, you are substantially reducing the cost to fix them. If bugs are caught right after code is written, it’s faster and easier to identify what went wrong.Better yet…if it’s its caught before it went live, you save potential downtime and the associated revenue costs (not to mention reputational damage). Those regression bugs that hit older parts of the code base? They can take a significant amount of time to dig out why things were written the way they were.
Automated testing’s value can be seen from space…with the naked eye. What’s often overlooked and unappreciated is that the work is just as complex as feature development. Building a setup that can run thousands (or tens of thousands) of automated tests, in an on-demand, scalable fashion, where the results can be categorized or played back in the case of failures, requires significant back-end engineering. These suites have to run fast enough to provide timely results. They have to be reliable enough to be counted on to not impede development.
More complex even is that automated testing engineers have to know two professions: software testing and programming. They are building products that test products. Quickly…consistently…cheaply. Automated testing requires all the skills, rigor, and discipline that feature development does, it just isn’t as glorified a profession.
If you and your development team want to take the long view, make the up-front investment to build out an automated testing framework. Your future self – and your future bosses and co-workers – will thank you. You will find yourselves working far more on products and features that deliver value to customers, far less on hot fixes and repetitive checking of the things you have already built.
If you liked this post, please help us spread the word about it by using the Click to Tweet feature or the social sharing icons below.Automated Testing IS Engineering...and Manual Testing is Lunacy. 3Pillar CTO Jonathan Rivers writes about why #automatedtesting is just as complex and valuable as feature development in this blog post. Click To Tweet