Testes e QA no Brasil

O orçamento de QA nasce de uma pergunta: o que precisa ser testado e com que frequência. Para um lançamento pontual — o sistema novo indo ao ar, uma versão grande —, o ciclo fechado resolve: o profissional recebe o escopo, escreve os casos de teste, executa, registra os defeitos e entrega o relatório por valor único. Para produto que evolui toda semana, o pacote mensal de horas acompanha o ritmo, cobrindo o teste de cada entrega antes da publicação. A automação é investimento de outra natureza: construir a suíte de testes automatizados custa um projeto — dimensionado pelo número de fluxos críticos cobertos —, e em troca a regressão que tomava dias passa a rodar em minutos, quantas vezes for preciso. Sobre qualquer formato pesam a quantidade de plataformas (web, celular, navegadores diferentes), a existência de integrações e a profundidade pedida: teste funcional, desempenho sob carga e segurança são disciplinas com esforços próprios. Peça propostas que expressem a cobertura — quais fluxos, quais dispositivos — em vez de horas soltas, porque é a cobertura que você está comprando.

O ciclo de testes é um vaivém, e é o vaivém que define o calendário. A primeira rodada percorre os casos planejados e produz a lista de defeitos, classificados por gravidade; o time de desenvolvimento corrige; o QA reexecuta os casos afetados e confere se as correções não quebraram outra coisa — e o laço se repete até a lista de pendências graves zerar. Duas rodadas costumam bastar em sistema bem construído; software frágil consome quantas rodadas houver de orçamento. Por isso a variável decisiva do prazo não é a velocidade do testador, é a qualidade do que chega para testar e a agilidade de quem corrige. No planejamento do lançamento, reserve o QA como fase com datas próprias e critério de saída combinado — por exemplo, nenhum defeito crítico aberto —, em vez de espremê-lo nos dias que sobrarem. Testes de carga e segurança, quando contratados, correm em paralelo ao funcional e adicionam alguns dias. Ambientes de homologação estáveis e massa de dados de teste preparada com antecedência evitam a causa mais boba de atraso: o testador parado esperando acesso.

A entrega do QA é informação organizada sobre a qualidade do software, e cada peça do escopo serve a isso. O plano de testes define a estratégia: o que será testado, em quais ambientes e dispositivos, com qual prioridade. Os casos de teste transformam requisitos em roteiros verificáveis — e frequentemente expõem requisitos ambíguos antes mesmo da execução, um dos ganhos silenciosos do serviço. A execução gera o produto mais visível: defeitos registrados com passos de reprodução, evidências em tela e classificação de gravidade, no formato que o time de desenvolvimento consumir (Jira, Trello, planilha). Fecham o pacote o reteste das correções e o relatório de encerramento, com a fotografia da qualidade e os riscos residuais para a decisão de lançar. Nas propostas de automação, o escopo soma o código dos testes, a integração com o fluxo de publicação e a documentação para rodar a suíte. Fica fora a correção dos defeitos — misturar quem testa com quem corrige dilui a independência que dá valor ao serviço. Delimite também os tipos de teste: desempenho, segurança e acessibilidade são contratações específicas.

As duas verificações não competem: se complementam. Quem desenvolve testa contra a própria interpretação do requisito — se entendeu errado, o teste dele confirma o erro com convicção. O QA parte do requisito e do ponto de vista do usuário, e explora o terreno que o desenvolvedor evita por instinto: o CPF digitado com letra, o botão clicado duas vezes, a conexão que cai no meio do pagamento, o celular antigo com tela pequena. A decisão de contratar se apoia no custo de o defeito escapar: sistema de vendas fora do ar em data de pico, cobrança errada em produção e vazamento de dados custam ordens de grandeza acima de qualquer ciclo de testes. Sinais de que chegou a hora: clientes encontrando defeitos antes da equipe, medo de publicar versões, retrabalho constante pós-lançamento. Na escolha do profissional, peça exemplos de relatórios de defeito reais e experiência no seu tipo de sistema. Para quem contrata desenvolvimento terceirizado, há um uso adicional: o QA independente funciona como aceite técnico da entrega do fornecedor antes do pagamento final.

Os dois formatos respondem perguntas diferentes. O teste manual responde se o produto está certo: um profissional percorrendo o sistema enxerga o texto confuso, o fluxo que irrita, o comportamento estranho que nenhum roteiro previu — abordagem valiosa em funcionalidades novas e na exploração livre. O automatizado responde se o produto continua certo: scripts reexecutam os mesmos caminhos a cada nova versão e acusam na hora quando uma mudança quebrou o que funcionava, tarefa que no manual consome dias e desmotiva qualquer equipe. A ordem econômica é começar manual e automatizar o que se repete: quando o mesmo fluxo de login, compra ou emissão já foi testado à mão pela décima vez, ele é candidato à suíte automatizada. O critério de seleção é contábil — fluxos críticos para a receita, estáveis no design e executados com frequência pagam a automação rápido; telas em mudança constante geram manutenção infinita de script. Em produto maduro, o arranjo de regime é a pirâmide: a regressão roda automatizada a cada publicação e o esforço manual se concentra no que é novo e no exploratório, onde o olho humano rende mais.

