Teste Adhoc

O que é teste adhoc?

Quando um teste de software é executado sem planejamento e documentação adequados, é chamado de Teste Adhoc. Esse tipo de teste é executado apenas uma vez, a menos que descobramos os defeitos.

Os testes adhoc são feitos após o teste formal ser executado no aplicativo. Os métodos adhoc são o tipo de teste menos formal, pois NÃO é uma abordagem estruturada. Conseqüentemente, os defeitos encontrados com esse método são difíceis de replicar, pois não há casos de teste alinhados para esses cenários.

O teste é realizado com o conhecimento do testador sobre a aplicação e o testador testa aleatoriamente, sem seguir as especificações / requisitos. Portanto, o sucesso do teste Adhoc depende da capacidade do testador, que realiza o teste. O testador deve encontrar defeitos sem qualquer planejamento e documentação adequados, baseado exclusivamente na intuição do testador.

Quando executar o teste adhoc?

O teste adhoc pode ser executado quando há tempo limitado para fazer o teste exaustivo e, geralmente, realizado após a execução formal do teste. O teste adhoc será eficaz apenas se o testador tiver um conhecimento profundo sobre o sistema em teste.

Formas de teste adhoc:

1. Buddy Testing: Dois companheiros, um da equipe de desenvolvimento e um da equipe de teste, trabalham mutuamente na identificação de defeitos no mesmo módulo. O teste de camaradagem ajuda os testadores a desenvolver casos de teste melhores, enquanto a equipe de desenvolvimento também pode fazer alterações de design antecipadamente. Esse tipo de teste geralmente acontece após a conclusão do teste de unidade.

2. Pair Testing: Dois testadores são atribuídos aos mesmos módulos e compartilham ideias e trabalham nos mesmos sistemas para encontrar defeitos. Um testador executa os testes enquanto outro registra as notas de suas descobertas.

3. Monkey Testing: O teste é executado aleatoriamente sem nenhum caso de teste para quebrar o sistema.

Várias maneiras de tornar os testes adhoc mais eficazes

1. Preparation: Ao obter os detalhes do defeito de um aplicativo semelhante, a probabilidade de encontrar defeitos no aplicativo é maior.

2. Creating a Rough Idea: Ao criar uma ideia aproximada no local, o testador terá uma abordagem focada. NÃO é necessário documentar um plano detalhado sobre o que testar e como testar.

3. Divide and Rule: Ao testar o aplicativo parte por parte, teremos um foco melhor e uma melhor compreensão dos problemas, se houver.

4. Targeting Critical Functionalities: Um testador deve visar as áreas que NÃO são cobertas ao projetar casos de teste.

5. Using Tools: Os defeitos também podem ser trazidos à luz usando profilers, depuradores e até mesmo monitores de tarefas. Portanto, sendo proficiente no uso dessas ferramentas, pode-se descobrir vários defeitos.

6. Documenting the findings:Embora os testes sejam realizados aleatoriamente, é melhor documentá-los se o tempo permitir e anotar os desvios, se houver. Se forem encontrados defeitos, os casos de teste correspondentes são criados para ajudar os testadores a retestar o cenário.