Deprecated: Function create_function() is deprecated in /home/qualit96/public_html/wp-content/plugins/revslider/includes/framework/functions-wordpress.class.php on line 258

Warning: Cannot modify header information - headers already sent by (output started at /home/qualit96/public_html/wp-content/plugins/revslider/includes/framework/functions-wordpress.class.php:258) in /home/qualit96/public_html/wp-includes/feed-rss2-comments.php on line 8
Comments on: Don’t start with learning Selenium https://quality-spectrum.com/dont-start-with-learning-selenium/ Redefining software quality Thu, 16 Jan 2020 16:06:53 +0000 hourly 1 https://wordpress.org/?v=5.5 By: Ali Khalid https://quality-spectrum.com/dont-start-with-learning-selenium/comment-page-1/#comment-22856 Thu, 16 Jan 2020 16:06:53 +0000 http://quality-spectrum.com/?p=14914#comment-22856 In reply to Jason Yang.

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.

]]> By: Jason Yang https://quality-spectrum.com/dont-start-with-learning-selenium/comment-page-1/#comment-22811 Thu, 16 Jan 2020 06:55:23 +0000 http://quality-spectrum.com/?p=14914#comment-22811 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.

]]>