A escolha do modelo depende de quanto o escopo está claro. Se o sistema é bem definido, com telas e regras conhecidas, o preço fechado protege o orçamento — mas qualquer alteração vira aditivo, e isso precisa estar previsto. Se o produto ainda vai ser descoberto, cobrança por hora ou por sprint evita a ficção de estimar o desconhecido, desde que haja teto acordado e relatórios de horas. Alocação mensal faz sentido em produto vivo, com fila constante de melhorias. Em qualquer modelo, some os custos de infraestrutura, serviços de terceiros e licenças, que são recorrentes e não fazem parte do desenvolvimento. Peça uma proposta com premissas explícitas: o que está incluído, o que não está e o que acontece quando uma premissa se mostra falsa.

O prazo cai bastante quando o escopo inicial é cortado ao essencial: o objetivo da primeira versão é colocar em uso o fluxo que gera valor, não cobrir todos os casos. Peça um plano com entregas incrementais e ambiente de homologação disponível desde as primeiras semanas — acompanhar telas funcionando é a única forma confiável de saber se o projeto anda. Reserve tempo para o que costuma ser esquecido: migração de dados existentes, permissões, relatórios, integrações com sistemas de terceiros e testes com usuários reais. Homologações dependem de você e entram no cronograma. Defina desde o início critérios de aceite por entrega, para que aprovação não vire discussão subjetiva, e combine como serão tratados os defeitos encontrados durante o período de garantia.

Escopo definido apenas em conversa é a origem da maior parte dos conflitos em projetos de software. Invista na descoberta: mapear os processos atuais, listar perfis de usuário, desenhar os fluxos principais e escrever as regras que o sistema precisa respeitar, incluindo exceções. Protótipos navegáveis ajudam a validar antes de escrever código, quando mudar ainda é barato. Documente também o que está fora do escopo, com a mesma clareza. Estabeleça um processo simples de mudança: pedido escrito, avaliação de impacto, aprovação e ajuste de cronograma. E defina quem, do seu lado, tem autoridade para decidir — projetos com muitos aprovadores e nenhum decisor final acumulam retrabalho. Guarde as decisões num registro acessível às duas partes, com data e responsável por cada definição.

Peça que o contrato descreva quais testes serão feitos, o que a garantia cobre e o que caracteriza defeito em oposição a nova funcionalidade — sem essa distinção, toda solicitação vira discussão. A documentação mínima inclui instruções de instalação e configuração, variáveis de ambiente, dependências, estrutura do banco de dados e procedimentos de publicação. Some a isso acesso ao repositório de código desde o início do projeto, e não apenas na entrega: código versionado em repositório seu é a garantia mais concreta de continuidade. Combine também backup, monitoramento e plano de recuperação, itens frequentemente esquecidos. Por fim, defina o suporte pós-entrega com canal, horário de atendimento e prazo de resposta por severidade, porque é isso que determina o impacto de uma falha em produção.

Na conversa inicial, observe se as perguntas vão além da tecnologia: quem usará o sistema, qual processo ele substitui, qual o volume esperado, o que acontece se ele ficar indisponível. Peça referências de clientes com projetos parecidos e pergunte a eles sobre cumprimento de prazo, transparência e o que aconteceu quando algo deu errado — é aí que a diferença aparece. Verifique práticas de engenharia: versionamento, revisão de código, ambientes separados, testes e publicação automatizada. Confirme quem executará o trabalho e a estabilidade da equipe. Comece, se possível, com um contrato menor de descoberta ou com uma primeira entrega bem delimitada antes de assinar o projeto completo. E garanta desde o primeiro dia a propriedade do código e o acesso aos ambientes.

O tema vai de R$ 20 a cerca de R$ 15.000 no catálogo, cobrindo desde peças gráficas avulsas até desenvolvimento de software. Alguns valores de referência: site institucional de R$ 1.500 a R$ 8.000, landing page de R$ 800 a R$ 3.500, loja virtual de R$ 2.500 a R$ 15.000 e gestão de redes sociais de R$ 800 a R$ 4.000 por mês. O que define o preço é a quantidade de telas ou peças, o nível de personalização, se há integração com outros sistemas e quem produz o conteúdo. Projeto feito sobre tema pronto custa uma fração do desenvolvimento sob medida, e é a escolha certa para muita gente. Lembre dos custos recorrentes que não estão no orçamento do projeto: domínio, hospedagem, licenças e manutenção. Peça a proposta com escopo, entregas e o que fica fora.

A execução dos serviços do tema fica em média em torno de quatro horas nas entregas menores e passa de setenta horas nos projetos maiores — mas o calendário real é sempre maior que a soma das horas técnicas. O que mais atrasa projeto digital não é código: é conteúdo. Texto, fotos, catálogo de produtos, logotipo em alta resolução e acessos a domínio e hospedagem precisam estar prontos, e quase nunca estão. Combine desde o início quem produz cada item e uma data de corte para entrega do material. Estabeleça também quantas rodadas de revisão estão incluídas e qual é o prazo para você responder cada uma; projeto parado esperando aprovação é o cenário mais comum. Peça um cronograma com etapas — descoberta, protótipo, desenvolvimento, testes, publicação — e um ambiente de homologação para revisar antes de o site ir ao ar.