"Back" to move forward

I. Xavier — Thu, 09 Jul 2026 14:58:46 +0000

Sometimes, it’s essential to return to the beginning to clear your mind. Last month, I took a 15-day vacation, and I really needed to reset my thoughts. Working as a QA requires a great deal of attention to detail and accuracy with specifications, among other things. So, I decided to revisit my origins as a technician: I purchased an Arduino and started coding on it. No OOP, no LLMs — just turning LEDs on and off, buzzers, analog buttons, and executing simple commands. This made me feel really good. Occasionally, we need something uncomplicated to help "the brain smile" to relax and reset our minds.
You might wonder why I’m sharing this. Well, if no one has told you, here it is: take a break. Engage in something simple. We need to achieve small things and remember how to create basic items to feel okay.
When I mention "creating simple things" or "achieving small things," I’m not just referring to studies and projects related to tech work. Build a Lego set, ride a bike. Move your body. We aren’t machines. We need to reconnect with our roots and remind ourselves why we chose this journey.

Take a step back, breathe. Do something new (or revisit something old), and then move forward.

4 Steps for a good BDD

I. Xavier — Tue, 02 Jun 2020 13:44:37 +0000

First of all, we need to keep in mind that BDD (Behavior Driven Development) is a form of agile software development and that the main objective of BDD is to establish an easy way to communicate the idea to other people. Developers, testers, investors and customers
can understand and discuss software requirements, to create a clearer test and validations to obtain a good product/service with fewer defects.

The structure of BDD is:

Scenario: a title of your requirements;
Given: the state of the system that will receive the behavior/action;
When: the behavior/action that happens and causes the result in the end;
Then: the result caused by the behavior in the state;

"Ok" - you may think -"so... there's no error in this methodology". Well... not yet. If you are too simple or too detailist you take the risk of not reaching the right point of your issue.
"And how do I reach the central point of my cases?". Well, I got these steps:

Step01 : A good Scenario 🖼

Try to create accessible scenario. Paying attention to the most recurring situations and requirements is a good way to guarantee the integrity and quality of your software. Create scenarios that are easily identified as "Success" and "Failure" because this will help the user to see through the objective.

Step02: a simple command has a simple response ⚖️

To execute a scenario, lowering the complexity of the action makes the test more comprehensible and helps the person behind the test o understand the response a little better.

Step03: don't be too much ❌

In addition to avoiding creating very simple or very complex test cases, it is important to create test cases that are recurring. Always prioritize the main actions of your software to guarantee the delivery of the main functions. With the main functions tested, you will be able to spend more time with less recurring actions.

Step04: let the answer guide the way 🗺️

Before all these steps, make sure that the answers will make sense with your main objective. Collecting and analyzing responses are points of important attention as these are the ways that will inform your team if the final product needs to evolve and where it needs to evolve.

Well, that's it guys.