What a provocative webinar title! And what a wonderful piece of “brain candy” this Thursday morning webinar was! The entire presentation was organized as a set of two-sentence slides. The first sentence was an example of what I termed in my notes “wrong Selenium thinking.” After a minute or two of explanation, presenter Adam Goucher would display the second sentence, the complementary “right Selenium thinking.”
My favorites of these wrong/right points from Adam’s slides:
My goal is to replace humans and push to production faster.
My goal is to let humans test higher quality builds with greater efficiency.
Adam claimed that thinking like the “wrong thinking” point above is “setting yourself up for failure.” I couldn’t agree more! Awhile back, I interviewed with a company that wanted to automate their tests primarily in order to shorten their release cycle. No mention was made of the higher quality product that could be achieved if testers were freed of mundane, time-consuming, repetitive checks that could be better done by automation. Automation was only about saving time!
My application is written in X so my scripts must be as well.
I write scripts in the language that makes the most sense.
In Adam’s view, Python and Ruby are far easier languages for test engineers to pick up if they’re
not used to a lot of programming. He stated that just because your application is written in Java doesn’t mean that your scripts have to be too. I was really cheering on this one! At a previous QA gig of mine, the developers wanted Selenium automation done in PHP because that’s what all the developers used. (What about the language all the QA engineers used? Wasn’t that more relevant?!?) And at another recent interview, the QA manager wanted the Selenium automation done in Java, because that’s what all the developers used, so they’d be able to help with issues. (Mightn’t the developers know other languages besides Java? Mightn’t better Selenium support be available from the Selenium community than from the company’s developers? Shouldn’t the skill set of the QA engineers be taken into account when determining the most suitable automation language?)
I email updates to formats and extensions.
I use a site-specific plugin.
Adam mentioned that he had added a plugin API as soon as he started maintaining Selenium IDE. He recommended bundling up one’s user extensions for IDE scripts using a Firefox extension which can be hosted inside your company’s firewall. (Note: Adam made a presentation entitled “Selenium IDE Plugins – The What, How, and Why” at the Selenium Conference in early April.) I was really inspired by this wrong/right pair. I was well aware of IDE plugins (several are available, some of which I already use, at the Selenium Downloads page), but I never thought of using one to bundle site-specific user extensions!
I felt validated by many of Adam’s other points: using a cloud service is a better way to go than using Selenium Grid for cross-browser testing; locators should be placed in a shared <thing> (user extension for IDE, ini file in Python, resource bundle in Java, etc.) rather than in a script; data should be fed in externally rather than being present in scripts; individual scripts should do only one thing; and automation code should be treated the same as product code with respect to source code check-in, back-ups, etc.
And I’m eager to investigate Jenkins CI and learn more about Page Objects, both of which were roundly praised by Adam during this presentation.
To summarize, I found this PushToTest-sponsored webinar to be validating, full of good reminders, and educational / inspiring! Not only that, but the presentation style was eminently successful! I heartily advise you check out Adam Goucher’s slides, which are available now, and check PushToTest Screencasts soon–the webinar itself should be posted there within a week.