Using browser dev tools to improve testing

-
One of the first questions that I usually hear from testers, when talking to other testers is "Which tools do you use <to do something>?". During our local meetups here in Norway, conferences or larger gatherings, or even at work between teams, this questions seems to be quite central and important to many testers, judging by how many times I have heard it. Some tools could improve and broaden your "testing-repertoire" but even though one should not be too dependent on a given tool or be tool-centric, this toolbox can be quite useful, and I seldom hear that someone mentions it when talking about tools used for testing.

The toolbox that I'm aiming at here is the Developer Tools toolbox that are bundled with all major browsers. I usually mostly use Chrome, so that is why I will, very shortly, present how and why I use the tools in the Chrome Dev Tools, but you'll find either all or most of the features/functionality in other browsers as well.

So what are these Dev Tools?
Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. DevTools can help you diagnose problems quickly, which ultimately helps you build better websites, faster.
https://developers.google.com/web/tools/chrome-devtools/

Could it be that many testers read this and think, these are developer and not testing tools, as stated in the description, and do not give them a chance or try them out? If so, please disregard the description, and give them a try.

The Dev Tools toolbox consist of a set tools, which are divided into different tabs, which you can access by pressing F12 in your browser. The tabs are;
  • Elements - gives you ability to inspect a web page, find and edit HTML, CSS elements, properties, view event listeners. This was probably the tab I started to use first, in order to find elements on that I wanted to manipulate in order to write automated tests in Selenium/C#. You can use this to check how the page is built up, which elements are visible/hidden, and whether you can manipulate visibility of an element in order to access some functionality that is not supposed to be available yet.
 
  • Console - view logs/messages logged by a web page and interact with the page using JavaScript. Here you can catch different errors or warnings to get a better understanding of what is not loading as it should have been. Here you can also in some cases overwrite functions and manipulate them do produce other outcomes than the original function. You have probably seen high scores in browser games which have an impossible high score of "999999999", this is likely achieved by overwriting the score-calculation function (or even worse just overwriting the label before it is sent to back-end). If you want to cheat some older web games then console and some JavaScript knowledge can probably help you with that. 

  • Sources - see which sources are loaded, read/edit these sources, inspect the web storage and cookie caches. I usually use this to check what is loaded, traverse through the code in some cases to get a better understanding of the page and different functionality, and if there something that is exposed which should not be. After reading these sources, you can go to the Console tab and overwrite these functions, if you would like. In the Sources tab you can also create small snippets, if there is some code you use often and would like to run on multiple pages, so you do not need to re-write these. Recently Google also introduced Overrides functionality which is located here, which enables you to store files from that are usually loaded from the web server (which we perhaps do not have access to, or do not want to manipulate), store these locally and manipulate these before setting that the web page override these files and rather use the ones from local disk each time you reload the page, than the files from the server. Just be aware of when you have enabled this, so that you do not end up reporting false positives. You can also watch the introduction of this feature here, from the 3rd minute or so in the video - https://www.youtube.com/watch?v=7-XnEMrQnn4

  • Network - inspect and monitor requests and responses from network and browser cache. Look at all sources that are loaded when a page loads, in which order, how much time each request/response takes. This can point you in the right direction of which requests are the slow to load. I do not use this tab that often, but it is great to use if you have some network performance issues (as well as the performance tab). 

  • Performance - profile the page in order to analyze your sites responsiveness, JavaScript and layout performance. Here you can measure the execution time of each element on your web page, check which part is loaded in which order. You also get a good overview of what processes are using most of the time when page is loading, and this can help you localize your bottlenecks. For example if rendering the page takes 70% of the time the page takes to load it could be a good idea to investigate this further. This is also not used on a daily basis but if we need to investigate slower performance, this will be a natural place to start, or if we are testing new pages where this have never been run, I would profile the page over a period to learn more about it's performance. 

  • Memory - profile memory usage and track down leaks. This part of the Dev Tools I have not used actively, so my experience with this is limited. You use this to profile and find out how much memory your page is using and visualize the memory usage over time. Probably worth investigating in the future.

  • Application - Inspect all resources that are loaded, including IndexedDB or Web SQL databases, local and session storage, cookies, Application Cache, images, fonts, and stylesheets. Here you can check what is stored in local, session storage and cookies. You can see what attributes a cookie has set, if it has HTTPonly, or Secure attributes set. You can also manipulate the cookies, IndexDB and play around with attributes set there.

  • Security - this helps you understand different security issues, and highlights what is secure vs non-secure. If you have some issues with certificates, it will be shown here, or if something is loaded from a non-secure or unknown source. It is pretty straight forward, and usually when investigating and looking for security issues, I use this tab to give me a first impression of the web page. 

  • Audit - this part was also added not that long ago, an open source tool called Lighthouse, now enabled through the Dev Tools tab "Audit", which is an automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, and more. When running the audit it gives you a nice dashboard overview with different scores on each of the areas, Performance, Progressive Web App, Accessibility, Best Practices, and SEO (Search Engine Optimization). Based upon some audit criteria you get a report on what is good on the page, and also what has potential to be improved with direct suggestions of how to improve these. A really nice feature.

