Boas práticas
Nomes, cenários, anotações, uma descrição e um ambiente de teste dedicado: o que faz os testes durarem.
Um teste é lido mais vezes do que é escrito
Uma gravação dá a você um teste que funciona em poucos minutos.Mais alguns minutos no GUI Test Studio o transformam em um teste que toda a equipe consegue ler: na linha do tempo, no Relatório de confiança e nos relatórios de bug que ele produz.
Tudo o que vem abaixo aparece no relatório.Um relatório que diz “Asserção Botão Salvar reprovada em Pagamento” mostra a um desenvolvedor o que quebrou antes mesmo de ele abrir qualquer coisa.
Dê nome ao que importa
Cada etapa recebe um nome automaticamente, como “Clique” ou “Asserção visual”.Dê às etapas importantes um nome seu: selecione o bloco e pressione F2.
| Em vez de | Chame de |
|---|---|
| Asserção visual | Verificar botão Novo chamado |
| Asserção textual | Verificar mensagem de pedido confirmado |
| Texto digitado | Digitar nome do cliente |
| Clique | Clicar em Validar |
Agrupe as etapas em cenários
Selecione as etapas de uma parte do percurso e pressione Ctrl+G: “Entrar”, “Adicionar ao carrinho”, “Pagar”.Um teste longo se torna alguns capítulos coloridos, o relatório diz em qual deles uma execução parou, e um cenário como “Entrar” pode ser reutilizado em outros testes.
Mais em Cenários: reutilizar grupos de etapas.
Deixe anotações
Um marcador é uma anotação na linha do tempo (M).Use-o para o que a próxima pessoa não consegue adivinhar: por que uma asserção é mais flexível, de que dados a etapa precisa, o que fazer quando ela falha.
Descreva o teste
Abra Configurações, Configurações do projeto e escreva a descrição: o que o teste cobre, o estado do qual ele parte, os dados de que precisa.
“Pagamento com um cartão salvo.Início: sem login, na página inicial, usuário de teste qa-01 com o carrinho vazio.Precisa do gateway de pagamento de teste.”
Use um ambiente de teste dedicado
Os testes são tão estáveis quanto aquilo em que são executados.Execute-os em uma máquina e com dados reservados para testes, não no computador em que você trabalha.
Um ambiente dedicado
- Uma máquina de teste ou uma máquina virtual com tamanho e escala de tela fixos
- Uma cópia de teste do seu aplicativo, com dados que são redefinidos antes de cada execução
- Contas de teste que ninguém mais usa
- Nenhuma notificação, atualização ou janela pop-up durante uma execução
Um ambiente compartilhado ou pessoal
- A sua própria área de trabalho, onde janelas e configurações mudam todos os dias
- Dados de produção que outras pessoas editam
- Uma conta compartilhada cujo carrinho ou histórico não para de mudar
- Uma máquina que entra em suspensão, bloqueia ou instala atualizações no meio de uma execução
Mantenha os testes pequenos e independentes
Um teste, um percurso.Dez testes curtos dizem exatamente o que quebrou; um teste longo só diz que algo quebrou, e tudo o que vem depois da primeira falha fica sem verificação.
Cada teste deve preparar o próprio estado inicial, com uma etapa Executar aplicativo ou Executar script Python no início, e nunca depender de outro teste ter sido executado antes.
Uma lista de verificação antes de compartilhar um teste
- O teste tem uma descrição: o que ele cobre e onde começa
- As etapas estão agrupadas em cenários com nome
- Cada asserção tem um nome que um desenvolvedor entenderia
- Valores que mudam (datas, totais, números de pedido) são verificados pelo tipo, não pelo valor
- Ele começa por conta própria, a partir de um estado conhecido
- Ele foi aprovado duas vezes seguidas na máquina de teste
Ainda com problemas?Conte o que você estava tentando fazer, e respondemos em até um dia útil.Ask our team