Quais testes são de responsabilidade do desenvolvedor e quais são do QA?

Uma dúvida muito comum entre desenvolvedores e times de QA é: quem é responsável por escrever quais testes? A resposta passa por entender dois conceitos fundamentais — caixa branca e caixa preta — e como cada papel no time se relaciona com eles.

Antes de falar sobre quem testa o quê, é preciso entender a diferença entre os dois modelos de teste:

White box (Caixa branca) — o testador conhece e tem acesso ao código interno da aplicação. Testa a lógica, os caminhos de execução, as condições e os dados internos. É o modelo natural para quem escreveu o código, porque só quem conhece a implementação sabe exatamente quais cenários internos precisam ser cobertos.

Black box (Caixa preta) — o testador não conhece (e não precisa conhecer) o código interno. Testa apenas o comportamento externo da aplicação: dado uma entrada, verifica se a saída é a esperada. Simula a perspectiva do usuário final.

O desenvolvedor é o único que conhece profundamente o código que escreveu — cada condição, cada caminho possível de execução, cada dependência. Por isso, cabe a ele escrever os testes que verificam a lógica interna. Isso não significa, porém, que o desenvolvedor está restrito à caixa branca — ele também pode (e deve) escrever testes de unidade no modelo caixa preta, testando apenas a interface pública de um método sem se importar com os detalhes de implementação internos.

Unit Test (Teste unitário) — White Box ou Black Box

Testa o menor pedaço de código isoladamente — uma função, um método, uma classe. As dependências externas (banco de dados, APIs, serviços externos) são substituídas por mocks ou stubs, garantindo que o teste valide apenas aquela unidade específica.

• White box: o dev conhece a implementação e escreve cenários para cobrir cada ramificação interna, cada condição e cada caminho de execução.
• Black box: o dev (ou o QA) testa apenas a interface pública — dado esta entrada, espero esta saída — sem se importar com como o código chegou lá. É uma forma mais resiliente a refatorações.

Por que o dev lidera? Porque é quem tem contexto para escrever os dois tipos com profundidade — tanto os cenários de cobertura interna quanto os de comportamento externo da unidade.

Características: muito rápidos, altíssimo volume, executados a cada build. Formam a base da pirâmide de testes.

Integration Test (Teste de integração)

Testa a comunicação entre dois ou mais módulos ou sistemas — por exemplo, a integração do serviço com o banco de dados, com uma API externa ou com uma fila de mensagens. Diferente do unit test, aqui a dependência real é chamada (quando isso é viável e sem impacto financeiro ou de infraestrutura).

Por que é do dev? Porque requer conhecimento da implementação de ambos os lados da integração — saber qual contrato é esperado, quais erros podem ocorrer e como o sistema deve se comportar em cada cenário.

Características: mais lentos que unit tests, menor volume, verificam que os módulos funcionam corretamente em conjunto.

Load Test (Teste de carga)

Verifica se o código e a infraestrutura aguentam N vezes a carga normal — simulando picos de acesso para identificar gargalos de performance antes que cheguem ao usuário em produção.

Por que é do dev? Porque envolve entender onde a aplicação pode ter gargalos técnicos — queries lentas, conexões esgotadas, memória insuficiente — e requer conhecimento da arquitetura interna para interpretar os resultados.

Características: executados em ambientes que simulam produção, geralmente em ciclos de release ou após mudanças arquiteturais significativas.

O QA (Quality Assurance) tem um papel complementar ao do desenvolvedor: validar que o sistema como um todo funciona corretamente do ponto de vista do usuário, sem se preocupar com os detalhes de implementação. O QA pensa em termos de fluxos, comportamentos e regras de negócio — não em funções e classes.

Isso não significa que o desenvolvedor não pode escrever E2E ou participar de UAT. Em times menores ou com práticas mais avançadas de engenharia, o próprio dev pode automatizar cenários E2E. A diferença está em quem lidera e quem tem a visão mais ampla dos fluxos de negócio — papel que naturalmente recai sobre o QA.

E2E Test (Teste fim a fim)

Testa um fluxo completo de usuário de ponta a ponta — desde a interface até o banco de dados, passando por todas as camadas do sistema. Simula exatamente o que um usuário real faria: abre a tela, preenche um formulário, clica em um botão, verifica o resultado.

Por que o QA lidera? Porque exige visão do fluxo de negócio e dos cenários que o usuário vai executar. Não importa como o código está estruturado internamente — só importa se o comportamento final está correto. O QA tem essa visão de ponta a ponta que o dev, focado na implementação, muitas vezes não tem.

O dev pode escrever E2E? Sim. Em muitos times, principalmente os que praticam DevOps e automação de qualidade, o desenvolvedor contribui ativamente na escrita de testes E2E — especialmente quando não há QA dedicado. A distinção é de liderança e responsabilidade primária, não de exclusividade técnica.

Características: lentos, menor volume, alto custo de manutenção. Formam o topo da pirâmide de testes.

UAT — User Acceptance Test (Teste de aceitação do usuário)

É o teste final antes de um sistema ou funcionalidade ir para produção. O objetivo é confirmar que o que foi construído atende às necessidades reais do negócio e do usuário final — muitas vezes conduzido pelos próprios usuários ou pelo time de produto, com suporte do QA.

Por que é do QA? Porque o QA atua como o guardião da qualidade entre o desenvolvimento e o usuário. É o QA quem organiza os cenários, facilita as sessões de teste com stakeholders e documenta os resultados.

Características: geralmente manuais ou semi-automatizados, executados em ambiente de homologação, com participação direta do negócio.

A pirâmide de testes é um modelo clássico que ilustra a proporção ideal entre os diferentes tipos de teste:

A lógica da pirâmide é simples: quanto mais baixo o nível, mais testes você deve ter e mais rápidos eles devem ser. Quanto mais alto, menor o volume e maior o custo de criação e manutenção. Um projeto com muitos E2E e poucos unit tests tem a pirâmide invertida — o que resulta em suítes de teste lentas, frágeis e difíceis de manter.