VAMOS EXPLORAR OS TESTES EXPLORATÓRIOS?

Esse título soou um pouco redundante mas foi proposital para chamar sua atenção.

Em meu último post, Por que eu deveria automatizar minha aplicação, comentei sobre testes automáticos complementarem os testes manuais, cada um com sua importância dentro do projeto, mesmo porque um item que considero relevante em testes manuais é poder realizar testes exploratórios que enriquecem, e muito, nossos testes.

Mas vamos por partes, primeiro vamos aos conceitos:

Recordando, podem existir vários tipos de testes manuais como teste funcional, teste de caixa preta, teste de caixa branca, etc…
E para executá-los geralmente o testador seguirá um roteiro com os passos a serem seguidos e qual é o resultado esperado para cada ação, que chamamos de casos de teste.

Imagine que queremos nos desprender um pouco do script, quero fazer algo diferente do descrito no roteiro, é nesse momento que entra o teste exploratório.

Como seu nome mesmo diz, teste exploratório é aquele que o testador deixará aflorar sua criatividade, pensará em outros caminhos e possibilidades que poderiam acontecer para uma determinada funcionalidade que não foram previstos inicialmente nos casos de teste, não foram planejados serem validados.

Sempre que começamos a testar algo e até mesmo após encontrar algum erro, idéias do que poderia ser validado e outros cenários não previstos inicialmente e que seriam interessantes são imaginados no meio do teste. 

E seu eu fizer diferente? Qual seria o comportamento do sistema?

Ele está preparado para portar-se corretamente diante de determinada ação do usuário?

É o momento em que você explora o sistema, em busca de outros erros que ainda possam existir. Isso enriquece nosso trabalho e aumenta a margem de qualidade do software, então já temos um ponto positivo em aplicar o teste exploratório.

Descubra o curioso que existe em você e deixe o teste exploratório trabalhar
Descubra o curioso que existe em você e deixe o teste exploratório trabalhar

 

Vejamos um exemplo saindo um pouco de projetos de software:

Você pode testar uma nova marca de sabão em pó, por exemplo, verificar se ela atende o mínimo dos requisitos necessários para que no final do processo, lavar a roupa, seu produto final, que é a roupa limpa, seja alcançado.

Saindo um pouco de TI para esse cenário eu teria o seguinte roteiro (caso de teste):

1) Colocar a roupa suja no balde
2) Encher o balde de água
3) Colocar o sabão em pó na quantidade informada na embalagem
4) Deixar a roupa de molho o tempo determinado na embalagem
5) Esfregar a roupa
6) Enxaguar a roupa
7) Estender a roupa
8) Retirar a roupa do varal

Dado nossa “receita de bolo” como é que conseguiria encaixar um teste exploratório no meio desse cenário?
Se observarmos esse script, temos algumas possibilidades para explorar, por exemplo:

– E se eu alterar a quantidade de sabão no processo? Posso mudar para mais ou para menos do que foi estabelecido.
– E se eu alterar o tempo que a roupa fica de molho? Mesma coisa, para mais ou para menos.
– E se eu juntar as 2 coisas? Diminuir o sabão e aumentar o tempo?
– Conseguiria pular alguma etapa? Se eu não esfregar a roupa e aumentar o tempo que ficará de molho e a quantidade de sabão?
– Não foi citado no cenário mas e se eu misturar peças coloridas com peças brancas? Eu teria no fim meu produto final roupa limpa alcançado com sucesso?
– Poderia pensar ainda na possibilidade de usar recursos não descritos nesse script, poderia usar uma máquina de lavar para realizar o processo.

Enfim, no meio dessas suposições que levantei dado um cenário, meu produto final ficaria como determinado em requisitos da funcionalidade, ou seja, a roupa limpa?

Agora você pode pensar que mistura essa mulher fez e o que isso tem a ver com TI?
Tudo meu caro, é só ligar as coisas e pensar que podemos aplicar isso para outros cenários, principalmente os casos do exemplo da roupa colorida.

Muitas vezes não encontramos todas as informações nos documentos de requisitos. Como o cliente vai operacionalizar aquela funcionalidade ou pode existir mais de um cliente para aplicação e cada um utiliza de uma forma diferente de acordo com suas necessidades.

A dica que gostaria de ressaltar nesse contexto é manter-se atento sempre aos detalhes, vai perceber que neles moram potenciais cenários para pensarmos.

É claro que tentamos sempre levantar o maior número de cenários possíveis na criação dos casos de teste, mas como comentei acima nem sempre lembramos de tudo por mais focados que estejamos. Muitas idéias surgem durante o teste, e nem sempre quem escreveu o caso de teste irá executá-lo. Então, sempre que possível dentro do cenário dos projetos tente aplicar testes exploratórios. Quanto mais conseguirmos validar e garantir o funcionamento antes de liberar a versão melhor será para qualidade do software, a qual tanto prezamos.

Uma outra dica que pode fazer muita diferença no seu teste exploratório, na verdade, não somente nele, mas nos testes em geral, é o conhecimento no negócio. Se interesse pelo produto que está testando, como os clientes trabalham, busque informações. Quanto mais conhecer, dominar aquilo, vai perceber como o número de cenários que levantará para seu teste será amplo.

E você tem usado sua criatividade em seus testes?

Como geralmente aplica teste exploratório nos seus testes?

Vamos discutir a respeito, conte para gente.

Links

[1] http://www.matera.com/br/2015/09/18/por-que-eu-deveria-automatizar-minha-aplicacao/

Referências

[1] http://www.testesdesoftware.com/2009/09/tipos-de-teste.html

[2] http://pt.slideshare.net/alancarlos29/alm-testes-exploratrios-26949951

Por ARIANE FERREIRA IZAC

Analista apaixonada por testes, dançarina, corredora e colecionadora de viagens! Filha de peixe (jornalista) peixinho (blogueira) é. Meu grupo no LinkedIn só poderia ser "Diário de uma paixão: Teste de Software"

Postado em: 16 de outubro de 2015

Confira outros artigos do nosso blog

Introdução ao Dev-Test Pairing

13 de junho de 2018

Caio Rizolli

Falando sobre Teste de Intrusão (ou PenTest)

03 de abril de 2018

Jacqueline Costa

Protractor – Testes automáticos end-to-end para aplicações em Angular

07 de dezembro de 2017

Jacqueline Costa

Testes em Node.js

04 de dezembro de 2017

Alan Cesar Elias

Deixe seu comentário