Critérios de aceite de um site: como definir e conferir a entrega

Critérios de aceite de um site são resultados observáveis usados para conferir se uma entrega atende ao que foi combinado. Em vez de aprovar “um site moderno e fácil”, descreva o que o visitante precisa conseguir fazer, em quais condições e como o resultado será registrado. A avaliação fica mais clara para quem contrata e para quem executa.

O guia de como escolher quem fará seu site organiza a contratação. Aqui, aprofundamos a conferência da entrega. Os critérios precisam ser discutidos antes dessa etapa e proporcionais às páginas, funções e responsabilidades incluídas no projeto.

Comece pela tarefa que o visitante precisa realizar

“Encontrar os serviços e abrir a página de um deles” é uma tarefa delimitada. “Aumentar as vendas” depende também de oferta, divulgação, atendimento e outros fatores. O segundo objetivo pode orientar o negócio, mas não permite conferir sozinho se um menu foi entregue corretamente.

O Service Manual do GOV.UK sobre histórias de usuário apresenta critérios de aceite como resultados que permitem verificar se a necessidade foi atendida. Usamos esse princípio de gestão de serviços públicos como referência para organizar a conferência de um site empresarial. Ele não determina as condições da sua contratação.

Os critérios da tabela são propostas para adaptar. Defina também o que acontece nas situações previstas de erro, como um campo obrigatório vazio. Não inclua silenciosamente integrações, páginas ou canais que não fazem parte do escopo.

Separe critério, caso de conferência e evidência

O critério descreve o resultado necessário. O caso explica a condição e a ação para examiná-lo. A evidência registra o que foi observado numa versão e num ambiente identificados. Ter uma captura de tela sem essa ligação pode deixar dúvidas sobre o que ela demonstra.

Um mesmo critério pode exigir vários casos. Uma navegação que funciona com mouse ainda precisa ser examinada por teclado quando esse uso estiver no requisito. Uma tela de confirmação não comprova, sozinha, que a solicitação chegou ao destino combinado.

Exemplo: o menu funciona no computador, mas falta conferir o toque

Exemplo fictício: uma empresa de serviços definiu o critério C-01: abrir o menu Serviços e acessar a página escolhida por mouse, teclado e toque. O cenário didático registra a conferência por mouse e teclado no computador, mas deixa o toque no celular pendente. Não houve site, navegador ou participante real testado para produzir esses registros.

C-01: resultado exigido

Abrir Serviços e acessar a página escolhida por mouse, teclado e toque. Exemplo fictício.

T-01 e T-02

Mouse e teclado no computador: destino esperado aberto, conforme as premissas inventadas.

T-03: toque no celular

Não executado. Falta definir o ambiente e realizar a conferência.

Resultado do conjunto

C-01 permanece pendente. Não há falha nem sucesso demonstrados no celular. Nenhum site real foi testado.

Descrição da figura

O critério fictício C-01 exige abrir o menu Serviços e acessar a página escolhida por mouse, teclado e toque. O caso T-01, por mouse no computador, e o T-02, por teclado no computador, têm destino esperado aberto como premissa do exercício. O caso T-03, por toque no celular, não foi executado e depende de definir o ambiente e realizar a conferência. Como uma condição não foi examinada, o critério permanece pendente. Isso não demonstra falha ou sucesso no celular. Os registros são inteiramente inventados, sem site real testado.

O resultado parcial não permite marcar C-01 como totalmente atendido, porque uma condição combinada ainda não foi conferida. Também não permite dizer que o celular falhou. “Pendente de conferência” preserva a diferença entre ausência de evidência e falha observada.

Numa entrega real, identifique navegador e versão, sistema, dispositivo ou dimensão da janela, página e versão examinada. Redimensionar o navegador ajuda a observar o arranjo, mas não equivale a conferir um aparelho físico com toque. Registre exatamente o procedimento realizado.

Defina quais pendências impedem a liberação

Combine antes da conferência quais falhas impedem o uso previsto e como os demais ajustes serão encaminhados. Um destino essencial errado, uma solicitação que não chega ou uma informação relevante incorreta podem impedir a liberação do percurso afetado. Avalie o efeito concreto, sem aprovar por média de itens concluídos.

