The Agile Architect

Why CEOs Should Care About Test Automation

As CEO of a tech company, you've been briefed by your VP of IT on the benefits of test automation. While the reasoning seems sound, it clearly is not an area you personally care much about. You should care. A lot! Our Agile Architect will tell you what your VP should have.

You are the CEO of a major tech company. You are sitting in your board room with your company President and VPs. Your VP of IT is droning on about the benefits of test automation. He's been talking for five minutes about some nonsense regarding increasing quality and time to market using test automation. All good and desirable things, but why is he wasting your time with it? Besides, you can get these same benefits from an inexpensive army of offshore manual testers.

The CEO's Argument for Test Automation
From a CEO perspective, there is one thing that automated testing provides that you cannot get from manual testing. And that is equity. By equity, I am referring to business value as an innate component of your company. One that can't walk out the door because a better offer came along. One that is not dependent on the tribal knowledge of people to realize the value.

Simply put, to maintain the value of your company, that value should be locked into assets of the company, not the people who work there.

Think about it: The value of your tech company is in your ability to maintain and update your software. The software itself has value, but it has a short shelf life and can become stagnant. The true, sustainable value is in your company's ability to move the software forward.

The current value of your software is in 3 places:

  1. The people who built the software, including programmers, testers, and product owners
  2. The software itself and the documentation supporting it
  3. The automated tests that describe what the software is supposed to do

Let's take them one at a time.

  1. The people who built the software, including programmers, testers, and product owners
    The value of your people is in the intellectual property (IP) they hold in their brains and in the tribal knowledge that provides context for that IP. While a good company will do things to retain its people, there's no guarantee that they will stay. Events outside your control could trigger a mass exodus. Even the loss of a small number of key people could mean important parts of your IP evaporate.

  2. The software itself and the documentation supporting it
    Then there's the second location for value: the software itself. Except, without proper testing, the integrity of the software can and will degrade over time. You might think that your documentation, including manual test scripts, will prevent that from happening. It won't. Documentation goes stale. In a rush to make a change to the software, the documentation is forgotten or ignored. Soon, you're not sure if the code is right or the documentation is right. Important business rules are mangled, forgotten about, or simply misinterpreted.

  3. The automated tests that describe what the software is supposed to do
    Then there's the third place where your business value lies: the automated tests and the supporting automation infrastructure. This is the only truly dependable, innate equity in your software. With proper test automation, the documentation for the system is literally your executable tests. Because your documentation is executable and runs every time the code is updated, it is not possible for it to become out of date with the software. In fact, with rigorous software development that includes test automation, the automated tests test the software and the software tests the automated tests. Change either one and the other breaks, causing a failing test that immediately warns you of the error.

For this to be successful, both the code and the tests must be well written and self-documenting, meaning that the executable code and automated tests describe in English their intent. No, this doesn't mean use a lot of comments. Self-documenting code has almost no need for comments. Well written automated tests encapsulate and explain, not only how the system works the way it does, but also why the system works the way it does.

What Equity?
What is this business value, this equity, that we want locked into the software through test automation?

  1. Equity of the software itself to perform its functions properly and/or to be sold for profit
  2. Equity in business rules encoded in both the software and the automated tests
  3. Equity in additional product knowledge encoded in both the software and the automated tests

This equity is protected by your ability to update the software, maintain quality, and ensure data integrity. And that protection is safeguarded by test automation, including automated tests that are the property of your company.

Final Thoughts
As CEO, you are ultimately responsible for the value of your business. If the knowledge of your company resides predominantly in the specific people who work for you at this moment, you are at risk. If that value is encapsulated in your rigorously written software and test automation supported by smart but not indispensable people, you've minimized your risk and maximally locked in the equity of your company.

Building that rigorously written software and test automation is not easy. Luckily that's someone else's job. But that's an article for another day.

About the Author

Dr. Mark Balbes serves as Vice President, Architecture at WWT Application Services, and leads multiple Agile projects for Government and Fortune 500 companies. He received his Ph.D. in Nuclear Physics from Duke University in 1992, then continued his research in nuclear astrophysics at Ohio State University. Dr. Balbes has worked in the industrial sector since 1995 applying his scientific expertise to the disciplines of software development. He has led teams as small as a few software developers to as large as a multi-national Engineering department with development centers in the U.S., Canada, and India. Whether serving as product manager, chief scientist, or chief architect, he provides both technical and thought leadership around Agile development, Agile architecture, and Agile project management principles.