My Testing Thoughts

In today's world, where new automation test solutions are being released monthly, enterprises are looking for ways to expand and accelerate their software delivery processes. The key to success is choosing the right solution that balances your team’s skill sets and expertise and simultaneously meets your organization’s objectives. This blog details out the pros and cons of code-based vs. low-code/no-code test automation solutions. Author: Dheeraj Gambhir Blog Link Enjoyed reading this article? Please share the knowledge with your friends and colleagues.

QAOps - What is it? Is it a specialization or a new team role? – The answer is No.  QAOps is critical for teams that automate their Continuous Integration and Continuous Delivery (CI/CD) pipelines, as it focuses on speed without sacrificing quality. Head over to our recent blog that explores the various ways to implement. Enjoyed reading this article? Please share the knowledge with your friends and colleagues.

 A huge pain for SDETs is filling mock data to our automation test. PODAM is one such library that is easy to use, requires little to nothing set up, and auto-fills Java POJOs with data. It initializes a java object tree with random data, but you can also define a strategy or use attributes to decide the values that should be set (this makes it more powerful than other libraries like Java Faker, JFairy, etc.)   Read more here: https://mtedone.github.io/podam/index.html   Quick nice video: https://youtu.be/oaQSb-PxrrI Enjoyed reading this article? Please share the knowledge with your friends and colleagues.

  Pynt is a free API security solution that generates automated security tests based on your existing functional test collection within postman. It appeals to perform dynamic security testing covering all the OWASP API Top 10. More details:  https://www.postman.com/pynt-io/workspace/pynt/overview I tried and it looks promising. #pynt   #postman   #apisecurity   #testing   #security

Implementation of Selenium Manager across bindings is one of the key features of the Selenium 4.6.0 release. The Selenium project wants to simplify how we all set up our environment. Setting up browser drivers has been for many years a task that we need to perform all the time.  To run a Selenium test with Selenium 4.6.0, we only need to have Chrome, Firefox, or Edge installed. If you already have browser drivers installed, this feature will be ignored.  Just add 4.6.0 Selenium dependency: <dependency>     <groupId>org.seleniumhq.selenium</groupId>     <artifactId>selenium-java</artifactId>     <version>4.6.0</version> </dependency> And as is use: WebDriver driver = new ChromeDriver(); Also, future releases of Selenium Manager will eventually even download browsers if necessary. :) Enjoyed reading this article? Please share the knowledge with your friends and colleagues.

To access Shadow DOM elements in Selenium 4 with Chromium browsers (Microsoft Edge and Google Chrome) version 96 or greater, we can use the shadow root method: WebElement  shadowIdContent  = driver.findElement(By.cssSelector("#shadow_host")) .getShadowRoot() .findElement(By.cssSelector("#shadow_content")); What happened in v96 is that Chromium has made its shadow root values compliant with the updated W3C WebDriver specification, which now includes definitions for getting an element’s shadow root and locating elements in a shadow root.   I found this excellent video for the same : https://youtu.be/-uMLqBO2x7c Enjoyed reading this article? Please share the knowledge with your friends and colleagues.

 Comparison of maven-surefire-plugin and maven-failsafe-plugin: References :     Maven Failsafe Plugin: https://maven.apache.org/surefire/maven-failsafe-plugin/index.html      Maven Surefire Plugin: https://maven.apache.org/surefire/maven-surefire-plugin/index.html   Someone asked me then what is the advantage of using one over the another. The advantage is the way they fail: Failsafe > runs all the integration tests, but if any tests fail during the integration-test phase, the plugin does not fail the build immediately. It still executes the post-integration-test phase. Therefore we can still perform any cleanup and environment tear-down as part of the post-integration-test phase. The subsequent verify phase of the build process reports any test failures. Surefire > It binds with the test phase, in case of any test failures, the build fails, and no further phases execute during the build process.