Ep 59: Hit Record (and play)

Quick news:

I am going to be at Leeds Testing Atelier on 20th September, which is a free one day testing conference, and I’m very excited to be there1., there’s going to be some amazing talks and some people I’m excited about meeting IRL at last.

Obviously I am also going to be at TestBash here in my adoptive city of Manchester, which is also very exciting! Plus more podcast interviews and other awesomeness.

This week, I want to talk about Selenium IDE.

Selenium has two parts: the script management/automated testing bit (Webdriver) and a Firefox add-on (IDE) that you can use to record browser actions and then play them back. It’s often denigrated by the testing community and for some very good reasons:

They’re brittle and flakey (but then again, so is every automation script that relies on find_element_by_id as far as I can tell). If nothing else, you’re only testing the UI, or through the UI2., and that can can cause issues (Mark Winteringham talks about this briefly in this blogpost here, and I saw him do a talk about this in Liverpool this month, it was very good, highly recommended, the video is on youtube3.). Some of these tests should be pushed down to the API/service level, not the UI level, and that isn’t really possible using the IDE add-on.

They get mis-sold. There are a lot of ‘record and play automation: so easy anyone can do it’ adverts and that annoys testers and leaves a bad taste in a lot of mouths (and rightly so). Testing is skilled work, and the idea that an automated record and play system can replace the work of a tester – even if that tester is solely an automation tester – is ridiculous. Writing them requires a human, and a tester at that. Someone who can bring all the skills of a tester; the curiosity, the need to gather information, things like that.

There are many reasons IDE is not a good choice for building an automation suite. But I’ve used IDE, and I found it useful, so I’m going to share my use case with you today.

I’ve literally just started Selenium, in bits and pieces, between other bits of work and podcasting, etc. and I had no idea where to start. I could find the header of the script from the documentation (where you call the webdriver and other bits you need from selenium), but after that I wasn’t sure. So I recorded a brief session around the site I wanted to get some automation on. The IDE has an option to export the scripts into code. So I exported the script into Python, which is the language I was planning to use, opened it in Sublime, and started to review the script.

The commands are slightly different, but it gave me a good starting point. From there I can make changes to make things robust. I wasn’t sure how to do something, but with the IDE commands in front of me, I could google those and then find out what they did, what they were called in webdriver, and if I could improve it in any way (IDE does implicit waits by default, for example, and I could change these to explicit waits.

In the world of Selenium based automation, it gave me a starting point. I converted the script to a ‘better’ webdriver script, and saved that out for repeated use. And once I got that down, it was a lot easier to start again, from scratch, to do another test. And yeah, it was hard and I still have no idea why people like coding, but I did it, and I felt I had a good grounding to do it and google about for help (read: copy and paste shit off stackoverflow as I am a true developer 😉 ). And now I’ve proven the concept, I’m doing more and it’s starting to form an automation strategy, which is incredibly exciting.

So IDE is a tool, and like any other it can be used or misused. For me, it’s a great starting point for Selenium, where I would probably still be bashing my head against a wall if I tried to build this from scratch. I have a lot to learn, but this was certainly a good springboard.

Footnotes

[1] http://leedstestingcommunity.co.uk/
[2] http://www.mwtestconsultancy.co.uk/cross-browser-checking-anti-pattern/
[3] https://www.youtube.com/watch?v=VGNxv9ilFbQ

1 Comments

  1. Reply

    By far the best piece of automation GUI by far I’ve come across is Ranorex – its a great tool – don’t get me wrong it does ‘suffer’ some of the same limitations but at least testing via the UI (I do desktop testing) – its a great bit of kit. And you get to ‘test’ in the way that a user would be interacting with your system. I use the word test very loosely – as automation is GREAT at checking and not testing – something us testers would know all about but is also an essential part of ‘Test’. Great pod casts and I’m glad MW’s Youtube vid gets a shout out – ta muchly Gem keep up the good work.

Leave Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.