Firebug, You’re Fired – Angie Jones
post-template-default,single,single-post,postid-3816,single-format-standard,eltd-core-1.1.1,flow-ver-1.3.6,,eltd-smooth-page-transitions,ajax,eltd-grid-1300,eltd-blog-installed,page-template-blog-standard,eltd-header-vertical,eltd-sticky-header-on-scroll-up,eltd-default-mobile-header,eltd-sticky-up-mobile-header,eltd-dropdown-default,wpb-js-composer js-comp-ver-5.0.1,vc_responsive

Firebug, You’re Fired

Firebug, You’re Fired

When interviewing candidates for UI automation openings, I like to give them typical automation ‘problems’ to solve. Most of the problems provide them with a picture of a UI and the corresponding HTML, and ask how they would automate something given a tricky DOM. I’m finding that many of the candidates have experience in writing automation scripts, but are still stomped by these interview questions. Many of them respond with “I’d need Firebug to answer that”.


Please don’t be so dependent on Firebug, or any other browser’s dev tool. They are great to show you the DOM, but you should not rely on them to accurately give you proper handles to elements. Especially not in this day of modern web development where applications are being created with fancy Javascript libraries that pretty much guarantee a dynamic DOM.


Blindly depending on Firebug’s xpath or css selector recommendations is a sure-fire path to unstable scripts. I honestly can’t think of the last time I coded a scenario and was able to rely on the static identifiers for 100% of the elements involved in the scenario. There’s always one or two that require a bit more thought on how to reliably get a handle to it in different situations. As an automation engineer, it makes maintenance a lot more manageable if you develop your scripts with a good understanding of the DOM (including the relationships between nodes), and how to craft reliable xpath and css selectors.

Are you ready to fire Firebug? Or at the very least, be able to question the information it provides you? If so, here are some resources I’d recommend to help you be more efficient at identifying elements:

Understanding the DOM

Xpath Statements

CSS Selectors

Angie Jones
  • James Willett

    Nice post. FireBug is handy for when you are getting started, but when you work with anything but the most basic of applications, the CSS / XPath that it throws out is often wildly inefficient or simply unusable (particularly if the page has dynamic content loaded through JS, for example)

    October 31, 2016 at 6:15 pm Reply
  • Mark City

    I had a lot of fun writing an automation library that would find the form control on the browser based on its label. For buttons, it’s easy to find, but for fields in tables, it was trickier, but doable, particularly if it’s meant for only one organization (but a lot of it is generalizable).

    December 23, 2016 at 11:53 am Reply

Post a Comment