My Testing Thoughts

  The Test Automation Pyramid is a framework and guiding principle, for organizing and structuring software testing efforts in terms of automation. It visually represents the types of tests that should be included in a test suite with the detailed tests at the bottom and broader tests at the top. According to the Test Automation Pyramid, a successful approach to test automation should be built upon three layers or levels of tests each serving a purpose and providing feedback; Unit Tests: These are the most detailed types of tests and should be automated for each individual section of code in the application. They are quick to execute and focus on testing units. Typically created and executed by developers, they aim to identify defects in the development process. Unit tests provide feedback. Help ensure that individual code units function correctly. Service Tests : These tests primarily focus on interactions and integration between various components or services within your application.

  Peter Drucker quoted “ You can't improve what you don't measure ” reminds us that measuring our progress is essential. It is especially important to measure what we do and what we measure too. Do read what I authored here: https://www.tavant.com/blog/top-metrics-measures-determine-test-automations-true-roi  

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.

 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.

  A simple, extendable, and nice alerting tool to forward the test results from your CI/CD environment to different entities like teams or Slack: https://test-results-reporter.github.io/ It publishes test results from test frameworks like JUnit, TestNG, and xUnit.  GitHub link: https://github.com/test-results-reporter/reporter #alerts #automation #reporting #slack #teams #webhooks Enjoyed reading this article? Please share the knowledge with your friends and colleagues.

  Of course, there are many ways to tackle it but I have mentioned below one of the ways where you can use the given code in the Tests tab of the postman. Unfortunately, in some of the lower environments, there can be a situation where you request fail at times due to infra issues, timeouts, etc., so in that case, this can be super helpful: var notExpectedText = 'Failed'; var maxTries = 3; var pauseBetweenTries = 5000; if (!pm.environment.get("tries")) {     pm.environment.set("tries", 1); } if ((pm.expect(pm.response.text()).to.not.include(notExpectedText)) && (pm.environment.get("tries") < maxTries)) {      var tries = parseInt(pm.environment.get("tries"), 10);      pm.environment.set("tries", tries + 1);      setTimeout(function() {}, pauseBetweenTries);      postman.setNextRequest('PaymentService'); //here you should give your request name that you want to retry on failure  } else {      pm.environment.uns

   We all do text validation in our automation tests to validate whether the returned value is the same as the expected one or not. I see that many folks use the assertTrue command instead of assertEquals to validate the returned text while using assertions from TestNG or JUnit. Let's see why using assertTrue is bad practice for text comparison.   assertEquals public static void assertEquals(String actual, String expected) Asserts that two Strings are equal. If they are not, an AssertionError is thrown. Parameters: actual - the actual value expected - the expected value assertTrue public static void assertTrue(boolean condition) Asserts that a condition is true. If it isn't, an AssertionError is thrown. Parameters: condition - the condition to evaluate   Let’s say that I have an automated test script where I would like to verify the Title of the home page -  we are doing the check using assertTrue as well as assertEquals methods.   String Exp

 If you use this code as mentioned in few other blogs and videos:   Map<String, String> headers = new HashMap<String, String>(); headers.put("Content-Type", "multipart/form-data"); byte[] fileContent = FileUtils.readFileToByteArray(new File(filePath)); RestAssured.given().headers(headers).body(fileContent).post(url);   There are high chances that you will get errors related to content-type or "400 - Request is not a multipart request". So, the solution is to use: .multiPart("file", new File("/path/to/file"),"application/pdf"). Please note that I have used "application/pdf" as 3rd param in the multiPart method and this value should be passed as per the file type that you are uploading like for the png file it should be "application/octet-stream", for JSON file it should be "application/JSON". multiPart is an overloaded method that can take max 3 parameters:   a)

  To integrate TestRail with any automation suite, we can use the TestRail APIs with the following basic flow: Create test cases in TestRail.   Provide those unique Test IDs from TestRail to your TestNG tests. Run automation: Create a test suite in TestRail before test execution using the TestRail API. And then post the run results according to test automation results using the TestRail API. Create test cases in TestRail:        2.  Creating a custom annotation and calling it as TestRails:      3.  After that, we associate our test cases with actual Test Rails ID’s like:     4.  These ids 1, 2, 3, and 4 are test case ID that we got from TestRail test cases, you can hover over your test case and see that ID in the URL (as shown below):     5. Create a Test Run in TestRail through code,  as you can look at that we have not created any Test Run manually (see below): Snapshot of TestRail before execution of automation suite: 6. Retrieve Test Case ID from Annotation: 7. Run the test cases a

Your automation project should have all of these to be called a good solution : Well drafted Project Design Clear Project Structure and Documentation Defined Page Objects (For UI project) Independent Automated Unit Tests Automated End to End Tests  (Loosely coupled) Reliable Locators (For UI project) Highly effective strategies for managing test data Comprehensive Dependency Management Precise and concise logging and Reporting

