Think as… a Dev

From QAs to QAs & Software Developers

In the day to day of a Software QA Engineer, many ideas make our tech skills grow; ideas that come to us through courses, webinars, workshops, or simply from experience. This new knowledge enables us to be more effective as we learn different test approaches, testing techniques, or new methodologies. We are referring to practices such as Shift Left or Continuous Quality, but in this article, we want to let you know about a new paradigm, a new challenge. Maybe you have heard of it before; it’s not new, but certainly, it is gaining more and more attention, especially when working with high-performance teams.

We are talking about the developer side of a QA. In this article, we want to explore how we can take that side and leverage it, how to take advantage of it, and how to use it to improve the QA process in high-performance teams.

Where does this idea come from?

Nowadays, even in small companies and small projects, it is pretty common to have a QA mindset spread across every team member, especially when working on interdisciplinary teams. That means every member is involved in the QA process and has a responsibility for the product under development. This mindset has several advantages while creating software because it enables developers to think in test scenarios rather than just checking that the software works.

But… Why not think the other way around as well? Why not ask QA Engineers to have a developer mindset? Hmm… interesting! This brings us to a new door, and several questions come up, such as:

• How much can a QA Engineer think as a Developer?
• What does a QA Engineer have to do to achieve this new goal?
• What do developers think about it?
• What are the challenges QA Engineers are going to face in this practice?

To respond to such interesting questions, we gave ourselves the task of collecting data from different sources, such as doing interviews with frontend and backend developers, tech leads, discipline leads, digging on the internet, and putting our experience on paper.

Why thinking as a Dev is important?

If you are a Developer, you know how easy it is to have a conflict or a misunderstanding with a tester; indeed, this is expected. Both have different mindsets, and each perspective fulfills a skill required to achieve a high-quality product.

Even though both, Developers and QAs, have the technical knowledge, it is sometimes difficult to identify the root cause of an issue and its consequences. Let’s read about a funny experience that can help us learn about a common situation that occurs in our daily work:

“One day, I was trying to merge my changes, but the test in the QA environment was failing. However, the same testing scenario was successful in the dev environment, so I decided to reproduce the same steps manually in QA environment, they worked fine. The error code returned by the automated pipeline indicated that the issue was related to the code, so I am supposed to fix it, but there was nothing to fix from my side!”
Natalia Puente del Valle | Application Management Engineer

In this example, we can clearly see how easy it is to fall into a situation where we are doubtful about many things, and the reasons are numerous:

• The lack of information when a bug ticket is raised.
• Different configurations exist in different environments.
• Third-party software is failing.
• The steps to reproduce the issue may be different among environments.
• Preconditions may not be clear enough.
• A module of the system is having an outage.

The Think as a Dev practice intends to provide more tools and knowledge to QA members. In this way, they can help at each stage of the SDLC in tasks such as finding bugs as early as possible, enabling the technical team to increase their productivity, reducing risks, and, why not, even proposing out of the box ideas.

“It would help that QAs have a deep enough understanding of the code so that they can detect the weakest parts of the system and are able to test them.”
Joaquín Bravo | Engineering Discipline Lead

Advantages and disadvantages of thinking as a Dev

As with everything in the world, there are good and bad things that we need to take into consideration when starting a new practice, so, let’s discuss the advantages and disadvantages we can face:

Advantages

Thinking as a Dev may be really helpful for QAs; it gives a clear idea of what and how to test. Some of the advantages are:

• Understanding the code makes it much easier to help the Developer find issues earlier.
• QA gets enabled and helps to take better technical decisions.
• Two eyes are now available to do static analysis by doing PR reviews when needed.
• It gives the QA a better idea of where the weak points of the system are.
• Less lack of communication between Devs and QAs as they start working closely.
• Getting familiar with the architecture helps the QA to make better tests.
• Better estimations can be made during the grooming sessions because the QA has a wider view.
• QAs help to reduce debugging time because they provide better and more accurate info.

“A QA Engineer can contribute like any Developer in the team.”
Victor García | Software Engineer

Disadvantages

However, thinking as a Dev might have some consequences for the QA team. The following are some of the disadvantages that we have to consider:

