Most Viewed Article Right Now: Optimize Selenium WebDriver Automated Test Scripts: Speed
Most Viewed Article Last Month: Estimating Test Automation Story Points is a Total Waste of Time
Working automated test scripts is only the ﬁrst 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…
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.
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.
Working automated test scripts is only the ﬁrst 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.
To verify a piece of text on a web page, frequently for assertions, we can use
driver.find_element(:tag_name => ‘body') .
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. …
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…
On a recent software project, I heard of an embarrassing mistake: emails have been sent to real customers during internal system testing.
CUSTOMERS SHALL NEVER RECEIVE TESTING EMAILS!
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:
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.
The definition of “Done, “Done” varies across ‘Agile’ software teams.
“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…
Award-winning software developer, test automation & CT coach, author, and speaker. Help teams succeed with Agile/DevOps by implementing real Continuous Testing.