Diferencie divergência do requisito, preferência e novo pedido. Trocar uma cor por gosto depois da aprovação não é a mesma situação de um link que abre outra oferta. Para formular o retorno com contexto, consulte como escrever comentários na revisão de design.

Quando uma condição não puder ser examinada, identifique dependência, responsável e próximo retorno. Se houver liberação parcial, registre exatamente quais páginas e funções foram liberadas e quem tomou a decisão. Não use uma observação genérica de “pequenos ajustes” para esconder uma limitação relevante ao visitante.

Inclua acessibilidade sem prometer uma avaliação completa

As verificações iniciais de acessibilidade da W3C WAI abordam títulos, alternativas de imagens, contraste, teclado e formulários. A própria referência esclarece que esse conjunto é preliminar: passar por verificações rápidas não demonstra ausência de barreiras nem substitui uma avaliação abrangente.

Defina com o fornecedor a abrangência da avaliação prevista no projeto e a evidência a entregar. Uma expressão como “site acessível” precisa ser desdobrada nos requisitos e no método aplicáveis. Não apresente um relatório automático ou uma conferência visual isolada como comprovação completa.

Prepare a conferência sem afetar a operação

Use o ambiente de teste combinado e dados fictícios apropriados. Se a tarefa envolve mensagens, pedidos ou integrações, esclareça quais efeitos o teste pode produzir e como o responsável os acompanhará. A conferência não deve gerar contatos comerciais ou cobranças por engano.

Para cada pendência corrigida, repita o caso afetado na nova versão e confira os caminhos que dependem dele. Alterar o menu pode atingir outras páginas. Corrigir o formulário pode exigir observar novamente envio, destino e retorno ao visitante. Guarde o resultado anterior como histórico, sem deixá-lo parecer evidência da versão atual.

Identificador e tarefa do visitante:
Página ou função incluída no escopo:
Resultado necessário e referência acordada:
Condições de uso a conferir:
Caso: estado inicial, ação e resultado esperado:
Versão, ambiente, dispositivo e navegador:
Dados fictícios e efeitos permitidos do teste:
Resultado observado e evidência:
Estado: atendido / divergência / pendente / não aplicável com motivo:
Pendência, efeito no uso e responsável:
Correção aplicada, versão e nova conferência:
Decisão de liberação, abrangência e responsável:

Confira a versão que ficará disponível ao público

A aprovação no ambiente de teste precisa ser acompanhada da conferência pertinente depois da publicação. Domínio, links, conteúdo e integrações podem depender do ambiente. Combine quem publica, quem confere os caminhos essenciais e como uma divergência será tratada.

A entrega pode incluir também arquivos, documentação, orientação e acesso às contas conforme a proposta. Registre esses itens separadamente das tarefas do visitante. Aceite de uma etapa, publicação do site e início de manutenção são marcos diferentes que precisam de condições claras.

Perguntas frequentes sobre critérios de aceite de um site

Posso definir os critérios somente no fim do projeto?

É melhor discuti-los antes da execução, junto do escopo e das necessidades. Se uma condição surgir depois, registre a mudança e seu efeito nas atividades, no prazo e nas responsabilidades.

Uma captura de tela comprova que o formulário funciona?

Ela pode mostrar uma parte da apresentação. Para conferir o fluxo, observe os casos combinados, o destino da solicitação e o retorno ao visitante no ambiente autorizado.

Pendente significa que a função apresentou falha?

Não. Pode significar que falta ambiente, acesso, informação ou execução. Registre a dependência sem apresentar ausência de evidência como sucesso ou falha.

Passar numa verificação automática comprova acessibilidade completa?

Não. A abrangência depende do método e dos requisitos avaliados. Verificações iniciais e ferramentas automáticas não substituem uma avaliação abrangente.

Se a dificuldade é traduzir o papel do site em uma entrega verificável, converse conosco sobre objetivos, conteúdo e caminhos de contato. Podemos ajudar a organizar os critérios de comunicação e as responsabilidades do projeto.