AUTOMATION 16 - GUI 4, Selenium WebDriver Installation

Technical level: ****

One of the reasons I started you out on developer tools and TamperMonkey previously was because all these things were relatively easy to get started with.

Our next few pieces will use and explore Selenium WebDriver, which I hope you will follow along with at home - but to do that, you'll need to install a lot of extra software on your system.

Install Firefox browser

We mentioned last time that out of the box Selenium WebDriver works with the Firefox browser - so it's kind of helps if you have it installed.  If you do have it, make sure it's up to date, as I've found compatibility problems if both your browser and WebDriver aren't up to date.

Currently available from here.

Install Java Eclipse

Selenium WebDriver is driven from Java, which means we need to have a Java development environment to make it work.

Currently Eclipse Java Mars is my preferred program for this - and it can currently be found here.

Install Oracle JDK

Eclipse won't work just by itself - it requires a Java development kit installed for the supporting middleware between what you code in Eclipse and your computer.

I always use the Oracle kit from here.

Download Selenium WebDriver

Finally you need to download the WebDriver library from Selenium which is currently here.

There's a huge smorgasboard of stuff there, so it can get confusing (I've actually ended up downloading the wrong thing) - remember you're after the WebDriver for Java, which is here ...

You will need to extract onto your computer - I suggest Documents/WebDriver folder.

When you create a script in Java Eclipse you will need to import these JAR file (Java ARchives) into a library to use them - don't worry, I'll walk you through it.



Next time we'll set up our first project, and run our first manipulation with WebDriver.


Golden Rule

This and the next section, you might encounter difficulties as you go through.  I'm adding help where I've encountered problems (typically my problem is I never read the instructions fully before going ahead and doing something).

However my tried and tested method when I have difficulties is to Google any error message, and work through any message boards and advice which is out there, until I find something.  Turns out most developers do the same thing!

My point being, if you are having problems, don't give up at the first hurdle.  Here's another post showing similar instructions.

If you're seriously struggling, drop me a line on Twitter, and I'll see if I can help.  Although be prepared for ...

AUTOMATION 15 - GUI 3, introducing Selenium WebDriver

Technical level: **

Through some of these next few posts I'm going to flag up the technical level I believe I'm going to.  This is about 2/5.  I think everyone who is a tester and works with or alongside automation will benefit from.

So far we've looked at identifying page elements, and some very basic manipulation of page elements using Tamper Monkey.  This should be increasing our comfort and sense of "hands on" with the automation.

For the next few sections we'll be looking at Selenium WebDriver, and some tests we can do within this framework.  I'm hoping that by the end of this series you'll understand why we're focusing on Web Driver - over Selenium IDE, which is record and playback.

In a nutshell...

Driven by common computer languages

Selenium WebDriver is powered by a computer language - you can download it on multiple languages such as Java, C#, Ruby, Python.  In this series I'm focusing on Java.

We will also explore by series end why that's incredibly useful.

An API tool

Selenium WebDriver is an API tool - but it's somewhat different to the API's we've looked at previously.  It uses API commands to remote control your browser, and retrieve information from it.  In the examples we've looked at before, we used API commands to remote control part of your test system.  As such, testing with Selenium means we're testing with a complete system under test (your users browser is always external to your system).

Firefox out of the box, but other browsers are available

Out of the box, Selenium WebDriver works on Firefox.  You might be aware that Firefox is updated quite frequently, and likewise Selenium WebDriver has to be updated to keep pace.

In preparing an example, I was unable to get a very simple case to work - turns out my Firefox browser needed an update, and without it Selenium just wouldn't communicate!

Support for other browsers such as Chrome are available, including headless browsers.  Headless browsers such as PhantomJS don't have a graphical interface and return page information in pure html form.  This is really handy for an API driven system like Selenium, which doesn't really need that visual element.  It means if you run your automation with a headless browser, you can perform it much faster as it's stripped down to the bare minimum, such browsers work much faster than say Firefox.  Against that you're not able to screenshot when you have an issue.

I won't be going into any more detail about headless browsers, but if you're interested, you should do further reading.

Looking at Selenium, the commands available fall into several broad categories.  I believe it's useful for testers to be aware of these, even if they don't actually script it, because when you ask your automator to create automation for scenarios for you, you need to be work within these kinds of commands.

Page Manipulation

These kind of commands are a continuation of those we explored previously using TamperMonkey (although we use a different language here).

They are a set of commands to simulate us "doing" something to the page such as,

