#selenium #qa #agiletesting #karma #js
Dear Selenium Users,
It is the end of the year. You’ve worked hard as a QA person. You deserve to take a step back from your keyboard and intricacies of your awesome QA automation framework and meditate on where you are. You and your team have found lots of bugs and the sad part is that your customers don’t even know how well they have it since you’ve saved them lots of agony in their user experience. The fact that those Selenium developers work hard to make sure the experience is great across all browsers makes them the team behind your team. Having the Webdriver interface become a W3C browser standard will only make the Selenium architecture better in years to come.
I know, I know; you chalk this up as being part of your job. After all, you find very valid bugs, even critical ones and the developers rely on you to find those issues that are only found with the level of integration that currently exists only in your Selenium tests. You are a career QA’er and so you fight each and every GUI change with your Selenium machete until the next clearing where tests are happy again. That’s who you are. You know that your hundreds of Selenium tests don’t match the Agile Testing Pyramid in the book Agile Testing since they are not the API/beneath-the-GUI tests which is the largest part of the Agile Testing Pyramid, but you brush that concept off as ivory tower academic.
I know, I know; you have serious reservations about pulling the majority of your test cases into something like this. Your reservations are listed below with my responses.
That is correct. But how many bugs will you really find by performing a Selenium mouse click vs doing a jquery click instead? Furthermore, you can use something like jquery-simulate which performs native DOM events. Those OS native events that Selenium performs bubble up to the DOM anyhow.
When Selenium renders each of those live pages, you have an expensive test. They take much longer to run. However, if you look at the Agile Testing pyramid in the book Agile Testing, you’ll see the layer at which the bulk of your tests should reside is identified as “API Tests” which is described in the text as “beneath the GUI testing”. This is the kind of testing I’m advocating herein. So you indeed can’t take screenshots with these types of tests and that is a worthy tradeoff, but important to remember nonetheless.
This is correct. Only an end-to-end integration test can do this and ferret out problems like a misspelled script include in an html page.
So Selenium users, a new year is approaching. Testing tools are getting smarter and NodeJS is making a lot of this possible. We are at an inflection point in terms of how we approach front-end testing and it is worth taking a step back to see where we are and, more importantly, where we should be heading. Herein the gauntlet has been thrown down, will you pick it up?
Enjoy the holidays – you deserve it — and have a Happy New Year full of fantastic tests!!