Switch to:
QA and the invisible pillar of software development

QA and the invisible pillar of software development

The term Quality Assurance (QA) is often invoked as a buzzword, but rarely is it truly understood in its broader scope. For many, QA is reduced to simply ‘finding bugs’ or running tests to see if something works. But in reality, it’s much more: it’s a strategic, cross-cutting, and cultural approach aimed at ensuring that the final product is consistent with user expectations and business objectives.

One of the most common confusions is between QA and testing.

Testing is undoubtedly a fundamental tool: through manual or automated tests, it allows verifying that the code works according to specifications, that there are no obvious errors, and that the user experience is smooth. But stopping here means limiting the vision enormously.

QA, in fact, is not only about verifying afterwards, but about preventing; it’s a set of practices, methods, and mindsets aimed at avoiding certain problems from the earliest stages of ideation and design.

Let’s think about building a bridge.

Doing testing is equivalent to checking that the beams and concrete can withstand the expected weight. QA, on the other hand, is the design work of the bridge: choosing the appropriate materials, establishing safety loads, assessing risks, and ensuring that, even in adverse conditions, the structure holds. QA doesn’t come into play only when the bridge is already standing, but starts working even before the first line of the project is drawn.

One of the most complex challenges related to QA is determining who is responsible for it. There is no single answer: it depends a lot on the product’s growth phase and the team structure.

In a startup or a very small team, often the same developers handle it, perhaps with the help of a project manager. In these cases, there is heavy reliance on manual, exploratory tests and a deep understanding of the most critical user flows.

When a product starts to grow and scale, however, automation comes into play: end-to-end tests, regression tests, and CI/CD tools become essential. It’s at this point that the introduction of dedicated QA roles is often considered.

In more mature companies, finally, QA becomes a structured department, with specialized roles working closely with developers, designers, product managers, and stakeholders. In this perspective, QA is fully integrated into the DevOps cycle, actively participating in every development phase.

However, there is an argument that often comes up when talking about QA: that it costs too much. And partly it’s true.

Some QA practices require time, resources, and specific skills. End-to-end tests, for example, are notoriously slow to write, execute, and maintain. However, as with any investment, the value is measured in the long term.

A critical bug discovered in production can have a devastating impact in terms of costs, image, and user trust. Preventing it before it happens is, ultimately, much more cost-effective.

The key to making QA sustainable lies in finding the right balance: automate what is repetitive and easily reproducible, focus on the most used user flows, and above all, accept that not everything can be covered 100%.

Perfectionism in QA is not only inefficient, but risks slowing down the development cycle without bringing real benefits. Better to aim for smart coverage, iterate often, and stay flexible.

Attention though! QA is not a phase, it’s a culture.

It’s not an activity to be carried out at the end of development, nor a role to delegate to a single team.

It’s a mindset that must permeate every part of the process, from writing specifications to interface ideation, from technology choices to user feedback analysis.

This means cross-cutting collaboration among all team members: PMs, designers, developers, and QA specialists. It means acting preventively, identifying risks before they become problems. And it means constantly adapting, evolving together with the product and market needs.

Investing in QA doesn’t just mean building more reliable software: it means protecting your brand’s reputation, reducing future maintenance costs, increasing user trust, and improving the overall experience. In a competitive market like the current one, quality is no longer a luxury: it’s a prerequisite.

A well-thought-out QA strategy is not a technical frill, but a fundamental lever for product growth.