This is a summary. For a deeper dive, read the LinkedIn article.
The first mistake in test automation training is making the tool the center of the conversation.
Selenium, Cypress, Puppeteer, and similar tools are useful. I had a joyful early experience with Selenium IDE and Selenium WebDriver, and for a while it was easy to think of Selenium as the default answer for every automation problem.
That view breaks down when the system changes. Microservices, cloud deployment, and faster delivery cycles make it too late to wait until an application is fully deployed before serious testing begins. If testing only starts at the black-box UI layer, the team sees defects late and learns little about whether the system was designed to be testable in the first place.
What new engineers need is not only Selenium syntax. They need to understand:
- how the application is shaped
- where the useful seams for testing are
- which risks belong at unit, service, contract, integration, or UI level
- how a test pyramid protects the team from slow, brittle feedback
- how product and engineering choices can make testing easier or harder
UI automation still has a place. The problem is letting one tool control the whole strategy. A good test plan starts with the risk and the architecture, then chooses the cheapest reliable feedback loop.
When training new engineers, I would rather spend time on the system, the user flow, and the testability of the design. The tool can come after that. A team that understands the app can learn any framework. A team that only knows the framework may still be blind to the app.