Subscribe me on new discussions

5 reasons why you should use DevTools for testing

Views: 1918

As we all know, testing is very useful and must be used on all kinds of projects to guarantee the proper level of quality. Being a tester nowadays means being a "Guardian of Quality", who will bravely find the nasty bugs and help to exile them from the product forever. And there are a lot of different ways to do this, plenty of different types of testing, testing tools, etc. Today we will talk about using DevTools for improving your testing skills.

If you are a Junior QA, you probably mostly concentrate on what you can do with application's UI: create, edit, delete something, etc. But more experienced QA's almost always have browser DevTools opened while testing, and there are a number of reasons why:

#1 Mobile browser emulator

If you really need to test mobile view (only view in terms of resolution, not mobile app), but you do not have any devices - you can easily test using "Mobile" option in your DevTools (browser emulator). It helps you to emulate most of the devices you need. This feature is really useful, especially if your application is a Web Mobile app. In this case, you can perform all your major testing on the browser emulator, and after that only check UI on the most critical mobile devices. Here is how it looks like:

#2 Playing around with HTML & CSS

There are cases, when  you need to test how a large piece of text would look like on your Web application. But you cannot edit some text on the page. That's when you can edit page HTML and see what happens:

This is only one example of all the stuff you can do in the "Elements" section. More options for you:

  • Inspecting elements (e.g., finding image source, if a video is missing - you can see if it's uploaded to its source or not; you can play around with styles, text colors etc.)
  • Verification of really specific UI requirements (font size - you can check it in pixels, font style, icon width/height/position and many many more)
     

#3 Checking out application requests and response structures for API testing 


If you know a thing or two about backend and API testing, you might need to know which request is being sent and with what data in certain cases, in order to test purely the backend part. You can check this in DevTools -> "Network" tab. 
 

#4 To win the hide-and-seek game with bugs :)

Some defects hide from you! And you can't really find them unless you check browser console. For example, this is also a bug:
 

It's a bug because you shouldn't have any errors in your application. An error means that something is not working correctly.

#5 Defect investigation & root cause analysis

Sometimes the page crashes, or some unknown error appears, or something else goes wrong or doesn't work. For example, "Experience" field does not have a limitation. You think it's a minor defect with low priority, right? Wrong! Because if you abuse that field, you will get an internal server error (code 500) in response, and the page will crash, and such things should never happen for your user :)

I have only listed these 5 reasons because that is what I mostly use browser DevTools for. Of course, this list is not exhaustive and goes on and on. But if you want to be a successful tester - please, take my advice, and keep those browser DevTools opened while testing! (F12 key ;))

Happy bug hunting!

Karma: {{ total }}
Published: 6 years ago by Ivanna
QAProvider Team at 2019-06-10 17:55:17
Karma: {{ total }}

We have seen your test with big data post from last screenshot in our log files :)

You did a really perfect job!

We can add here a little bit more from our point of view.

Maybe it is not a problem of user experience. It looks like that, isn't it?

Some of testers/developers/users might think there is no problem here. We know that real users will never put a lot of data in the field "About me".

But!

For the guys who want to break the server - it is a good hole.

So, what the problem here?

On the screenshot above we can see a log size (10 June second one). When you did a post action it generates error and this error has been logged in the log file. It puts all the data from your post request, it is about 1 MB from your example. Let's use 1 MB.

Now, imagine that you prepared a script that does 1000 requests to the server with the same post data (easy task for student). This actions will generate a log of 1GB.

So, when our server will use all the disk space? It depends on our hosting plan :)

And what will happen when disk space is over? We think you all know what will happen with the server and the web site.

Ivanna replied to QAProvider Team comment at 2019-06-10 17:57:18
Karma: {{ total }}

Great point! Thank you for adding it :)