Critérios de aceitação escritos depois de concluído o desenvolvimento não são critérios de aceitação. São uma opinião formada ao observar o resultado e não podem resolver nada.
Escrever os critérios antes da construção
Os critérios de aceitação descrevem como você decidirá que uma funcionalidade está concluída, e precisam existir antes de ela ser construída por dois motivos: o desenvolvedor precisa saber qual é o objetivo da construção, e o cliente precisa de um padrão que não tenha sido influenciado pelo resultado.
Um critério utilizável é específico e testável:
- Fraco: "A pesquisa deve funcionar bem."
- Utilizável: "A pesquisa por nome do cliente retorna registros correspondentes em até dois segundos, encontra nomes parciais e não diferencia maiúsculas de minúsculas."
O segundo pode ser testado por qualquer pessoa. O primeiro não pode ser testado de forma alguma.
Realizar um UAT que encontre problemas reais
Testes de aceitação do usuário realizados como "dê uma olhada e diga o que acha" encontram problemas cosméticos e deixam passar os que realmente importam. A estrutura melhora isso enormemente.
- Teste por fluxo de trabalho, não por tela. Percorra de ponta a ponta tarefas completas realizadas por um usuário real. Os bugs vivem nas conexões entre as telas, não nas telas.
- Use dados realistas. Nomes longos, caracteres acentuados, campos opcionais vazios, grandes quantidades, datas nas transições de mês e ano. Dados de teste limpos ocultam a maioria dos problemas de tratamento de entradas.
- Teste deliberadamente os caminhos de falha. Envie o formulário duas vezes. Digite uma senha incorreta cinco vezes. Perca a conexão no meio do processo. É nesses caminhos que os usuários reais acabam e que os testes raramente percorrem.
- Faça com que os usuários reais testem. A pessoa que usará o sistema diariamente encontra problemas que o patrocinador nunca encontrará, porque sabe o que o trabalho realmente envolve.
- Registre cada descoberta em um único lugar, com as etapas para reproduzi-la e uma captura de tela. Uma descoberta que não pode ser reproduzida não pode ser corrigida.
Defeito ou mudança
Todo UAT produz descobertas que não são defeitos, e classificá-las de forma justa é o que impede que o processo se torne conflituoso.
Um defeito é uma diferença entre o que foi acordado e o que foi construído. É corrigido às custas do desenvolvedor.
Uma mudança é algo que funciona conforme acordado, mas já não é o que o cliente deseja. É orçada separadamente.
Os clientes frequentemente vivenciam a segunda situação como um defeito, porque o software faz algo que não esperavam. A resposta honesta não é discutir o rótulo, mas apontar para o critério acordado e então perguntar se vale a pena fazer a mudança. Muitas vezes, não vale.
Severidade, que determina o que bloqueia o lançamento
Nem todo defeito precisa ser corrigido antes da entrada em produção, e tratar todos como bloqueadores atrasa lançamentos sem benefício. Uma classificação simples de três níveis acordada antecipadamente:
- Bloqueador — um fluxo de trabalho essencial não pode ser concluído, dados são perdidos ou corrompidos, ou existe um problema de segurança. Deve ser corrigido antes do lançamento.
- Importante — uma funcionalidade funciona incorretamente, mas existe uma solução alternativa. Corrigido antes do lançamento se houver tempo; caso contrário, programado com uma data.
- Menor — problemas cosméticos, redação, pequenas inconsistências. Agrupado em uma versão pós-lançamento.
Acordar essa classificação antes do início do UAT transforma uma discussão sobre urgência em uma avaliação compartilhada.
A que a aprovação compromete ambas as partes
A aprovação deve ter um significado específico: os critérios acordados foram atendidos, os itens menores pendentes estão listados com datas, e o marco de pagamento é liberado. Ela inicia o período de garantia, durante o qual os defeitos encontrados posteriormente são corrigidos sem custo.
Isso não significa que o cliente nunca mais possa comunicar um problema, e um contrato que implique isso não é razoável. O período de garantia é o que cobre defeitos que um UAT razoável não teria encontrado.
Tempo a reservar
O UAT é constantemente subestimado no planejamento. Para um projeto pequeno, reserve uma a duas semanas — tempo suficiente para que usuários reais testem durante seu trabalho real, para que as descobertas sejam corrigidas e para uma nova rodada de testes.
Reduzi-lo a dois dias produz uma aprovação sem significado, e os problemas aparecem, em vez disso, na primeira semana de uso em produção, quando custam mais e são muito mais visíveis.
Serviços relacionados da Manboo
- Desenvolvimento de aplicativos Flutter para MVPs de iOS e Android.
- Desenvolvimento de software empresarial para sistemas de CRM, reservas, inventário e fluxos de trabalho.
- Desenvolvimento de painel administrativo para dashboards operacionais e gestão de back-end.
- Integração de API de IA quando seu produto estiver pronto para pesquisa inteligente, chat ou automação.
- Solicite uma revisão do escopo e uma estimativa do projeto quando estiver pronto para planejar a primeira versão.