For those teams who are spending hours on a defect-tracking system (DTS), such as Quality Center, they may get offended by the title of this article. Fortunately, some world’s leading experts share the same view as me.
Continuous Testing (enables software teams to release to production daily, not fake CI/CD talks. Check out “Continuous Integration at Facebook” and AgileWay Continuous Testing Grading) is the heart of the software development process. It benefits all stakeholders of a software project.
The biggest beneficiary of a successful software product, financially speaking, is the owner and/or executives of the company. A good process of developing successful products is often more important than the products themselves. …
All test automation engineers know that a single application change may break many automated test scripts, and these kinds of application changes happen constantly. To effectively deal with it, test automation engineers need to be in a position to respond to a simple application change in a matter of seconds (here I mean the time is taken to modify the test scripts, excluding execution).
The key to test maintenance (a common problem in test automation) is the test script, not the test tool. Tool vendors like to focus on their tools or deliberately blur the relationship between test scripts and…
Now and then, I receive requests for advice on learning test automation. The most effective way is to work with a real test automation mentor. For most, that might not be possible. However, you can self-learn test automation. Here is my advice:
1. Make your mind on the test framework, not the tool
I highly recommend Selenium WebDriver + RSpec. Don’t fall in record/playback testing tools. Though they have been existing for over 20 years, history has proved they were wrong. Still, ‘new’ test automation tools in a form of record-playback come out and die every year.
AJAX is widely used in modern websites. Testing AJAX (or XHR) operations require waits. Let’s look at a typical AJAX operation: a user clicks the ‘Pay now’ button on the payment page.
My teenage daughter Courtney applied for a casual programmer position during this Uni break. Before the interview (via Zoom), I suggested: “You still have a few minutes, why not write an automated test against the company’s website? You might be able to show them something relevant if they asked about your test automation skills”. She did.
While watching her write the test, I was pleased that she did quite well for most of the part, though needs improvements on a few areas. …
Recently I saw alarming text such as “Creating your own Automation Framework” repeatedly appeared in some test automation video courses and blog posts. As a test automation consultant, I believe this has to be one of the most unnecessary and insane mistakes that will kill your test automation attempts. Sadly, this mistake is common.
I am against using recorders for test automation, except for two situations:
“Selenium IDE is the place to start with Selenium, but it is Selenium on training wheels” — Jason Huggins, the creator of Selenium v1 at AAFTT Workshop 2009
However, with the advancement of Browser (Chrome) and testing tools (such as TestWise I created. By the way, iTest2, TestWise’s former name, was demonstrated at this AAFTT Workshop 2009), I found using recorders was no longer necessary. Attendants of my training verified that.
2. Writing tests with many similar steps
This is very rare. I only remembered one case…
I have received some positive feedback on my “Why Cypress Sucks for Real Test Automation” (Part 1) article. A few readers wanted to clarify it a bit more. Yes, the article was more focused on why there is really no need to use Cypress, as there is a much better tool (in almost every way) Selenium WebDriver. In this follow-up article, I will focus on the limitations of Cypress.
Award-winning software developer, test automation & CT coach, author, and speaker. Help teams succeed with Agile/DevOps by implementing real Continuous Testing.