Good to have web development background for web test automation

26 Jul

Based on my experience collaborating with others online and offline relating to Selenium, it was evident to me that to get the greatest potential in automating websites and web applications using Selenium and like tools, one really needs a web development background. Granted I have such background, but wish that others using Selenium are able to have such a background. You don’t need to be a guru web developer but at least know the basics around web development.

And granted, this applies to all fields of test automation (e.g. software or desktop application development for desktop GUI application automation; APIs, protocols, and hard core low level stuff for embedded systems, etc.), not just the web, but it’s more evident for the web, based on the number of technologies involved, popularity, and how we hire automation QA for the web area. I may stand corrected, but comparatively, in embedded systems, it is much less likely to find a “software engineer in test” or QA doing automation who is inexperienced with programming and developmental aspects of embedded systems. For desktop GUI applications, you may still find inexperience QA doing automation (typically with commercial or free record & playback type tools), but that’s less of an issue as their inexperience less to code/test maintenance issues resulting from bad test code design.

But in the area of web automation, inexperience is worse because it’s possibly bad test code design combined with improper (or inefficient) automation due to lack of knowledge of the following areas:

  • Web UI element familiarity – what is really a “popup” window vs an HTML element that looks like a popup but is still on same main window. How div elements can be made to render like a button, form field, image, etc. Whether an alert/prompt/confirmation dialog is a browser based one (via javascript alerts or an HTTP basic/digest login form) or an HTML element rendered to look like a popup prompt window.
  • DOM – how to access and manipulate elements via the DOM and javascript (e.g. document.getElementById(‘someId’).innerHtml = “blah blah”;). Useful as alternate ways to work with elements besides Selenium’s native element methods.
  • Javascript – lots of things you could do with it in terms of automation. Only restricted by browser security settings, same as what web developers go through. Especially in WebDriver with its near full javascript support, many things you couldn’t do in Selenium RC, you can now do in WebDriver via javascript.
  • XML, XSLT, and XPath – some people only know how to use Firebug and like tools to get their XPath. That’s only step 1 to narrow down the location and context of the element. Step 2 and beyond involves defning the best XPath manually, not what the tool gives you.
  • CSS selectors – some people only know how to use Firebug and like tools to get their CSS. That’s only step 1 to narrow down the location and context of the element. Step 2 and beyond involves defning the best CSS manually, not what the tool gives you.
  • HTML, CSS, javascript – understanding overall how site is rendered, how element attributes and styling work, etc.
  • AJAX, HTTP, REST, API calls, traffic sniffing – to know how to analyze server side problems (or AJAX related issues) that only show up via network traffic sniffing or Firebug console, that are not evident from looking at the web UI itself. Also useful to know how to sniff HTTP traffic and replicate those HTTP calls using HTTP request/REST code libraries and combine with Selenium to do things you couldn’t do with Selenium alone, or just to speed up Selenium tests by automating steps like configuration (that are important to test but not need to be directed tested as the feature under test).
  • Use developer centric techniques to help automate like exploratory Selenium automation development via (Python, Java Beanshell, Ruby) interpreter shell rather than write script, run, debug, repeat. You can do similar with shell than an IDE w/ debugger. Granted full development could benefit from IDE, but for quick hacks and trial tests, the shell method works better (for me anyways).
  • and perhaps more, as I think of them to list here…

If you are doing web test automation using Selenium and do not have this kind of background, good time to start learning. =D


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Der Flounder

Seldom updated, occasionally insightful.

The 4T - Trail, Tram, Trolley, Train

Exploring Portland with the 4T

Midnight Musings

Thoughts on making art

Automation Guide

The More You Learn The More You Play...!

The Performance Engineer



Thoughts related to software development

Yi Wang's Tech Notes

A blog ported from

Appium Tutorial

Technical…..Practical…..Theoretically Interesting


I swear! Meerkats can do Linux


Requeuing the packets dropped in my memory.

Two cents of software value

Writing. Training. Consulting.

@akumar overflow

wisdom exceeding 140 chars.

Lazy Programmer's Shortcut

Java, J2EE, Spring, OOAD, DDD & LIFE! .......all in one :)

Testing Mobile Apps


education and inspiration for visual storytellers

No, Seriously...

Freeing up some mind cache!

Mike Taulty

I do some developer stuff for Microsoft UK

%d bloggers like this: