Os testes exploratórios procuram saber como o software funciona na realidade, e procuram fazer perguntas para saber como o software vai lidar com casos difíceis ou fáceis. Este termo foi introduzido pelo Cem Kaner (Kaner, Falk, and Nguyen, Testing Computer Software (Second Edition), Van Nostrand Reinhold, New York, 1993), que o definiu como um estilo de testes de software que enfatiza a liberdade e a responsabilidade pessoal do testador como individuo para optimizar continuamente a qualidade do seu trabalho, tratando os resultados da aprendizagem relacionada com testes,com o design de teste, a execução de teste e a interpretação dos resultados dos testes como actividades de apoio que funcionam em paralelo durante todo o projecto.
Enquanto o software está sendo testado, o testador aprende coisas que juntamente com a experiência e criatividade gera novos bons testes para executar. Teste exploratório são frequentemente considerados como uma técnica de testes caixa preta. Em vez disso, aqueles que o têm estudado considere que a abordagem pode ser aplicada a qualquer técnica de teste e em qualquer fase do processo de desenvolvimento. A chave desta técnica de testes é o envolvimento cognitivo do testador, e a responsabilidade deste para administrar o seu tempo.
Existem inúmeros motivos para se usar, e para não usar este tipo de testes, algumas dessas motivos são apresentados a seguir, Assim:
Algumas vantagens de se usar exploratory testing
- Ajudam a verificar a usabilidade da aplicação.
- Ajudam a colmatar as lacunas na documentação.
- Ajudam a encontrar buracos nos requisitos – Os testes exploratórios reportam muitas vezes erros causados por requisitos errados ou por documentação incorrecta. Geralmente acontece que os problemas aqui encontradas são de importância vital para a aplicação. Estes testes podem deitar por terra um conjunto de assumpções feitas durante o desenvolvimento de uma parte do sistema.
Algumas desvantagens na utilização de exploratory testing
- Quando usada de forma errada pode dar uma má noção do software. Esta situação quando utilizada excessivamente pode trazer rotinas aos testers tornando a detecção de erros mais difícil.
- Precisa sempre de uma boa base documental para funcionar bem.
- Detecção fraca de pequenos problemas – Os testes exploratórios são focados em encontras buracos no fluxo principal da aplicação. Mas por outro lado deixam passar ao lado situações menores, como por exemplo, campos que não estão a ser devidamente validados. Neste casos são situações para serem cobertos com testes unitários, ou para serem incluídos em baterias de testes automáticas.
- Facilmente se pode transformar numa rotina – A metodologia descrita é essencialmente baseada da dedução ou intuição do testador que a aplica, mas esta dedução vai-se degradando a medida que a pessoa em causa vai sendo exposta repetidamente às mesmas situações. Um dos modos de evitar esta situação é ir variado as equipas de testes, de modo a estas trocarem o software em uso ou mesmo trocarem os elementos da equipa.
Os teste exploratórios são uma peça fundamental na metodologia de processo de testes, mas de modo algum deve ser o único tipo de testes utilizados, pois corremos sérios riscos de deixarmos escapar muitas situações sérias. Uma sessão de testes exploratórios deve sempre possuir o foco bem definido. Não devemos simplesmente andar à toa na aplicação, mas procurar validar (ou chumbar) determinado sector da aplicação. Por exemplo testar a parte de gestão de utilizadores de uma aplicação, verificar a sua criação, edição e eliminação, alterações de privilégios e os impactos que a situação possa ter.
Pessoalmente uso os testes exploratórios normalmente na seguinte situação. È criada uma nova versão do software com um conjunto de requisitos novos. Geralmente, após uma análise da descrição dos requisitos e da documentação existente início uma sessão de testes exploratórios que geralmente tem o objectivo de perceber se na generalidade os requisitos se encontram a funcionar. Ajudam também a perceber a importância do requisito na aplicação e sobre a viabilidade ou necessidade de automação das operações em estudo.
Bom, até à próxima.
