A recent posting (apparently no longer available) on LinkedIn entitled “Why Is Automated Software Testing A Better Choice?”, prompted some discussion. (As usual, the question “better than what?” was begged.) Then came this comment from my friend Jon Hagar: “There are … environments where the team must automate, e.g. a fast embedded control system where computation cycle is 10ms.”
You might be inclined to agree with Jon, and I might have been too. But then I remembered this incident.
At one point a few years back, I was attending a testing conference. When I arrived at the registration area, the first person I saw was Jerry Weinberg. I hadn’t seen him for several months, and was delighted to see him again.
“Hi, Jerry,” I said, offering and accepting a hug. “Great to see you! And I’d really like to hang out with you as much as I can for all four days of the conference, but I have to go home.”
“No you don’t,” said Jerry.
I was taken aback. “Huh?”
“You don’t have to go home.”
“No, Jerry, I really do. My family’s there, and I’ve been away a lot lately.”
“You don’t have to go home. You don’t have to do anything.”
“Well…”
“You don’t have to go home. You want to go home, and you’ve chosen to go home. And that’s fine.”
I paused for a moment, and on reflection, I realized that was it was true. Jerry, in his Zen-master way, was reminding me to speak and think precisely. If we do The Right Thing reflexively and unconsciously, without recognizing that it’s optional, there’s a risk that we could do The Wrong Thing just as reflexively and just as unconsciously.
Since I wanted to see my family, and since I wanted to be a good husband and a good father, I had chosen to go home. I was not compelled to go home. In that case, going home was a choice—one that was important to me, and that I was happy to make, and that would serve me well, but a choice nonetheless.
So… you don’t have to automate, not even for a fast embedded control system where the computation cycle time is 10ms. You could decide that your faith in the designers, your theory about how the system is constructed, and your confidence in how all its parts work together is good enough for you. You might decide that you could trust the designers and the theory and the implementation.
You could subject the code to peer review. You might try simulating the system, or interacting with the real system in some super-slow mode. That is, you could proceed based on theory and on trust, even on that kind of system. People sometimes select tools thoughtlessly or don’t use them at all. You don’t have to use appropriate tools, because you don’t even have to test.
But maybe it’s important for you to learn things about that system, things that might cause intolerable problems for real customers in the real world. If so, it’s probably important to you to perform experiments that enable you to vary the conditions you set up, the inputs you provide, and the behaviours you observe. It might be important for you to do it quickly, in a way that’s beyond the bounds of your unaided perception.
If those things are all true, then selecting and using appropriate tools to help you test—along with developing the skills to use them expertly—will guide a choice to use tools expertly. In that case, using tools is a choice—one that’s probably important to you, and that you’ll be happy to make, and that will serve you well, but a choice nonetheless.
You don’t have to use tools, but you want to use tools, and you can choose to use tools. And that’s fine.
Thanks for the post! Worth remembering, and puts the power in the hands of people, rather than being a slave to the tools that are supposed to be helping them. On precision of language I’m reminded of a reply I gave to someone asking what stages of the software testing lifecycle they could skip to make testing less time consuming. All of them, of course.
Clearly the points of this blog post were to stress the importance and need to speak and think precisely, and that automation isn’t a requirement, but a choice. I agree with both.
That said, I’m focused on the words (as usual)… ?
Let’s consider the 2 phrases in question: “the team must automate” and “I have to go home”.
The first phrase uses the word “must” while the second uses the word “have (to)”. Using Merriam-Webster to get definitions for both words I found a lot of similarities and cross-over. Both words could be used to express something that is absolutely, positively required. See “You must breathe to live.” And “You have to breathe to live.” And both words could also be used to express something that is recommended, urged, or compelling. See “You must read this book!” and “You have to read this book!” In fact, both definitions make reference to the other word! So, since the words “must” and “have (to)” are essentially interchangeable, how can we differentiate their meaning? By context.
The context of the first phrase (“the team must automate”) was a semi-formal discussion on automation. In this context, I would expect the participants to be much more vigilant with their choice of words. In this context, it is very important to speak and think precisely in order to communicate exactly. As this blog post does, I would challenge the phrase and meaning “that we absolutely, positively are required to automate”.
The context of the second phrase (“I have to go home”) was an informal conversation between colleagues (friends?). In this context, I would expect the participants to be less concerned about speaking and thinking precisely. I wouldn’t see the need to challenge the phrase, and would likely understand that the intended meaning was “I want, choose, and am compelled to go home” rather than “I absolutely, positively am required to go home”.
No disrespect at all, but to me, in this particular instance, Jerry’s response was a “Well, actually…” (tirania.org/blog/archive/2011/Feb-17.html). As in, “Well, actually…You don’t have to go home. You don’t have to do anything.” Gotcha! In this particular instance, I don’t think it added to the conversation, but detracted, instead.
I like to think that I do speak and think precisely…when it is necessary and appropriate. If I spent so much time considering each word, even when informally talking with friends, I’d have a hard time communicating, at all.
Just some quick thoughts on a Friday morning. What do you think? Thanks!
Actually “well, actually…” is a good rhetorical tool. We should not let some hipster moralist sour it with his whinging.
I think Michael’s point is that one of our rhetorical strategies in conversation is to obscure our own agency in the choices we make. In engineering this can be dangerous, since it discourages critical thinking. We don’t need everyone at all times to speak precisely, but sometimes it is important and sometimes it is good practice.
Michael replies: Exactly so. If you look carefully, the “Well acutally” guy was well-actuallying “Well, actually…” Some habits are hard to break, I guess.
James,
Thanks for the reply! It took me a while to parse and understand your reply, but with some help 😉 I think I got it.
I had focused on Jerry’s reply, while Michael was attempting to highlight Jon’s. If I may attempt to paraphrase your reply: Sometimes, (consciously or not) using certain words (or vague language) can distract from or hide our intentions (decisions) and avoid dispute, which could be bad in some situations (like engineering).
Yes?
[…] Blog: We Have to Automate – Michael Bolton – http://www.developsense.com/blog/2014/02/we-have-to-automate/ […]
Great post, loved reading it. Since the subject was test automation, was wondering if anyone had an answer to this. I’m looking to create some automated tests but have limited coding knowledge. I have used Microsoft’s Test Manager, VS Coded UI Tests and Selenium but all have been lacking in some respect. Anyone who is aware of any other testing tools for creating automated tests, i’d love to hear from you. Please e-mail me at Peter.Molchan@leg.wa.gov