Did you know there is a set of testing tools available in your browser? Every modern browser like Chrome and Firefox (but also Internet Explorer, Safari, Edge, …) contains a set of web development tools (often referred to as DevTools) allowing web developers to test and debug their code. Do not confuse these web developments tools with an IDE (integrated development environment), they are not used for the creation of the user interface, but only for testing it. Since testing is becoming more and more technical, these developer tools are not only interesting for developers, but also for testers. In this post we will be sharing some DevTools features which might benefit you as a tester. In the beginning the DevTools UI might be overwhelming, but if you take your time to get familiar with some of the tabs, you will discover that it will definitely boost your productivity. For many of the modern browsers the developer tools work very similar, so for the purpose of this article we are going to focus on the Chrome DevTools.
Inspecting HTML elements
Every tester who has ever written an automated test knows how difficult it can be to uniquely identify a webpage element which doesn’t have a unique id. In these cases you need to understand the html behind the element and be creative with classes, css selectors or xPaths. With DevTools you can right-click the element and choose “Inspect” to open the Elements pane which will highlight the element within the HTML. The automator can use this information to determine the best way to access the element in a stable and unique way. You can hover over the different html tags to find whatever element you need, each element which is hovered is highlighted on the webpage so you can easily see which element is selected.
Opening the DevTools Elements pane and hovering the html will highlight the corresponding element within the web page
Within the Elements pane you have the possibility to change the html at runtime and in some cases this might be very useful. Consider the situation where you need to identify a label which only appears when you hover a specific element. When hovering the specific element the html for the label is generated within the Elements pane, but whenever you move your cursor from the web element on the webpage to the Elements pane in the DevTools, the element looses its focus, the hovering is no longer active and the html is changed to its original source code. This situation makes it hard for you to investigate source code behind the label in order to find out a unique identification method to automate this field. DevTools allows you to change the html source code and even change the status of a specific element, it allows you to force the state of a field to “hovered”, just by right-clicking the element and opening the “Force state” submenu.
Right-clicking an element within the Elements pane allows you to adjust the state of the element
Searching for specific string, css selector or xPath using the Elements pane
When writing an automated script, most of the element identifiers or locators are pretty straightforward, but occasionally you need to produce complicated css paths or xml paths. In order to create a stable test these identifiers need to be well thought out (avoid absolute paths, but use relative paths instead). Running your test in order to verify if your identifiers are working is a very time consuming task, definitely when you are creating automated end-to-end workflows which handle several pages before reaching the page on which you need to verify your identifiers. Luckily there is a better way… using DevTools.
On the Elements pane you have the ability to search for a specific string, css selector or xPath within the html source code (by clicking Ctrl+F). When entering a css selector or xml path this feature will indicate how many elements can be found with this identifier and gives you an indication whether your locator is unique on the page or not. When hovering this element in the source code will identify the element visually on the webpage itself, this allows you to immediately verify all the identifiers you have written for the current page instead of running your automated test and hoping it works as expected. This feature is also very useful when creating an identifier which does not need to be unique, but need to find all similar elements on a page (e.g. all items in a webshop). This will allow you to write a css path or xml path to count the number of elements which can be found with this css or xml path, and you can easily hover over all of the elements one by one to verify if they select the correct elements.
The Console pane
Simulate network performance
Testing a web application while working in the office usually means you are using a high-speed network. But what if the end user has a slower network connection? How will the application behave? And how can we test this? With DevTools you can simulate slower connections and throttled CPU, which could help to uncover rare conditions in your application. This feature can be found in the Performance tab where you are able to create your own custom network profile or select one of the of the available Network presets like Fast 3G, Slow 3G or even Offline to simulate not having any network connection. Besides the connection you can also simulate the CPU throttling going from no throttling to 4x slowdown or even 6x slowdown. Don’t forget to reverse your settings when you are done testing!
Setting the network connectivity and CPU throttling within the Performance pane
Investigate HTTP requests
When you open the Network pane within DevTools you will get a list of background requests made to the server while using the web application. This list includes webservice calls, which you can re-create in any API testing tool, e.g. Postman. This feature will help you to determine if the application is using the expected API calls. Afterwards you can further test these API calls within a dedicated API testing tool. For example, assume you have a web page containing an input field which should be limited to 100 characters. Just because the frontend doesn’t allow the user to enter more than 100 characters, doesn’t mean it can’t be done. You could bypass the frontend, copy the API request to your API testing tool and try to send more than 100 characters to the server. This is why it is important to have both frontend and backend testing.
Be aware that a lot of the above tools will simulate specific circumstances, which is off course not 100% the same as the real -life situation. This way of testing will therefore not entirely replace testing on real mobile devices and real test situations. Of course, it’s sometimes very hard and time consuming to set up these specific real life situations and you have to make a decision whether or not it’s worth the effort. In this case the simulated conditions within the Chrome DevTools can be the solution. It allows you to execute these simulated tests much easier and when you find bugs, you will find them earlier in the development lifecycle, which makes it cheaper to solve them…