Technical Exploratory Testing – Using Dev Tools – Callum Akehurst-Ryan's Testing Blog

Technical Exploratory Testing – Using Dev Tools to look under the hood

One of the best things that I’ve learnt to improve my exploration, and make it more technical, has been to use the dev tools to “look under the hood” and see API traffic between the front and back end. Being able to use the dev tools to chase data was a really easy thing to level up my testing and it’s allowed me to:

Help debug issues better
Be seen as more technical
Work better with developers

Talking about APIs with Ramone the Testing Otter

An API is a way that software components talk to each other. One component will send a request (calling for information, sending information or sending instructions) via the API and get a response from the other.

On a web page the front end will make calls via an API to back end services or servers to get information or will send information that’s submitted. Let’s say you log in to a website, the details you enter will be sent to the back end via an API when you click submit.

Chasing the data

As a tester I want to know that what the UI shows me is correct (or what I’ve sent from the UI is saved correctly). This usually means looking at the UI, sending things to be saved and checking the database. But what about the sending of data in between?

We can check the API traffic, the requests and responses, to see what the UI is sending to the back end and what the back end is responding with. This is great to check the accuracy of requests, see any data that’s not saved to a database and see what’s sent and returned when we cannot directly access the back end.

I can also check the speed of requests, whether they were successful and see any errors that are happening; all useful things when trying to explore how good something is.

Opening the dev tools

Opening the dev tools is really easy. On Chrome and Firefox, just right lick anywhere on a web page and select “inspect”.

Fig 1. The Inspect option when right clicking on a web page opens the dev tools.

This will open the developer tools on the right hand side of the page in its own column. You can configure where the developer tools are displayed (even having them pop out of the browser in their own window) but by default they appear on the right.

The developer tools give us access to loads of information:

Elements: shows the page code
Console: shows logged messages and errors as the software is used
Network: shows the calls made via the APIs
Lighthouse: (Chrome only) in built tools for testing front ends for Progressive Web App status.

To chase the data we want to open the Network tab.

The network tab

The network tab gives us a number of filters, a visual representation of traffic performance and then a list of the calls that have been made in order.

Fig 2. The network tab as seen on the Chrome browser developer tools.

Each time we make a call via the frond end to the back end (like moving page or submitting a form) a call will be made and can be seen in this list of calls. We can click on these to open them and see the details in them.

Fig 3. Opening a traffic call to see its data.

Opening a traffic call creates another column in which we can see more tabs:

Headers: shows where the call is being made to, status of the call and type of call.
Payload: shows the details of what was sent in the request from the front end.
Preview: shows the details of what was sent in the response from the back end (in a more human readable format).
Response: shows the details of what was sent in the response from the back end.

LET’S LOOK AT A TRAFFIC CALL

Here is a traffic call from a Ministry of Testing search of the word “Callum”.

Headers

Fig 4. Traffic call headers.

Request URL: where the query is being sent to is https://www.ministryoftesting.com/search?q=Callum&button= which matches the main URL of the web page.
Request method: is a GET, which makes sense as we’re requesting information.
Status code: is 200 which means it’s worked fine. See a list of API response codes here.

Payload

Fig 5. Traffic call payload.

In the payload (the request we’re making to the back end) we can see the q: was otters, which matches what we’d input.

When we’re testing we can check for the accuracy of what’s being sent to the back end. Was everything included? Was anything changed unexpectedly? Does anything get added that we didn’t expect?

Response

Fig 6. Traffic call response.

For this query the response is the page html which we can look at to see what’s come back. For other calls we make we might get a JSON response of data as opposed to html and we can look at that data directly.

Being able to see the html or the data that’s been returned by the back end allow us to do all sorts of exploration and testing. Has everything been saved? Is everything returned shown on the UI? Is anything missing?

Preview

Fig 7. Traffic call preview.

For this query the preview renders the html that’s been sent (missing any page css that hasn’t been inherited). This is another way of reviewing the response to see what’s been sent back from the back end, we can then compare this to what the browser shows us.

When the response from the API is a JSON response, the preview will format this into a nice human readable view. We can use this to easily check the response data and see if it’s what we expected and then look at how the UI uses this.