Cobertura de teste fica prejudicada com multiplos exit points?

Volta e meia essa pergunta volta a aparecer aqui no trabalho e eu continuo advocando por testes (automatizados ou nao) mais simples possiveis - sem IFs, sem Exception handling, sem multiplos exit points. Os 2 primeiros pontos sao facilmente abstraidos botando a complexidade no lado do framework/helpers/etc, mas nao o 3o.

Imaginando a seguinte situacao de um teste com 3 passos dependentes entre si:

  • Passo A
  • Passo B
  • Passo C

Faz sentido executar o passo C se A ou B falharam? No meu pensamento faz, ja que quero saber como C reage a falha de A ou a falha de B ou considerando ambas as falhas.

Porem, automatizar o Passo C tendo essa caracteristica em mente (que A ou B podem ter falhado) pode ser bem complexo, as vezes sem necessidade. Se A falhou, mata o teste e pronto, o teste falhou de qualquer forma.

E voces, o que acham? Quais pensamentos levam voces a parar o teste no meio ou seguir adiante?

Se A ou B falharam, mas tu ainda consegue continuar um fluxo até o fim do teste, eu continuaria o teste.
Atualmente faço esse pensamento: Validações que são elementos existentes e não são críticos para seguir um teste, eu pego a falha e faço o teste continuar. Agora se for algum item que sem a presença (ou mal funcionamento do mesmo, HUE…), etc etc…é “bloqueante”, eu falho e paro a execução dos testes relacionados ao fluxo… Por que se a minha validação é “adiante” do local onde está dando problema, não faz sentido continuar. Faço assim por que esse tipo de coisa ajuda bastante em certos testes…

@ramses-saccol-de-almeida teu reporte ao “ir adiante” ficaria “C falhou” ? mesmo que, na realidade, tu tem testou C ?

Eu sei que to sendo purista ao extremo e que gerente nenhum vai diferenciar “C falhou” e “C esta bloqueado”, mas acho que faz parte do papel de QA ter esse cuidado, nem que seja so uma nota mental…

Depende do report…Se é dentro de um CI, fica com falha e o time analisa o impacto disso. (Que seria review para flakyness test, elementos com detalhes bobos errados…etc…etc…) Se é algo manual, e precisa cadastrar bug ou informar erro, eu deixo como erro e nas notas (ou junto do teste) se teve bug aberto, ou registrado em algum lugar. Uma boa política que estou fazendo, é quando já rola ajuste pequeno e foi resolvido, coloco falha e o commit (com data) em que foi ajustado. Para visualização de que algo menor já foi consertado.

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.