The More Things Change…

As test automation gains traction in the IT industry, people who have specialized in manual software testing worry about what may happen to their careers. It’s a hot topic these days.

To understand who is affected by the growth of test automation, and the possible reasons they are worried about the impact to their careers, it may be helpful to clarify terms. People tend to use the word “test” in a pretty loose way. Personally, I like the distinction between testing and checking described in this piece by Michael Bolton: Testing vs. Checking.

What is changing?

Most checking (and in some cases, all of it) lends itself to automation. If we control the inputs and the execution environment and we know the expected result, it’s usually possible to set up some form of executable check that can set up the preconditions, exercise the code under test, and verify the output matches expectations. The ecomomic decision comes down to the relative cost and benefit of doing the checks manually vs. creating and maintaining automated checks.

In contrast, testing in the sense Bolton and others have defined it does not lend itself to automation. People who perform software testing (by this definition) have nothing to fear from the automation of routine checking. If anything, the more checking that can be automated, the better for testers. In many organizations, they already spend far too much time performing manual checking, and they don’t have time to do the value-add work they would prefer to do as testers.

Who is affected?

So, why are testers worried? They aren’t. The people who are worried are those who perform manual checking by following scripts prepared by senior testers. And all of them aren’t worried. The only ones worried are those who can neither (a) learn to become testers, nor (b) learn to automate routine functional checks. Demand is growing for people who have genuine software testing skills. Demand is growing for people who specialize in test automation.

It occurred to me the question of what will become of manual checkers is an example of a recurring pattern: As the industry evolves, a given activity may no longer have to be performed manually, or it may not need to be performed at all, or it may become a commodity service that can be supported by a smaller number of workers than previously. If that task used to require an army of people to support it, and many individuals have specialized in performing that task, then how will they respond to such a change?

Mounting tapes

In the 1960s and 1970s, there were full-time jobs in data processing shops for people to mount and dismount reels of magnetic tape, and to catalog and manage the storage and retrieval of such tapes. Eventually, that job was automated. A few years later, reels of tape were no longer used routinely to store active files.

What happened to the people who used to handle the reels of tape? Did they die? No. There’s plenty of other work to do. Most if it is substantially more interesting than handling reels of tape.

Back-office applications

In the 1970s and even into the 1980s, programmers often worked full-time to develop and support custom, in-house accounting applications for corporations. Eventually, accounting applications became commodity products. Today, companies wouldn’t consider developing and supporting a non-differentiating, back-office application system in-house. It is not a cost-effective use of software developers’ time and skills.

What happened to the people who used to write custom accounting software? Did they die? No. There’s plenty of value-add development to be done on applications that differentiate the company from competitors or that create new markets. Most of it is substantially more interesting than writing back-office applications.

Network architecture

In the 1980s and 1990s, and continuing into the 2000s, enterprise architects spent a fair amount of their time keeping track of available IP addresses, and diagramming and documenting the static addresses of every device connected to corporate networks. It was tedious and error-prone work. It was also necessary.

Today, routine aspects of network management are handled by tools. Your friendly neighborhood cloud provider uses dynamic infrastructure management to create and destroy virtual servers routinely. There are tools to automate this task for non-cloud environments, too. Someone has to define a range of IP addresses, but no one has to draw diagrams manually or keep track of IP addresses manually anymore.

What happened to the people who used to manage IP addresses manually? Did they die? No. There’s plenty of architectural and infrastructure-related work to be done. Most of it is substantially more interesting than documenting static IP addresses by hand.

Deployment and release management

Until well into the 2000s, most deployments of software to production (as well as through intermediate environments) and most release management activities have been carried out using manual methods. Large organizations have whole teams of people whose work consists only in doing these things. Tooling is available today that can automate nearly all this routine, repetitive, and error-prone work.

What’s happening to the people whose jobs consist in manually deploying and releasing software? Are they dying? No. There’s plenty of other work to be done. Most of it is substantially more interesting than provisioning environments by hand, migrating code through environments manually, and dealing with release issues in a reactive mode.

Software testing

From the dawn of software to the present, testing and validating software systems has been done primarily using manual methods. Starting as far back as the 1960s, people have devised ways to use software to test software, beginning at least with Higher Order Software invented by Margaret Hamilton while working on the Apollo Guidance Computer. Today, a wide range of software-based testing tools can free up testers’ time by automating routine checking.

What will happen to the people who perform routine functional checking by hand? Will they die? No. There’s plenty of value-add work to be done in software testing. Most of it is substantially more interesting than following a documented test script by hand to verify that a known piece of functionality works today the same way as it did last week.

Why the angst?

Change doesn’t come easily or naturally for most people. It’s stressful enough if your employer has to cut back and you find yourself in the job market, looking for another job just like the old one. How much more stressful, then, if it isn’t a question of finding another, similar job, but a question of adapting to a larger change in the industry; a change that may mean your old job won’t exist at all, anywhere?