Releasing software without automated tests can and will have a negative financial impact to your organization. Software will be more expensive to develop and maintain, your quality will diminish, and software updates will take longer and longer to get released.
Automated testing will also help mitigate risks associated with buggy software that can cause negative user experiences or customer service issues. Plant floor operators that can’t work because of an app crash, limo drivers missing the pickup of a VIP customer because their logistics app didn’t display important data, and online retail customers that couldn’t complete their order because of an untested scenario. Any of these scenarios can cause significant loss of revenue or increases in operations costs.
To be fair, automated tests will not solve all your problems and are only as good as the scenarios that the developer was able to think about ahead of time. But, as the software evolves, so do the tests. This is the increasing payback from the ongoing investment in automated testing. When done correctly, as new bugs or issues are found they would be documented and codified within the ever growing suite of tests.
Automated tests are not a panacea, organizations would still require some level of manual process to verify certain aspects of the software; user interface behaviors, animations, and anything else where only a human eye can be the true judge. There have been technical advances in this field as well but that topic is beyond the scope of this discussion.
Organizations sometimes choose not to support automated testing because the extra time needed to write the tests doesn’t provide an immediate ROI. When developers lack the strategies required to design testable code they will take longer to develop the testable code, at least initially. This is the perceived waste of time. But, like everything else in life, it is a phase that will pass. The duration of the phase depends upon the skills of the developer and the patience of the organization. When the skill of writing testable code is nurtured, then the tests will be the foundation from which your your high quality software is built upon.
One of the other major concerns with automated tests is that if they are not kept up to date then they become hard to maintain over time. This will occur when the tests are a lower priority than the main application code. When the test code is treated at the same priority as the application code then they will be kept as up to date as the application code, and will evolve the same as the application code. Again, there are strategies that can help with this from a developer perspective.
If I had my way developers shouldn’t ever ask if the organization wants automated tests. They should just be writing them as part of their normal day to day application development. When the automated tests are treated as a second class citizen they are looked down upon and pushed down in the stack of priorities
I get some of the reasons why an organization wouldn’t see the value in automated testing. Some can’t justify paying for code that isn’t explicitly usable by an end user or customer. Some would argue that the time spent on developing the tests would be better spent on developing features. I could go on and on… but I won’t!
I am a big proponent of automated testing and believe that in the long run it will actually save your company some money, there’s a return on your initial upfront investment of getting this process in place. The more you invest upfront the bigger the payback.
As your software product evolves and grows your developers will be able to make changes throughout the application code with confidence, they would just have to run the tests and see if they introduced any bugs. Sometimes it takes a bit to get all tests to pass, but better found during the development process as opposed to QA or production; the further away from the development process a bug gets the more expensive it’s impact, and the longer it takes to fix.
The following is a somewhat fictional story of Jack the developer and how automated testing changed his process for developing applications.
Jack’s Testing Journey
In the beginning, Jack would test his applications by manually poking at the user interface; pressing buttons, selecting items in lists, and entering text. For Jack, if the application didn’t crash then it must be working correctly. Jack would always run the application within the debugger and manually step through code, look at data points, and visually validate the state of the application after each interactions.
This process that Jack followed would force him to take a long time to deliver features. Many developers follow this process when creating the latest user interface based web, mobile, and desktop applications. The bigger the applications and the more developers working on it the quicker this process breaks down.
After many delayed releases and quality issues Jack eventually tried to figure out a better way. Jack started to separate the user interface specific code from the business logic code. He then learned that the separated out business logic could be housed within a command line application at the same time.
Jack could now write some code within the command line application that would mimic the user interface but not require all that clicking. He could then orchestrate his business logic in different scenarios using different sets of data and automate the series of tests. He would still use the debugger to manually validate things but he didn’t have to do all that clicking around in the user interface to get to the part that he wanted to test.
Once Jack started developing his applications this way he found that the separation of user interface and business logic allowed him to make changes quicker because of the better designed code. Because it was easier to run the automated tests he was writing more of them to validate edge cases and exceptions within the application. Overall Jacks quality went up and his releases were faster.
Jack then discovered testing frameworks, and his world really opened up. Instead of writing command line applications he would write a test application that would organize all his tests, allow him to run from the command line or IDE, and could give constant feedback as he coded.
Jack was finally able to kick the manual debug steps but coding the logic to assert state and data right within the test itself. In some case he had to redesign his code yet again to enable the ability to assert certain things within the application. These redesigns led to a better designed application that was easier to change.
Jack’s process didn’t change over night, it was a little painful, and cost the company a little extra time and money as he got up to speed. But, as Jack’s skills increased he was able to save the company money by cutting down on bugs, releasing features quicker, and providing higher levels of customer satisfaction
Summary
Developers should never have to ask automated tests are desired or if they should be delivered with the application being developed. Developers should be creating tests as part of the code writing process. If they have to provide hourly estimates they should include the time to write tests and design the code to support testing, but not specifically call out tests anywhere in their estimates. If developers get questioned about why they took the time to write tests, their response should be that the writing of the tests is how they’re able to deliver higher quality features faster and with less risk to the business.
When I release a piece of code I want to tell the stakeholders that it WILL work, not that it SHOULD work. It is my responsibility to mitigate any risk to a company by delivering the highest quality code possible.