O fornecedor envia o link e pergunta se o site está aprovado. Você abre a página inicial, gosta do visual e responde que sim. Dias depois, descobre que o formulário não chega ao responsável e que ninguém explicou como atualizar o telefone. A aprovação ficou concentrada na aparência, enquanto funções importantes permaneceram sem conferência.
Um processo de aceite ajuda o contratante a verificar o que foi combinado, registrar pendências e distinguir correções de novas solicitações. Ele deve ser ajustado ao escopo do projeto e às condições da contratação. Este guia propõe uma revisão operacional; não interpreta cláusulas jurídicas nem substitui uma avaliação técnica especializada.
Converta cada entrega contratada em uma condição observável
Comece pela proposta e pelo escopo aprovados. Liste páginas, conteúdos, formulários, recursos, publicação e orientações de uso que foram efetivamente combinados. Se houver dúvida sobre um item, esclareça antes de transformá-lo em uma exigência de aceite. A revisão não deve introduzir uma loja virtual em um projeto contratado como site institucional.
Depois escreva como cada entrega será conferida. “Página de serviços pronta” pode significar textos aprovados, serviços corretos, links funcionais e caminho de contato disponível. “Formulário funcionando” deve incluir preenchimento, validação, mensagem final e acesso ao registro no destino definido.
Evite critérios subjetivos sem complemento. “Site profissional” é amplo. “As páginas previstas podem ser abertas, os textos correspondem à versão aprovada e o contato pode ser concluído nos ambientes combinados” oferece um ponto de partida verificável.
Combine também limites de teste. Quais navegadores e dispositivos serão avaliados? Quais funções dependem de serviços externos? Haverá revisão de acessibilidade com qual profundidade? O material do W3C sobre verificações iniciais lembra que uma checagem simples não substitui avaliação abrangente.
Defina quem aceita conteúdo, quem testa funções e quem reúne pendências. Em uma empresa pequena, a mesma pessoa pode assumir os papéis, mas as etapas continuam diferentes. Uma aprovação do texto não comprova que o formulário funciona.
Escreva cenários de teste que o fornecedor consiga repetir
Um cenário contém cinco informações: tarefa, ambiente, dados de teste, resultado esperado e resultado observado. Acrescente o endereço da página e a data. Isso permite comparar o que foi solicitado com o que ocorreu, sem depender de mensagens vagas como “no meu celular está estranho”.
Exemplo fictício: tarefa de enviar uma solicitação de orçamento na página de serviços; ambiente de celular e navegador identificados; nome fictício e e-mail controlado; resultado esperado de mensagem de recebimento e registro acessível ao responsável. Se a tela informa sucesso, mas o registro não aparece, anote as duas observações.
Use dados de teste que a equipe reconheça e remova ou trate esses registros conforme o procedimento combinado. Não teste em nome de clientes reais. Também não envie formulários de sites de terceiros para avaliar o portfólio do fornecedor; peça uma demonstração autorizada ou um ambiente de teste.
Inclua erros previstos. Deixe um campo obrigatório vazio, informe um formato inadequado e tente corrigir. O tutorial do W3C sobre notificações ajuda a discutir feedback compreensível. O resultado esperado deve explicar como o usuário percebe e resolve o problema.
Quando um teste depender de uma conta ou permissão, combine um acesso adequado. Não coloque senhas, tokens ou dados pessoais em capturas de tela. O relatório precisa demonstrar a tarefa, sem ampliar desnecessariamente a circulação de informações reservadas.
Uma planilha de aceite pode usar os mesmos campos para vários testes, mas cada linha deve descrever uma entrega concreta. O quadro abaixo sugere evidências para um site institucional simples.
| Entrega | Cenário de conferência | Evidência suficiente |
|---|---|---|
| Cinco páginas previstas | Abrir cada endereço e comparar textos | Lista de páginas e versões conferidas |
| Formulário de contato | Enviar teste identificado e conferir destino | Mensagem final e registro correspondente |
| Validação de campos | Omitir e depois corrigir um obrigatório | Erro identificado e dados preservados |
| Edição de telefone | Atualizar os pontos combinados | Alteração visível nos locais previstos |
| Acesso de administração | Entrar com a conta autorizada | Permissão necessária disponível |
Faça uma rodada de aceite em um projeto hipotético
Imagine um escritório que contratou cinco páginas institucionais e um formulário de contato. O fornecedor incluiu publicação e orientação para atualizar textos. Não foram contratados comércio eletrônico, integrações comerciais ou acompanhamento de campanhas. A rodada de aceite deve refletir esse conjunto.
A pessoa responsável confere as cinco páginas contra os materiais aprovados. Encontra um serviço com nome antigo e um botão que leva à apresentação geral em vez do contato. Registra cada ocorrência com endereço, texto atual e resultado esperado. São duas pendências específicas, que podem ser verificadas novamente após a correção.
No primeiro envio fictício, aparece uma mensagem de sucesso. A equipe confere o destino e encontra o registro completo. No segundo, o e-mail fica em branco; o formulário bloqueia o envio, mas mostra somente uma borda colorida. O primeiro cenário passou, o segundo precisa de correção na identificação do erro.
A equipe testa também o link de contato no celular. Ele abre o canal correto, mas a mensagem pré-preenchida menciona outro negócio. O problema não está na aparência do botão. A evidência deve incluir o destino e o texto que surge depois do toque, sem expor conversas reais.
Durante a orientação, o contratante tenta alterar um telefone em um ambiente apropriado ou mediante procedimento combinado. Descobre que o mesmo número aparece em três lugares, e apenas um foi explicado. O fornecedor precisa mostrar como manter todos consistentes ou esclarecer quais alterações dependem de suporte.
Ao final, o escritório tem uma lista de achados verificáveis. O projeto pode estar próximo da conclusão, mas “quase pronto” não descreve cada função. A rodada demonstra quais itens passaram, quais falharam e quais não puderam ser testados.
Peça evidências proporcionais ao risco e ao escopo
Para conteúdo, uma comparação com a versão aprovada pode bastar. Para formulário, acompanhe o envio e o registro. Para acessos, confira se a pessoa autorizada consegue entrar com a permissão necessária. Para uma funcionalidade complexa, pode ser preciso demonstração técnica e documentação mais detalhada.
Uma captura da mensagem “enviado” não demonstra o recebimento. Um vídeo de navegação não comprova a possibilidade de atualizar conteúdo. Um arquivo chamado “backup” não garante restauração. Se recuperação faz parte da entrega, esclareça qual procedimento e qual evidência foram combinados, respeitando as capacidades da plataforma.
Com desempenho, combine contexto em vez de perseguir uma nota isolada. A documentação do PageSpeed Insights distingue testes de laboratório e dados de experiência real. Peça que o fornecedor explique achados relevantes e o que foi corrigido, sem apresentar uma pontuação como garantia de vendas ou de funcionamento universal.
Para domínio, plataforma e serviços recorrentes, registre titularidade, responsável administrativo, cobrança e forma de acesso. Isso não significa que todos os arquivos serão exportáveis ou que a migração será simples. As possibilidades de continuidade dependem da solução e precisam ter sido esclarecidas na contratação.
Faça uma lista separada de dependências de continuidade: data de renovação, responsável pelo pagamento, contato de recuperação e serviços que param se uma assinatura terminar. Confira essas informações nas contas apropriadas, sem copiar credenciais para o relatório. Se o fornecedor administra um recurso em seu nome, esclareça como solicitar uma alteração e o que acontece no encerramento da relação.
Se uma evidência não foi produzida, marque o item como não verificado. Não transforme ausência de informação em aprovação por conveniência. Ao mesmo tempo, não exija testes ilimitados que nunca foram previstos; discuta a necessidade e o impacto com o fornecedor.
Separe bloqueios, correções e pedidos novos
Uma classificação operacional possível começa pelos bloqueios: impedimentos de acesso, contato enviado ao destino errado ou exposição indevida de informação. Esses problemas merecem prioridade e podem impedir a liberação da função afetada. A decisão de publicar ou aceitar deve considerar consequência e condições acordadas.
Depois vêm falhas importantes que não impedem todo o uso, como uma instrução incompleta ou informação antiga em uma página secundária. Registre responsável, prazo combinado e forma de reteste. Questões visuais menores também podem ser corrigidas, mas não devem esconder problemas de maior impacto.
Pedidos novos são outra categoria. Acrescentar um idioma, alterar completamente a oferta ou criar uma área de acesso pode mudar escopo e custo. Uma pendência de entrega não deve virar uma lista interminável de ideias que surgiram depois de ver o site pronto.
Para cada correção, peça uma resposta objetiva: o que foi alterado, em qual versão e como conferir. Repita o cenário original e, quando necessário, verifique caminhos próximos. Consertar um menu pode afetar outros links; mudar um formulário pode alterar a mensagem final.
Evite encerrar pendências apenas porque alguém marcou “feito”. O critério é o resultado observado no ambiente correto. Se o fornecedor não consegue reproduzir a falha, compartilhe a sequência e as condições do teste, sem assumir imediatamente que o problema desapareceu.
Formalize o resultado e combine os primeiros cuidados
O registro final deve identificar a entrega avaliada, a versão ou data, os critérios utilizados, os itens verificados e as pendências aceitas expressamente, quando houver. Condições contratuais sobre aceite, pagamentos e garantias merecem leitura própria e apoio jurídico quando necessário.
Confira a orientação de uso, os acessos apropriados e os responsáveis por manutenção. Diferencie correção de defeito da entrega, atualização de conteúdo e nova funcionalidade. Se houver suporte por um período, registre o canal e o alcance que foram combinados.
Registre a liberação para publicação separadamente do resultado dos testes. Um envio de teste correto não autoriza trocar o site anterior ou desligar um serviço por conta própria. Quando a publicação exigir mudança de domínio, combine janela, responsáveis e uma forma de retorno ao estado anterior caso apareça um bloqueio. Ajuste esse plano às capacidades da plataforma contratada.
Depois da publicação, repita as tarefas essenciais no endereço final. Configurações que funcionavam em teste podem precisar de conferência em produção. Faça um contato fictício identificado, valide links importantes e confirme que a equipe sabe acompanhar os registros.
O aceite está bem preparado quando você consegue explicar o que verificou e por que considera a entrega correspondente ao combinado. A aparência continua importante, mas passa a ser parte de uma decisão mais completa sobre conteúdo, funcionamento e continuidade.
