DEV Community: Gabriel Mathias

Bubble Sort Algorithm

Gabriel Mathias — Sat, 14 Dec 2024 23:48:33 +0000

The Bubble Sort is an algorithm that sorts the array from the lowest to the highest value. Learning it is quite useful when starting to learn about algorithms, even though there's not many use cases for it.
My goal here is a full comprehension of the algorithm and be able to explain how this works and how I implemented that.
It has a O(n²) complexity on average Big-O Chart Complexity, but it is reaaaally fast when you have an Array that is nearly sorted.

So how it works?

We loop through the array as many times as it has values inside it, so...

One value at a time;
If the current value is higher than the next value, we swap them. The highest values will come last;

Here's possible to check that with the first passing through, the number 9 changed its place with the number 1, and all the other values stayed the same.
On the second loop, something like that will happen:

[3, 1, 9, 10, 23]
[1, 3, 9, 10, 23]

And we're done, our array is sorted.

Coding

You remember what I said before that the loop will go through as many times as it has values inside the array, so it is equivalent to the array size. But we also have a wise way of implementing the bubble sort in a way that, with nearly sorted arrays - like ours - the loop will stop as soon as no more items were sorted inside it.

### basic version
array = [3, 9, 1, 10, 23]

looping = array.size - 1 # The index starts at 0, so we fix the size for that

looping.times do |current_loop|
  (looping - current_loop).times do |index| # Having nested loops makes it a O(n²)
    if(array[index] > array[index + 1])
      temp = array[index]                   # Create a temporary variable to hold the value.
      array[index] = array[index + 1]
      array[index + 1] = temp
    end
  end
end

### optimised version

array = [3, 9, 1, 10, 23]

looping = array.size - 1 # The index starts at 0, so we fix the size for that

looping.times do |current_loop|
  swapped = false

  (looping - current_loop).times do |index| # Having nested loops makes it a O(n²)
    if(array[index] > array[index + 1])
      temp = array[index]                   # Create a temporary variable to hold the value
      array[index] = array[index + 1]
      array[index + 1] = temp
      swapped = true
    end
  end

  break unless swapped # We stop the loop as soon as any changes have been made
end

p array

Java version:

import java.util.Arrays;

public class Main {

    public static void main(String[] args) {
        Integer[] array = {3, 9, 1, 10, 23};

        int size = array.length - 1;
        // Times that the loop will happen
        for (int i = 0; i < size; i++) {
            boolean swapped = false;

            // Compare and swap
            for (int j = 0; j < size  - i; j++) { //
                System.out.println(Arrays.toString(array));
                if(array[j] > array[j + 1]) {
                    int temp = array[j];
                    array[j] = array[j + 1];
                    array[j + 1] = temp;
                    swapped = true;
                }
            }

            if(!swapped) {
                break;
            }
        }

        System.out.println(Arrays.toString(array));
    }
}

Another useful resource about Sorting Algorithms is this website that "[...] illustrate how effectively data sets from different starting points can be sorted using different algorithms."

Feel free to add any suggestions and comments.
Thank you 👋

Black Box Testing

Gabriel Mathias — Thu, 05 Dec 2024 16:58:05 +0000

Software Testing is not about - just - finding bugs. Certainly it is important to catch them. But, at the end of the day, the most important aspect is to have a useful software for your end-user. Business is about having customers consuming your product, right?
So, always keep in mind that when you are testing (or building) software, some functionally can look obvious to you or to how you use it, but not to the end-user.

What is black box?

It is a system that produces results without the user being able to see or understand how it works. - Cambridge Dictionary

In a testing perspective, it serves us to check how an app works from a non-technical end-user point of view, so basically, how a user is actually USING it or how it was SUPPOSED to be used.

The tester checks the software functionalities without any concerns of internal details or implementation strategies. They simply provide the input (by initiating different user actions) and observe the output (response time, usability, reliability) generated by the system.

That's why it's important for the tester to know the end-user, maybe have a talk with them. A solid knowledge about the end-user is key.
The tester doesn't need to be part of the development team if he knows what are the system specifications and requirements of the app to work.
This test can cover a lot of aspects but the primary intention is to check the
outputs without considering what's happening after the inputs.
I highly recommend someone that at least knows what is going on with the product or have a certain experience using it, just knowing the specifications may be harmful in some situations when the system is an ERP, for example, and even the customer uses just a few functionalities inside it in a day-to-day basis.
From my perspective, not knowing anything and going completely isn't ideal, since perceived errors are prone to happen when actually it wasn't an error after all, "Hey I am not sure if clicking here was supposed to open this window instead of that one".

When to use it?

A black-box test incorporates different forms, The most common ones are testing its functionalities, how is the user interface in a variety of platforms, with user-eyes and focusing on its usefulness... so, functional, UI, usability and ad-hoc tests, technically speaking.
They help building a complete coverage and eliminating possible risks on the app, checking boundaries and simulating real-world scenarios.

Techniques

Black-box testing employs some techniques to have a great test coverage. Mentioning a few:

Equivalence partitioning

