Don’t start with learning Selenium

I seem to have different feelings about Selenium. I think it is a great platform to teach QE how to start thinking like a developer with the design and function of an automation framework and what that framework targets. Sure API is important, but not all web applications, especially ones from the late 90s and early 2000s have a fully functional REST API for people to work with. You talk about a means to an end, but what end are you implying? Good quality? Ensuring quality, I feel, is an exercise but one that must be practiced constantly without end. We don’t stop testing just because we are between releases, and we shouldn’t stop testing just because we stop supporting software. This is why we have CI/CD. Automation is a tool for continuous QA, not a “means to an end”. On your third point, yes if you have a bad foundation, then everything else is bound to crumble. But being afraid to build that foundation on something that has been proven and has patterns and software models already designed and mathematically proven for it only prevents you from making progress. And yes without knowing how product architecture is setup, we cannot test to the best of our abilities. Have you heard of black-box testing? Have you ever reverse-engineered something from a set of test-cases derived from a systems manual and test exploration sessions? Yes UI testing can be unreliable and cumbersome, but the UI is where your clients and customers are going to see the defects you missed first. The UI is how your clients and customers will deal with those bugs, and whether or not they continue to use your product. I strongly believe that it is the UI that is a better introduction for SDETS to understand the problems and frustrations that they are trying to solve, and moving into unit tesitng and API testing only strengthens their toolkit and helps them build better automation frameworks. Without seeing the application of the APIs, students are more likely to get bored with API testing.