An Introduction to Browser Developer Tools

Unless this article has been printed out and handed to you, you’ve most likely used a web browser before. Heck, there’s a good chance it’s the most-used application on your computer! Especially if your job involves testing websites…

But have you ever been below the surface of the site and checked out its inner workings; the HTML, JavaScript and CSS stlyings? How about editing and manipulating them? And would you be interested in seeing exactly what information flows between websites and servers?

Today, we will discuss how to use your Browser’s Developer Tools to get under the hood of a website, and hopefully extend your skillset as a software tester.

An XKCD commic spoofing the Mac vs. PC commercials.

Image: Randall Munroe, XKCD

Since the first browser was created by Sir Tim Berners Lee in 1990, the Web Browser has grown, branched and flourished in a variety of forms. At the time of writing this article, the top spots are held by Google Chrome, Microsoft Internet Explorer, Mozilla Firefox respectively. Other browsers that you definitely must test your website on are Apple Safari, Opera and the Android Browser.

A chart showing web browser statistics for 2015.

Screenshot: Wikipedia, Usage Share of Web Browsers

Google Chrome is currently the dominant (and still rising) force, with Microsoft Internet Explorer and Apple Safari playing catch-up. Mozilla Firefox is also a major player in the browser scene, with a strong user-base of loyal fans.

The recent versions of these browsers come with built-in Developer Tools. With the exception of a few extra differences here and there, they all come packing the same features. We’ll be use Google Chrome in our screenshots (sorry Phil), but as long as you’re using an updated version of one of the aforementioned browsers, you should be able to follow everything fine.

In your browser, bring up the Developer Tools by pressing F12, or Ctrl+Shift+I, or going to Menu > More Tools > Developer Tools. It’ll probably appear attached at the bottom of the browser window like this:

The Browser Developer Tools, attached to the bottom of the browser window.

Screenshot: Google Chrome with Developer Tools

You’ll see a bunch of tabs along the top of the window. These compartmentalize the main features of the developer tools. Since this is just a basic introduction, we won’t be covering all of them – that’s what the manual is for! Instead, we’ll be focusing on the tools we believe will help software testers and other web professionals in their day-to-day work.

By default, the Elements/Inspector tab will be selected, so we’ll start with that first…

The Elements Inspector

A preview of the Elements tab in Developer Tools.

Screenshot: The Elements tab on the Chrome Developer Tools

The Elements tab displays the HTML markup of a website, along with its CSS styling. The HTML elements are all nested; you can expand them by clicking the small grey arrows to the left of each element.

Hovering over a HTML element causes the corresponding page element to be visibly highlighted. The inverse is also possible; by selecting the small magnifying-glass icon (to the left of the Elements tab) you can select visible elements on the page with your mouse.

If you’re familiar with HTML, you’ll know that elements can have IDs, Classes, and a number of other attributes. Knowing these precisely can be very useful for testing; it allows you to provide the developers with more accurate descriptions of how a page is misbehaving, and getting IDs of elements is essential for writing automated test scripts.

A depiction of how visible page elements correspond to HTML elements.

Screenshot: How visible elements on the page map to html elements

You might notice that when you select different elements, the contents of the Styles panel on the right changes. The panel displays the CSS styling rules for the currently selected element.

True to the name ‘Cascading’ Style Sheets, the rules first displayed are the most relevant and surplant less specific rules which are displayed further down.

If you move your cursor over any of the CSS rules, you’ll notice some checkboxes appear alongside each one. Unchecking these will temporarily disable that CSS rule on the page. Using this, you can see how much of an effect CSS can have on a website – and maybe also pinpoint a rule that is causing a particular bug!

But the Elements panel doesn’t just let you look at elements – you can also edit them.

An example of an HTML element ready to be edited.

Screenshot: Editing some HTML using the Developer Tools

Try double-clicking on any of the HTML elements, and they’ll become editable. You can change the names of IDs, Classes, anything you want. The same is also try for the CSS styling rules; click on any of them to edit their values.

You can also add your own styling rules to the page. Position the mouse over an existing CSS rule, then move it to the left until the cursor changes from a text cursor back to a regular mouse. Click once, and you will be ready to enter your own CSS property (auto-complete options will appear to help you). Then press the Tab key to move on to the property value. If you keep pressing Tab, you can keep adding rules. Simples!

There’s a lot more to the Elements tab, but those are the basics. Play around and see what else you can find.

Remember: everything you modify there is client-side. If you refresh the page, the browser will wipe your changes and get a fresh copy of the site!

Now, moving on to…

The Network Monitor

A preview of the Network tab in Developer Tools.

Screenshot: The Network tab on the Chrome Developer Tools

The Network panel is used to show all the network requests a website makes. This includes any media – images, video, etc – displayed on the page, and also any scripts or styles that affect the page too. Along with resources requested on page load, the Network panel also shows any subsequent requests made by the page, such as AJAX calls.

The Network panel can also be used to view data that the website sends to its server. For instance, upon submission of a web form, the website will send the user input to the server. Using the Network panel in conjunction with the Source panel (we’ll talk about that later), you can perform a detailed analysis of a website’s communcations.

