Define a tarefa que a aplicação precisa de concluir
O critério de aceitação deve descrever uma tarefa do utilizador, o resultado esperado e as condições em que acontece. Evita encerrar o trabalho apenas porque os ecrãs existem. Um conjunto de páginas pode estar desenhado enquanto o processo que motivou a aplicação continua dependente de passos manuais que querias eliminar.
Ao planear uma aplicação de prognósticos desportivos, defini que os resultados dos jogos deviam ser recolhidos e usados no cálculo das classificações. A intenção era evitar introduzir manualmente essa informação. Ter uma tabela bonita de jogos não seria suficiente para demonstrar que esse objetivo estava cumprido.
Esse exemplo mostra a diferença entre uma funcionalidade visível e uma tarefa completa. Há uma origem de dados, uma atualização, uma regra de cálculo e um resultado apresentado às pessoas. A aceitação precisa de percorrer essa sequência e de conferir se cada parte contribui para o comportamento que foi pedido.
Numa aplicação hipotética de marcações, a tarefa pode começar com a escolha de um horário e terminar com a reserva confirmada para as pessoas certas. Ver o calendário não chega. É necessário perceber se o horário deixa de estar disponível depois da reserva e se a informação guardada corresponde à escolha efetuada.
Estes critérios devem ser escritos ao planear a aplicação antes de começar a programar. Se surgirem apenas no fim, a equipa pode estar a avaliar um objetivo diferente daquele que orientou a construção. Definir o resultado cedo permite pedir demonstrações concretas em vez de discutir genericamente se está tudo pronto.
Para preparar o próximo passo, consulta Criar produtos digitais com IA.
Confere os dados e o estado depois de cada ação
Uma tarefa só fica demonstrada quando a informação recebida, guardada e apresentada corresponde à regra definida. Compara o estado anterior com o resultado da ação e volta a abrir o registo. A interface pode mostrar uma confirmação sem que a operação tenha produzido o efeito esperado no sistema que sustenta a aplicação.
No exemplo das marcações, regista um horário com uma conta de teste e consulta a reserva a partir da vista da equipa. Confere a data, o serviço e o estado. Depois termina a sessão e volta a entrar. O objetivo é distinguir um resultado persistente de uma atualização temporária que existiu apenas no ecrã.
Se há cálculos, prepara exemplos cujo resultado consigas confirmar. Uma soma, uma classificação ou uma regra de distribuição precisa de valores de entrada conhecidos. Não aceites apenas que a aplicação apresenta um número. A pessoa que valida deve conseguir explicar por que razão aquele é o resultado correto para o caso ensaiado.
Observa também atualizações incompletas. Uma origem externa pode não devolver todos os campos ou pode estar indisponível. Define o que a aplicação mostra nessa situação e como se evita apresentar informação antiga como se fosse atual. O critério de conclusão deve incluir uma resposta compreensível para as falhas relevantes daquele processo.
O trabalho de testar uma automação antes de a entregar à equipa ajuda a organizar estas provas. Junta o caso preparado, o resultado esperado e a evidência observada. Se o ensaio usou dados simulados, identifica esse alcance para não transformar uma simulação numa confirmação da integração real.
Valida quem consegue fazer cada parte do trabalho
A aceitação deve incluir os perfis que vão usar a aplicação e as ações que cada um pode executar. Confere acessos permitidos e recusados com contas adequadas ao ensaio. Uma demonstração feita apenas com a conta de administração não prova que a equipa terá as permissões certas quando começar a trabalhar.
No exemplo hipotético, quem atende clientes pode precisar de consultar marcações, enquanto outra pessoa gere a disponibilidade. Se ambas receberem acesso total só para a demonstração correr bem, fica por resolver uma decisão operacional. As contas de teste devem representar as responsabilidades que existirão no uso normal da aplicação.
Também importa verificar a localização do projeto e o controlo dos serviços. Já tive de corrigir a criação de um repositório na minha conta pessoal quando o objetivo era deixá-lo na conta da empresa. O código existia, mas a equipa não tinha a continuidade pretendida a partir dos seus próprios acessos.
Este cuidado não obriga a entregar tudo da mesma forma em todos os projetos. Exige que a organização saiba quem controla o código, os dados e a operação, de acordo com o modelo escolhido. A passagem está incompleta quando só quem construiu consegue explicar onde o trabalho ficou ou publicar uma correção necessária.
É por isso que definir quem aprova o quê no trabalho com uma equipa externa também faz parte da aceitação. A decisão sobre o conteúdo e a decisão técnica podem pertencer a pessoas diferentes. Identifica quem confirma cada dimensão, sem transformar um teste técnico numa aprovação de negócio que ninguém deu.
Distingue o ambiente testado do ambiente entregue
O resultado deve ser verificado nas condições em que ficará disponível, com a configuração e os acessos previstos. Um teste local pode demonstrar uma parte do trabalho sem confirmar o serviço publicado. Regista o ambiente utilizado e as dependências que ainda precisam de configuração ou validação antes da utilização pela equipa.
Uma aplicação pode funcionar no computador de quem a criou porque aí existem ficheiros ou configurações que não foram preparados noutro ambiente. A prova de entrega deve revelar essas dependências. Quem recebe precisa de saber o que está disponível, o que tem de configurar e quem assume essa tarefa.
As integrações merecem uma distinção semelhante. O sistema pode mostrar uma mensagem “enviada” porque o teste simulou a resposta de um serviço. Isso é útil para verificar o comportamento interno, mas não confirma receção por uma pessoa real. Quando essa confirmação fizer parte do objetivo, é necessário um ensaio autorizado e uma verificação apropriada.
Evita resolver esta diferença enviando mensagens ou criando operações reais sem controlo. Prepara destinatários, dados e condições de teste acordados. A aceitação deve produzir evidência sem introduzir trabalho indevido na operação do negócio. O plano do ensaio precisa de esclarecer que efeitos são permitidos e como serão reconhecidos.
Depois da disponibilização, confirma novamente os percursos essenciais a partir de uma sessão normal de utilização. Confere também o que acontece num dispositivo relevante para a equipa, como o telemóvel de quem faz marcações fora do escritório. A conclusão deve corresponder ao contexto de utilização previsto, não apenas à demonstração mais conveniente.
Fecha com pendências explícitas e responsabilidade definida
O fecho deve indicar o que foi aceite, que provas o sustentam e quais as pendências com responsável e próximo passo. Distingue uma melhoria futura de uma falha que impede o objetivo principal. A equipa consegue decidir com mais clareza quando recebe um estado concreto, em vez de uma mensagem genérica de conclusão.
Um relatório curto pode associar cada requisito ao teste realizado e ao resultado. Se a reserva funciona, mas a recuperação de acesso ainda falha, as duas informações precisam de aparecer separadas. O agente não deve apresentar a média do trabalho como sucesso quando uma condição necessária à utilização continua por cumprir.
Há diferenças que podem ser aceites conscientemente. Uma exportação adicional pode ficar para uma fase seguinte se não era necessária ao objetivo acordado. Já perder reservas ou expor dados de outra pessoa altera as condições de utilização. A prioridade deve resultar do impacto no processo e das decisões dos responsáveis.
Regista ainda quem acompanha falhas depois da entrega e onde fica a informação necessária para as investigar. Isso inclui o histórico de alterações e as instruções de operação adequadas ao âmbito do projeto. Quem vai usar a aplicação não precisa de decorar a construção, mas deve saber como obter ajuda e manter continuidade.
Eu daria o trabalho por concluído quando uma pessoa autorizada consegue realizar as tarefas acordadas, os resultados foram conferidos e as responsabilidades seguintes estão claras. A IA pode ajudar a organizar toda essa prova. A frase “terminei” só ganha utilidade quando vem acompanhada de evidência que permite aceitar a aplicação nas condições combinadas.