Publicidade - Adsense

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?


  • MVP

    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…


  • MVP

    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.


 

Publicidade - Adsense

status at

6
Online

2.7k
Usuários

1.7k
Tópicos

5.6k
Posts

Parece que sua conexão com Agile Testers caiu, por favor aguarde enquanto tentamos reconectar.

});