My Testing Thoughts

There are multiple ways to achieve it but one of the simplest ways is to use the Dotenv module. Dotenv is a lightweight and zero-dependency module that automatically loads environment variables from a .env file into the process.env object. Handling multiple environments using dotenv involves creating separate .env files for each environment (e.g., dev, testing, staging, production) and dynamically loading the appropriate file based on the current environment. Here's a step-by-step guide to follow:          Step 1: Install dotenv Package (recommended- locally):           npm install dotenv --save          Step 2: Create separate .env files for each environment. For example:         .env.dev for development         .env.test for testing         .env.stage for staging         .env.prod for production           Each file should contain environment-specific configuration variables. For instance: Step 3: Configure your application to read environment-specific variab

  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  

  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']"

For sure we can do data-driven testing using automated UI tests (Selenium, Cypress, WebDIO, etc.) but just because it gives us the option, doesn’t mean that we should it for all cases through UI only. Take an example where we visit any website to get a price quote on any policy — let’s say a medical policy, what do we do- we run our test by going through the same page(s) like select value from few dropdowns, select few checkboxes, and enter values in few text fields to get one final output i.e. the “ price quote ” of your medical policy- here the variation was only the “ Test Data ” that finally derive a  certain output . Don’t you think that to test this business logic, the efficient way would be to perform API testing which is better maintainable and powerful? As I mentioned in my previous post too, our UI (end to end) should be meant to confirm that user(s) can use our application in the way it’s intended to do so, perform interactions with it without hitting any issues and always w

If there is a use case where you need to override the geolocation of the browser before you hit the website, Selenium 4 Alpha version does support that now by using the power of Chrome DevTools and Protocol (CDP) along with setGeolocationOverride method present in Emulation class. To set it back to default, use the clearGeolocationOverride method. #mockGeoLocation #testAutomation #selenium4Alpha @Test private void testGeo() throws InterruptedException { driver .get( "https://www.google.com/maps?q=28.704060,77.102493" ); Builder<String, Object> mapLatLan = new ImmutableMap.Builder<String, Object>(); mapLatLan .put( "latitude" , 40.712776); mapLatLan .put( "longitude" , -74.005974); mapLatLan .put( "accuracy" , 100); ((ChromeDriver) driver ).executeCdpCommand( "Emulation.setGeolocationOverride" , mapLatLan .build()); driver .get( "https://www.google.com/maps?q=40.712776,-74.005974&q

We all should try that our End to End test should NOT considerably reiterate the test efforts of our Unit test and API test. Ideally, our end to end should be meant to confirm that user(s) can use our app in the way it's intended to do so, perform interactions with it without hitting any issues and always work when performing any E2E transaction(s). On the other hand, our Unit and API test should test and cover business logic.  Many a time, we go overboard to reach 100% coverage, create an automated mess in terms of freezing a scope of our End to End tests and we might reach to a point: - Where our test source code becomes even the same or in fact, more than the application codebase - And/Or automation execution run time is likely to take the same time as it takes to write the test case, etc. There's no silver bullet here and it's all about trying, failing and finally succeeding. One such approach can be: Divide your test cases broadly into two major groups

In the agile world, the deployment window will continue to grow narrow and for sure you can’t catch every bug- so, always use the power of both i.e. on-demand (including webhook on every change) and scheduled automation test suite run.  On one hand, your on-demand test run will make sure that you get fast feedback (i.e. which change and by whom broke it) and also you will get the complete test coverage. And, on the other hand, your scheduled runs ensure that you get continuous feedback, don't push any broken pieces to the next environment and hence confidence in your code changes especially after the integration with the larger system(s). Keep your builds green (Organically).

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

At times, we need to visit a page in our application that automatically starts downloading the file which is as per the feature of that page. But we're navigating to this page (A) only to further navigate to the other page (B) by clicking on some link given on this page (A) which redirect us to the page (B) but at the same time, we don't want to download the file on visiting this page (A) as it's not required every time while running our Selenium automation script. Did you know there is a preference option "download_restrictions" that can help us achieve this? Let say A is this: http://selenium-release.storage.googleapis.com/2.41/selenium-java-2.41.0.zip HashMap<String, Object> prefs = new HashMap<String, Object>(); prefs.put("download_restrictions", 3); ChromeOptions opt = new ChromeOptions(); opt.setExperimentalOption("prefs", prefs); WebDriverManager.chromedriver().setup(); driver = new ChromeDriver(opt);