As a QA, I've had multiple chances to understand that efficient testing is essential for ensuring the quality of a product. The developer console is one tool that can help us maximize our working rate success, but it is somewhat neglected. In this article, I want to explore and present my opinion on how QA testers can leverage the developer console to boost the efficiency of their testing processes and deliver higher-quality products.

What is the developer console?

The developer console is a built-in tool in web browsers that allows developers to test and debug their code. It also provides a lot of additional information about the respective website, including JavaScript errors, network requests, and general performance details. And while developers tend to use the console primarily for debugging and optimization, QA testers can also take advantage of it to improve their testing processes.

How can QA testers use the developer console?

There are various utilizations of the developer console, so let's focus on the most beneficial ones to a tester. For starters, open the dev console by pressing F12 or fn + F12 for Mac.

Identifying and reporting errors from the Console tab
Once the developer console is opened, to review the occurring errors (if there are any) - simply select the Console tab by pressing Console from the navigation bar at the top.

The console tab is where errors and warnings are logged in real-time, and it is convenient to keep it open and scan it occasionally for issues with the JavaScript running on the page. Doing so allows the QAs to identify problematic code and analyze the source of the problem or, at the very least - report it properly. It costs nothing to have a console opened; however, it helps testers greatly in identifying hidden issues that may be causing problems with the functionality of a web page or application.

The console tab acts as a JavaScript playground as well. It can accept JavaScript expressions, much like a terminal would, and will execute them against the context of the current page. Even though it's a slightly more advanced usage, you will surely learn to appreciate it as you go down the 'automation' road.

Inspecting the HTML DOM from the Elements tab

The HTML DOM is a text file that represents a webpage. Browsers read, parse, and follow the instructions inside it to 'paint' the webpage so we can view it. Whenever you see a bug in a website, you are most likely catching a bug inside the DOM document. That's why QAs must learn basic HTML and how to navigate it. Luckily for us all, the developer console has a built-in inspector that can be accessed from the Elements tab.

The primary use case for opening the Elements tab is inspecting an element. One can do that via a right-click on the element in question and selection of the Inspect option or by utilizing the shortcut ctrl/command + shift + C and then clicking on the element.

Selecting an element will update the context menu that, by default, displays the styles associated with the active element. Here you can modify the CSS and add, remove, or update its values and properties. This way, you could try out a few approaches and figure out how to fix an issue yourself. It's good to note, however, that once you refresh the page - all HTML and CSS changes you made will be lost. Thus, you still need to report the issue and have it fixed by a developer.

The QA work you can perform by utilizing the Elements tab and its Styles subtab includes:

Verifying CSS property values

By inspecting elements in the console, you can quickly verify that the correct CSS properties are being applied to different elements on the page. This can be useful for ensuring consistency (font size, font family, color, etc.) across the site and troubleshooting issues with specific styles.

Troubleshooting layout issues

Inspecting elements in the console can help identify the source of layout issues, such as misaligned or overlapping elements. By identifying the problematic element and inspecting its CSS properties, you can often find a quick solution to the issue.

Monitoring network requests in the Network tab

The network tab logs the request that the browser executes to load a webpage. This includes the fetch of the HTM and any styles, scripts, images, fonts, etc. The logs are also used for determining performance bottlenecks and network errors.

Some concrete examples include:

Optimizing page load times

By monitoring network requests, we can determine which resources are taking the longest to load and take respective measures. This can include reducing file sizes, caching resources, and prioritizing critical resources.

Testing APIs

APIs are an essential part of many modern web applications, and monitoring network requests can help ensure that the API is working as expected. By examining the request, we can verify that the API is returning the correct data in the desired format and identify any issues with the API endpoint or response.

Observing failed requests

The Network tab allows for reviewing failed requests as well. When a network request fails, it will get a red color error in the Status column, which indicates that the request was unsuccessful. Failed requests can be then clicked and inspected for more information about the error, including the error message and any associated error codes or details.

Inspecting standards of performance through the Performance tab

Performance is a critical factor for improving the user experience. By analyzing key metrics in the Performance tab, we can identify areas of the application that are slow or resource-intensive. Here are two use cases of how we put the dev console into practice here:

Testing performance under different network conditions

4G and 5G networks are amazing. They can and often do provide faster speeds than the cable internet we have at home. This allows developers to build bulkier and ever more demanding websites that look and feel great. Best-case scenario aside, the same sites fail miserably under slow connection speeds, which are still predominant in the world. The developer console allows you to match your internet speed with the slower 3G speed standards or cap it with a custom value of your own. Now, you can experience the product you are testing as it would be felt by the broader user base and, perhaps, report load-time issues.

