I very much dislike automation trainings starting with teaching Selenium,
For starters that’s the wrong place to do automation. One should focus more on API tests and do a handful UI checks.
Secondly, automation is a means to an end, not an exercise for the heck of it. Therefore talk about why to automate.
Thirdly, in some cases folks learning automation don’t really learn how to test well either. If your testing is bad, your automation is just going to amplfy that bad.
Lastly, without knowing how the underlying architecture of the product works, IMHO one cannot truly learn how to test well.
So next time you plan an automation training, make sure you get the fundamentals right first.
#RedefiningSoftwareQuality #TestAutomation #Training
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.
Thank you for adding Jason. Automation is means to an end, to facilitate testers to highlight risks as early as possible. Where applications are not built with REST APIs, we can still have API tests.
IMHO UI tests need to happen, but just to test the code running on the UI, not the whole business logic piece.