Topic: Decide whether automatic testing makes sense for y

Even if nobody changes your software, the environment that it lives within can still change. Most software doesn't live in isolation; thus, it cannot dictate the pace of change.

Virtual machines are upgraded. Database drivers are upgraded. Databases are upgraded. Application servers are upgraded. Operating systems are upgraded. These changes are inevitable—in fact, some argue that, as a best practice, administrators should proactively ensure that their databases, operating systems, and application servers are up-to-date, especially with the latest patches and fixes.

Then there are the changes within your organization's proprietary software. For example, an enterprise datasource developed by another division in your organization is upgraded—and you are entirely dependent upon it. Alternately, suppose your software is deployed to an application server that is also hosting some other in-house application. Suddenly, for the other application to work, it becomes critical that the application server is upgraded to the latest version. Your application is going along for the ride whether it wants to or not.

Change is constant, inevitable, and entails risk. To mitigate the risk, you test—but as we've seen, manual testing quickly becomes impractical. I believe that more automated testing is the way around this problem.

Some argue that management should be responsible for coordinating changes; they should track dependencies and ensure that if one of your dependencies changes, you will retest. Cross-system changes will be synchronized with releases. However, in my experience, these dependencies are complex and rarely tracked successfully. I propose an alternate approach—that software systems are better able to both test themselves and cope with inevitable change.

As I see it, organizations that do not cope with this change often lean in one of two directions: those who reduce their testing to maintain the pace, and those who reduce the pace to maintain their testing. Each of these approaches has its problems.


Organizations that reduce their testing to maintain the pace tend to say: "Manual testing takes too long, and automated testing is too hard, so we just won't test as much." Consequently, they suffer from all of the problems that result when you reduce testing. However, as I mentioned in my introduction, this article doesn't argue why we should test, so I won't discuss the subject further.


Organizations that reduce pace to maintain testing tend to say: "Testing is important, but writing automated testing is too hard, so we'll manually test." This is better than no testing, but I do not believe that on large systems in an enterprise environment, manual testing can cope with the necessary pace of change. Reduction in pace is a barrier to the system's advancement—the software's architecture slowly but steadily degrades. For example: application servers are not upgraded, and new projects are forced to use old platforms because it is not practical to manually retest everything already deployed on that platform.