QA vs teste vs controle de qualidade: não são a mesma coisa

Uma equipe diz "temos QA" e quase sempre quer dizer "temos alguém que testa o app antes de lançar". Isso não é QA. Isso é teste, e nem sequer todo o teste. A confusão soa inofensiva até a conta chegar: você contrata um testador achando que comprou um processo de qualidade, mede defeitos encontrados achando que mede qualidade, e se surpreende quando os mesmos erros voltam release após release.

QA, teste e controle de qualidade são três coisas distintas que trabalham juntas. Uma previne, outra verifica, outra inspeciona. Separá-las não é purismo de manual: é o que te diz quem contratar, o que medir e em que momento do projeto agir. Aqui eu as desmonto uma por uma e te deixo a tabela que você pode colar na parede da equipe.

01 · o processoQA é prevenção: cuida de como se constrói

Garantia de qualidade (Quality Assurance) é uma abordagem de processo. Não olha o produto pronto: olha a forma como ele é produzido. Sua pergunta não é "esta versão está boa?", mas "estamos trabalhando de um jeito que evite que defeitos surjam?". Por isso é preventiva e por isso acontece ao longo de todo o ciclo, não no final.

QA define padrões, define como o código é revisado, como os requisitos são documentados, quais critérios uma história deve cumprir para ser considerada pronta. Quando QA funciona, muitos defeitos nem chegam a existir porque o processo os fechou antes. O ISTQB resume com clareza: a garantia de qualidade se concentra no cumprimento de processos adequados para dar confiança de que a qualidade esperada será alcançada [1].

QA não revisa o bolo. Revisa a receita, o forno e a mão de quem cozinha.

Isso tem uma consequência incômoda para quem contrata: você não pode "colocar QA" no fim de um projeto e esperar milagres. Se o processo foi caótico durante seis meses, botar uma pessoa na última semana não garante qualidade, só a mede. QA é uma decisão tomada no começo e sustentada por todo o caminho.

02 · a atividadeTeste é verificação: executa o produto para achar falhas

Os testes são uma atividade concreta: executar o software com a intenção de encontrar defeitos e de comprovar que ele faz o que deve. É dinâmica por natureza: roda o sistema, insere entradas, observa saídas e as compara com o esperado. Teste é uma das ferramentas do controle de qualidade, não um sinônimo de qualidade em si.

Aqui convém lembrar um princípio antigo e ainda ignorado: os testes demonstram a presença de defeitos, nunca a sua ausência. Encontrar zero erros não significa que o software esteja perfeito; pode significar que você testou pouco ou testou mal [1]. Por isso "quantos casos de teste passaram" é uma métrica que engana se lida sozinha.

Teste também não é uma coisa só. Há testes que verificam o código por dentro (unitários, de integração) e testes que validam o comportamento visível (de sistema, de aceitação). Um testador executa e reporta; um bom testador projeta o que testar para que cada teste conte. Mas mesmo o melhor teste continua sendo verificação no fim da cadeia, não prevenção na origem.

03 · a inspeçãoControle de qualidade é detecção: inspeciona o que já foi construído

O controle de qualidade (Quality Control) é detecção. É a inspeção orientada ao produto: pega o que já foi construído e verifica se cumpre os critérios de qualidade definidos. Enquanto QA pergunta "o processo é bom?", QC pergunta "este resultado concreto cumpre?". É reativo por concepção: age sobre algo que já existe.

Teste é a principal atividade de QC, mas QC é mais amplo: inclui revisões de produto, inspeções, verificação contra especificações e critérios de aceitação. A norma ISO/IEC 25010 traz aqui o vocabulário que torna a inspeção séria: define um modelo de qualidade de produto com características mensuráveis como adequação funcional, confiabilidade, usabilidade, segurança e manutenibilidade [2]. Sem esse modelo, "cumpre?" é uma opinião; com ele, é uma medição.

04 · a tabelaQuem faz o quê, quando e com que mentalidade

Postos lado a lado, os três deixam de se confundir. QA é o guarda-chuva de processo; QC é a inspeção do produto; teste é a atividade concreta que alimenta o QC. A relação não é de rivalidade, mas de encaixe: o teste serve ao controle de qualidade, e o controle de qualidade vive dentro da garantia de qualidade.

Você contrata mal quando pede QA e descreve um testador. Mede mal quando conta testes e acha que conta qualidade.

A consequência prática é dupla. Primeiro, na contratação: se o seu processo é um desastre, um testador não o conserta; você precisa de alguém que trabalhe o processo (QA). Se o seu processo é saudável mas você precisa encontrar falhas antes de entregar, você precisa de quem execute testes (teste/QC). São perfis e momentos distintos. Segundo, nas métricas: "defeitos encontrados" mede atividade de QC, não qualidade do processo. Um bom indicador de QA é o oposto: defeitos que não ocorreram porque o processo os preveniu, algo que se vê na tendência de defeitos que escapam para produção ao longo do tempo, não em um número de testes executados.

Que esses termos sejam usados como sinônimos nas reuniões não é grave por pedantismo. É grave porque cada um responde a uma necessidade distinta, e misturá-los faz você gastar no que não era e medir o que não importa. Separe-os e de repente você sabe quem chamar, em que momento e qual número olhar.