Input is categorized into partitions of valid and invalid values.
Example: When checking if a user is older than 18, it is enough to test using a birth date that's under that, and another older, covering both scenarios.

Boundary value analysis

Check the boundaries of input ranges.
Example: When selecting a product, the quantity should be between 1 and 100. So the test cases should revolve around values inside the range and outside it, such as negative values or greater/equal than 100, and of course valid inputs inside the range.

Decision table testing

A technique that captures various input data combinations and their corresponding behaviors in a tabular format.
Let's consider authorization of user when entering e-mail and password.

Correct e-mail	Correct password	Message
Yes	Yes	Success
Yes	No	Incorrect password
No	Yes	Incorrect e-mail
No	No	Incorrect credentials

This is a conditions table, which helps covering all the possible cases.

Some others include: State transition testing, exploratory testing and guessing.

Conclusion

This pretty much covers the essential parts of a black-box testing and its implementation. Please feel free to add any comments and correct me if necessary.

Important aspects of a Bug Report - QA

Gabriel Mathias — Mon, 25 Nov 2024 00:18:17 +0000

Writing a good, concise, and clear bug report can save you a lot of time explaining and reproducing the bug with your developer friend. That’s why I’m here today: to clarify—or at least refresh—your understanding of how to report that not-so-great issue found in a given application.

Keep in mind: Put yourself in the shoes of both the user and the developer. What seems obvious to you might not be clear to them. Sometimes, the best approach is to explain things as if everyone around you were kids. We need to explain things properly (kids always ask “why?”), in a simple way (they’re still learning), and with as few gaps as possible—or ideally none—unless you want them to keep asking “why?” over and over.

Most important aspects

Title, Steps to Reproduce and Logs.

Title

It has to be clear, short and obvious.
"Product quantity input should only accept positive numbers"
"Product quantity input should not accept negative numbers"

Both titles clearly convey what is happening. I would say that the first one is more generic, as the problem could involve negative numbers or floating-point numbers. The second one is more specific, and I would personally choose this one.

Remember: If you can’t make the title completely clear, provide a concise but informative explanation in the summary section of the description.

Please don't do that:
"Product quantity inputted in field X should not accept negative numbers only positive numbers from 1 to 2......."
It is just a title my friend, as I said, create a summary if necessary, the details go after that.

Steps to Reproduce

I dare to say that this is the most important one, where you communicate exactly how you reached that issue. Think like holding someone arms showing the way.

Enter the link abc.com
Go to the field X at the left corner of the page
Insert the value -199
Click on the button "Add to cart"
Product was successfully added to the cart

In this simple example, the issue can be easily reproduced. You talked about where to go, the fields, buttons, where to click and what is expected after the click.

Logs

That is where you attach some evidences denoting the place where you found the bug, preferably highlighted.
Everything that can help and show the problem: screenshots of the webpage, server logs, exceptions.

What else ?

There are additional elements to include in a bug report, such as the ID, environment, version, priority, labels, and attributions. These are essential, and I will cover them in greater detail in a separate article about creating a bug report in Jira. For now, I hope this explanation clarifies the core purpose of a bug report and, ideally, saves you from at least one Google/Teams meeting, allowing you to focus on what matters.

End-to-End Testing with Cypress

Gabriel Mathias — Sat, 09 Nov 2024 10:41:55 +0000

While searching for tools to learn and apply end-to-end (E2E) automated tests, I found Cypress to be quite impressive! My goal was to find a tool that was easy to set up and had a clean user interface (UI) as a plus.

For me, the best way to learn is by doing. So, I decided to automate an order on the Pizza Hub website, stopping at the point of payment, and having the opportunity, I also made a more complete approach on another website visiting and filling all the necessary fields to their job application process.

The code can be found below. I ensured it's easy to read and follow along.
Github Repo - Ordering on PizzaHut

Here's the process automated:

Access the website
Click on "New Order"
Accept the cookies
Fill in blank fields (address, etc.)
Select the pizza
Modify the dough type
Add to cart
Reach the payment page
Check the cart

I tested them both on Chromium (v130) and Firefox (v129).

For the job application process, I ensured to include all the necessary information on the repository, with images and videos to follow along!
Github Repo

There's also some examples of creating and documenting user stories using Jira and Confluence.

Impressions

I've found that the methods cy.get and cy.should were my best friends. Cypress has amazing documentation and courses to get you through everything pretty well and acquire a solid knowledge. I still have a lot to learn!

Pros

My first two impressions of this tool were the real-time reloading and "time travel" features. Every time I saved the code I changed, the test automatically reloaded, making it incredibly fast to check for any possible errors and move on. I was able to examine every step made by the program and the web-app's state at each point. I can't say how much time this saves and how it allowed me to focus on what really matters: what I wanted to test and whether it was working properly or not.

Cons

Well, It doesn’t support WebKit Browsers Engine (Safari) and mobile testing natively. It’s mainly suited for JavaScript applications and involves huuuuge DOM manipulation, which can be problematic for some applications that manipulate the DOM after the page loads.
I also have the feel that certain complex scenarios might slow down the execution speed of the tests. Using more assertions could potentially help with this, but I am not sure since this particular test wasn’t resource-intensive.