The dev console will show you the total load time and the amount of data transferred:

You can use these stats in your reports and set a reasonable threshold for the developers to aim at.

Compare performance to industry standards

We can use the performance metrics in the dev console to set the standards of our application's performance against industry standards. For example, we can compare our application's load time against Google's or Microsoft's recommended standards for web performance or use competitors to set the bar around the industry level. This approach can help us identify areas where our application falls short and take steps to improve its performance.

Device simulation

The Console offers a range of pre-made mobile and tablet devices, enabling developers and us testers to examine a website's responsiveness across different devices and screen sizes.

And here are two everyday use cases we can observe:

Testing responsive design

With the device simulation feature, we can test how our web application looks and behaves on different screen sizes and resolutions, as well as on other mobile devices. This can help us ensure that our application's layout and user interface are responsive and optimized for various devices and screen sizes.

1. By clicking on the "Toggle device toolbar" (top left of the dev console, right of the Select and inspect element button), we go into Responsive mode, where we can simulate different resolutions of various devices. Because we can drag the borders of the responsive screen, we can also test the resolution breakpoints at which the design shift to phone/tablet/desktop mode.

1. We're to mention the reasonable dimensions for basic devices. In that case, they're as follows: for a phone, it can be 360 x 640 pixels, 768 x 1024 pixels for a tablet, and for a monitor, it can be 1920 x 1080 pixels, all of which are common measurements for the respective devices.

2. 

3. We can take as an example a 4K monitor edge case: It's usual for websites to appear too narrow and zoomed out on greater resolutions. This might be a good test that increases user satisfaction, depending on the product you are testing.

Simulation

Device simulation can also help us identify issues. There are several devices to choose from to simulate, including adding other devices that can be selected from a list. Touchpad and mouse cursor are both options to choose from as well.

Pixel ratio in the developer console is a way to understand how many pixels are used to display a single pixel on a screen. It helps developers create websites that look sharp and clear on devices with different pixel densities by adjusting the design accordingly. In the dev console's device simulation mode, you can simulate other devices and adjust their pixel ratios. To adapt your desired pixel ratio, click on the "Toggle device toolbar" icon in the top-left corner of the dev console, then choose a device to simulate from the dropdown menu. Once you've selected a device, you can adjust its pixel ratio by entering a new value in the value fields to auto-zoom the window. You can also use the Responsive mode to resize your window through mouse dragging.

By simulating different devices, we can test how our application looks and behaves across different platforms and identify any layout or functionality issues that may be specific to certain browsers or devices. This can help us ensure that our application is compatible with a wide range of devices and browsers and provide a consistent user experience for all users.

Application tab

The dev console's Application tab provides us with various tools to manage a website's application data, such as cookies, local storage, and cache. QA testers can use it to verify that the website functions as expected and that sensitive user data is protected. Here are two examples of how it is integrated into our testing process:

Debugging and managing cookies

The Application tab allows you to manage and debug cookies, which websites use to store data like authentication details, preferences, and shopping cart contents. You can view, edit, delete, and block cookies from specific websites, as well as simulate cookie behavior for testing purposes. This can be useful for ensuring that cookies are being set and read correctly and for troubleshooting issues related to user data and preferences.

Analyzing and managing cache

The Application tab also provides tools for managing and analyzing the cache of a website, including the ability to clear cache storage for specific websites or all websites. This can be useful for testing website performance under different cache scenarios, as well as troubleshooting issues related to outdated or cached content. Additionally, the Application tab allows you to manage and analyze other forms of storage used by websites, such as local storage.

The Local storage is a key-value storage that persists data even after we close the browser or shut down our device. Even though the data there will not be deleted automatically, it is limited in size (5MB). It's not considered best practice to use it; however, it has some practical usage, like setting the site's theme to dark, for example.

The Session storage is another key-value storage that keeps data only for the individual session, or in other words, for as long as we don't close or navigate away from the respective page. For example, after entering a webpage and choosing a specific language different from the default one, once we reload or navigate away from the page and go back again, the default language will be restored.

Conclusion

As a QA tester, I can confirm the overall usefulness of the developer console, especially in my transition from a manual QA into an automated QA, as the need for its utilization becomes more and more crucial for my work. It is a powerful tool that improves the testing processes and delivers more reliable and concrete results to the developers, which leads to higher-quality products as a result.

By using the console to debug errors, inspect elements, monitor network requests, analyze performance metrics, and manipulate data in general, you can count on a reliable partner for optimizing the application in terms of performance and usability. And, of course, with practice and experience, you can become proficient in using the developer console, improving your efficiency and effectiveness as a QA tester.

Radoslav Kosev — QA Engineer at Lexis Solutions