Testes ad-hoc: Como encontrar defeitos sem um processo de teste formal

O próprio termo ad-hoc implica a falta de estrutura ou algo que não é metódico. Quando você fala sobre testes ad-hoc, significa que é uma forma de caixa preta ou teste comportamental realizado sem qualquer processo formal no lugar.

O processo formal aqui significa ter documentação como documentos de requisitos, Planos de Testes, Casos de Testes, e Planejamento de Testes adequado em termos de sua programação e ordem de testes realizados. Além disso, quaisquer ações realizadas durante os testes não são tipicamente documentadas.

Isto é feito principalmente com o objetivo de tentar descobrir defeitos ou falhas que não podem ser capturados através de processos tradicionais ou formais seguidos durante o ciclo de testes.

Como já entendido, a essência deste teste reside em não ter uma forma formal ou estruturada de teste. Quando este tipo de técnicas de teste aleatório é realizado, é evidente que os testadores realizam este tipo de teste sem nenhum caso particular de uso em mente com o objetivo de quebrar o sistema.

Acima de tudo, é definitivamente ainda mais óbvio que tal metodologia de teste intuitiva ou criativa requer que o testador seja extremamente habilidoso, capaz e tenha um profundo conhecimento do sistema. O teste ad-hoc garante que o teste realizado é completo e é particularmente útil na determinação da eficácia do balde de teste.

Leitura recomendada => Teste Exploratório – Como Pensar Além dos Limites dos Testes Tradicionais?

Vamos começar com um exemplo de teste ad-hoc

Aqui está um exemplo de como podemos executar este teste quando se trata do Assistente de IU.

Vamos dizer que você precisa criar um plano ou um template para algum tipo de tarefa a ser executada usando este assistente de IU. O assistente é uma série de painéis que têm entrada de usuário como nome, descrição, etc.

A medida que o assistente progride: digamos em um dos painéis, os dados do usuário devem ser inseridos, o que envolve o assistente de IU para lançar uma caixa pop-up de contexto que adiciona os dados associados para completar o assistente e implantar/ativar o assistente.

Para testar este testador faz seus testes regulares como:

• Completar o assistente com sucesso com todos os dados válidos e criar o plano.
• Cancelar o assistente a meio caminho.
• Editar um plano criado através do wizard.
• Eliminar o plano criado e ver que não há resíduo do mesmo.
• Entrar um valor negativo no wizard e ver que as mensagens de erro apropriadas são vistas.

Agora, para o exemplo acima, aqui estão alguns casos de testes para testes ad-hoc que poderiam ser realizados para descobrir o maior número possível de defeitos:

