A Software Architect Attempted to Undermine Continuous Testing with BuildWise—Then Eagerly Sought My Guidance on BuildWise Before My Departure. Part B: FAQ
Understand some human factors essential for implementing real Continuous Testing in Agile and DevOps.
After the story, some readers might have some questions, such as:
Why did this software architect want to sabotage by targeting BuildWise?
Why was this software architect so eager to learn BuildWise (and TestWise) during your final days there?
Do you think this software architect mastered E2E test automation well enough to apply it in future projects?
What happens to the Test Automation later in that company?
Lesson for Software Company Founders/Executives
Lesson for Software Professionals: Cherish the rare opportunity, if you're extremely lucky, to work with a real E2E Test Automation Engineer.
FAQ
1. Why did Steve want to sabotage by targeting BuildWise?
The reason: Steve couldn’t target the test scripts, Selenium/Appium + RSpec, is 100% open and standard-based, and Selenium is well known. He couldn’t target TestWise either, because it has already been proven, and loved by the testers and even some developers in the team. If to change, people might ask, “OK, Steve, can you suggest a TestWise alternative to continue developing our automated tests?”
It’s common to encounter absurd proposals for test automation frameworks and tools, as you may have experienced. However, this situation is different—a successful, functional, and free approach is already in place.
If the BuildWise server is running successfully (as it was) and accessible to the team (then, maybe beyond this team), and he does not understand, he would feel embarrassed. So, naturally, he resorted to sabotage to prevent others from seeing BuildWise running. From Steve’s perspective, it's fine for BuildWise to run on an individual developer’s machine (no hostname), as it delivers value to the team every day.
It is a fairly common result, my daughter encountered pretty much the same during her internship. Check you this article, “An IT Graduate’s Frustration with a Fake ‘Senior Test Automation Engineer’”. An underminer, unable to stop the established success of E2E test automation within the team, takes the first step by preventing outsiders from seeing it. Then, they cite a so-called upper management decision—such as “must use TypeScript,” “we’ve decided on Cypress,” or “adopt a Gherkin framework”—to completely smother the success of E2E testing. I have experienced this far too many times.
Back to the architect’s sabotage. It is easy to target BuildWise too, because:
it is not well known.
it is free and open-source, i.e., can’t blame the vendor.
the company has already decided on commercial CI servers, such as Bamboo, despite not being suitable for executing E2E tests.
Steve is not a bad person at all; he simply lacks skills in E2E test automation, like most software professionals. When he had to take on tasks related to E2E test automation and Continuous Testing, it was outside his area of proficiency, and he had to ‘protect his professionalism’. He proabaly never expected to meet a real E2E test automation engineer in his life time.
2. Why was this software architect so eager to learn BuildWise (and TestWise) during your final days there?
Keep reading with a 7-day free trial
Subscribe to The Agile Way to keep reading this post and get 7 days of free access to the full post archives.