• The QA might try to test many things and pay little attention to the essential stuff.
• The QA might face a high learning curve. It’s hard to juggle learning specific project technologies and creating manual/automated tests.

As you noticed, there are more advantages than disadvantages, which means this practice is a GOOD option if we want to go further and move the QA process to the NEXT LEVEL.

OK, we want to go further… What is the first step?

First of all, we need to understand the following…

→ What are the challenges in this journey?

QA challenges in Thinking as a Dev include:

• As different points of view exist, communication between Developers and QAs can become challenging.
• A QA Engineer might not have the same Developer’s expertise in using a specific technology or programming language.
• A QA Engineer might not be familiar with many of the technical terms and coding methodologies.
• It’s hard for a QA to allocate time to understand the technologies, architecture, languages, etc. and at the same time maintain their current responsibilities.

→ What are some terms and concepts used by Developers?

Developers often use some terms and concepts that the QA engineer might not be familiar with., That’s why it is important to start looking more into them.

The first concept is Technical Debt and it is the result of prioritizing speedy delivery over good code creation. When an already working functionality needs to be refactored because it was not properly coded, we are talking about technical debt.

To start thinking as a Dev, it is also important to keep in mind the techniques and principles of clean code, such as:

• KISS (Keep It Simple Stupid)
• YAGNI (You Are not Gonna Need It)
• DRY (Don’t Repeat Yourself)
• SRP (Single Responsibility Principle)

When we asked Developers about the most common programming principles they follow, they mentioned:

“We always have Clean Code in mind, also DRY and SRP. You don’t want the code to surprise you.”
Joaquín Bravo | Engineering Discipline Lead

“They all are Programming Principles, and they are not associated with a role, so it makes sense that a QA uses them too.”
Álvaro Laguna | Tech Lead

When the QA Engineer is familiar with those techniques and principles, it is easy to identify the situations that can end in refactoring, and they can be fixed at earlier stages.

→ How do Devs achieve good quality code?

If we want to think as a Dev, then we need to extract words directly from Devs, and that’s exactly what we did. In the following, we discuss what developers think about code quality, how they test their code, and what their concerns are when coding.

High-quality code can be reached by using code standards, creating unit tests, and peer-reviewing my team’s code.

As a wise man said: “If someone is doing something very well, then you have to replicate the same”

The following are some tips we collected from our interviewees that, for sure, Devs and QAs must follow:

“Document the PR and the ticket, list the scenarios to test beyond unit testing”
Iván Galaviz | Software Engineer

“If I’m going to do a unit test, although I know my code, I review line by line to find more test scenarios and the different ways my code can react to certain value or data“
Víctor García | Software Engineer

“Define the best practices for our project, and look for an agreement across the team, focusing on Clean Code”
Joaquín Bravo | Engineering Discipline Lead

→ How do Devs debug?

Debugging is the process of locating bugs and fixing them.

In high-performance teams, Developers take the debugging process very seriously. To have an idea of what they think about it, we can start by saying that the bug report is the first step for them to fix a bug, and they have high expectations on what a QA should do when creating bug reports, just take a look at the next comment:

“The basis is that it (a bug report) should carry clear information that enables identifying it (the bug) and replicating it; it is especially helpful to replicate it in different environments.”
Álvaro Laguna | Tech Lead

Most of us already know that the information provided in bug reports should be complete, but let’s take a look at the next comment, which went even further:

“Normally, it (the QA process) would be just to detect and communicate bugs, but maybe that should change, and everyone must be proactive in identifying and fixing bugs.”
Francisco Tejón | Software Engineer

It aligns exactly with what the Think as a Dev practice is looking for: enabling everyone to be able not only of identifying bugs but also fixing them.

Why start reviewing PRs is important for a QA Engineer?

Usually, reviewing PRs is a task associated with Developers or people who have coding knowledge, but why should a QA Engineer learn a little about the code and help with PRs reviewing?

The QA Engineer does not need to be a coding expert to participate in this activity; it is enough to have the basic knowledge of the language used by the team, as Iván Galaviz, a Wizeline software engineer, said to us:

