QA (Quality Assurance): como funciona num projeto real e o que cobrar do seu time de desenvolvimento

Você contrata um desenvolvedor, o projeto é entregue, parece funcionar, e duas semanas depois o cliente liga reclamando que o formulário de contato não envia, que o botão de compra sumiu no celular ou que uma funcionalidade nova quebrou outra que já existia. O desenvolvedor corrige, surge outro problema, e o ciclo continua.

Isso não é azar. É ausência de QA.

QA (Quality Assurance) é o processo que evita exatamente esse ciclo. E o mais importante para quem contrata ou gerencia desenvolvimento: QA não é responsabilidade só do desenvolvedor, e não precisa de uma equipe inteira para funcionar. É uma questão de processo, e processo é algo que dá para exigir, estruturar e acompanhar mesmo sem saber escrever código.

Este artigo explica como QA funciona na prática, quais ferramentas aparecem no dia a dia e o que você precisa saber para cobrar qualidade de quem desenvolve para você.

Por que a maioria dos projetos entrega com defeito

A resposta simples é: porque testar dói. Leva tempo, atrasa entrega, e quando o prazo aperta, QA é o primeiro item cortado.

Mas existe uma lógica perversa nessa decisão. Estudos na área de engenharia de software mostram que corrigir um defeito encontrado em produção pode custar até 15 vezes mais do que corrigir o mesmo defeito durante o desenvolvimento. Quando o bug chega ao usuário final, você soma o custo de identificar, reproduzir, corrigir, testar novamente e fazer novo deploy, além do dano à reputação e, em e-commerces, às vendas perdidas durante o problema.

Cortar QA para ganhar tempo é uma das economias mais caras que existem em desenvolvimento de software.

O que QA faz antes, durante e depois do código

Uma das confusões mais comuns é achar que QA entra no projeto só no final, para “aprovar ou reprovar” o que foi desenvolvido. Na prática, um processo de qualidade bem estruturado tem três momentos distintos:

Antes do desenvolvimento: o QA revisa os requisitos. Se a funcionalidade está descrita de forma ambígua, o desenvolvedor vai interpretar de um jeito e o cliente espera outro. Definir critérios de aceite claros antes de começar elimina uma categoria inteira de defeitos que não são bugs técnicos, são mal-entendidos transformados em código.

Um critério de aceite é uma descrição objetiva do que significa a funcionalidade estar funcionando corretamente. Em vez de “o formulário precisa funcionar bem”, o critério seria: “o formulário deve enviar o e-mail de confirmação em até 30 segundos, exibir mensagem de erro quando o campo de e-mail estiver em formato inválido, e não permitir envio com campos obrigatórios em branco”.

Durante o desenvolvimento: o QA acompanha o que está sendo construído, testa versões parciais e sinaliza problemas antes de acumularem. Em projetos com metodologias ágeis, isso acontece ao final de cada sprint ou ciclo de entrega.

Depois do desenvolvimento: executa os casos de teste formais, valida se os critérios de aceite foram atendidos, documenta o que falhou, acompanha as correções e realiza testes de regressão para garantir que nada que já funcionava parou de funcionar depois das mudanças.

Tipos de teste que aparecem em projetos reais

Não existe um único tipo de teste. Cada um tem um propósito e um momento certo de ser aplicado:

Teste unitário: verifica se uma função específica do código faz o que deveria, de forma isolada. Se você tem uma função que calcula o frete, o teste unitário garante que ela retorna o valor correto para diferentes combinações de peso e destino. São rápidos, automatizáveis e ideais para serem executados a cada nova alteração no código.

Teste de integração: verifica se diferentes partes do sistema funcionam corretamente juntas. O formulário salva no banco? O banco envia o dado para o e-mail? A API retorna o que o front-end espera? Esse tipo de teste pega os problemas que aparecem na comunicação entre componentes.

Teste end-to-end (E2E): simula a jornada completa do usuário. Um robô abre o navegador, navega até a página de produto, adiciona ao carrinho, preenche os dados de entrega, finaliza a compra e verifica se o pedido apareceu no sistema. É o teste mais próximo do uso real e o que mais pega problemas visíveis ao usuário.