We do, however, need to check that the Network Recorder is turned on before we can do any of that! This is shown by circle icon beneath the maginifying glass logo, which will be red if the Dev Tools are recording. Next to this icon are other useful tools, such as options to clear the current log, filter the recording to display only certain types of network traffic, and preserve the recorded network calls between page navigation.

An image labeling the important settings on the Network panel.

Screenshot: Important settings on the Network panel

Various details of each network call are visible in the table. They include:

  • Name – The name of the resource, or the URL path queried.
  • Method – Usually either GET or POST, this shows what request method was used.
  • Status – 200 if the request was susccessful, and a variety of other codes if it was not. See a full list for more details.
  • Type – The type of resource returned, such as fonts, images, or scripts.
  • Initiator – Provides a link to the code which fired the request. Clicking on it opens the Source panel, which we will discuss later.
  • Size – The file size of the requested resource.
  • Time – The total time it took for the resource to be acquired.
  • Timeline – A detailed breakdown of the activities required to acquire the resource, and how long each one took.

To view more technical details of a particular resource request, you can click on one of the logged items to bring up a details panel. The data in the panel refers only to the selected network call.

As previously mentioned, one of the major uses of the Network panel is to see what data is being passed to the server. The example below shows how a form submission triggers an AJAX server call, which sends up the details the user has entered:

An example of how the network panel can be used to inspect dataflow between client and server.

Screenshot: Using the Network panel to view data flow

This informaiton can be especially useful in isolating whether bugs are caused by faulty back-end or front-end code; if the data being passed to the server is as expected, odds are it’s a server-side issue. However, if the data being passed isn’t what you’d expext, there’s a bug in the client-side code!

There’s obviously a lot more to the Network panel, so have a play around with its other options and features.

But for now, let’s progress to…

The Source Tab

A preview of the Source panel in the Developer Tools.

Screenshot: The Source tab on the Chrome Developer

The Source tab is incredibly important to front-end developers, and can be equally useful for a software tester to better assess the impact of a bug.

Just like the Element panel reveals the website’s HTML and CSS, the Source tab unveils the JavaScript code that makes it run. It also allows you to breakpoint, debug, and modify the code in a similar manner to how the Elements panel allowed you to change the page structure and styles.

Since a website might load multiple script files, the Source tab allows you to browse a tree-structure of them in the left-hand panel. After selecting a script file, it will display in the central panel, and you can open several different files in various tabs. The right-hand panel displays context sensitive information, such as breakpoints and variable values.

Probably the most common thing you use the Source tab for is breakpointing. This means placing markers in the JavaScript code and when the code is running it will pause at those points. For example:

A demonstration of how to use breakpoints to debug code.

Screenshot: How to use breakpointing to debug code

Once the code has paused on a breakpoint, you can use a set of controls located at the top of the right-hand panel to continue navigating through the code at your own pace:

Labeled picture of the debugging control buttons.

Screenshot: How to use breakpointing to debug code

The versatility and power of the Source tab make it a valuable part of any web profesisonal’s toolbox. This functionality also goes hand-in-hand with the final feature we’re going to talk about…

The Console Panel

The console panel with some basic code examples.

Screenshot: The Console Panel with some basic code examples

The Console Panel isn’t like the other Developer Tool tabs. It comes in two viewing modes – stand-alone, which can be activated by clicking the Console tab at the top next to the others; and inline, which makes a Console area pop up beneath whatever Dev Tools tab you currently have open. You can open the Console from any Dev Tools tab by pressing the ESC key, and click-drag on its grey header to resize it.

The Console lets you run arbitrary pieces of JavaScript. Just start typing in some code like 1 + 1 and press ENTER to see the results. The usefulness of this feature does depend a lot on your knowledge of JavaScript, but you can also paste in code from other places too. And if you want to practice learning some JavaScript, this is the perfect playground!

For actual tuition on learning some JavaScript, check out Codecademy or Code School for some great interactive tutorials.

A quick warning though: any code you paste in from elsewhere must not have any errors. That is to say, any required variables must be created within the pasted code, and any dependencies must be accounted for.

Something else worth noting is that, depending on the website you’re on, you can also access variables and functions from the site’s JavaScript in the console. In the following example, we can access the $troocode variable in the trooTest website’s script, and then that object’s child methods, and so on.

Showing off autocomplete in the Console.

Screenshot: The Console attempts to autocomplete your code

Context is really important to bear in mind if you’re using the console whilst debugging. If you’re paused at a breakpoint in the code, try looking around for any variables instantiated just before the breakpoint, and then type them into the Console. You’ll be able to access and use them freely in your own code snippets.


While the Developer Tools may – as the name suggests – primarily be used by developers, they have a great many uses in the testing field. Having knowledge of a site’s structure and scripts can give a greater insight into where bugs might be lurking.

Being able to easily find the IDs of page elements, or identify particular server calls, is extremely helpful in writing automated tests. Writing bug reports suddenly becomes a lot easier when you can precisely say that function so-and-so in the JavaScript is failing because such-and-such parameter hasn’t been passed in. Developers will love you for making their lives that much easier!

Although we’ve only covered a small handful of the uses of the Developer Tools, there’s plenty more features in there. If you think any of the tools we’ve mentioned might be useful in your testing workflow, have an explore and see what else the Developer Tools have to offer.

Go on, hit F12 right now…

Original article: