Automatize o que um script verifica igual em toda execução: fluxos críticos de ponta a ponta, requisições que falham, erros de console, acessibilidade e cada tamanho de tela. Deixe manual o que exige julgamento: teste exploratório, saber se um fluxo faz sentido, uso com leitor de tela. Nosso pacote Fundamentos de automação de QA cobre os seus 5 fluxos críticos no CI, com acessibilidade, por US$ 5.000 em duas semanas.
Fazemos QA manual e automatizado em produtos nossos e de clientes, e as regras abaixo saem daí. Mostro como é um teste que escreveríamos de verdade e onde eu pararia de automatizar.
Qual a diferença entre QA e teste?
QA (garantia de qualidade) é a prática inteira de assegurar que o software faça o que deve: como os requisitos são escritos, como as mudanças são revisadas, o que segura uma versão. O teste é uma atividade dentro disso: executar o software e conferir o resultado. Um time pode ter muitíssimos testes e um QA fraco, se os testes verificam o que não importa ou ninguém reage quando eles falham.
Isso pesa na hora de terceirizar. Se você compra “teste”, recebe casos de teste. Se compra QA, deveria receber menos defeitos em produção. Se você quer comprar assim, Fundamentos de automação de QA é o pacote de preço fixo com que começamos.
O que é automação de testes?
É escrever código que usa a sua aplicação como uma pessoa usaria (abre páginas, clica, preenche formulários) e confere o resultado sem intervenção humana. Roda em segundos, a cada mudança, sempre igual. O limite é que só verifica o que alguém pensou em verificar.
A IA vai substituir o QA?
Não na parte que exige julgamento. A IA já ajuda a escrever código de teste e a gerar dados, e é assim que a usamos. Mas decidir o que importa o bastante para ser testado, perceber que um fluxo está tecnicamente certo e na prática confunde, e assumir que uma versão não está pronta continuam sendo decisões humanas.
O guia de acessibilidade do Playwright diz isso sem rodeios: os testes automatizados detectam alguns problemas comuns, como propriedades ausentes ou inválidas, mas muitos problemas de acessibilidade só aparecem em testes manuais. E isso vale muito além da acessibilidade.
O que automatizar com Playwright?
Tudo o que um script consegue verificar de forma idêntica a cada execução e que doeria se quebrasse sem ninguém notar. Comece pelos fluxos críticos, clicando como um usuário: cadastro, login, o formulário que gera receita. Não “a página carrega”, e sim “o usuário chega ao fim”. Enquanto o fluxo roda, vigie a rede (qualquer resposta 4xx ou 5xx, qualquer requisição que falhe) e a execução (exceções não tratadas e erros de console, que uma captura de tela nunca mostra). Some as regras de acessibilidade que o axe consegue verificar, como rótulos faltando, contraste e IDs duplicados, e rode tudo em cada tamanho de tela suportado, no mínimo um de desktop e um de celular.
Um teste que só tira uma captura mostra que a página foi desenhada. Um que percorre o fluxo e falha diante de qualquer erro mostra que ela funciona. Esta é a forma que usamos:
import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";
test("o fluxo de contato funciona e é acessível", async ({ page }) => {
const problemas: string[] = [];
page.on("pageerror", (e) => problemas.push(`exceção: ${e.message}`));
page.on("console", (m) => m.type() === "error" && problemas.push(`console: ${m.text()}`));
page.on("requestfailed", (r) => problemas.push(`falhou: ${r.url()}`));
page.on("response", (r) => r.status() >= 400 && problemas.push(`${r.status()}: ${r.url()}`));
await page.goto("/pt/");
await page.getByRole("link", { name: "Contato" }).click();
await page.getByLabel("E-mail").fill("qa@example.com");
await page.getByRole("button", { name: "Enviar" }).click();
await expect(page.getByRole("status")).toContainText("Obrigado");
const axe = await new AxeBuilder({ page })
.withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa", "wcag22aa"])
.analyze();
expect(axe.violations).toEqual([]);
expect(problemas).toEqual([]);
});
Roda-se uma vez por tamanho de tela com os projects do playwright.config.ts, por exemplo um a 1440 × 900 e outro a 390 × 844. É a mesma estrutura do percurso que fizemos para uma plataforma que centraliza solicitações e aprovações entre áreas de uma organização. Num build local, foram 10 passos a 1440 e 390 pixels de largura, com zero requisições com falha, zero erros de console e zero violações do axe nas páginas avaliadas.
O que deve continuar manual?
O que um script não consegue julgar. Primeiro, o teste exploratório: uma pessoa com um objetivo e um tempo limitado, tentando quebrar a funcionalidade de jeitos que ninguém escreveu. Depois a pergunta “isso faz sentido?”, porque um fluxo pode passar em todas as asserções e mesmo assim confundir. Também o leitor de tela e o uso só com teclado, de ponta a ponta: as regras automáticas pegam rótulo faltando, mas não dizem se a experiência funciona para quem não vê a tela. E as funcionalidades novas, cujo comportamento ainda muda, porque automatizar um fluxo que se altera todo dia gera testes que acabam apagados.
Minha regra é automatizar a verificação e deixar o teste exploratório nas mãos de pessoas. Verificar confirma o que você já sabe que deve ser verdade. Testar descobre o que você não sabia que precisava perguntar.
Quanto custa terceirizar QA?
Conosco há duas formas. Os Fundamentos de automação de QA custam US$ 5.000 fixos, em duas semanas, por uma suíte Playwright com seus 5 fluxos críticos no CI mais checagens de acessibilidade. Ou você contrata um engenheiro de QA por hora via staff augmentation: US$ 30 como júnior, 35 a 40 como pleno, 45 a 50 como sênior.
Como referência dos Estados Unidos, o BLS informa um salário mediano de US$ 50,14 por hora para analistas de QA e testadores de software em maio de 2025. É um salário. O custo total para o empregador é maior, então não se compara direto com uma tarifa faturada. Como compará-los direito está no texto sobre valor hora, e tudo junto, em preços.
Que ferramentas usamos para automatizar testes?
Em produtos web partimos do Playwright para os percursos no navegador (Chromium, Firefox e WebKit com uma só API). Usamos o @axe-core/playwright para as regras de acessibilidade dentro dos mesmos testes. Para a lógica, o runner de testes unitários do projeto (Jest, Vitest ou o nativo da linguagem). Para as junções entre componentes, testes de integração contra um servidor e um banco locais de verdade, sem mocks.
Quando o produto pede mais, acrescentamos. No portal de uma plataforma de publicidade com IA que construímos para um cliente, os percursos rodam também só com teclado, em modo escuro, com cores forçadas e com zoom de 400%. Há ainda verificações de fidelidade contra os designs aprovados no Figma. No release v1.61.0 eram 30.282 testes unitários em 569 suítes e 1.440 de integração em 266, todos passando. Numa plataforma PropTech de moradia, os percursos no navegador cobrem 13 variantes, com comparação pixel a pixel contra os designs aprovados e testes de ponta a ponta contra um servidor local real.
Vale a pena automatizar testes?
Quando os testes falham por motivos reais. Não quando são instáveis, verificam o que não importa ou demoram tanto que ninguém os roda. Quatro hábitos mantêm uma suíte honesta.
Afirme sobre o resultado: “a mensagem de status diz Obrigado” vale mais que “o botão foi clicado”. Junte os erros de console e as requisições com falha em cada teste, como acima, para que os erros que você não vê também derrubem a execução. Use papéis e rótulos como seletores, porque getByRole e getByLabel quebram quando a acessibilidade quebra, que é o que você quer. E nunca enfraqueça um teste para ele ficar verde: um teste que mudou para passar sem que o requisito mudasse é um teste apagado com passos a mais.
Quais são os tipos de teste de software?
Por nível, de baixo para cima. Os unitários verificam uma função ou módulo isolado. Os de integração, vários componentes juntos, de preferência com dependências reais. Os de ponta a ponta, a aplicação completa como uma pessoa a usa, e os de aceitação, contra os critérios do negócio. Por objetivo, são funcionais (faz o que deve?) ou não funcionais (acessibilidade, desempenho, segurança). Uma boa suíte tem muitos unitários, os de integração necessários e poucos de ponta a ponta, bem escolhidos, porque são os mais lentos e os mais caros de manter.
Como terceirizar QA sem perder o controle?
Peça a qualquer fornecedor, a nós também, três coisas por escrito. Onde moram os testes: no seu repositório, rodando no seu pipeline, legíveis para o seu time. O que quebra o build: quais verificações seguram uma versão e quais só informam. E o que um “passou” cobre: quais fluxos, tamanhos de tela e navegadores, para que um resultado verde signifique algo concreto. Se essas respostas forem vagas, os relatórios também serão.
Se quiser ver como ficaria no seu produto, nomeie os seus 5 fluxos críticos e comece os Fundamentos de automação de QA: US$ 5.000, 2 semanas.
Fontes
- W3C, WCAG 2.2, Recomendação publicada em 5 de outubro de 2023 e atualizada em 12 de dezembro de 2024. Consultada em 6 de outubro de 2026.
- Playwright, accessibility testing e documentação da API do axe-core, consultadas em 6 de outubro de 2026. Versões no registro do npm naquele dia: Playwright 1.63.0, @axe-core/playwright 4.13.0.
- BLS, Occupational Employment and Wage Statistics: analistas de QA e testadores de software (SOC 15-1253), maio de 2025, mediana de US$ 50,14 por hora. Consultada em 6 de outubro de 2026.