As testers, it’s our job to test (obviously) and look for anomalies. In some cases, this can be enough. In order to add value, I would say it is equally important to help identify the problem before presenting it to anyone else. There are various ways in which a tester can help themselves to identify the root cause of a problem.

Here are some of the basic things I have picked up so far throughout my career as a software tester.

I’m going to be using a specific example here to help illustrate my point but these methods can be used in most cases.

Scenario:

Let’s assume we have filled in a form and we are proceeding to click the submit button and something doesn’t right. we may be expecting some form of confirmation or a change of screen. The following are the steps I would go through in order to try and understand if there is an issue and where that issue may be manifesting.

Check the response of the request

This is the first step of any investigation when dealing with a web application. As we are dealing with a form submission? in this case, we can be confident that we are expecting a POST request (for more info in the different types of request we can expect see the following post) if we see that we are using a GET instead of a POST or vice versa this could be where the issue lies.

If we are indeed seeing the correct request type then I would start looking into the response codes. In most cases you would be expecting a 200, If we see anything other than a 200 then this could be where the issue is. You can copy the request link then go and see a developer.

If all checks out we can look to move onto the next step

Check the application to see if the information has been submitted

This step would only apply if we are submitting data and expecting that data to be saved somewhere else. For instance, we may expect the submitted data to be fed to a database. We could check here and see if the data is where we expect it. If not we now have more information about the potential issue.

Check log files

As we move to a more DevOps world, log files are being presented through tools such as Kibana. These tools make log checking a lot simpler. Having said that we can get access to the log files even without a front end. Speak to the infrastructure team about getting access to this sort of data. Once we have access we would be looking for the type of request where we are seeing the issue. We would look for any error messages associated. We may not fully understand what we are seeing (or we may) buy even having this information is excellent feedback.

Still cant find anything?

1. Give the committed code a once over
2. Give the test another run through
3. Check for any lingering cookies or sessions (a very common one)
4. check for any network issues
5. Have a quick chat with the business analyst

The BA on your project is normally in a good position to be able to corroborate your findings regarding the expected vs actual behaviour.

Final thing before creating a bug!

Go and see a developer…

At this point, it’s a good idea to go and see a developer with all of your finding at hand. Even if you don’t find much beforehand, being able to describe your analysis can go along way to speeding up the process of finding the issue. It can also give you a deeper understanding of the issue

At this point, you still may need to create a bug, but this process should allow you to create a much more detailed and thorough bug. It can also give you more reference points to retest once the issue has been fixed.