• Entering test into a field
• Selecting a radio button
• Selecting/deselecting a checkbox
• Choosing an option from a dropdown box
• Pressing a button

Browser control

There are a host of controls which simulate some very basic commands, pretty much anything you can do with your controls in the top band of your browser there's a command for maximise/minimise, read the URL you're on, close/quit, go back.

One of the most useful functions is the navigate command, which takes your browser to the URL you provide.  This is obviously typically step 1 of most tests!

Capture web element

These kind of commands typically get Selenium to "locate" at an area of the web page, from details you provide (such as the ID we used last time).  

Once located, you can run checks on the content at that location - for instance you might open a page, and see if it ever makes a reference to the text "blue aardvark" for instance.

Explicit wait

After issuing a command using Selenium, you have to wait for the browser to respond.

When I was doing "old-style" automation back in 1999, we typically set a wait of about 2 seconds a command to cover this.  These days we want the script to run as fast as possible.

Selenium uses something called an explicit wait - it waits for an event to occur (which you define), it that happens, it will wait up to a time you determine, before moving on anyway.  [Trust me, you don't want to wait indefinitely]

Next time we'll look into installing everything you need for Selenium WebDriver, before moving on to some basic examples.

Extension material

I am using a host of material to prepare this section - primarily sourcing the WebDriver support pages here and here.  I've learned though such pages move around a lot, so be prepared to use Google for a search if this post is quite old.  Hopefully reading this series will help you get more out of those support pages, which I encourage you to visit and read as we work through some examples.

Engel Consulting runs a great course on Selenium WebDriver, and they have provided me support in putting together this series.

Ministry Of Testing has some a useful collection of videos with Richard Bradshaw, but they require membership - which although might seem expensive, talk to your company about (it's an on-demand learning resource, cheaper than sending on a course).

I'm hoping that this blog will have the most comments

See the blue aardvark.  See it run.

You should always check for a blue aardvark.

You might even wish to check there is no aardvark of any other colour.


This blog is as you might have guessed, a test object in it's own right ... I'll explain later.

AUTOMATION 14 - GUI 2, basic page manipulation with TamperMonkey

Technical level: ***

Previously I introduced you to web browser development tools and had you exploring sites to inspect elements and the code behind them.

In folklore there is a concept called a "true name", everything and everyone has one - something sacred which describes it's nature.  In magic, to know something's true name it to have great power over it.

Now automation isn't quite like a magic spell, but this concept applies, and why it was worth our previous entry exploring finding out true names with dev tools.  If you know a page element's name, there's a lot you can do with it in automation!

Today I want to introduce you to some very elementary automation through a tool a developer told me about Tamper Monkey.  Installations vary - so to install I suggest you Google "Tamper Monkey" with the name of the browser you use.  So far I know it works for Firefox and Chrome.

Once installed, you'll see the following icon in the top right corner of your browser,

There is quite a bit of support material out there, which always seems to be on the move and being updated, so rather than give you a static link, I'm again going to suggest you Google things like "Tampermonkey instructions", "Tampermonkey examples" etc.

What we're going to do is populate some fields in Facebook to register an account using this tool.

What you do is to go to Facebook and select the TamperMonkey icon and "Add New Script".  You're shown a page like this ...

You can see in brown what looks like a comment which reads @match - this is the website this script will apply to.

You'll also see a defined function() which is the core of the script.  Where it says "// Your code here", we're going to add some code

document.getElementById('XXX').value = 'YYY';

This is the core instructions we're going to use today.  Basically it instructs the script to find an element with a name "XXX" and set it to "YYY".

This is where last times experimentation with developer tools is helpful - we can search through it to find the "true name" of the field you want to manipulate.  In this case, it's the mobile number - and I'm looking using the dev tools for the id field which currently is "u_0_6" for me.

I want an easy number to remember, so I'll choose "0123456", and so have the following command,

document.getElementById('u_0_6').value = '012346';

I save this, hit refresh in Facebook page, and voila, it's populated with my value!

Okay I'm going to add the following, and see what happens for you,

document.getElementById('u_0_1').value = 'Mike';
document.getElementById('u_0_3').value = 'Awesome';
document.getElementById('u_0_6').value = '012346';
document.getElementById('u_0_9').value = '012346';


Just be aware - Facebook might tweak these field names - good job last time you learned to find out those ID codes using dev tools to tweak this!

So far so good - one of the reasons I chose Facebook is it currently has these drop down and radio buttons shown below,

For the drop downs, try the following commands,

document.getElementById('day').selectedIndex = 14;    

document.getElementById('month').selectedIndex = 2;

document.getElementById('year').selectedIndex = 33;

Instead of the previous "value" you're using "selectedIndex" to select the item at the number you've provided.  For instance Feb is the 2nd month.  Likewise 1984 us the 33rd month.

Finally for the female radio button,

document.getElementById('u_0_e').checked = 1;

This time using the "checked" function to set values.



Extension Material

Hopefully you've downloaded TamperMonkey and tried some of this out as we go along.  It's the only way to really get your hands dirty and understand.

I find TamperMonkey really helpful especially for pre-populating registration pages.  You can set variables and use them to enter text.  An example I've done is to convert the time into a phone number, which is always changing.

Likewise, try setting random dates of birth - TamperMonkey uses a basic Java (maybe even Javascript, I can't tell the difference), so try a few things out, and see how you get on.

Have fun playing around on different sites.  Next time we're going to look a little at Selenium Web Driver.

War in numbers

I previously blogged about The Battle Of The Somme's 100th Anniversary, and have been binge watching episodes of The Great War since.

This episode really struck a chord with me, it echoes "our love of numbers", but played out from a historical perspective.  In talking about The Great War, one of the deadliest wars ever fought, we often get lost in the numbers ...

Indiana Neidell's speech starts at about 6:30, and I've copied it below,

We don't seem to talk about this war on an individual level.  We don't seem to do that so often because that's not how this war works, this World War.

Think - when I tell a tale of heroism or an everyday tale of the trenches that may inspire or entertain. what of the ones I don’t tell.  They have their stories too.

Whether it’s the brief tale of the 19 year old being killed by a sniper his first day of battle because he peeked over the trench.  Or the 40 year old veteran of countless tropical colonial battles, freezing to death in the mountain snows far from home.

We’ll never hear those stories and mostly never think of them because we get fooled by the numbers.  Look at this week (February 1915), three huge offensives.  Soldiers in the millions fighting all over Europe.  Tens of thousands being captured at once.  Just imagine how that even looks.  Fifty thousand men dying in a single week in a single army.

We get fooled by those numbers, because we can’t really conceive of them in terms of horror.  So go back to the individual, try to think of those men one at a time.

The Russian solider captured by the Germans, unable to speak the language, doomed to spend what remains of his life in a prison.  The Hungarian soldier who’s never even been to the mountains before, but is now fighting in temperatures of -20C, in boots with cardboard soles.  The wounded stuck in No Man’s Land and finally being eaten by wolves at night, because that really happened.

Every single one of these men involved in campaigns had a story, so think of them, and think of this.  Three great offensives were being fought this week – there was nothing great about any of them

The Somme: 100 years on

It's no secret that I've a huge interest in history.  It's one of the reasons I was very proud when my son chose to study the subject at University this year.

This week sees a significant anniversary of a very poignant event to me - the start of the infamous Battle Of The Somme.

Two years into World War One, and things were not going well for the allies of France and Britain on the Western Front.  In February, Germany had started a major offensive against the fort of Verdun, which was controlled by the French.  The sole purpose of this offensive was to bring French forces into a meat-grinder where they'd take casualties in such numbers it would impact their ability to continue the war, meaning they'd have no choice but to sue for peace.

Desperate to relieve the forces at Verdun by inflicting a counter-attack which Germany would be forced to react to, Britain planned an imaginative and daring attack against the German line.  In the week before attack, German lines would be bombarded with over a million shells, including the detonation of a gigantic mine immediately prior to the attack.

British commanders believed this barrage would completely annihilate the opposition - no one would be left alive in the enemy trenches.  What would remain for the troops would be to cross no mans land and occupy German positions, preparing them for an inevitable German counterattack.

The first day's offensive was planned in minute detail, with a timetable of follow up waves, who would come forward to support the first waves, together with set later artillery support for where the Germans were anticipated.

On July 1st 1916, the massive mine was detonated, and officers blew their whistles to "go over the top" into no-man's land.  Within minutes the problems in the plan were being exposed - unknown to British generals, the Germans had deeper trenches, with better fortifications than their British counterparts.  As the British army marched in formation into no man's land, the Germans on the other side were already in position, able to cut down whole swathes of men with their machine gun positions.

But the real tragedy of the Somme's first day was the inflexibility of the plan.  With wave after wave of later formations being forced to stick to the plan, and follow a previous wave which had been annihilated just an hour before.  What we now would describe as "doing the same thing over and over again, but expecting different results".

The grave of Horrace Iles, who died only 16 on the first day of the Somme.

Photo by Paul Reed

It is still remembered as the worst day in British military history - with 60,000 casualties, including 20,000 dead.  The inflexibility of the plan, which saw so many futile losses even when the shortcomings had become obvious would tarnish the Generals involved as uncaring leaders "far from the trenches" more wrapped up in dreams of glory than for any care of their men.

Such a view is perhaps somewhat unfair - the disaster of the first day of the Somme was a somber wake up call to what was still a relatively new kind of warfare compared with the wars of the 19th Century.  Tactics did change (although arguably perhaps not fast enough) and led to ideas such as,

• Development of the tank armoured vehicle to attempt to break the stalemate and cross no-man's land
• Use of telephone and radio communications to signal back the situation to generals behind the trenches
• Integration of artillery to support the movement of infantry, particularly "creeping barrages"
• Use of staggered formations to approach machine gun positions instead of approaching in formation
• Development of grenades and portable mortars to support troops against dug-in positions

The Battle Of The Somme (which lasted until November 1916) did succeed in taking pressure off the French at Verdun, and prevent the collapse of the Western Front, but at a terrible price.  Sadly, even on it's best day, trench warfare remained a bloody and costly business.

To me, the Somme is a ghastly reminder about planning.  We often think that the more detail a plan is scoped out in, the better.  However there are always "things that go wrong".  Hence probably the greatest weapon developed was greater flexibility for junior officers to appraise and make their own decisions, over following a plan.  This is the hallmark of all modern armies, but one which was forged in blood.

Reading a lot of American testimonies from World War Two, there is a lot of criticism of the British army for being "overly cautious".  It's impossible to pin that comment to a single root cause, but after the costly disasters of World War One, caution seems to have worked into the DNA of army thinking.

Resources

• Dan Snow's History Hit is doing a series of podcasts on the Somme this week with some of the world's experts.  The series has taught me a lot of things I'd never knew.  Start with part one here.
• The Somme: From Defect To Victory - you can see this on YouTube here.
• First World War Centenary Site
• Paul Reed's been sharing a lot of poignant material on Twitter, and his blog is well worth checking out.  He talks to Dan Snow here.
• YouTube channel The Great War is well worth checking out.  Here Indiana Neidell looks at General Haig, the man behind the British offensive in the Somme.  He also looks at Arthur Currie here who suggested some changes in tactics such as flexibility of units.
• Wikipedia has an interesting page looking at the development of tactics for trench warfare here.

Although just a dramatisation, this Blackadder sketch is well worth a watch,

AUTOMATION 13 - GUI checking 1, exploring with developer tools

Technical level: **

In this next section, we're going to start to explore the use of automated GUI checking.  I'm going to focus this down onto browser based GUIs for ease.  Indeed most applications today are web-based (at least the ones I seem to test), so this isn't a major assumption.

To help us get there, today I'm going to introduce you to the developer tools on your browser.

For every browser the developer tools are slightly different.  For Firefox and Chrome currently all it takes is selecting F12.

These tools allow you to peek at the code that makes up a web page.  One of the most useful is the inspection icon which allows you to select an item from the page, and it will show you the code and the name for it.  The icon looks like this,

When I select the Google search box on my browser, it shows me this,

And here I am selecting my gender as female for Facebook,

The starting part of thinking about driving GUI tests is understanding some of the page elements of your system.  It's something we probably do intuitively as testers, however automation requires we specifically state actions (as we've talked about previously).

Here are some common page elements - if any seem unfamiliar, spend some time looking them up.

• Labels and text - any textual information displayed to the user
• Fields - this is where you as a user can enter test into
• Button - an item on the page which causes an action when selected
• Checkbox - an item which can clearly be toggled between being selected and deselected
• Radio buttons - a cluster of buttons which when selected will deselect any others in the group which have been selected.  [Bonus - tell me in the comments below why they are called radio buttons]
• Drop-down list - the user is presented a list of items to select

Next time we'll take the next step, and use this understanding of web elements to perform some basic steps.

Extension material

• Look up the web elements I've talked about, and think about how they can be manipulated.  Drop me a line below on how radio buttons got their name!
• Find out what the developer tools are like on other browsers.
• Use the developer tools to select different page elements on a range of systems - especially anything you test at work.  Have a go at reading the information about the elements, and don't be afraid to try and demystify what you read by asking around or Googling.