Let’s start by explaining what a bug is, which will be our ally or enemy from now on.

A bug is basically an error (unexpected behavior, visual error, etc.).
Why do I say it is an enemy or an ally?

One of the ways to know if we are doing our job well is to find bugs in a platform. And we can say that it is an enemy because the more bugs a platform has, the longer it takes us to get it into production.

To better understand the problem, let’s take the following example: we have a warehouse system and in this system, we have a product CRUD where we can create, edit, delete and view the loaded items.

Our job as QAs is to test every field, every function and even everything visual that we can see in the screen we are testing.

Let’s say we are registering a product and the fields are:
We can try things like:
Title: special characters, more than 500 characters, leave blank, etc.

Quantity: enter a very large number, negative number, number with decimals, letters, etc.

Price: enter letters, negative numbers, special characters, etc.

The idea here is to try to break the application as much as possible, so if the field is a quantity field, it makes no sense to enter letters. It seems a bit obvious, but you have no idea how many bugs like this are found in applications. Often, in the rush, developers forget to put validations in the fields.

I know what a bug is… What do I do now?

This depends a lot on the project we are working on, the time we have and so on. But assuming that this is an ideal world where testing starts with the project, i.e., development starts with our testing, then we will create a test plan with test cases. This has the advantage of creating documentation that shows the scope of the testing, and which things are tested and which are not.

If the project is already developed and testing is needed in a short period of time, we can opt for other testing strategies, such as exploratory testing, which consists of browsing the application in search of bugs. The bad thing about this is that we have no way of documenting what we did and did not test.

In another post I will discuss what test plans are and how to set them up, as well as test cases and the different test strategies.

I found a bug! How do I fix it?

In any software development process, it is very necessary to have an issue tracker (Redmine, Jira, etc.).

The issue trackers are not only used to document the functionality of the application, but also to report every bug found.

Whenever we report a bug, we need to be as clear as possible when reporting it, i.e., we need to document well what kind of bug it is, steps to reproduce it, etc.

Next, I will give you a template that I usually use when reporting a bug.

ID #: Unique ID for each bug. Issue trackers set this automatically.

Title: I usually put the name of the module that has the bug in square brackets.

Description: A short description of the bug.

Prerequisites: Do I need special access or permissions to reproduce the bug?

Reproduction steps: step-by-step details of what I need to do to reproduce the bug.

Current result: explain what is currently happening.

Expected result: explain how it should work.

Screenshot/video: a screenshot or video showing the bug.

Priority: How serious is this bug for the company?

Assignment: Assign the issue to the developer who created the feature.

In general, we usually use the following template for bug reports, where you can see full instructions on how to report bugs and an example.

I hope you find these tips useful!