Reflections on China's Transformation of the Car Industry, Part E: Faking efforts with “Show Ponies” 👎🏾
No commitments, no win.
Agile software development, rooted in Lean car manufacturing principles, emerged during a pivotal revolution in the 1980s. Now, we are witnessing another, much greater, transformation in the automotive industry—one that may offer valuable lessons for software professionals. In this series:
Part A: The Disruptions
Part D: Traditional Car Manufacturers Reluctant to Evolve 👎🏾
Part F: Lacking on Plan B and C 👎🏾
Part G: Acknowledge Mistakes
The first pavilion I visited at the 2010 Shanghai World Expo was General Motors, which left a lasting impression on me. Inside, they presented a prototype of an electric vehicle (EV) on stage, followed by a film envisioning a future of entirely eco-friendly transportation.
In other words, while GM, a giant in the automotive industry, seemed to have plans for EVs (or new-energy vehicles), they did very little to bring those plans to fruition. As evident from the image above, the showcased vehicle was far from practical, starkly contrasting with Tesla's first EV, the Roadster, released in 2008.
It's easy to talk but hard to execute. Creating a functional production pipeline is a completely different challenge than building a prototype. Telsa started with a firm commitment to doing it real and learning and growing, while GM did little more than show ponies for many years.
Of course, most of GM's senior executives were well aware that its EN-V concept car was merely a show pony. While they sang about the benefits of future EVs, such as energy efficiency, pollution reduction, … etc., deep down, they didn't truly believe in EVs back in 2010, at least, not seriously.
I’ve seen this behaviour repeatedly in E2E test automation at many organisations, where many automation initiatives—often in the form of proof-of-concept (POC) projects—were created merely to somewhat justify “we are doing agile.” However, CIOs and senior managers rarely treated E2E test automation with genuine seriousness.
Test architects or principal software engineers who lack a solid grasp of E2E test automation often conduct proof-of-concept projects that serve merely as showpieces. Their focus was producing a good-looking demo, that’s all.
This explains why, despite the proven and standards-compliant Selenium WebDriver being available in 2011, many projects still chose the demo-friendly but functionally limited Cypress (Check out the article "Why We Switched from Cypress to Playwright"). I once witnessed a Cypress POC showcase at a company whose app relied heavily on Frames—a feature Cypress didn’t even support. Yet, the audience enthusiastically praised the presentation. It was pure madness!
E2E test automation efforts are often treated as a futile, money-wasting exercise, with both the CIO and participating QA engineers fully aware of it. It's a sad reality!
To mature adults, this kind of behavior was not unusual. For instance, in Australia—my home country—a vast land with relatively few people has somehow led to one of the most unaffordable housing markets in the world.
Over the past 25 years, different political parties have promised "housing affordability" programs during election campaigns, but in the end, these promises turned into mere show-pony policies once in power. Why? Because the government never had a genuine interest in making housing affordable. It was simply a game they played.
A candid senior QA engineer once told me, "Before meeting you, we didn’t believe E2E test automation was even possible. Yet, we kept trying out new, overhyped frameworks and tools, hoping to stumble upon a miracle solution. When our chosen tool or approach failed, we simply needed to come up with an excuse—usually blaming the commercial vendor. No one was ever held accountable. Honestly, we’ve been pretending for years."
I typically completed the planned 3-month E2E test automation POC in just 3 to 5 days, which upset the fakers. Why? Because I used the free, open-source Selenium WebDriver with RSpec, which had been available since 2011. The results—seeing test execution in the browser—were undeniable, and they realized it was simply a matter of skill. More often than not, senior engineers would attempt to sabotage my work. The most common tactic was refusing to allow Ruby as the scripting language, which was ridiculous since black-box testing is completely independent of the programming language. Yet, more often than not, the fakers prevailed. Why? Because few senior managers were willing to support an outsider. After all, it is just a job.
From my experience, with executive support (like this case at LinkedIn), the benefits of E2E test automation could be realized in weeks, if not days. However, once again, most IT executives are not wise enough, much like their counterparts in the automotive industry, to recognize this.
If you are a software manager or start-up owner and want to implement real E2E test automation, check out this article, “Test Automation and Continuous Testing Competition Week”.
Related reading:
My eBooks:
- Practical Web Test Automation with Selenium WebDriver
- Practical Continuous Testing: make Agile/DevOps realBe aware of the “fake it until you make it” mindset in Test Automation and CI/CD
Benefits of Real E2E Test Automation and Continuous Testing series: Executives, Managers, Business Analysts, Developers, Testers and Customers.
Comments on the claims of “7 ways Cypress is different”. All False, Wrong or Lie