How to deal with Selenium Stale Element Reference Exception issue?

Lately I’ve been working on a legacy web UI test code base trying to fix issues and upgrade Python3.6 to the latest 3.11 version. Along the way I encountered a lot exceptions like below when the code is trying to get text of a dynamic table content:

selenium.common.exceptions.StaleElementReferenceException: Message: The element with the reference ba734ca8-f168-4a11-8e2d-aec0b79647c9 is stale; either its node document is not the active document, or it is no longer connected to the DOM; For documentation on this error, please visit: https://www.selenium.dev/documentation/webdriver/troubleshooting/errors#stale-element-reference-exception

After consulting with chatGPT, I found an effective way to solve the issue which is the Retry Mechanism – Wrap the code that interacts with the element in a try-except block, and catch the StaleElementReferenceException. I have tested and proved it’s working as expected for the dynamic web content.

Here is what it looks like in Python:

from selenium.common.exceptions import StaleElementReferenceException
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By

def retry_action(driver, by, value, action, max_retries=3):
for _ in range(max_retries):
try:
element = WebDriverWait(driver, 10).until(
EC.presence_of_element_located((by, value))
)
return action(element)
except StaleElementReferenceException:
pass
raise Exception("Max retries reached. Unable to perform action.")

# Example usage:
def perform_click(element):
element.click()

driver.get("https://example.com")
retry_action(driver, By.XPATH, "//button[@id='exampleButton']", perform_click)

Yay, another problem down!

AWS automation with Ansible

This blog is to document tips and thoughts around Ansible(v2.9) and AWS automated provision for an enterprise application deployment project.

Why Ansible?

  • No need to re-invent the wheel to code your own basic AWS block (boto), but you can still write Python module with boto to support your needs if Ansible hasn’t cover it.
  • It’s 100% Python native, can be easily integrated with your python code/module as part of overall solution.
  • Short learning curve, as I have 0 Ansible knowledge only with Python experience, it only took me a month to up to speed with building enterprise solution.
  • light footprint, just need to install as a Python package, not like Terraform or other tool which requires to install as a separate software.
  • Big user community base, you can always find support document or answers online.

Tips:

  • In the playbook yaml file, you can use “{{}}” to include simple expression such as “|” pipe to pass value, or list operation, it’s always handy to have such limited “programming” capability.
  • For the simple solution, you may not need to use “roles”, and “tasks” structure to build your project, just use plain playbooks and include these playbooks into a master playbook yaml file.
  • You can call/invoke python program within your play book as a separate logic line.
  • To speed up your playbook execution, it’s better to use plugin such as “mitogen“, however “async” can be unpredictable when you assign it to a task (as it doesn’t wait the task to complete) and impacting other tasks.

Use Case

I’ve built a scalable Python module library with Ansible for my company’s test automation team to provision AWS EC2 cluster with VPC, networking and applications installed configured. This module is the key part of our CICD pipeline for our production release cycle.

Have you checked the log file?

mac-log-files-670x335

Today’s blog I want to talk about the “primitive technology” (not the YouTube channel)  in software industry which is the fundamental skill of debugging – Log Verification.

This technique is so basic that many of us just assume that everyone knows how to do it and don’t pay much attention to it. Time and time again it’s been proven to me that we often overlook the logging and missed the tiny error or warning line in the oceans of application logs which gives us the most grief.

So as software debugging 101, check your log file!!! I mean really go through each line to filter out any abnormal information. Of cause there are effective ways to do that rather than eye ball each line of the file, but the key thing is to pay attention to all the errors and failures as they all happen for reasons, that’s the beauty of computer science. You will find your answer from these errors and lines, just need to dig deeper and ask why there is such error been written in the log.

Here are some tips of log scanning:

  • if you in Unix like OS, grep is your best friend to search errors is the file or directory
  • if it’s windows, use sublime or any modern editor to find pattern in the file or directory
  • do read through the entire line, as the devil is always hiding in between the words
  • for advanced log scanning, use Python to code your own script to filter and catch

Next time before you call someone for help or about to give up debugging, check the log one more time as above, you will have find your clue.

2020, see you in Tokyo

Tokyo-Tower

This none-tech blog is to mark that I’ve got my 5 years working Visa in Japan and on the day I turned to 40 :-P!

After 12 months job hunting and countless interviews in 2019, finally it paid out and I found my dream job in Tokyo and the new team is just AWESOME!!!

A new era has just started, I can’t wait to enter the new chapter of my life, just focus on the key and stay positive, life will leads it’s way.

 

Web driver, Cucumber-JVM and Jenkins

Recently I’ve worked on fixing/rescuing a legacy Cucumber + Selenium JVM Web UI automation framework, I’ve managed to fix and extract some valuable test scenarios and added them into our CICD in Jenkins as daily integration regression for the team.

Learnt a few tricks with Cucumber and Webdriver running in Jenkins docker image.

How to run cuke test with JVM single thread?

As the original cucumber tests were configured to run multi-thread in Maven, it caused some intermittent page timeout and resource hanging. To fix that, you can configure your RunCukeTest class to be run in single thread only. Add below annotation to your RunCukeTest class then it will enforce your test run in single thread.

@net.jcip.annotations.NotThreadSafe

How to fix page crush and Chrome won’t start issue when running Selenium Test in Jenkins container?

Some tests runs smoothly on my local env but failed on Jenkins server intermittently, after googling it’s to do with the Chrome web-driver options, as it will behave differently when the driver runs in the container with limited resource allocated. The solution is to add below arguments when you instantiate your Chrome WebDriver in your Java code.

chromeOptions.addArguments("--no-sandbox", "--disable-dev-shm-usage");

