Backtracking in general
The word itself describes the process. If we smell something erroneous and would like to know why this is happening and for what reason, usually, we will go back to the traveled way and find where it starts or what is the exact problem. In simple words it means .... Detecting the problem with exact root cause...
In a software testing context
Identifying the issues is the main essence and is a must-have skill for a tester. Based on the experience level bug identification skills might be different.
Back Tracking of issues?
In the world of software testing, a tester's primary job is to identify the issues. Yes, of course. But, how the issues are being identified before reporting it to the developers vary based on the experience he/she has obtained. As a novice, if they encounter any inconsistency in the test flow, they can view it in the UI layer and report to the developer.
Once the issue is raised in the ticketing system, the developer might have to spend a lot of time to identify the exact root cause of the issue, if the issue has only basic information. From my perspective, I would always like to report the issue with the exact root cause where it lies. This shows the strong understanding about the feature/module you are working on.
Software in general has three layers.
- UI Layer
- Web service Layer
- Database Layer
Based on the business process, architecture may vary.
Let's take a very simple example:
Functionality testing
Graphs are implemented in a specific module to show some statistics.
As a process, based on the test cases, testers will start the test execution. After data population, one bug is cropping up in the UI.
![]()
Just raising the issue like “Data is not showing up in the UI for such and such scenario” will not help the developer to identify the exact root cause.
Backtracking of issues in depth view
In UI Layer
Due to the following reasons data might not appear in the UI layer.
- Binding issue
Web service is returning the response with expected values, but due to improper binding, data might not be shown in the chart.
- Look for the console error, if any
While plotting the value in the graph, console error may appear. By using developer tool window, you can identify if any error appears.
![]()
- Browser issue.
Application under test cannot be supported by the browser where the test execution is happening.
- The exception is not handled properly
Lack of exception handling in the application. I mean, the exception is handled on the server side and service is returning the same whereas that is not bound properly in the UI.
- The proper validation message may not be shown in the scenario.
Service Layer
After the investigation in the UI layer in above mentioned scenarios, backtracking should be carried over in the second layer “Web Service”.
In this case, let’s consider, REST web services are being used.
- We need to identify which method the web service is using GET or POST.
- In case of GET method, first we need to consider the header information which is being sent from the UI. Whether the correct header information is passed through the headers.
![]()
- In case of POST method, consider the request payload information which is being sent from the UI is correct.
![]()
Database Layer
The database is the collection of data in an organized manner. All the data before and after processing are persisted properly in the corresponding tables.
Log Files Validation
We can cross check the log files, if any information is captured related to the scenario.
Conclusion
Issue backtracking is an art and we will become experts through experience. This shows the strong knowledge one possess about the product/project which they are working on.