Problem Statement: On your registration page, you entered valid values in few mandatory fields but submit the form with no values in few of the mandatory fields. Now along with the error message(s), you want to verify that your cursor position is in the correct field (current focused element) like in the first blank mandatory field using Selenium. Solution : There are many ways to validate that but the simplest one would be to use:> driver.switchTo().activeElement() Use : Switches to the element that currently has focus within the document currently "switched to", or the body element if this cannot be detected. This matches the semantics of calling " document.activeElement " in JavaScript. Returns : The Web Element with focus, or the body element if no element with focus can be detected. And then you can put assertion based on your expected focused element, something like: Assert.assertTrue(driver.findElement(By.xpath("//input[@type='password']"

Small but a cool and an old trick for copy-pasting Java code in Eclipse. I have seen so many folks are still doing this when they want to copy-paste the Java code from the net via clipboard in their Eclipse. >Right click on the target folder where you want clipboard Java code >New >Create Class >Give a name and then finally remove the default code in this class and paste the Java code from their clipboard. You don't need to do all this. Just Right-click on the target folder where you want this Java code and paste from the clipboard or directly CTRL+V. Nice- isn’t it? Sample code: package com.test.apiAutomation.test; import java.util.HashMap; import java.util.Map; import org.testng.annotations.Test; public class TestCopyPaste { @Test public static void testCopyPaste() { Map<String, String> formParams = new HashMap<String, String>(); formParams.put("grant_type", "hey"); System.out.println("It's working, TADA

RestAssured Vs Karate Initial Score: Rest Assured 0- Karate 0 1) RestAssured is really good but there is no built-in way to do a full equality match of a JSON payload in one step (not talking about extracting a particular field out of the response JSON). Contrary to this, Karate offers full JSON Comparison with so much ease (as shown in the first image below). And in case you have some node that shows dynamic value then you can simply ignore it by using hashtag # ignore for that node (as shown in the second image below). Note* There is no direct command to compare the whole response in RestAssured at once but we can still use JsonPath to parse the JSON file into a Map and then compare it with Hamcrest Matchers. Current Score: Rest Assured 0- Karate 1 2) Ease of using matchers: The powerful matching logic of Hamcrest is unbeatable in Rest Assured. Of course, we can use RegEx and Macros in Karate for the match but you need to learn that first. Final Score: Rest Assured 1

You can’t automate testing; you automate only the checks (tests)... Still baffled? Checks can be automated for sure but testing can NOT. When we interact with any application, we use our human brilliance to know the functionality of that application and then based on our intelligence we judge whether the behavior (use case) of that application is right or wrong — Can that judgment be automated? So far- Nope. Can we automate whether the behavior of that application is right or wrong on performing certain action/test? Yes.

False-Negative is a case where your test result comes out to be positive, but in actuality, an issue is present in the system and the functionality is not working as it should. And Vice-versa is False Positive, which is a case where the test execution results show an error, even though everything is working as intended. Fundamentally, both these have always posed a challenge for web automated testing but I guess it’s ok to say that a False-negative is more hurting than a False-Positive, as the former creates a false sense of security (a lie) and would definitely end up costing much more to us. I agree that a False-Positive too consume a lot of our's time and worth. On average 70% of automated test case failures are False-Positives due to which testers spend an average of 1/3rd of their time analyzing, correcting and reporting results that actually should NOT need any attention at all. In fact, with CI/CD implementation, running automated tests every night or after every commit

Authoring automated tests is quite easy but authoring easily human-readable and maintainable tests is much tougher. Especially, when your project grows in size and complexity. There are many approaches that can help you build your tests in a Selenium framework like correct handling of your Base Class well. The Base class should have these things: - the setup() and teardown() test methods. - the WebDriver object. - load your configuration/properties file here (can be a part of its constructor) - common aspects of all tests like handling sync issues, ScreenshotOnFailure, etc. - have a method to visit the site that returns the Index page object. - and All test classes should inherit it. P.S. My view on this topic is purely subjective. And in many cases, you may not be able to apply this type of approach to your framework.

In automation space, who doesn't need random test data for things like let's say a name, address, CC, date, phone, etc.? We are always inclined to use a Java class that provides some random numbers or strings like this jk4h5j6hjkh for a name, address, city, etc. But isn't it dreadful? Do you guys know that there is a Faker library that is excellent at generating realistic test data? And that too based on your locale: https://github.com/DiUS/java-faker Do check this out too for the examples: https://java-faker.herokuapp.com/ I find it very shway. Do comment if you are already using it or like it. #seleniumautomation   #easierway   #betterway   #apiautomation   #testData   #automationtesting