O que é QA (Quality Assurance) em software, explicado de forma simples

QA (Quality Assurance, garantia de qualidade) é o conjunto de práticas que dão a você uma forma de saber, antes de publicar, se o software faz o que você prometeu. Essa é a resposta curta. A resposta longa é que QA não é o momento em que alguém "testa para ver se funciona": é o sistema que torna a qualidade previsível em vez de uma surpresa no final.

A imagem popular de QA é a de uma pessoa que quebra coisas pouco antes do lançamento. Encontra falhas, as reporta, e todos correm para consertá-las. Essa pessoa existe e é necessária, mas confundir isso com QA é como confundir o bombeiro com a segurança contra incêndios. Apagar o fogo é necessário quando já há fogo. QA, bem entendido, é o trabalho que torna o fogo raro.

01 · a confusãoQA não é "quem quebra coisas no final"

É preciso separar três palavras que costumam ser usadas como sinônimos e não são: qualidade, garantia e teste. A qualidade é uma propriedade do produto: o quão bem ele faz o que deve. A garantia (o A de QA) é o processo que trabalha para que essa propriedade se cumpra. E o teste é uma das atividades dentro desse processo, não o processo inteiro.

O padrão internacional que define o que significa "qualidade" em um produto de software se chama ISO/IEC 25010. Ele não fala em "sem bugs". Fala em características mensuráveis: adequação funcional, confiabilidade, eficiência de desempenho, usabilidade, segurança, compatibilidade, manutenibilidade e portabilidade [1]. Um produto pode não ter um único erro visível e ainda assim ser de má qualidade se for inseguro, impossível de manter ou incompreensível para quem o usa.

Testar no final diz o que quebrou. QA decide, desde o começo, o que jamais deveria poder quebrar.

Por isso QA começa muito antes de existir código para testar. Começa quando alguém escreve o que o software deve fazer e sob quais condições será considerado correto. Sem esse acordo prévio, "testar" é opinar. Com ele, testar é verificar.

02 · o sistemaPrevenir é mais barato que corrigir

A razão econômica pela qual QA se antecipa ao final tem décadas de evidência. Um erro custa mais quanto mais tarde é descoberto. Um requisito mal escrito, se pego enquanto ainda é uma frase em um documento, custa corrigir uma frase. O mesmo requisito mal escrito, descoberto quando já é código em produção que um cliente usa, custa refazer código, dados, comunicação e confiança. A regra prática que Barry Boehm popularizou é que o custo de corrigir um defeito cresce de forma acentuada conforme o projeto avança [2].

Daí vem a ideia central da garantia: mover o cuidado com a qualidade para o início em vez de deixá-lo para o final. Na prática, isso significa várias atividades que não parecem "testar" e no entanto são QA pura:

Definir o critério antes de construir. Antes de escrever código, escreve-se o que contará como "feito" e "correto". Esse critério é o oráculo: a referência contra a qual depois se verifica. Sem oráculo, ninguém pode afirmar que algo passou ou falhou, apenas que "parece bom".

Revisar, não apenas executar. Ler um requisito ambíguo e pedir que se esclareça é QA. Revisar um design e detectar que ele não contempla um caso é QA. Nada disso executa o programa, e ainda assim previne falhas que custariam muito mais tarde.

Verificar contra o critério. Aqui entra o teste: executar o software e comparar seu comportamento com o que foi acordado. Esta é a parte visível de QA, a que as pessoas reconhecem, mas é a ponta do iceberg apoiada em tudo o que veio antes.

03 · a abordagem QiravaQualidade é um sistema, não um heroísmo de última hora

Tudo isso leva a uma conclusão incômoda para muitas equipes: se a qualidade depende de uma pessoa corajosa encontrar as falhas a tempo na noite anterior ao lançamento, você não tem qualidade, tem sorte. E a sorte não escala. Funciona até o dia em que essa pessoa está de férias, ou o produto cresce mais rápido do que um par de olhos consegue revisar.

Na Qirava tratamos a qualidade como um sistema com regras, não como um ato de heroísmo. Um sistema tem três coisas que o heroísmo não tem: é repetível, é explicável e não depende de quem está de plantão. Quando uma falha escapa, a pergunta não é "quem falhou em testá-la", mas "que parte do sistema permitiu que ela chegasse até aqui sem que ninguém percebesse". Essa pergunta conserta o processo; a outra apenas procura um culpado.

Se a qualidade depende de alguém ser heroico na noite anterior ao lançamento, você não tem qualidade: tem sorte.

Esse sistema se apoia em uma base que já cobrimos em outros artigos: escrever a especificação antes do código, para que exista um critério contra o qual verificar. Sem especificação não há QA possível, só opiniões sobre se algo "parece bom". Com especificação, cada afirmação de qualidade se torna comprovável.

04 · em uma fraseO que levar

QA é a disciplina de saber, antes de publicar, se o software cumpre o que você prometeu, e de organizar o trabalho para que esse cumprimento seja a norma e não um golpe de sorte. Testar no final é uma parte, a mais visível, mas é a ponta de algo maior: definir o critério, revisá-lo, construir contra ele e verificar sem drama.

A imagem do herói que quebra coisas na última noite é cativante e enganosa. A qualidade de verdade é entediante no bom sentido: sistemática, precoce e repetível. Quando funciona, quase não se nota, porque os incêndios que ela apaga são os que nunca aconteceram.