A Software Architect Attempted to Undermine Continuous Testing — Later Eagerly Sought My Mentoring on BuildWise Before My Departure. Part A: The Story
When you understand the human factors after witnessing real E2E Test Automation, the two contrasting behaviours actually make perfect sense.
(Update: Part B is available)
Today, I'm sharing an intriguing and true story.
Many years ago, I joined a financial company as a contractor test automation engineer. Within just a week, I developed an innovative automated testing solution (with a dozen real business scenarios automated, this app is more tricky than standard web app automation)—something that an 'agile transformation team' had been researching for nine months with nothing to show for it.
After a manual tester in our team demonstrated how quickly she learned (with joy), the rest of the team began to embrace test automation. Each day, alongside my own testing tasks, I’d regularly get up to help other testers (on request) resolve their issues, typically in under a minute. By the way, this is how a real test automation coach works daily.
Our team’s software architect remained uninvolved. It wasn’t until later that I realized how wise he was, especially compared to his replacement, Steve.
Steve was a nice guy but knew little about E2E test automation (which is common), though he pretended to (also common). One mistake Steve made was not researching to discover that real test automation was already happening.
On the first day, he promoted a flawed idea in a meeting: “We should automatically raise a defect in TFS when an automated test fails.” I expressed my disagreement, and many team members supported me, which embarrassed him. We two started on the wrong foot purely due to our differences in technical aspects.
Later, the manager told him to stay out of E2E test automation. So, we were fine, at least on the surface.
In private conversations, I corrected him on some obvious mistakes in using testing terms, like when he called E2E automated functional tests 'unit tests.'
The team was using the BuildWise CT server instance running on my machine (accessing via IP address). I raised the concern of what would happen if I left, so I requested to host BuildWise on a dedicated server. The task was assigned to Steve, the software architect.
During the first meeting on this issue, after explaining that I only needed a basic virtual machine, I quickly set it up and documented the steps.
Steve asked, 'Will a VM on Azure be sufficient?'
I replied, 'Yes, the basic $40/month one should be enough.'
Steve replied, 'Easy, It’ll probably only take me 15 minutes.”
However, those 15 minutes turned into 15 hours, then 15 days, and so on. I followed up a couple of times but was met with various excuses. Eventually, I gave up.
One day, I came across a Confluence page written by Steve, “Relying on BuildWise proposes a risk to the project …” I remember it so well because discovered this when browsing Confluence with one Agile Coach (who was trying to partner with me after witnessing the obvious success).
Steve didn’t outline the specific “risks”; instead, he merely implied that BuildWise was created by me, without stating that BuildWise was free, open-source, and a winner of the 2018 International Ruby Award in Japan. Despite sitting just 5 meters apart, he never approached me to discuss this.
As my contract end date approached (I typically take short contracts and don’t renew), I brought up the topic of future hosting for the BuildWise CT server with the manager again. Shortly after, Steve, the architect, came to me and asked if he could move to the empty seat next to me. He wanted to learn how to set up and use the BuildWise CT Server.
In the remaining three days, Steve eagerly learned about BuildWise and scripting with TestWise, and I answered all his questions, just as I would for any of my mentees. I vaguely remember him cancelling all meetings and even cutting his lunch break short to spend as much time with me as possible.
After I left, Steve requested LinkedIn Connect and asked one question, which I answered. Then, never heard back from him.
What happened to the team’s E2E test automation? It failed—no surprise there. I'll cover the details in Part B: FAQ.
Related reading:
My eBooks:
- Practical Web Test Automation with Selenium WebDriver
- Practical Continuous Testing: make Agile/DevOps realWhy Software Testing is Not Effective in Most Software Teams?
🎖A Tale of a Deceptive End-to-End Test Automation Engineer (Boosted)
Benefits of Real E2E Test Automation and Continuous Testing series: Executives, Managers, Business Analysts, Developers, Testers and Customers.