bugslife

Mitos dos Testes Exploratórios

Os testes exploratórios são um tipo de teste onde são usados seus skilss, conhecimento e experiência como premissa para os testes. É portanto um teste baseado em experiência.

  • Com eles você descobre novas informações em caminhos que possivelmente ainda não explorados. Você pode usá-los para encontrar bugs que outras técnicas não cobrem.
  • Testes Exploratórios não são lineares, ou seja, com eles eu devo procurar novos caminhos para executar entradas e saídas variadas. – Para que você entenda melhor, se eu crio um checklist de problemas que eu encontrei no passado e verifico isto novamente, isto é uma abordagem linear.

A seguir vamos falar sobre alguns mitos dos Testes Exploratórios.

  • Mito da Completude: vamos fazer o software rodar e garantir que ele funciona antes do lançamento.

Nem todo o software está completo no lançamento de uma nova versão, ele apenas cumpre uma necessidade levantada para o momento. Então é natural que ele ainda tenha alguns detalhes e novas features para novas versões.

  • Mito da Suficiência: nós treinamos os QAs para serem Jedi’s dos testes exploratórios e então nós vamos encontrar mais defeitos graves.

Nem sempre apenas testes exploratórios são suficientes. Se não houver uma maneira sistemática para encontrar defeitos comuns da área de negócio e/ou da própria tecnologia é possível que defeitos graves possa passar mesmo você sendo o melhor QA da sua equipe.

O segredo é usar a técnica/abordagem correta para cada etapa do processo de desenvolvimento e para o estado atual do sistema.

  • Mito da Irrelevancia: nós temos TDD, ATDD e BDD, então nós temos 100% de confiança no nosso software!

Lembre que nenhum tipo de especificação é perfeita, bem como o código nunca é perfeito porque é codificado por pessoas.

Projetos ágeis geralmente trabalham balanceando os quatro quadrantes dos testes e em projetos de testes tradicionais, são aplicados os tipos e níveis de teste para cada etapa do processo de desenvolvimento. Isto inclui testes exploratórios

  • Mito Teste é Ingerenciável: quando as pessoas realizam testes exploratórios, não existe forma de gerenciar isto ou capturar a cobertura dos testes

Você pode usar ferramentas de Log, elaborar forma de reportar rapidamente.

Quais informações são subsídio para os Testes?
– Os dados, os riscos, as user stories devem ser cobertas com testes
– Detalhes que podem ser relevantes em conversar com os stakeholders
– O comportamento atual do sistema para prever comportamento alternativos
Ou você pode usar uma estratégia Reativa:
– Não usar nenhum tipo de documentação, ou seja, qualquer informação é útil para um novo teste! =D

Como organizar um Charter:

Você pode usar uma janela de tempo (time-boxing) num escopo bem definido (chamado de sessões de “charter”)

– Sessões incluem tempo para setup, projetar e executar os testes, salvar os resultados, investigar bugs, e o tempo gasto deve ser registrado.
– Sessões incluem atividades de familiarização com as features, avaliação da feature
– Sessões podem listar atores, propósito, condições de testes, entradaas e saídas de dados, atividades realizadas, oráculos de testes e variações de entrada tentadas e saídas inexperadas.

Questões para guiar um charter:
– O que é importante descobrir?
– Como o sistema deve falhar?
– O que acontece SE … ?
– O usuário vai estar satisfeito?

Use intuição, idéias, skilss com:
– Sistema, domínio de negócio, as formas como as pessoas usam o software, as formas que o sistema falha

Considere possíveis interrupções, configurações variadas, limites de dados/informação

Eis aqui um Exemplo de Card de Charter:

Ator:
Propósito:
Setup:
Prioridade:
Referências (User Story):
Dados de Teste:
Atividades: como um usuário enlouquecido tente realizar xyz
Suposição: Algumas pessoas têm menos tolerância do que outras pessoas
Variações: possibilidades são infinitas

Referências:

Anúncios

5 comentários sobre “Mitos dos Testes Exploratórios

  1. Gabriel Oliveira disse:

    Muito bacana o texto ! Sempre é bom ver pessoas desafiando mitos 🙂 !

    O foco nestes mitos acabou puxando a minha atenção, enquanto a parte de charters ficou num segundo plano que não merecia (além da escrita parecer meio corrida). Essa última merece um artigo a parte e com mais referências (ao material do James Bach ou aos outros) ou até, quem sabe, um exemplo/case de como você usa na prática.

    Te seguindo no twitter e esperando ansioso por essa continuação 😉 !

    Curtir

    • Bárbara Cabral disse:

      Yes, we can! We can choose some goals and try to find bugs. Of course sometimes we will discover a lot of possible bugs, and this kind of issue can be discussed with the team to confirm if it’s a bug or not. So, when you finish the tasks you can register the learning in order to manage the knowledge aquired. Could I be clear?

      Curtir

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s