by Wendolayne Maldonado, Senior QA Engineer at Growth Acceleration Partners
Quality Assurance (QA) engineering plays a critical role in software development, ensuring that software products meet the highest standards of quality and reliability. Despite its importance, there is a common misconception that QA engineers are only responsible for testing software and documenting bugs. However, this inaccuracy overlooks other essential skills required to excel in this role.
Since I decided to get into the world of software quality, I was sure that, like any other role, it deserves respect, dedication and commitment to continue growing professionally and getting better at it. And figured I must get the best out of myself in each company, with each project, and the client I was assigned to. Today, I can say with certainty that I feel an infinite passion for my job, and I know I am made for this.
As a result of this respect and passion I feel for my role, I decided to write this article to share my personal opinions gathered through work experiences during these 10 years of my career in the world of Quality Assurance.
If I go back in time, I still remember my first job as a software quality analyst, where I was the only one running tests in the company. I’m not going to lie; I felt very scared because, after doing my mental math, I was the only one testing work of at least eight different developers distributed in separate, independent projects (insert a surprised emoji here). That is, I would be in several projects at the same time, something I am sure has happened to many of you, but it was my first job! So I immediately asked myself, “Why are there so many projects, and it is just now that they decide to hire a QA engineer?” Clearly, it was an answer I did not have at that time.
So, let me ask you… has it ever happened to you that when you get more involved in the role and with the applications, that you must test and solutions you are expected to provide more questions that keep arising one after the other? Well, that’s how I got to the answer of my first question above.
It is quite common to see scenarios where the same person develops and tests at the same time. Therefore, for some companies, a QA engineer is not necessary. Nonetheless, when errors begin to arise due to the few scenarios that are covered, the lack of integration of components — among other things — is when companies notice the correction of errors, as it becomes very expensive. And that’s when they decide to hire a QA engineer.
That scenario, unfortunately, is very common to see in our environment. This reminds me of a blog I read from a developer who said:
“I’ve seen a lot of programmer-tested applications fail miserably because the developer thought so highly of their code that testing was deemed unnecessary.” — James Jeffery on the Hacker Noon blog
Each professional in their respective field should contribute to the same goal so things can work out. Now, being an expert does not mean knowing everything. However, if you desire to enrich your knowledge daily, phrases like “you just click here… here… and then here” and so on help you better understand how (and why) it works. It should not be enough to try to guarantee the quality of a product, but it is important to have a curious mind and have an interest in knowing where the information comes from, where it is stored, what previous configurations are necessary to be able to reach one point, etc. And it may happen to others like it did to me, and they may ask “Why does she want to know that?“
In the same way, I think we have come across fellow developers who tell us things like: the QA engineer I worked with did not review the database; the QA engineer I worked with did not look at logs; or the QA engineer I worked with only told me this was failing (with a screenshot of the error and nothing else). All these phrases should make us feel very uncomfortable and not proud of our role.
We should not normally see QA engineers saying things like, “That’s very technical.” “We shouldn’t know that, we just define the scenario and execute.” “That part doesn’t interest us, we just get to the feature and validate.” “Dev configures everything for us, and then we can start testing.“
Unfortunately, we have people in this environment with that type of mentality. And of course, it is expected that a company does not see the need to hire us if this negative reputation was already created around this. Therefore, it is understandable that they tell us what we want to know. It’s also understandable if they think we just follow steps, as they may think we are here just for the clicks.
Unfortunately, many people in our software quality role are the ones who have nurtured this not-so-favorable reputation, so it would be great to keep in mind that:
- There is a difference between the essential technical tasks for our profession and those tasks that generate value. For example, when validating data in a database, we are not generating any extra value by doing so, but rather, it is something we are expected to do.
- Let’s not settle for the basics. We must have the ability to take on challenges, and not just follow a document.
- Regardless of whether or not you have an engineering degree, if you decide to enter this wonderful world of QA, you must be clear that our contribution goes far beyond executing steps. So, go on and study; get the knowledge you need on a daily basis to succeed.
- Let’s take advantage of the opportunity we have as QAs that allows us to know a product in-depth through our tests, and thus propose new flows or improvements generating added value in these project.
I have a firm conviction that if we go further, we will be able to understand why things work the way they do. We’ll be able to create mental maps of where we can associate processes, and thus be able to support our ideas when we want to defend any of them.
