My parents dropped my wife and I at Hobby airport in Houston after spending Christmas week visiting with them. The baggage ticketing line and the security lines were pretty long as you’d expect for the holiday. TSA agents kept our skies safe by patting down the 80 year old lady in a wheel chair in front of us and me before we made it to our gate. She was clearly menacing. My pants were a little loose.
We eventually made it to our gate and after some reading, people watching, and waiting lined up to board when our group was called. But we never made it on that plane.
After waiting about 45 minutes past the board time, the Southwest person at our gate announced that the autopilot system on our plane was broken and we would be taking a different plane from a different gate.
I distinctly remember that people used to fly airplanes, not autopilots. When I was a kid, my family took a short site seeing flight over the Grand Canyon. The plane was small enough for the pilot to ask people how much they weighed so he could distribute the weight evenly. A person flew that plane.
Can People be Removed From the Software Equation
In software, there is a concept of automation. The word usually implies something along the lines of a computer doing something with little intervention or guidance from a person. ATMs give or take money when no tellers are around, and car washes drag your car through a building with sprayers and brushes.
Teams building software, at least some of them, are trying to automate their work, too. Talk with dev or test managers and you’ll probably hear about how they either want to or are currently going through the efforts to automate as much of their testing work as they can.
I see this most often in Agile and continuous delivery (CD) shops. The normal model in these environments is to use a code design aid like test driven development, add to that some sort of integration tests, and maybe pair programming. This isn’t a bad thing, you end up with lots of change detection and lots of reports telling the programmer that they in fact did what they think they did.
The danger here is the loss of interaction. Groups move away from the pulse of the product and fly almost exclusively based on autopilot. Even worse is the idea that all of this code testing means that the development did their job and did it right.
Maybe this can work in some contexts. My guess is that this works best when the people using the product aren’t the paying customer, or the product has no users yet.
A Human Touch
Autopilot isn’t flying your plane and automated tests aren’t testing your software.
The interplay between your tester and their testing tools is what makes them useful. Tools like automation are useful because they help us do things faster, or they give us information in a special way that would be otherwise be difficult. We use tools to help us make decisions and to figure out what to do next. Automation isn’t doing the work, people are.
Lately, I have been using the phrase tool aided testing, or just testing, to describe software testing work I do with the help of tools. The tools aren’t testing software, nothing is actually getting automated, but they are helping you do things that maybe you wouldn’t want to do without them.
Furniture makers never say they they made a chair with tool aided furniture making, they just say they made a chair.
I don’t know anything about the role of autopilot in airplane systems, but I do know a little bit about software development. It’s concerning that we happily handover controls of our mass transit systems from trained professionals to software made by people with some vague understanding of what happens on a plane.
I’m not going to stop flying (or testing software).
That would be crazy.