Teste de regressão: executado depois de qualquer alteração no sistema para garantir que o que já funcionava não parou de funcionar. Em projetos sem esse teste, é comum uma correção simples quebrar outra funcionalidade sem que ninguém perceba até o cliente reclamar.

Teste exploratório: o testador usa o sistema sem um roteiro fixo, tentando encontrar comportamentos inesperados. É complementar aos testes automatizados e captura defeitos que um caso de teste previsível não encontraria.

Ferramentas que aparecem no dia a dia de QA

Você não precisa saber operar essas ferramentas, mas conhecer os nomes ajuda a entender o que seu time está fazendo e a fazer perguntas certas:

Cypress e Playwright: são as ferramentas mais usadas para testes E2E em aplicações web. Elas abrem o navegador de forma automatizada e executam fluxos completos como se fosse um usuário real. Quando um desenvolvedor diz “vou escrever testes com Cypress”, significa que ele vai automatizar a verificação de fluxos críticos do sistema.

Jest e Vitest: frameworks para testes unitários em JavaScript e TypeScript. São a base da automação de testes em projetos com React, Next.js e Node.js.

Postman e Insomnia: ferramentas para testar APIs diretamente, antes de qualquer interface gráfica estar pronta. Permitem verificar se os endpoints retornam os dados corretos, se a autenticação funciona e se os erros são tratados adequadamente.

SonarQube: analisa o código em busca de problemas antes mesmo de qualquer teste ser executado: duplicações, vulnerabilidades de segurança, complexidade excessiva. Integrado ao pipeline de desenvolvimento, funciona como um portão de qualidade que impede código problemático de avançar.

Jira, Linear e equivalentes: não são ferramentas de teste em si, mas são onde bugs são registrados, priorizados e acompanhados. Um bug sem registro é um bug que some e volta. Um bom processo de QA tem rastreabilidade: cada defeito encontrado tem uma descrição clara, como reproduzir, qual o comportamento esperado e o que está acontecendo de fato.

Como estruturar QA sem ter uma equipe dedicada

Em projetos menores, não faz sentido econômico ter um profissional de QA exclusivo. Mas isso não significa abrir mão do processo. Existem formas de absorver QA dentro da estrutura que você já tem:

O próprio desenvolvedor como QA parcial: qualquer desenvolvedor experiente deveria escrever testes unitários para o código que produz. Isso não substitui um QA externo, mas é a base mínima de qualidade interna. Se o desenvolvedor que você contrata não escreve nenhum tipo de teste, é uma conversa que precisa acontecer.

Ambiente de homologação: antes de qualquer entrega ir para o ar, ela deveria passar por um ambiente de testes separado do ambiente de produção. Muitos problemas aparecem simplesmente porque mudanças são publicadas direto em produção sem nenhuma validação intermediária. Exigir um ambiente de homologação é uma das medidas mais simples e mais eficazes que você pode adotar.

Critérios de aceite como parte do contrato de entrega: antes de o desenvolvimento começar, defina por escrito o que significa “pronto”. Isso formaliza a expectativa dos dois lados e evita discussões sobre se algo funciona ou não: ou atende ao critério acordado, ou não atende.

Checklist de entrega: uma lista de verificações que o desenvolvedor preenche antes de qualquer entrega. Inclui itens como: os testes automatizados passam? Foi testado em mobile? O fluxo principal foi validado em ambiente de homologação? Parece burocracia, mas economiza horas de correção depois.

O que cobrar do seu desenvolvedor em termos de qualidade

Quando você contrata desenvolvimento, esses são os pontos que fazem diferença e que você tem todo direito de exigir:

Cobertura de testes: pergunte se o projeto tem testes automatizados e qual a cobertura. Não precisa ser 100%, mas funcionalidades críticas como autenticação, fluxo de compra e integrações com APIs externas deveriam ter pelo menos testes básicos.

Ambiente de homologação: qualquer entrega deveria passar por validação antes de ir para produção. Se o desenvolvedor publica direto no servidor final sem nenhum ambiente intermediário, o seu site ou sistema é o ambiente de teste.

