By Sarah Fittje
And we’re back with round two! This second part of my series on QA best practices will cover some more technical aspects of the daily routine in Quality Assurance. In addition to a few words on browser dev tools and API testing, I’ll provide you with some tips I consider useful when investigating new bugs.
So without further ado, let’s get started!
Related and Unrelated Bugs
Have you ever heard the sentence “This is not related to my ticket!” when handing over a bug report to a dev? Well, it might be justified. As mentioned in my previous post, you need to determine whether a newly occurring bug is related or unrelated to the issue you are currently testing.
Whenever testing a feature or a bug fix, new problems might occur. And these problems need to be filed and fixed. To avoid unclear lines of responsibilities from the outset, it’s important to distinguish between related and unrelated bugs within your bug reports.
Related Bugs
Related bugs are related to the ticket currently being tested. They are caused by changes to the code associated with the feature or bug fix branch (hereafter referred to as issue branch) and thus do not occur on the master branch. These kinds of bugs need to be fixed in the course of the currently tested ticket.
Unrelated Bugs
Bugs which are not caused by changes to the code are unrelated to the current ticket. These kinds of bugs have to be reproducible on the production system as well. Unrelated bugs should be reported in a new ticket.
How to Find Out Whether a Bug Is Related or Unrelated?
In order to check whether a bug is related or unrelated, you can use a technique called “comparison testing”. This means that you perform the same test on your issue branch and on the master branch. If the bug only occurs on the issue branch, it’s related to the current ticket.
If you have a production system on which you can test without hesitation, you can perform comparison testing without any overhead. If you are restricted regarding specific actions on your production environment, you should ideally have two instances on which you perform tests in parallel. Otherwise you will have to deploy both branches (issue and master) successively on the same instance.
Browser Dev Tools
Browser dev tools are QA’s best friend. They give you information on errors and activities in the background of an application.
Network Panel
The network panel lists all requests and resources that are loaded on a page. Usually, we are most interested in requests, so we can select XHR in the filter bar to reduce the list of items.
Each request can contain a payload and a response. This basically depends on the HTTP method that is used for the request. A payload is sent to the API with a POST request. This is, for example, the case when a user registers on a page. All input data has to be validated and saved in the database, therefore it’s POSTed to the API inside the payload. For form validation, ideally the concept of AJAX (Asynchronous JavaScript and XML) is utilized. It enables the browser to exchange data with a server and to accordingly update parts of a web page without reloading the full page.
In contrast to a POST request, a GET request is not supposed to contain any payload, because it retrieves data from the API instead of sending it. Thus a GET request will mainly provide you with a response that contains data from the API.
Elements
I mostly use the Elements tab to find out an element’s name in order to be able to speak clearly to developers. Furthermore, it’s obviously needed for test automation and you will find all meta tags in the HTML header.
Console
The console comes in handy when dealing with frontend-related errors. All errors and warnings will be displayed here. For some projects, it even makes sense to retrieve additional data from the website or interact with the website’s elements.
Resources
Information on storage and cookies is located in the resources tab, which, for instance, is useful if you need to delete certain storage entries or cookies. This might be necessary in order to test a scenario multiple times or to test a specific storage entry or cookie, which could be something like hasSeenExitIntent — true. If this entry is deleted, the exit intent pop-up will behave as if it hasn’t popped up before.
API Testing
Since frontend developers usually ensure that invalid actions are forbidden on the frontend side, these have to be tested differently. Fortunately, there are some tools we can utilize for that purpose.
The easiest way to go is to use an API documentation tool like Swagger, which enables you to fire requests against the API. Tools like Swagger will provide you with an overview of all available requests. For the request parameters / payload you can either use a JSON string or provide the required data via the input fields. If you’re looking for a free option, you should take a look at Postman. What’s less convenient about Postman though is the fact that you need to create and save all requests manually. If you have an affinity for consoles, you are probably already using cURL.
How to Find the Correct Request
As soon as you perform the action to be tested in the browser, the specific request (and maybe some others as well) will pop up in the network panel. In order to directly find the correct request in the list, you might want to check the request’s URL by hovering over the request items.
Testing the API directly — without frontend validation — will help you to find out whether the API allows actions which should be prohibited due to privacy issues or which might break your system.
Frontend or Backend Bug?
If you work with frontend and backend devs it’s always advisable to determine the root cause of a bug before bothering them. Otherwise you might keep the wrong person from working.
Sometimes it might seem easy to decide whether a bug is related to the front or backend. For example, if there is an error in the 500 range, you might think “Oh yeah, that’s a server error, so it’s backend-related!” This might not be the root cause though. Sometimes the frontend is sending wrong data within the payload, which then causes the API to return an error. In that case, the API is behaving correctly and the bug is caused by the frontend.
However, sometimes it’s pretty hard to determine the root cause of a bug or both, front and backend, are involved in causing the bug. In these cases, it’s always good to have a dev with competencies in both fields, who can help you to find the root cause.
But of course there are also easy cases. A generic frontend error normally pops up in the browser console, presenting the error stack trace:
Aside from that, third-party software may cause errors in your application. In these cases, you’ll usually find the name or URL of the respective software inside the error message. Bugs caused by third-party software can again be related to the front or backend respectively.