Gabrijela Hladnik describes the expanding role of Quality Assurance

In Meaningful work interviews I talk to people about their area of work and expertise to better understand what they do and why it matters to them.

Gabrijela Hladnik is an experienced Quality Assurance Engineer. We discussed where quality fits into the development process, how to get started and what management should know about quality assurance practices.

What do you think about your role, and how do people introduce you?

I’m someone who prevents code from going to production (laughs). My primary job is to ensure that specific quality standards are met. My coworkers would say that I do Quality Assurance (QA) for their software products.

How would you explain what a QA does?

Usually, people think that we just click around the software and find some mismatched designs or try different strings in forms and see if that breaks them. Often our daily work usually looks like that, but we also do much more.

If you dig deeper, you discover that there’s actually more than just evaluating the product when it’s done. I often sit at initial planning meetings to help identify potential problems during the initial stages. It’s much cheaper to avoid them before the code is written than fix them afterward.

I often work on multiple projects within the company due to the way software development timelines work. This allows me to point out potential problems ahead of time since I’ve already seen the other team implement similar components.

Overall, it’s not just the quality of the end product but also the quality of our work. I think about how the entire process is structured and how to ensure a smooth internal process from the idea to the release.

What do you wish developers knew about your work as a QA?

I’m pretty technical in the sense that I’ve been around developers for around 20 years. I’m familiar with concepts like Kubernetes, API, and WebSockets. With this in mind, I can have a high-level conversation around the architectural changes. This allows me to help identify different edge cases on a project without going through the actual testing process.

I wish more developers would be open to speaking in more technical terms with my QA team members. It makes it easier to identify critical parts of the application and helps us make better test plans.

Can you describe some of the ways QA helps with the software development process?

On one side of the spectrum, QA engineers just write unit tests, and they might also be part of the software development team. On the opposite side, there is manual testing where testers click through the application based on some prewritten script. And between these two, you have a mix of both and a world of other jobs that help ensure a good product or process quality and that are done by QAEs if there’s no other person to do it. 

Besides trying to see if the program works correctly, you might also do other things. User Experience testing can be part of QA, or you might be involved in release management. All of this makes it potential for a very complex role as you often have to switch between different ways of working and thinking.

I see my role a bit everywhere. It very much depends on the product. In the case of a financial application, we would care more about data integrity than design. It would be the opposite if you’d work on a design-rich showcase project.

What do you wish management knew about your role?

The usual expectation is that there will be no bugs once we have QA in the company. That’s not how things work, and there will always be bugs in production. It’s a constant source of conflict with management as they’re just not willing to accept this reality.

A destructive pattern that I see is that management sometimes tries to make it QA vs. the Development team. This results in two camps where QA’s become bad guys who block the development and shipping of software. This is again counterproductive, and things work so much better if we collaborate together. There needs to be an understanding of what we all do so that work can be organized better.

I would also like the management to understand that all bugs are not equal. Some are more important than others, and we need to distinguish between them and react with appropriate severity of response.

How do you feel about the current state of QA job advertisements?

Due to the just described complexity of my role, I wish recruiters would be more specific in what they need. It would be great if the company would understand where their team lacks expertise and look for somebody with the missing competency.

Examples of such specializations could be a QA engineer that has experience with application security. If the visual design is essential for the application, get a QA with an eye for the details.

Is QA a good starting job for people that want to later transition into development?

No, that’s usually a terrible idea. It might work if you start by writing unit tests, then fixing bugs that your tests uncover, and improving your coding skills with time. But in general, QA requires a different mindset from writing code. Both demand a creative person, but that creativity is used differently. Development work results in the creation, while as a Quality Assurance Engineer, you need to think with an evaluation mindset. You start with something already created and inspect it in many creative ways to see if it matches up to the required standards

I more often see developers transitioning into QA roles than in the opposite direction. They can build on their development knowledge, add extra specialization like security practices and fill in a valuable niche. I also see my peers moving towards different management roles, especially product-related ones.

What are some of the trends that you see in your industry?

There’s a lot of talk about shifting QA left – bringing it closer to the beginning of the development process. I now often participate in the planning stages of projects since I have enough experience to identify potential problems early. However, I noticed that being too far left is not that useful. It’s much easier to reason about the system once you have some prototypes or mockups developed.

Our roles are also expanding. It’s not just pure testing anymore. We’re being part of discussions on how the software is made, building pipelines (CI/CD), and organizing the work. Some companies have dedicated management roles that deal with this, and others don’t. In those cases, it’s often QA that owns that process.

There’s a lot of truth in saying, “Do the right things, not the things in the right way.” It used to be just about the quality of the product, but it’s now much more about the quality of the whole process. There’s a lot of focus on ensuring that we can support the team where it needs most of the support. 

How do you manage the balance between this level of responsibility in a project without having formal authority around it?

It comes down to two things, trust from the team and working smart, not hard. The team trusts me because I’m reasonable and dependable – I won’t obsess over a minor bug. Still, I will pull the plug when there is potential for data loss.

Time-wise, I have to be smart and constantly weigh how much I should be involved at the beginning and which parts of the development process to support. I want to have enough time left to also check the final result. In agile development, these phases are intertwined, so during testing one feature, you already plan the development of another, and the third one is already in the making. I must be conscious about this and prioritize work that will make the most impact.

There are many parts of the development process where our input and contribution can be helpful. Since I have a good overview of the whole process, it is easier for me to pick up parts that other team members can’t handle. There are so many different tasks in a software development process. They’re all somehow related to the final quality of the product.

What would your suggestion be for someone that wants to transition into QA?

It’s a mindset of having an inquisitive approach to the world. You know that you already have one if you like solving puzzles. If you aren’t sure, one method is to look at where the seams are in the world. Imagine you’re looking at the drawing of a house, and you start seeing where the wall begins to transition into the roof. That’s a significant change that should be more closely inspected as it’s more likely that this is where errors will be. Spotting these transitions is what you need to train yourself to start seeing edge cases in software.

What are some of your favorite resources for leveling up and people that you learn from?

Cartoon Tester – Comic about testing that helps you see things in a different way

Ministry of Testing – QA Community that can help you figure out how to approach different QA challenges

Terry Pratchett – Discworld series – fun and thought provoking look into an alternate universe

Mark Manson – The Subtle Art of Not Giving a F*ck – to counter all the bugs that you see throughout the day

Parallel Passion from Miha Rekar – an excellent podcast to get to know your fellow developers