In addition to all these tools and features, you also have the possibility to view your page in different resolutions, imitating device screens, gestures, also throttling network to simulate different network conditions, which is quite useful if you want to test how your site will behave on mobile devices, and in, let's call them "real world scenarios".

So why do I use these tools? Simply because they help me to better understand how our service, and web pages that are presented to our end users work, from another perspective, and that they give me the ability to manipulate them in other ways than if I were not to use these tools. They are easily available in all browsers, free, rich in functionality and easy to start to use, what more could I ask for?

These tools are free, and are right under our noses, but I do not see or hear that they are being used in the daily testing, which I believe they should be, for anyone developing software with a web interface. I tried to give a quick and dirty introduction to these tools, and how I use them in some quickly explained scenarios, but I know that there are many features and scenarios that I have not covered in this introduction. All the Dev Tools have really nice tutorials on their respective pages, and there are many presentations that can be found online.

Hit F12 in your browser and start exploring these awesome tools that can aid you in your daily testing. If you would like to look more into Dev Tools in different browsers take a look here:

Comments

Post a Comment

Popular posts from this blog

How do I stay "up to date" on software testing related stuff?

-
Image
"Up to date" can probably be debated as development in our field change quite fast, and what was ground braking yesterday, fast becomes old news today. I try to read as much as possible, and this usually vary from week to week, day to day due to other obligations, but I squeeze in some hours each week. This is mostly done on the evening, on the way to and back from work, and at work when I have 5-10 minutes until a meeting starts, and I can not start on anything new, I spend that time picking up a blog post or two, and traversing through it. There is a set of blogs I follow, these are mostly from other practitioners in the field software testing / development. All of them are organized in different folders in Feedly , which I use to aggregate the blog posts, news, and other information. Here is a screenshot of the structure that I have. Testing folder contain most feeds from about 50-ish sources, and I have separated some of the blogs into AutTesting (Automated Test
Read more

Shifting left, shifting right - where to shift next? - part 2

-
2010 - a full year in, "if testers are not involved early, we do not want to be involved later" After being employed full-time for a year or so, we finally completed a full circle of releases, both the major releases involving a full scaled up beta/pilot program, and some minor releases, as this was taking place on a yearly basis. After each ended project, a small group of people from different teams formed a retrospective team, to go over what was done good and what could be done better next time, for all projects individually but also as a whole. This was before any agile methodologies were introduced. During the retrospective, or post-mortem analysis I think it was called at the time, we from the test team argued that we were not involved early enough and that we ended testing specifications that were well out of date due to our late involvement. This was taken into consideration and that from next phase we were to be included in all start up meetings, and walkthroughs
Read more

Does the language we speak shape the way we think?

-
This week I have been looking a bit into whether language(s) we speak, shape the way we think? Being raised up bi-lingual from the age of 8, where I spoke mostly Bosnian and Norwegian with a good addition of English, this is quite an interesting topic for me personally. Inspired by a talk from Lera Boroditsky from TEDWomen 2017, who had done a lot of experiments on this, here is what I found out. If you find this interesting, I encourage you to take a look at the presentation, many examples that I mention here are taken from her talk. 7000 languages, different way of thinking? There are about 7000 languages, each different from one another, in many ways, different sounds, different vocabularies, not at least different structures, to mention a few differences. Whether a language affect how we think has been debated throughout the centuries. "To have a second language is to have a second soul", stated Charlemagne, which is quite a bold statement suggesting that language is
Read more