Motivation

Have you ever wondered how websites work behind the scenes? While you don't need to be a programmer to be a tester with us, the ❝Sources❞ tab in your browser's developer tools can be a helpful companion in your testing adventures.

What is the Sources Tab?

Imagine a website as a play. The actors (images, text) and the stage (layout) are what you see, but the script (JavaScript) tells them what to do and how to interact. The Sources tab lets you view and explore this script, even if you don't understand the code.

Getting to the Console:

Open your browser and visit any website.
Right-click anywhere on the page and select ❝Inspect❞ or ❝Inspect Element❞ or hotkeys Cmd + Option + I (macOS) or Ctrl + Shift + I (Windows or Linux).
This opens the developer tools. Look for a tab labelled ❝Sources❞ and click on it.

Parts of the Sources Tab:

File Tree: This panel lists all the files used to build the website, like scripts, images, and styles. Think of it as a program with different parts working together.
Code Viewer: This is where you see the actual JavaScript code. While you need help understanding everything, look for patterns and repeated sections.
Console: This is a separate panel where you can type simple commands to interact with the code and see the results. It's like experimenting with the script during the play.

How Can Testers Use the Sources Tab?

Finding Hidden Elements: Websites sometimes hide elements based on certain conditions. The Sources tab can reveal hidden elements and their code, helping you test if they function as intended.
Checking for Errors: Errors in the code can cause unexpected behaviour on the website. The Sources tab often displays error messages, giving you a heads-up on potential issues you might encounter during testing.
Understanding Functionality: While you don't need to become a coding expert, the Sources tab can provide hints about how the website works. This can help you create more comprehensive test cases.

For instance, you're testing an e-commerce website, and the search function displays a duplicate category in the search suggestion list. When you click on one, the user navigates to a 404 page, while the other successfully takes users to the expected collection page.

Understanding why this is occurring not only helps us identify the type of bug (is it a content bug as the category is duplicated, or is it a low functional bug as a linking problem in a navigational feature or because one of the categories works?); the correct compromised feature (is it the problem on search the search suggestion list or the search results page? Remember that these three are separated but closely related features) and the correct severity, low or high (this is not a blocker; hence we dismiss critical).

Using the source tab, we can compare the predefined categories on the search suggestion list based on the compromised file and the one that leads to the 404 page.

Within the source, in the code view on the right side, we can see that the problem is shown as a JSON file structure.

JSON stands for JavaScript Object Notation. It's a lightweight data-interchange format that is easy for humans to read and write and for machines to parse and generate. JSON is often used to transmit data between a server and a web application, serving as a standard data format for APIs. Although it originates from JavaScript, JSON is language-independent and can be used with many programming languages. Virtually all modern programming languages have libraries or built-in functionality to parse and generate JSON.

Here is the JSON snipped of the 404 category:

{ 
 "data":{
  "urlResolver":null 
 } 
}

There is no information to exchange; hence, there is nothing to show, and the response is a 404 because when the urlResolver field is null, typically indicates that the backend could not resolve a URL or reference for the item selected from the suggestion list.

This usually happens in a few scenarios:

Nonexistent Resource: The item category selected refers to a resource that no longer exists or was never correctly set up in the backend. This could be due to outdated or incorrect data in the search index.
Backend Error: The server might have encountered an error while trying to retrieve the necessary details for the requested resource. For example, a database lookup might have failed due to an inconsistency or temporary unavailability.
Misconfiguration: The backend route or the resolver logic that is supposed to handle the request and return the appropriate data might be misconfigured, preventing the correct resolution of the requested item.
Incorrect or Missing Parameters: If the suggestion relies on specific parameters being passed from the frontend and these parameters are missing or inaccurate, the backend might not be able to resolve the resource.

With this information, we understand that the problem lies in the backend and is more than just a missing page. To fix such an issue, checking the server logs or reviewing the configurations related to URL resolution and routing is needed; the problem can also be linked to stale or incorrect data in the b index, and updating or reindexing the search data might be necessary (understand stale content better here).

Now, we can confidently dismiss the possibility of this being a content bug because the issue is not just a duplicated category or a broken link; the problem is also not a linking issue in a navigational category only. Despite the existence of a workaround (one of the categories with the same name redirects users to a related page), backend issues can escalate and compromise the entire system; hence, a high-severity bug can be determined.

Bonus Tip: Ensure you thoroughly investigate and properly document the bug in your report, including a well-documented screencast, to report the issue effectively and improve your testing skills.