Steam unfurled lazily from my tea in the quiet of agile alley. A sudden eddy broke my concentration as did a subtle alert of an instant message. Usually an IM from Steve, a tester on my team, arrived with a friendly salutation followed by some details around an unusual defect. This time, she asked that I stop over. I’m Reynolds McHumphrey – everyone calls me Mack.
Steve started as a business analyst out of school. With an eye for detail, a mind for programming, and passion for technology, she moved into testing. If she asked me to come upstairs to her cube, she needed a collaborative ear. I recalled her team was working on closing costs transactions.
I walked up the stairs and through the windows I could see gray gathering in the west. Leaves fluttered as a summer breeze picked up. It’ll probably rain. I arrived in Steve’s alley and saw John sharing some notes and diagrams with her.
“Hey Steve. John.”
“Mack! Hello! John and I were reviewing his plans to migrate the automated regression tests.”
I looked at her trying to stifle surprise in my face. “Oh?”
“Yeah”, she replied through a squint.
Skepticism had leaked in my voice. The automated regression was just starting to demonstrate benefit. It had its issues at first, but now we were relying on it to check hundreds of transactions with diverse inputs. This allowed Steve and her team to delve into higher risk scenarios, collateral impact, and infrequent batch processes. They had already found four defects that had been in the system as long as six months. I turned to John.
“Mack”, he brimmed with impatience, “this new tool became available in Git about a month back. It has native JSON libraries, improved performance, easier configuration – you know we’ve always wanted that, and lots of other cool stuff we can use.”
I kept my eyes on him while I took a sip of my tea wishing it was a stiff shot. He was silent. When it felt like the wake of his enthusiasm had crested and was returning to normal, he continued.
“Yeah. So, we, me and the other automation guys, we reviewed the present automation, split up the functions and re-wrote it all. I stopped over to see Steve so I could explain how to use it.”
Amidst the red flags waving around my head and dull thunder outside, I managed, “How do you mean ‘use it’?”
“Well, we want to deploy today it so you can start using it. It’s really cool! But it’s a little different in the start up. Ahhh – and the reports.”
I looked at Steve. Some hair had fallen over one eye, the other was looking at me, and she had a knowing smirk. I looked back at John. We were fortunate to have John and his team. It required a bit of energy to help our business team appreciate the value of automation in testing. They had concerns around the cost and maintenance, and rightly so. Many experiments with automation often resolve to maintenance nightmares, technology-of-the-month trials, or flaky results. I didn’t want our shop to follow in those industrial accidents.
We had described our implementation and maintenance plans, and how frequent use of automation could grow confidence in our products. With the time saved, our testing teams could dive deep where we saw fit. Steve’s team was the pilot for automation.
“John,” I started, “how much time did your team spend on this, ah, migration?”
Rain was hitting the roof – I may have left a car window open.
“Um, two of us worked about five or six days on it. I worked on it at home a little, too.”
“I see.” I held one arm in the other, pulled my hand across my mouth, rested my chin on my hand, looked at him intently, and let out a sigh. He half smiled, looked at Steve and then at me.
Energy and initiative are rampant with John and his team. Even while they developed the present automation, we did well to direct their energy without prescribing their work. Since its introduction into our work stream, we haven’t been meeting as often. Without a rudder, the automation team knew they “could” but neglected to ask themselves if they “should”.
“John, I appreciate your enthusiasm as always.” He detected a “but”. “But, we can’t deploy this new automation right now.”
“It’s so cool though and you’ll love it.”
“I’m sure. Let me ask you, what is the added benefit to Steve’s team?”
His face betrayed confusion. “Aaahh – ummm”.
“The present automation allows her team to investigate our more complex transactions. It provides them the benefit of time. And, we prioritize that time on complex and risky tests. If we deploy new automation, her team may have to execute tests manually while you get it running. We would lose not only the time spent in manual testing, but the time lost in what we could be testing. That’s a big impact.”
The puzzle was taking shape for him.
“If all you have done is to provide a replacement, there is no net benefit to our testing effort. That is, we would not get any more time to test our priorities for your effort.”
His expression was “Oh no”. Or something like that.
“Mack, I – I’m sorry. The tool just showed a lot of promise. We even created automation for your other team.”
“Let’s talk about that. We should also start meeting regularly.”
During our meetings, the testing team and automation team discussed methods of maintaining existing automation, and evaluating new tools. Frequently, Mack led discussions around topics from the book “Specification By Example”. He also encouraged the teams to answer two questions: “Can we?” and “Should we?”.
The first question was easy but the second question prompted them to investigate how the testing team would benefit. They decided that for the efforts of the automation team, the testing team should be able to, incrementally, expand their manual investigations. Over time, the automation grew to provide not only more time in manual testing but it improved project pace and reduced project duration.