“It’s good when the QA Engineer knows the coding language. Personally, it’s even better when they know only the basics. If they are able to understand my code, then it means it is well designed”

So, if you are not an expert in coding, then you can focus on reviewing this:

• Read and understand the task before reviewing the code.
• Keep programming principles in mind and ensure the code is easy to understand.
• Review the unit test related to the change.
• Review variable names to ensure they are accurate.
• Once your review is completed, ensure that your message is clear. You can use this example of emoji use when you are reviewing code https://gist.github.com.

And one extra tip, always promote respect!

Ok, Ok.. then, which are our action items?

• Improve communication

Part of the fact that we are one team

Communication is the first thing we should improve in this new adventure. Remember that HOW is always more important than WHAT. As the ISTQB points out in its psychology of testing section, Developers love their code like it was their child; we must always remember this when talking about their code. Since the Thinking as a Dev approach encourages a close relationship with Devs, to be able to comment on their unit tests or PRs, we need to understand their field, their language, and their pace of work.

• Help with the debug process

This can be achieved by providing better and clearer information when raising bug’s tickets. Sometimes the expected and actual results are not enough because they don’t give Developers a chance to be more effective when debugging. Thus, you can start by providing better logs, attaching logs from different environments or comparing good and bad logs.

But what really can help the most is: If you know which subsystem is involved and can recall another previous/current bug, then try to determine if they are related, so that you can direct the Developer straight to the affected area and, why not, even start suggesting how the bug could be fixed on an extra note.

Tip: If no pressure, a highly recommended suggestion is to make pair programming sessions with developers when working on a bug fix.

• Understand the programing language

If the time allows, try to take a basic course on the programming language your team uses. You don’t need to become a master (we don’t want you to become a developer and abandon us!), so, as Álvaro Laguna said:

“The QA Engineer’s increased knowledge becomes a new tool for the team.”

• Understand the project’s architecture

If you want to be more confident with what you are testing, then you must understand the system’s architecture. Ask your tech lead for diagrams. It’s also a good idea to ask your Manager for access to the infrastructure systems like AWS, GCP, or Azure and tools like Kibana, Consul, Splunk, Grafana, or any other Developers in your team commonly use.

Sometimes, even in high-performance teams, it’s pretty common to find out that there is not enough documentation about the infrastructure. If that’s the case, then it is an excellent opportunity to take the initiative and start creating more docs.

• Start doing cross-review of PRs

You can start by asking Developers to take a look into your automation PRs by adding them each time you open a new one. This will be very helpful as they start suggesting changes, refactorizations, and challenging you with new proposals.

If you don’t feel comfortable reviewing PRs, then you can start by asking them to add you to their PRs but just as a viewer. You can move ahead later after you’ve learned the basics of the code and feel comfortable to start doing Formal Reviews.

Tip: We highly recommend to take a look at the Code Clean Principles so that you can make better PR reviews.

• Be an active participant of technical discussions

Always attend and participate in the technical discussions. To start doing it, a good recommendation is to ask your Devs to think of you as another Developer, so that they add you to their private developer slack channels, to their developer specific meetings, and to their developer shared folders.

Tip: Make sure the Developer and the rest of the team are aware about your intentions to implement the “Think as a Dev” practice.

And last but not least… What can Devs improve to help QAs reach the dark side?

• Try to encourage QAs to participate in technical discussions by asking their opinion and being respectful, QAs need to learn too much technical stuff to build a strong opinion.
• Try to take a look at the automation repository of your QA teammate; make suggestions, and try to review their PRs whenever possible.
• A walk-through of your code would be highly appreciated by a QA Engineer.

At Wizeline, we focus on quality when it comes to an understanding of our clients’ needs. This is why the Wizeline QA Team concentrates on delivering quality and comprehending and applying the best practices to all the product’s building steps.

Authors:

José Luis Díaz Valenzo

Enrique López Magaña

Gloria Tovar Fernández

Francisco Tovar

Special thanks to:

Natalia Puente del Valle

Joaquín Bravo Contreras

Iván Galaviz

Víctor García

Álvaro Laguna

Francisco Tejón