• Embora tentando adicionar dados negativos, adicione certos caracteres especiais que não são restritos para ver se eles são tratados corretamente. Por exemplo, por vezes os feiticeiros não restringem {ou [ chaves, mas em certas situações, isto pode entrar em conflito com o código baseado na linguagem em que está escrito, e causar um comportamento muito pouco fiável.
• Outro teste é especificamente com respeito a pop-ups. Um usuário pode fazer com que o pop up seja iniciado e depois tentar pressionar o botão de backspace no teclado. Muitas vezes eu observei que fazendo isso, faz com que o assistente de background desapareça completamente e todos os dados do usuário que foram inseridos até o ponto em que o pop-up foi lançado, se perdem!

Características do teste ad-hoc:

Se você observar os cenários acima, você verá algo muito distinto deste tipo de teste.

Eles são:

• Eles estão sempre de acordo com o objetivo do teste. No entanto, são certos testes drásticos realizados com a intenção de quebrar o sistema.
• O testador precisa ter conhecimento e consciência completa sobre o sistema que está sendo testado. O resultado deste teste encontra bugs que tentam destacar as lacunas do processo de teste.
• Olhando também para os dois testes acima, a reação natural a ele seria que – este tipo de teste pode ser realizado apenas uma vez, pois não é viável para um re-teste a menos que haja um defeito associado.

Quando fazemos testes ad-hoc?

Uma pergunta de um milhão de dólares!

As equipas de teste da maior parte do tempo estão sempre sobrecarregadas com demasiadas características para testar dentro de linhas de tempo limitadas. Nesse espaço de tempo limitado, há muitas atividades de teste que são derivadas do processo formal que também devem ser concluídas. Em tais situações, os testes ad-hoc que se encontram no teste são finos.

No entanto, pela minha experiência, uma rodada de testes ad-hoc pode fazer maravilhas para a qualidade do produto e levantar muitas questões de design.

Desde que o teste ad-hoc é mais uma técnica de teste “wild-child” que não precisa ser estruturada, a recomendação geral é que ela deve ser realizada após a execução do balde de teste atual é feito. Outro ponto de vista é que isto pode ser feito quando o teste detalhado não pode ser executado devido a menos tempo.

Na minha opinião, eu diria que o teste ad-hoc pode ser feito quase a qualquer momento – no início, no meio e no fim! Ele apenas encontra o seu lugar a qualquer momento. No entanto, quando os testes ad-hoc devem ser feitos para trazer o máximo valor é melhor julgado por um testador experiente que tenha um conhecimento profundo sobre o sistema a ser testado.

Quando não executar?

Se a pergunta anterior valia um milhão de dólares, este deveria valer um bilião!

Embora tenhamos estabelecido quão eficazes e frutuosos os testes ad-hoc podem ser, como um testador hábil e capaz também precisamos de decifrar quando não devemos investir neste tipo de testes. Embora fique ao critério do testador, aqui estão algumas recomendações/exemplos quando pode não ser necessário.

• Evite este teste quando houver um caso de teste para o qual exista um defeito. Em tal situação há a necessidade de documentar o ponto de falha do caso de teste e então verificar/testar o defeito quando ele for corrigido. Portanto, não será aplicável aqui.
• Pode haver também certos cenários em que clientes ou clientes podem ser convidados a testar a versão beta do software. Nesses casos, esse teste não deve ser realizado.
• Outro cenário é quando há uma tela de IU muito simples que é adicionada. Os testes tradicionais positivos e negativos devem ser suficientes aqui para trazer o máximo de defeitos.

Tipos de testes ad-hoc

Testes ad-hoc podem ser categorizados em três categorias abaixo:

#1) Teste de Amigo

Nesta forma de teste, haverá um membro de teste e um membro de desenvolvimento que será escolhido para trabalhar no mesmo módulo. Logo após o desenvolvedor completar o teste da unidade, o testador e o desenvolvedor se sentarão juntos e trabalharão no módulo. Este tipo de teste permite que o recurso seja visto em um escopo mais amplo para ambas as partes.

O desenvolvedor ganhará uma perspectiva de todos os diferentes testes que o testador executar e o testador ganhará uma perspectiva de como o projeto inerente é, o que o ajudará a evitar projetar cenários inválidos, evitando assim defeitos inválidos. Isto ajudará um a pensar como o outro.

#2) Teste de Pares

Neste teste, dois testadores trabalham juntos em um módulo com a mesma configuração de teste compartilhada entre eles. A idéia por trás desta forma de teste para que os dois testadores tenham idéias e métodos para ter um número de defeitos. Ambos podem compartilhar o trabalho de teste e fazer a documentação necessária de todas as observações feitas.

#3) Teste com macacos

Este teste é realizado principalmente no nível de teste de unidade. O testador analisa os dados ou testes de forma completamente aleatória para assegurar que o sistema é capaz de resistir a qualquer colisão. Este teste pode ser ainda classificado em duas categorias:

Benefícios dos testes ad-hoc

Este teste garante que o testador com muito poder seja tão criativo quanto necessário.

Esta forma de teste aumenta a qualidade e eficiência como abaixo:

• A maior vantagem que se destaca é que um testador pode encontrar o número de defeitos do que nos testes tradicionais, devido aos vários métodos inovadores que eles podem aplicar para testar o software.
• Esta forma de teste pode ser aplicada em qualquer lugar no SDLC; não é restrita apenas à equipe de teste. Os desenvolvedores também podem conduzir este teste, o que os ajudaria a codificar melhor e também prever que problemas podem ocorrer.
• Pode ser acoplado a outro teste para obter os melhores resultados, o que às vezes pode encurtar o tempo necessário para os testes regulares. Isto permitiria gerar casos de teste de melhor qualidade e melhor qualidade do produto em geral.
• Não exige nenhuma documentação a ser feita, o que evita a sobrecarga extra para o testador. Um testador pode concentrar-se em compreender realmente a arquitetura subjacente.
• Em casos em que não há muito tempo disponível para testar, isto pode ser muito valioso em termos de cobertura e qualidade do teste.

Desvantagens dos testes ad-hoc

Os testes ad-hoc também têm algumas desvantagens. Vamos dar uma olhada em alguns dos inconvenientes que são pronunciados:

Porque não é muito organizado e não há documentação obrigatória, o problema mais evidente é que o testador tem que lembrar e relembrar todos os detalhes dos cenários ad-hoc na memória. Isto pode ser ainda mais desafiador especialmente em cenários onde há muita interação entre diferentes componentes.

• Seguido desde o primeiro ponto, isto também resultaria em não ser capaz de recriar defeitos nas tentativas subseqüentes se pedidas informações.
• Outra questão muito importante que isto traz à tona é a responsabilidade do esforço. Como isto não está planejado/estruturado, não há como prestar contas do tempo e esforço investidos neste tipo de teste.
• Testes ad-hoc só têm que ser realizados por um testador muito experiente e habilidoso na equipe, pois exige ser proativo e intuição em termos de previsão de áreas com potencial de defeitos.

Best Practices To Make This Testing More Effective

Discutimos longamente os pontos fortes e fracos associados a este teste.

De facto, os testes ad-hoc devem encontrar o seu lugar no SDLC, no entanto, se não forem abordados da forma apropriada, podem revelar-se dispendiosos e um desperdício de tempo de teste valioso. Assim, abaixo estão algumas dicas para tornar o teste ad-hoc eficaz:

#1) Identificar áreas propensas a defeitos:

Quando você tiver um bom controle sobre o teste de um software em particular, você concordará que haverá certas características que são mais propensas a erros do que as outras. Se você é novo no sistema, então vá em frente e verifique as características v/s defeitos abertos contra eles.

O número de defeitos em uma característica em particular vai lhe mostrar que ela é sensível e você deve precisamente escolher essa mesma área para realizar testes ad-hoc. Isto prova ser uma forma muito eficiente de expor alguns defeitos graves.

#2) Construindo perícia:

Sem dúvida, um testador que tem mais experiência é mais intuitivo e pode adivinhar onde os erros podem estar, quando comparado com alguém que não tem muita experiência. Eu diria, experiente ou não, cabe ao indivíduo dar o mergulho e construir expertise no sistema que está sendo testado.

Sim, os testadores experientes têm uma vantagem, pois suas habilidades construídas ao longo dos anos vêm a calhar, mas os novos testadores devem usar isso como uma plataforma para ganhar o máximo de conhecimento possível para projetar melhores cenários ad-hoc.

#3) Criar categorias de teste:

Após estar ciente da lista de funcionalidades a serem testadas, reserve alguns minutos para decidir como categorizar essas funcionalidades e testar. Por exemplo, você deve decidir testar os recursos que são mais visíveis e mais comumente usados pelo usuário antes de qualquer outra coisa, pois estes parecem críticos para o sucesso do software.

Então você poderia categorizá-los funcionalidade/ prioridade e testá-los segmento por segmento.

Outro exemplo onde isto é particularmente importante é se há integração entre componentes ou módulos. Nesses casos, pode haver muitas anormalidades que podem ocorrer. Usando categorização ajudaria a tocar neste tipo de teste pelo menos uma ou duas vezes.

#4) Tenha um plano aproximado:

Sim, sim, este ponto pode confundi-lo um pouco como nós descrevemos testes ad-hoc como testes que não devem ter nenhum planejamento ou documentação. A idéia aqui é se ater à essência dos testes ad-hoc, mas ainda assim, ter algumas dicas básicas sobre como você planeja testar.

Um exemplo muito básico é que às vezes você pode simplesmente não ser capaz de lembrar de todos os testes que você pretende realizar. Assim, anotá-los asseguraria que você não perderia nada.

#5) Ferramentas:

Vamos dar um exemplo que todos nós enfrentamos muito comumente. Muitas vezes, se você observar, o teste da funcionalidade em si é bem sucedido, sem nenhuma discrepância relatada em seu comportamento. No entanto, os logs nos bastidores podem estar relatando algumas exceções vistas que podem não ser vistas pelos testadores, pois não atrapalha de forma alguma o objetivo do teste.

Estes podem até ser de alta severidade. Por isso é muito importante para nós aprender e ferramentas que ajudarão a identificar isso imediatamente.

#6) Documento para mais defeitos:

Again, eu entendo que isso pode levantar algumas sobrancelhas novamente. A documentação não tem que ser detalhada, mas apenas uma pequena nota para sua própria referência de todos os diferentes cenários cobertos, desvio nas etapas envolvidas e registrar esses defeitos para a categoria particular de recurso de teste.

Isso o ajudará a melhorar o balde de teste geral, onde você poderá decidir como improvisar os casos de teste existentes ou adicionar mais, se necessário.

Conclusão

Discutimos em detalhe as técnicas de teste ad-hoc – os seus pontos fortes, fracos, situações em que seria e não seria benéfico.

Esta é uma técnica de teste que garante atender e satisfazer ao máximo a criatividade de um testador. Em toda a minha carreira de teste, eu ganho a maior satisfação com os testes ad-hoc, pois não há limite para ser inovador e você só acaba sendo mais conhecedor.

Dito isto, o principal a retirar de todas as informações acima seria determinar como aproveitar os pontos fortes dos testes ad-hoc e fazer com que eles agreguem valor ao processo geral de teste e à qualidade do produto.

Sobre o autor: Este é um artigo convidado de Sneha Nadig. Ela está trabalhando como líder de testes com mais de 7 anos de experiência em projetos de testes manuais e de automação.

Você realiza testes ad-hoc no seu projeto? Quais são as suas sugestões para tornar os testes ad-hoc bem sucedidos?