How to execute Unix shell ‘sed’ command in Jenkins Pipeline?

I spent quite a while figuring out how to run this useful ‘sed‘ as part of the Jenkins build pipeline, the devil is in the DETAIL… It requires triple ”’ quote mark to wrap it up and double quote for the argument as Groovy does some interpolation to the command.

steps{
sh '''sed -i \"s/old_string/new_string/g\" file.txt'''
}

So sed in Jenkins pipeline sorted… :)!

How to deal with manual integration test?

integration

Where it all begins…

Doesn’t matter how mature your CI/CD pipeline is or how awesome your Automation Test suite been built, as long as you are doing enterprise software applications. The reality is that you have to do some manual E2E integration test (which can’t be automated and mocked) execution to gain some confidence before your app go live.

Pain points

Since it’s manual, it’s end to end, it’s integration, so it is imperative, it relies on step by step test scripts. It also highly depends on test environment such as network, DB connection, middleware, upstream and downstream system availability etc. Here are some common issues that we are facing when doing the manual Integration test:

  • Test environment setup often is manual hence it’s very time consuming and problematic
  • Limited time window to perform test as the dependencies
  • Often relies on other team to provide E2E test result as you don’t have access to those dependencies
  • Manual test scripts and environment configuration is outdated and not in the VCS
  • Software version of each component needs to be consistent and compatible
  • Hard to pinpoint the bug or root cause when there is integration issue been detected, often requires investigation on each component of the transaction or data flow
  • Sometime the test result is not deterministic, it is up to interpretation as there are too many moving parts in the process

Possible solution

Most of above points are inherent issues of manual integration testing, so best way to resolve them is to put more effort on the low level unit test and component functional test to ensure the contract and system behavior. Try to limit and reduce the E2E Integration Test to the minimum happy path scenarios. However below are some tips when you do need to perform such lengthy manual testing:

  • Plan well ahead and have lead time for E2E test environment setup and coordinate with other teams involved
  • Ensure the correct version of each application in this integration test to avoid rework
  • Try to use container or Kubernetes to automate infrastructure setup
  • Use Git or any other VCS to manage your manual test script and configurations
  • Constantly assess and evaluate the scope and the needs of this manual exercise as part of your QA process

How to actually practice “Shift-left Testing”

keepleft

What is shift-left testing?

In a nutshell, shift-left testing refers to bring testing and QA activities as soon as possible throughout software development life cycle.

Why do we want to do it?

To provide earlier quality feedback to the delivery team therefore reduce the cost of finding defects and fixing bugs when building software. It has been proven to be the critical path for Agile succession.

Below diagram shows the exponential cost of finding and fixing bugs in software development industry.

chart

How to implement it in the Agile project?

Based on my own experience, here are some low hanging fruits you can easily get to achieve “shift-left” testing.

  • Make sure the whole team understands and adhere to the good Testing Pyramid
  • Pay more attention to the unit tests and low level component tests
  • Share QA’s functional tests with developers while they are implementing the feature
  • Running automated QA’s test on Dev ENV as smoke or sanity functional test before deploy to QA ENV

Java REST API Testing with Cucumber JVM

Background:

So you’ve used Java REST-assured library for endpoint API Testing, you’ve also used BDD Cucumber framework for your story acceptance testing, how about to combine them together to achieve BDD for Web API development? This blog is to show you how to do that in a simple way.

Dependency:

  • JAVA 8
  • Junit 5
  • Cucumber
  • Rest-assured
  • Maven
  • Intellij

Objective:

To write automated Java cucumber acceptance test with Rest-assured library to verify http return code from a simple http request server endpoint: https://httpstat.us/

Steps:

In your IntelliJ IDE, create a Maven project for your test.

  1. Install plug-in for your IntelliJ, [Cucumber for Java] and [Gherkin] to enable syntax highlighting and binding support.
  2. Edit your pom.xml file to have below dependencies: Junit 8, Cucumber, Rest-assured
  3. Create a feature file to describe the test.
  4. Create a Java class for step definition with Rest-assured code to retrieve http response and assert result which links to the feature file.
  5. Create a Junit test runner class to run the test via Junit.

The project is just a simple REST get call to return http code to demo the basic building block, for real world API Testing, you will need more classes and code logic to perform assertions for your scenarios.

For detailed implementation, see the Git repo: https://github.com/roy-boy/java-rest-cucumber-demo

So what’s the difference between QA and Testing?

I’ve seen a lot more software testing related role in the market lately as compare to the traditional QA job, sometime they are inter-changeable but QA and and testing is actually covering different aspects in software industry.

My view on software QA and Testing:

QA – much more broader concept, involves whole team member and throughout entire Software development life cycle. It employs a series test to measure and assure the SUT (system under test) quality to mitigate any production risk .

Testing – given a piece of software or certain features, perform a set of validations with input and conditions to assert expected output and behavior against functional spec and requirements.

To sum up, Testing is more around performing specific verification and validation tasks where QA is the method and process to ensure the software quality for production readiness.

Few thoughts around Big Data testing

big-data

Some high-level points to consider when we tackle BIG DATA testing.

* The big data testing approach involves both functional and nonfunctional components.
* Functional testing includes validating both the quality of the data itself and the processing of it.
* Test scenarios in data quality include completeness, correctness, lack of duplication, and more.
* Data processing can be done in three ways: interactive, real-time and batch; however, they all involve movement of data.
* Therefore, all big data testing strategies are based on the extract, transform and load (ETL) process.
* It begins by validating data quality coming from the source databases, validating the transformation or process through which the data is structured and validating the load into the data warehouse.