Testes de aceitação automatizados: o caso do CRM
Cada critério de aceite do controle de acesso virou um teste no navegador. O que foi difícil de testar, o que os testes pegaram e o que custou.
Neste artigo
Um teste de aceitação automatizado faz no sistema o que o critério de aceite descreve, do jeito que um usuário faria, e confere o resultado na tela. Neste CRM de cobrança, os 16 critérios do segundo incremento, sobre perfis, permissões e gestão de usuários, viraram 16 testes que abrem um navegador de verdade. Este artigo mostra como alguns deles foram escritos, os que deram trabalho, o que eles encontraram e quanto custaram.
Do critério ao teste#
A especificação do controle de acesso tem critérios no formato “dado, quando, então”. Um deles:
Dado a Operadora joana.souza@credor.example logada quando ela abre o menu e, depois, digita o endereço da importação então o menu não mostra Importar nem Configuração, e o endereço responde “você não tem permissão para esta ação”, com o acesso recusado registrado.
O teste repete o critério quase palavra por palavra:
def test_c33_operadora_nao_ve_nem_acessa_importacao(pagina, live_server, operadora):
entrar(pagina, live_server.url, JOANA)
expect(menu(pagina).get_by_role("link", name="Importar")).to_have_count(0)
expect(menu(pagina).get_by_role("link", name="Configuração")).to_have_count(0)
pagina.goto(live_server.url + "/importacoes/nova/")
expect(pagina.get_by_role("alert")).to_have_text("você não tem permissão para esta ação")
assert EventoAcesso.objects.filter(tipo="recusa", nome_usuario=JOANA).exists()
A segunda metade é a que importa. Esconder o botão do menu é conveniência; a proteção é o servidor recusar o endereço digitado direto. Um teste que só olhasse o menu passaria com o sistema inseguro.
Como no primeiro incremento, cada tela visitada passa por uma verificação automática de acessibilidade (WCAG 2.2, nível AA), e qualquer violação reprova o teste. As telas novas, de usuários, perfis e senha, também são testadas na largura de um celular.
Os critérios difíceis de testar#
Alguns critérios descrevem situações que um teste não consegue reproduzir literalmente. Cada um pediu uma solução, e cada solução tem um limite que vale registrar.
| Critério | O problema | Como foi testado | O limite |
|---|---|---|---|
| Trocar a própria senha encerra as sessões abertas em outros aparelhos | O teste precisa de dois aparelhos | Dois contextos de navegador independentes, com cookies separados: um troca a senha, o outro precisa voltar ao login | Não é um celular de verdade, mas a sessão é a mesma coisa |
| Senha temporária vencida (72 horas) é recusada | Ninguém espera 72 horas | O prazo da senha é movido para o passado direto no banco, e o login é tentado | O relógio não andou; um teste de regra separado confere o cálculo das 72 horas |
| Na atualização, os perfis Gestor e Operador são criados e todo usuário existente vira Gestor | É sobre a migração do banco, não sobre a tela | O teste volta o banco ao estado do incremento 1, cria um usuário antigo e aplica as migrações | Testa com um usuário só; a demonstração publicada foi a prova com dados reais |
| O administrador destrava o sistema pelo comando no servidor | Não é uma tela | O teste executa o comando e depois entra pelo navegador com o usuário destravado | Nenhum |
O padrão é o mesmo nos quatro: quando o critério não cabe num teste de navegador, o teste chega o mais perto possível, e o que fica de fora é coberto por outro tipo de teste ou por uma conferência registrada. O que não acontece é marcar o critério como testado sem ele ter sido.
O que os testes pegaram#
Um erro 500 que o uso normal levaria tempo para mostrar. Um critério diz que um perfil com usuários não pode ser apagado: o sistema deve recusar com “perfil em uso por 3 usuários”. O teste tentou apagar e recebeu uma página de erro do servidor. O código tratava a recusa corretamente, mas, ao montar a mensagem, acrescentava o erro a um formulário que não tinha sido enviado, coisa que o framework não permite. Ninguém tentaria apagar um perfil em uso nos primeiros dias de uso. O primeiro gestor a tentar teria visto uma tela de erro.
A regra de proteção funcionando onde não se esperava. A especificação proíbe deixar o sistema sem ninguém capaz de administrar usuários e perfis. Um teste que preparava os dados criava um perfil antes de existir qualquer gestor, e a regra recusou a criação. Não era defeito: a regra estava certa e o teste estava na ordem errada. É uma boa notícia sobre a regra. Ela vale para qualquer caminho, inclusive os que ninguém tinha previsto.
A suíte do incremento anterior. Depois das permissões, toda tela passou a exigir uma permissão específica. Os 109 testes do primeiro incremento rodaram de novo, inteiros. O único ajuste necessário foi que os usuários de teste precisaram ganhar um perfil, o que confirma que as regras antigas continuaram valendo com o controle de acesso novo. Sem essa suíte, a pergunta “as permissões quebraram alguma tela antiga?” seria respondida por quem usasse o sistema.
O que os testes não pegam#
Uma suíte que passa inteira diz que o sistema faz o que os critérios descrevem. Não diz que os critérios estão completos. No primeiro incremento, as dez lacunas da especificação foram encontradas por quem implementava, não pelos testes, porque os testes só verificam o que alguém escreveu. Da mesma forma, os dois defeitos visuais daquele incremento, um gráfico sem barras e uma página que rolava para o lado no celular, apareceram em capturas de tela, não na suíte.
Por isso a suíte não substitui olhar o sistema funcionando. A diferença é que, com ela, olhar o sistema passa a servir para achar o que ninguém especificou, e não para conferir de novo, a cada mudança, o que já estava especificado.
O custo#
| Item | Resultado |
|---|---|
| Critérios de aceite do incremento 2 automatizados | 16 de 16 |
| Testes no total, os dois incrementos somados | 137 |
| Tempo para rodar a suíte inteira | cerca de 6 minutos e meio |
| Defeitos encontrados pelos testes antes da publicação | 1 (o erro 500) |
| Testes do incremento 1 que precisaram de ajuste | os que criam usuários: ganharam um perfil |
Seis minutos e meio é o preço de rodar tudo a cada mudança, com um navegador de verdade e uma verificação de acessibilidade em cada tela. Em troca, cada mudança no sistema responde a uma pergunta objetiva antes de ir para o ar: os 16 critérios deste incremento e os do anterior continuam valendo?
