Não é uma questão filosófica, mas uma questão de saber fazer
Recentemente, em uma conversa de fim de semana, um desenvolvedor me trouxe o seguinte questionamento, que havia gerado opiniões divergentes com outros colegas: como você planeja os testes dentro de um plano de projeto de software?
A questão, no entanto, não surgiu como uma dúvida técnica propriamente dita. Ela foi colocada como uma espécie de discussão aberta, quase filosófica, como se estivéssemos diante de algo interpretativo, sujeito a diferentes abordagens e visões igualmente válidas.
Mas não estamos.
Depois de mais de uma década trabalhando com gestão de projetos de software, algumas questões deixam de pertencer ao campo da opinião e passam a integrar o domínio das boas práticas consolidadas. E esta é, claramente, uma delas.
A resposta é simples — e não é opcional
Quando se estrutura um plano de projeto, os testes não aparecem como um complemento eventual, nem como uma etapa acessória que pode ser encaixada ao final do processo. Eles fazem parte do desenvolvimento.
Isso significa, de forma bastante concreta, que o plano precisa contemplar explicitamente uma fase de homologação e validação do software, assim como uma etapa paralela de ajustes durante o período de testes. Não se trata de uma possibilidade metodológica nem de uma escolha baseada na preferência da equipe, mas de uma estrutura mínima necessária para que o projeto exista como tal.
Onde começa a confusão — e o problema
A dúvida que surgiu em seguida foi imediata: “mas isso não é correção de bugs?”
À primeira vista, a pergunta parece técnica. No entanto, ela revela uma confusão conceitual importante.
Se o software ainda está em fase de validação e precisa de ajustes para atender aos critérios previamente definidos, ele ainda não pode ser considerado pronto. E, se não está pronto, ainda estamos dentro do desenvolvimento.
Classificar esse tipo de ajuste como “correção de bug fora do desenvolvimento” não altera a natureza do problema. Apenas cria uma camada de interpretação que mascara o estado real do projeto.
Correção durante testes não é manutenção
Existe uma distinção básica que, idealmente, não deveria precisar ser reiterada, mas que frequentemente precisa ser resgatada:
corrigir algo que ainda não atende ao que foi definido faz parte do desenvolvimento; corrigir algo que já foi entregue e apresentou falha em produção caracteriza um processo de manutenção.
Misturar essas duas dimensões não é apenas uma imprecisão conceitual. É uma forma bastante eficaz de construir uma ilusão de progresso, ao mesmo tempo em que se perde o controle real sobre o estado do produto.
Se não está no plano, já começou errado
Nesse ponto, não há espaço para interpretação.
O plano do projeto precisa prever o tempo necessário para ajustes durante a fase de testes. Quando isso não acontece, não estamos diante de uma escolha metodológica alternativa, mas de um erro de planejamento.
E não se trata de um erro pequeno. É um problema estrutural que tende a comprometer simultaneamente o cronograma, a qualidade do produto e a previsibilidade da entrega.
Não se conserta o motor com o carro em movimento
Uma analogia simples ajuda a esclarecer o problema de forma bastante direta.
Não faz sentido colocar um carro em circulação para, em seguida, tentar ajustar o motor enquanto ele já está rodando. Quando isso acontece, não se trata de estratégia ou eficiência, mas de desorganização.
No desenvolvimento de software, a lógica é exatamente a mesma. Colocar algo em produção com a expectativa de corrigir depois não é um sinal de agilidade. É, na prática, a decisão consciente de aceitar a existência do problema e empurrá-lo para um momento posterior.
O ágil não é um álibi
É comum que, nesse contexto, surja o argumento de que o projeto está sendo conduzido com uma abordagem ágil.
No entanto, adotar metodologias ágeis não significa ausência de definição, nem dispensa critérios claros de validação. Ágil não é trabalhar sem estrutura, nem desenvolver para descobrir depois o que deveria ter sido feito desde o início.
Se existe um produto mínimo viável, então existe necessariamente um conjunto mínimo de funcionalidades definidas. E, se essas funcionalidades existem, elas podem — e devem — ser testadas com base em critérios objetivos.
Quando isso não acontece, o problema não está na metodologia adotada, mas na falta de estrutura na definição do próprio projeto.
Testar sem critério não é testar
Executar testes sem clareza sobre o que está sendo validado não configura um processo de teste.
Para que haja validação, é necessário, no mínimo, que existam critérios de aceitação, uma definição do comportamento esperado e um entendimento consistente do que o sistema precisa fazer.
Na ausência desses elementos, o que existe não é teste, mas uma dinâmica de tentativa e erro, ainda que apresentada com um nome mais sofisticado.
Onde a inteligência artificial entra — de forma útil
Curiosamente, ferramentas de inteligência artificial têm ajudado exatamente a evidenciar esse tipo de lacuna.
Soluções como ChatGPT ou Gemini podem ser utilizadas para transformar requisitos em cenários de teste, estruturar critérios de validação e identificar inconsistências ou falhas na definição do projeto.
Essas ferramentas não substituem o papel do analista, mas deixam bastante evidente quando o problema não é técnico, e sim resultado de falta de clareza ou definição.
Isso não é só sobre software
Há ainda um ponto que costuma passar despercebido: essa discussão não é exclusiva de projetos de software.
Trata-se de um princípio fundamental presente em qualquer projeto estruturado. Seja no desenvolvimento de sistemas, em projetos de pesquisa em humanidades ou em áreas como engenharia, sempre existe uma etapa essencial dedicada à verificação daquilo que foi produzido.
Com o tempo, isso se torna especialmente evidente no contexto do software, mas o mesmo princípio aparece em projetos de pesquisa — especialmente quando envolvem tecnologia para análise e organização de dados — e se torna ainda mais rigoroso em áreas como engenharia, onde a validação não é apenas recomendada, mas obrigatória.
Em todos esses contextos, a lógica é a mesma: existe algo que foi planejado, algo que foi produzido e a necessidade de verificar se o resultado atende ao que foi definido.
Sem essa verificação, não há entrega, mas apenas produção.
Produto sem validação não é produto
Independentemente da natureza do projeto — seja software, um modelo analítico, um processo técnico ou qualquer outro tipo de produto —, a ausência de validação impede que ele seja considerado concluído.
A validação não é uma etapa posterior, mas um componente intrínseco ao processo de construção.
Validar não é responsabilidade do cliente
Um dos erros mais recorrentes — e, muitas vezes, mais convenientes — é a ideia de que a validação do produto é responsabilidade do cliente.
Não é.
O cliente pode e deve participar do processo de homologação, mas homologação e validação não são equivalentes. A validação é responsabilidade da equipe que desenvolve e entrega o produto, que precisa garantir que aquilo que foi construído atende aos critérios definidos antes mesmo de chegar ao cliente.
Quando isso não acontece, o que se está fazendo não é validar, mas transferir o risco.
Enviar algo não validado não é entregar
Quando um produto é enviado ao cliente sem ter passado por um processo adequado de validação, não se trata de uma entrega propriamente dita, mas de um teste em ambiente externo.
As consequências são previsíveis: desgaste na relação com o cliente, perda de credibilidade, aumento de retrabalho e dificuldade na gestão do projeto.
No fundo, trata-se de uma inversão de responsabilidade.
O cliente não é ambiente de teste
Existe uma diferença fundamental entre envolver o cliente no processo de homologação e utilizá-lo como etapa de validação.
No primeiro caso, há colaboração. No segundo, há uma falha de processo.
E essa falha não pode ser interpretada como uma escolha metodológica. É, antes, um indicativo de baixa maturidade no processo de desenvolvimento.
O mínimo esperado
Independentemente da área, existe um princípio básico que deve ser respeitado: só se entrega aquilo que já se sabe que funciona.
O cliente não está ali para descobrir se o produto atende ao que foi prometido, mas para confirmar que atende.
O ponto que ninguém quer encarar
No fundo, a pergunta inicial nunca foi realmente sobre onde colocar testes no plano de projeto.
A questão central é outra: em que momento a equipe está disposta a reconhecer que o software ainda não está pronto?
Se ainda precisa de ajustes para atender ao que foi definido, então não está pronto. E, se não está pronto, ainda estamos no desenvolvimento.
Todo o resto é apenas uma forma mais confortável — e menos honesta — de nomear o problema.