Documentação de bugs: se um problema é encontrado e corrigido, você precisa saber o que era, o que causou e o que foi feito. Sem isso, o mesmo problema pode voltar de formas diferentes e você nunca vai saber se está resolvido de fato.

Testes de regressão após cada entrega: sempre que algo novo for ao ar, o desenvolvedor deveria validar que o que já existia continua funcionando. Isso pode ser automatizado ou manual, mas precisa acontecer.

Critérios de aceite antes de começar: não aceite iniciar o desenvolvimento sem ter clareza sobre o que significa “funcionar corretamente”. Essa definição protege você e o desenvolvedor.

O custo real de entregar sem QA

Para tornar isso concreto: imagine um e-commerce que recebe uma atualização de plugin que quebra silenciosamente o processo de finalização de compra num domingo à tarde. Sem monitoramento e sem testes de regressão, o problema só vai ser descoberto segunda-feira de manhã quando alguém verificar as vendas e perceber que não houve pedido algum desde as 14h do dia anterior.

Esse cenário não é hipotético. É o tipo de situação que aparece com frequência em operações que tratam qualidade como opcional. Para entender como estabilidade e performance de software se conectam ao negócio, vale ler o artigo sobre estabilidade de software na prática.

O custo vai além do técnico. Tem o tempo parado, as vendas perdidas, o desgaste com o cliente, o retrabalho do desenvolvedor e, dependendo do setor, possíveis implicações contratuais.

QA não é sobre ser perfeccionista. É sobre não deixar problemas previsíveis chegarem ao usuário final.

CI/CD e quality gates: quando o processo vira infraestrutura

Em projetos com maior maturidade técnica, QA deixa de ser uma etapa manual e vira parte da infraestrutura de desenvolvimento. Pipelines de CI/CD (integração e entrega contínuas) executam automaticamente os testes a cada alteração de código, e portões de qualidade impedem que código com problemas avance para produção.

Na prática funciona assim: o desenvolvedor faz uma alteração, sobe para o repositório, e um processo automatizado roda todos os testes. Se algum teste falha, o código não segue em frente. Se passa em todos, segue para a próxima etapa. Isso cria uma rede de segurança automática que funciona 24 horas por dia, sem depender de ninguém lembrar de testar manualmente.

Para equipes que trabalham com automação de processos de desenvolvimento, essa estrutura reduz drasticamente os erros de integração e acelera as entregas sem sacrificar qualidade.

QA como diferencial na contratação

Quando você está avaliando desenvolvedores, a presença ou ausência de uma cultura de qualidade é um dos indicadores mais honestos de maturidade técnica. Um desenvolvedor que nunca ouviu falar em testes automatizados, que não sabe o que é um ambiente de homologação ou que acha que QA é responsabilidade de outra pessoa vai entregar projetos com mais retrabalho, mais bugs em produção e mais dificuldade de manutenção a longo prazo.

Não é necessário que o desenvolvedor seja um especialista em QA. Mas ele precisa entender que qualidade é parte do trabalho, não um extra.

As perguntas certas para fazer numa contratação: você escreve testes para o código que produz? Como você valida uma entrega antes de publicar? Já trabalhou com ambiente de homologação separado de produção? O que você faz quando uma correção quebra outra coisa?

As respostas dizem muito mais do que qualquer portfólio.

Se você quer estruturar um processo de qualidade no seu projeto ou precisa de um desenvolvedor que trabalhe com boas práticas de QA desde o início, entre em contato.

Referências

QA (Quality Assurance) — Glossário. Gustavo Assis. Definição completa do conceito, diferença entre QA e QC, e o que faz um profissional de garantia de qualidade.
Cypress — End-to-End Testing Framework. Cypress.io. Documentação oficial da ferramenta de testes E2E mais usada em projetos web modernos.
Playwright. Microsoft. Framework de automação de testes end-to-end com suporte a múltiplos navegadores.
SonarQube — Code Quality and Security. SonarSource. Ferramenta de análise estática de código e quality gates para pipelines de CI/CD.
DORA Metrics. Google Cloud DevOps Research and Assessment. Métricas validadas cientificamente para medir performance e estabilidade de times de engenharia de software.