Simple techniques to make maintaining automated test steps easier.

Working automated test scripts is only the first test step to successful test automation. As automated tests are executed often and the application changes frequently, it is important that test scripts need to be:

Easy to maintain
• Easy to read (coming soon)

The №1 technical reason that most test automation attempts failed is that the team fail to maintain the automated test scripts. That’s why most software companies have tried test automation but failed to keep 20 automated tests ( Level 1 of AgileWay Continuous Testing Grading) running reliably and regularly.

In the article, I will…

Launch Chrome browser with extensions in Selenium WebDriver scripts

Software professionals often use Chrome extensions to assist in using the application. In rare cases, certain chrome extensions become an essential component of application testing infrastructure. Take a team that uses automation scripts for showcases as an example. After driving the application to a certain state, a business analyst may continue to use a Chrome extension (in the browser launched by selenium scripts) to demonstrate.

In the below case study, I will show a script that uses the TestWise Recorder extension to record user operations.

TestWise Recorder is an extension created by me, however, I rarely used it. (here is…

XP (eXtreme Programming) is well ahead of its time. However, few projects adopt it though XP is more correct and practical.

Today I picked up Kent Beck’s ‘Extreme Programming’ book (2nd ed) again from my bookshelf. What a great book! I have read it many times. Over the years, the XP (eXtreme Programming) practices make more sense to me. XP started Agile, and the ‘Extreme Programming Explained’ book was published in October 1999. 22 years later, many projects branded themselves as ‘Scrum’ under ‘Agile’ while XP has been forgotten. Why?

First of all, the name matters. To an executive's ears, XP is probably not a good name.

Simple techniques to improve the execution speed of some automated test steps, up to 50X.

Working automated test scripts is only the first test step to successful test automation. As automated tests are executed often and the application changes frequently too, it is important that test scripts need to be

Easy to maintain
• Easy to read (coming soon)

In this article, I will show some techniques to optimize test scripts for speed.

The test script examples are in Ruby syntax, the techniques are applicable to other languages as well.

1. Assert text in page_source is faster than the text

To verify a piece of text on a web page, frequently for assertions, we can use

driver.page_sourceor driver.find_element(:tag_name => ‘body') .


Data reset will help you to write automated tests much easier

Learning raw Selenium WebDriver is easy, very easy. After attending my one-day training session, the participants would be able to write maintainable selenium tests for common test scenarios. They often asked me: “What’s the next step?”. My answer: “Do more simple Selenium practices like the ones in the ‘Selenium WebDriver Recipes in Ruby’ book, then use it at work, make it real.” I could sense their hesitation which is easy to understand. For most of the training participants, they had seen failures of test automation attempts by tech leads/external contractors repeatedly. …

A shortcut to test automation success

Recently, a former colleague asked me for a successful test automation formula. This happened before; my default answer was to refer him to my book: “Practical Web Test Automation”, advise him to do the exercises, and then apply them to work. I believed that the success of test automation depends on many attributes: knowledge, willingness to learn and ready to change, test frameworks/tools, management support, .. etc. More importantly, do it hands-on from Day 1, and every workday onwards. There is no silver bullet.

When I put more thought into it this time, while I still hold the belief that…

Safe, Fast, and Reliable Email Testing with Selenium WebDriver and MailCatcher

On a recent software project, I heard of an embarrassing mistake: emails have been sent to real customers during internal system testing.


Unfortunately, this could happen to software testing after certain production data was loaded for verifying production issues when lacking good prevention procedures.

To avoid this, I have seen many solutions have been used, such as:

Lessons I learned from 15 years of hands-on experience in Test Automation and Continuous Testing

The title might sound a brag, but I am old enough to know that it is pointless to brag in a blog article as not many people would read it (for the younger generation, except academic studies, not many people have the patience to read anything longer than 140 characters). Rather, I want to share my lessons with people who are passionate about software testing, and hope that they might get something out of my past experience.

Let’s face it, test automation and CT are two areas that people can easily make wrong choices. 95+% test automation attempts failed though…

A user story is done after it is implemented by developers and verified by testers/business analysts. However, it is not “Done, Done”.

The definition of “Done, “Done” varies across ‘Agile’ software teams.

Done Done
We’re done when we’re production-ready” — The Art of Agile Development book

I have seen many ‘fake’ agile coaches talk about different versions of “Done Done”, such as

In my opinion, none of the above is really “Done, Done”. When I told my definition (see below) to many colleagues/friends, I don’t remember a single disagreement.

“Done, Done” for a user story…

Zhimin Zhan

Award-winning software developer, test automation & CT coach, author, and speaker. Help teams succeed with Agile/DevOps by implementing real Continuous Testing.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store