Unleash your coding superpowers in your free time
Hi everyone, and I guess a "Happy New Year" is well overdue! As I successfully predicted in my previous post, things have been rather manic since I began working in London, so this is the first chance that I've had to draw breath for a moment.
I'm getting back into the swing of things with a few short posts inspired by recent experiences - some in the workplace, others (like this one) from elsewhere.
This one's going to be about coding skills for testers, though I'm going to stop short of opening the "do testers need to code" debate (we're all getting bored of that). One of the problems typically associated with test automation is that the time and cost of creating automated frameworks can spiral out of control, meaning you're investing more resources into it than is worthwhile. This can make it hard to justify the time spent gaining coding/automation experience in the workplace.
However, you'd be surprised how frequently a little bit of scripting knowledge comes in handy! Here's an example which cropped-up for me at home recently...
As a 90s kid with a fond memory of the decade's music, I'll often use the UK Official Charts Company's archives to view the music charts from 20 years ago, reminiscing on the singles that I bought back then. The website is straightforward to navigate - simply select a year, and then select which week's chart you wish to view.
However, on two occasions last year (once in August, once in December where this story is set) I noticed that the chart for that week would fail to load. Instead, the user ended up on a completely different page, but the response was "HTTP 200 OK" (meaning that traditional spidering tools wouldn't notice a problem).
As a tester, my obvious first thought was to report these pages to the webmaster; but how many more pages might be broken? The site contains archives for over fifty years of charts; that's over 2,800 pages to check! How long would it take to find all of the broken pages? You'd likely never find them, as you wouldn't want to sit there reviewing them all by hand.
But how long would it take to check each of these charts programatically? Having dabbled a little in Selenium WebDriver, I decided I could write a simple, customised spidering script which would follow each of the links in the archive, and check whether the correct page was loaded. (If you're interested, the script is available on Pastebin, though it's pretty niche.)
I'd estimate it took about an hour to write, and a lot of that was learning how to parameterise a WebDriver script. The script then took less than four minutes to run, and identified a number of errors:
A small snippet of the Selenium output
Now I had a list of all the charts which were broken in this manner, extracted as a list which I was able to forward to the site team. They've all since been fixed (although interestingly, when I re-ran the script today, there's one new broken link - maybe the webteam would like to integrate my script into their testing process!)
Just designed, wrote & ran my first real Selenium test. Identified 9 missing charts on the @officialcharts website, email incoming guys :)— Neil Studd (@neilstudd) December 7, 2014
It's far from a perfect script, mostly because I created it as a throwaway piece of code. But it served its purpose, and achieved something for me (as a tester) which it would've been prohibitively long-winded to check manually.
In fact, in doing this exercise, I also learned a lot about WebDriver. For instance, I'd always heard that using a headless driver (HtmlUnitDriver) was much faster than spinning up a FirefoxDriver, but there was an absolutely massive difference here - when I switched-in a FirefoxDriver, the execution time increased from 4 minutes to over 2 hours, and there were many false positives caused by some slow-to-load third-party plugins (which aren't loaded when using a headless driver).
Since this bit of pre-Christmas fun, I've been looking out for more excuses to save time with code. I find this xkcd strip from 2013, reproduced below, is a useful heuristic for deciding whether to attempt to automate a task: for instance, if there's a task which you perform every day, and you think that you can decrease the time taken for that task by 1 minute, then you shouldn't spend more than a day working on it. (You can multiply these in the workplace; for instance, if there's five of you performing a task every day.)
So, go forth, and solve those interesting problems with code!