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.
Technical Thursday
DevTools must-have knowledge for a tester
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
Verifying whether or not your locator is unique can also be done by using the Console pane within DevTools. Within this pane you are able to execute javascript code on the webpage, but you’re also capable of executing a css selector or an xPath and verifying whether it works as expected. This can easily be achieved by using the following syntax: $$(‘{css selector}’) or $x(‘{xPath’) where you need to replace {css selector} and {xPath} by the corresponding identifier.
On the left: use the find option within the Elements pane to identify an element using a css selector
On the right: use the script executor within the Console pane to identify an element using a css selector
Device Mode
Within Chrome DevTools it’s possible to simulate how your application looks like and performs on a mobile device. You can do this by using the Device Mode, which is a collection of features e.g. simulating mobile viewports, throttling network and CPU, simulating geolocation and setting the mobile orientation. You can open the Device Mode by clicking the “Toggle Device Toolbar” icon in the upper left corner of your DevTools menubar. This will open a responsive viewport where you can change the viewport to whatever dimensions you need by manipulating the handles or by entering the specific values for width and height of the screen. Another way of changing the viewport is by selecting a specific mobile or desktop device and check the responsive design. There is a predefined list available but you can extend this with your own specific devices and viewport sizes. The Device Type list can be used to simulate whether you are working on a mobile device or a desktop device and whether you want to simulate a click or a touch event. Within this list the rendering method describes whether Chrome will render the page as a mobile or as a desktop viewport and the “Events fired” column will determine whether the page will fire a touch or a click event when you interact with the page. Last but not least, you can easily switch to landscape orientation by using the Rotate button.
Network connectivity and CPU power
Next to the responsive design, you can also change the network connectivity and CPU power of your simulated device by changing your mobile settings from Online to Mid-tier mobile, Low-end mobile to even Offline. The Mid-tier mobile setting will simulate a fast 3G connectivity and will throttle your CPU to 4 times slower than normal, while a Low-end mobile will simulate a slow 3G connectivity with a CPU pow which is 6 times slow than normal. (Keep in mind that the throttling is relative to the normal capability of your computer).
Device Mode will not actually run your code on a mobile device, instead you will simulate the mobile user experience on your laptop or desktop computer. There are certain aspects of mobile devices which can not be simulated, like the architecture of your mobile device, this is very different from the architecture of your laptop or desktop computer.
Overview of the different device types which can be used for simulations
Webpage opened on the selected mobile device
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…
