“Site responsivo, formulário e treinamento” parece uma lista objetiva, mas ainda permite interpretações diferentes. Em quais situações o formulário precisa funcionar? Onde o contato será consultado? O que o cliente conseguirá fazer depois do treinamento? Critérios de aceite respondem a essas perguntas antes da entrega. Eles conectam proposta, execução e teste, ajudando a reconhecer o que está pronto e o que ainda exige correção. Você pode começar com poucas condições bem escritas, ligadas às tarefas principais do projeto.
Troque adjetivos por situações que alguém consiga conferir
Um critério útil descreve uma condição observável. “Página intuitiva” expressa uma intenção. “Na página de serviços, o visitante encontra a região atendida e chega ao formulário pelo botão identificado” permite uma verificação. O segundo enunciado não resolve toda a experiência de uso, mas torna uma parte da entrega discutível com evidências.
A documentação da Atlassian sobre critérios de aceite trata essas condições como requisitos definidos para reconhecer uma entrega concluída. Em projetos pequenos, você pode aplicar o princípio sem adotar toda uma metodologia de desenvolvimento. Uma lista vinculada à proposta e conhecida pelo cliente já organiza a conversa.
Separe três elementos: entrega, critério e teste. A entrega é o formulário de orçamento. O critério diz quais dados ele recebe, o que acontece em erros e onde um envio válido aparece. O teste descreve os passos para verificar cada comportamento. Misturar tudo em “formulário funcionando” esconde decisões que depois serão difíceis de cobrar ou corrigir.
Evite critérios que dependam de fatores fora da entrega. “Receber vinte contatos no primeiro mês” exige demanda, divulgação, oferta e atendimento. Não é uma condição apropriada para comprovar que o formulário foi construído. Metas comerciais podem orientar o projeto, mas precisam ser tratadas separadamente, sem virar garantia automática do fornecedor.
Construa os critérios junto das dúvidas da proposta
Considere uma proposta fictícia para um pequeno estúdio de fotografia. O site terá apresentação, modalidades de trabalho, galeria e contato. A equipe quer que o visitante escolha entre ensaio pessoal e fotografia de produto. A confirmação do serviço será feita depois de uma conversa; não haverá compra, pagamento nem reserva automática.
Antes de escrever os critérios, esclareça os pontos que mudam a operação. Quem fornecerá as imagens? Quais campos são obrigatórios? Quem consulta os contatos? O texto de retorno deve informar apenas que a solicitação foi registrada? Essas respostas entram na proposta ou no anexo de escopo e precisam ser compatíveis com a plataforma escolhida.
Para esse caso, uma lista inicial poderia incluir as seguintes condições:
- As duas modalidades possuem descrição e imagens aprovadas pelo responsável.
- A galeria apresenta as fotografias combinadas, com autorização de uso confirmada pelo cliente.
- O formulário identifica nome, e-mail, modalidade e mensagem, conforme a definição aprovada.
- Um envio válido aparece no destino de armazenamento contratado e pode ser localizado pela pessoa responsável.
- Campos obrigatórios ausentes produzem uma orientação compreensível para correção.
- A mensagem após o envio não afirma que um ensaio está confirmado.
- Menu, formulário e botões principais podem ser utilizados nos cenários de teste definidos.
- O cliente consegue repetir a tarefa administrativa prevista no treinamento.
Esses itens são um ponto de partida, não um padrão universal. Um estúdio que precisa receber arquivos grandes ou integrar um sistema de agenda terá outras dependências. Não acrescente funções ao anexo apenas porque parecem úteis: confirme necessidade, disponibilidade e impacto no preço antes de assumir a entrega.
Quando a solução considerada é a Orbite, o armazenamento de contatos recebidos por formulário ou chatbot pode fazer parte do fluxo demonstrado. Isso não autoriza deduzir confirmação de horários, sincronização com calendários ou um processo comercial completo. Escreva o comportamento que foi verificado para o projeto, com seus limites.
Transforme o formulário do exemplo em um teste reproduzível
Identifique o teste com um nome simples, como “Contato válido para fotografia de produto”. Registre versão do site, endereço da página, dispositivo e navegador utilizados. Prepare dados demonstrativos reconhecíveis. A pessoa que executará a conferência deve conseguir repetir os passos sem precisar adivinhar o que você quis dizer.
O primeiro cenário começa com o formulário vazio. O avaliador preenche nome fictício, e-mail de teste controlado pela equipe, modalidade e uma mensagem identificada como verificação. Depois envia. O resultado esperado é o retorno previsto na tela e o registro acessível à pessoa autorizada. Se houver notificação por e-mail contratada e comprovada, ela precisa de uma conferência específica.
O segundo cenário deixa um campo obrigatório vazio. O teste observa se existe explicação do problema e se é possível corrigir a informação. O terceiro usa um endereço de e-mail em formato inválido. O objetivo é conferir a validação prevista, sem afirmar que a plataforma consegue verificar a existência de qualquer caixa de e-mail.
O tutorial de formulários do W3C oferece referências sobre rótulos, instruções e retorno ao usuário. Use essas orientações para definir condições compreensíveis. Uma borda vermelha isolada, por exemplo, pode não explicar qual campo falhou nem como corrigi-lo. A avaliação precisa considerar a experiência além da aparência.
Ao registrar o resultado, escolha entre passou, falhou ou não foi possível testar. A última categoria importa: se ninguém conseguiu acessar o destino dos contatos, você não sabe se o registro funcionou. Não marque como aprovado apenas porque a tela mostrou sucesso. Descreva a dependência e a pessoa que precisa liberar a verificação.
Se houver falha, registre comportamento observado, esperado e evidência sem informações pessoais desnecessárias. “Contato não apareceu na conta de teste após o envio desta versão” orienta melhor o diagnóstico que “formulário ruim”. Depois da correção, repita o cenário afetado e os caminhos relacionados que possam ter mudado.
O quadro separa o resultado do teste de uma impressão de funcionamento.
| Cenário do formulário | Resultado esperado | Quando não aprovar |
|---|---|---|
| Envio válido | Retorno correto e registro consultável | Sucesso visual sem conferir destino |
| Campo obrigatório vazio | Orientação permite corrigir | Erro não identifica o campo |
| E-mail malformado | Validação prevista sinaliza formato | Validação confundida com existência da caixa |
| Destino inacessível | Dependência registrada para novo teste | Item marcado como passou sem evidência |
Associe cada critério a uma única versão de referência. Se o cliente aprova o conteúdo enquanto você troca o componente do formulário, a aprovação anterior não cobre automaticamente o comportamento novo. Identifique quais testes precisam ser repetidos, sem exigir uma nova avaliação de tudo o que permaneceu independente. Esse vínculo entre versão e evidência evita dois extremos: considerar qualquer alteração irrelevante ou reiniciar o aceite inteiro por uma correção pequena. O registro deve mostrar exatamente o que continua válido e o que aguarda reteste.
Combine ambientes, responsabilidades e tratamento das pendências
“Funciona no celular” precisa de um recorte verificável. Defina os aparelhos ou tamanhos de tela e navegadores que serão usados na conferência, considerando o público e a complexidade do site. Uma amostra de testes não demonstra funcionamento perfeito em todas as combinações possíveis. Evite tanto uma promessa universal quanto uma lista tão estreita que ignore situações previsíveis.
Estabeleça quem aprova cada parte. O cliente valida fatos comerciais, imagens e decisões da marca. O responsável técnico verifica o comportamento contratado. Uma pessoa deve consolidar a aprovação final. Em conteúdo de profissão regulamentada, a revisão especializada cabe a quem tem competência, conforme a necessidade do projeto.
Separe problemas impeditivos de melhorias posteriores. Um botão que leva ao destinatário errado e a perda de contatos impedem o objetivo central. Uma sugestão de nova galeria pode ser avaliada para outra etapa. A classificação deve considerar uso e risco, não apenas se a correção é rápida ou se alguém tem pressa para publicar.
Se houver aceite com pendências, registre quais são, quem corrige e como serão verificadas. Não use uma aprovação genérica para esconder uma função incompleta. Também não transforme uma lista de testes em cláusula jurídica improvisada que pretende eliminar direitos do cliente. Condições contratuais e responsabilidades legais exigem tratamento próprio.
Quando o cliente não responde, siga o procedimento combinado para comunicação e cronograma. Não interprete silêncio como aprovação técnica sem base no acordo aplicável. Enquanto aguarda, avance somente nas tarefas que não dependem da decisão. Se a ausência de resposta mudar a programação, explique o efeito concreto.
Faça a reunião de aceite e guarde um registro curto
Na apresentação final, retome o objetivo e percorra os critérios principais. Mostre a versão que será entregue, execute os testes relevantes e deixe o cliente repetir sua tarefa administrativa. Isso oferece mais evidência que perguntar “está tudo certo?” depois de uma visita rápida ao painel.
Uma observação nova pode ter três destinos. Se revela descumprimento de um critério, abre uma correção. Se resolve uma ambiguidade, exige esclarecer o acordo. Se acrescenta uma entrega, entra como mudança de escopo. Essa separação evita que um problema real seja rejeitado como extra ou que uma função nova seja absorvida sem avaliação.
O registro final pode conter identificação da versão, testes executados, resultado, pendências e confirmação dos responsáveis. Guarde apenas as evidências necessárias. Contatos demonstrativos devem ser tratados conforme o procedimento combinado, e capturas não precisam mostrar listas reais de visitantes.
Antes de fechar o projeto, repita a verificação no endereço público quando a prévia tiver condições diferentes. Registre a data e informe o caminho para reportar falhas. Bons critérios de aceite não tornam o relacionamento burocrático: reduzem a quantidade de coisas que cada pessoa precisa supor sobre o que foi contratado e entregue.
