Menu

O que é teste exploratório em teste de software (um guia completo)

what is exploratory testing software testing

Experimente Nosso Instrumento Para Eliminar Problemas

O que é teste exploratório?

“Teste exploratório” - como o nome sugere, é um processo simultâneo de aprendizagem, design de teste e execução de teste. Podemos dizer que neste teste o planejamento, a análise, o design e a execução do teste são todos feitos juntos e instantaneamente.

Este teste é para explorar o sistema e encorajar o pensamento prático e em tempo real de um testador.

Nesta série, cobrimos os seguintes tutoriais:

Tutorial nº 1: O que é teste exploratório em teste de software (Este tutorial)
Tutorial # 2: Usando tours para garantir testes exploratórios completos
Tutorial nº 3: Teste exploratório vs teste com script
Tutorial nº 4: Teste exploratório com HP Sprinter
Tutorial # 5: 17 principais ferramentas de teste exploratório

*************************************
Teste Exploratório

O que você aprenderá:

Visão geral

Em termos leigos, o teste exploratório envolve o design de caso de teste simultâneo e a execução de teste de um aplicativo ou sistema em teste. O testador criará ou escreverá uma ideia de teste para fornecer orientação e explorar o sistema enquanto testa para criar testes críticos, práticos e úteis para o teste bem-sucedido de um aplicativo.

Isso requer um planejamento mínimo. Os testadores continuamente tomam uma decisão sobre sua próxima etapa de ação. Depende completamente do processo de pensamento do testador.

Às vezes, esse teste pode ser mais benéfico do que a abordagem de teste formal para encontrando alguns defeitos sutis que desaparecem nos testes formais.

Consciente ou inconscientemente, cada um dos testadores teria feito testes exploratórios em algum momento de sua carreira.

Como todos sabemos, o aluno aprenderá melhor por meio da experiência prática, em vez de acumular teoria.

Da mesma forma, um testador conhecerá melhor o aplicativo apenas enquanto explora e aprende sobre todas as funcionalidades que ele fornece por si mesmo. É sempre bom ter uma perspectiva do cliente e do negócio durante o teste para garantir o teste bem-sucedido de um aplicativo.

Por exemplo, se você abrir um site de compras, terá uma ideia geral de que esse site de compras permitirá que você faça compras selecionando um produto de sua escolha e pagando pelo mesmo.

Durante este processo, você pode aprender que o site fornece a você uma aparência humana virtual que o ajuda no processo de seleção de produtos. Você também descobriu que pode solicitar vários produtos para teste em casa ou que pode fazer o pagamento por meio de pontos de recompensa de alguns bancos, etc.

Como testador, você não só precisa verificar se um sistema está funcionando conforme o esperado, mas também se esse sistema não está se comportando de uma maneira que não era esperada.

Algumas coisas para lembrar ao realizar este teste:

  • Sua missão deve ser clara.
  • Certifique-se de criar notas e relatar o que você está fazendo e como um sistema está se comportando, o que pode ser um bug em potencial.
  • Aprenda, observe e, em seguida, crie novos casos de teste.

Serviço de teste exploratório recomendado

# 1) Digivante Direct

Logotipo Digivante Direct

Digivante Direct realiza testes exploratórios usando sua rede global de testadores profissionais para que você possa cobrir os testes em todos os principais dispositivos em uma escala de tempo inatingível por qualquer outro fornecedor de teste ou equipe interna.

Libere com mais rapidez, segurança e permita que suas plataformas digitais proporcionem maior satisfação ao cliente e maiores receitas online.

Características:

  • 24 dias úteis de teste em apenas 24 horas ou 90 dias úteis em 72 horas, e um nível incomparável e abrangente de teste inatingível por qualquer outro meio.
  • Baixo custo , pacotes de preços fáceis de entender, sem extras ocultos.
  • Self-service portal online que não requer nenhum compromisso contínuo.
  • Pessoas reais testando em dispositivos reais - cobertura de dispositivo e navegador muito maior do que você pode obter internamente e tudo em um tempo de resposta mais rápido.
  • Cobertura completa do teste exploratório - reduz o risco e melhora a satisfação do usuário final e as taxas de conversão, aumentando assim a receita e reduzindo custos.
=> Visite o site Digivante Direct

Exemplos de teste exploratório

Exemplo 1:

Um site de provedor de serviços de atendimento domiciliar com os seguintes componentes:

  • Conecte-se
  • Serviços
  • Carrinho
  • Pagamento
  • Histórico de pedidos
  • Atribuição de técnico

Uma ideia geral para começar exploratório o teste será para fazer o login ou reservar um serviço.

Como cobrir casos de teste?

Casos de teste de teste exploratório

análises imparciais independentes de firewall de 64 bits grátis

No acima Exemplo, a ideia é começar com funcionalidades baseadas no seu conhecimento. Conforme você aprende e observa mais sobre o aplicativo, pode controlar seu próximo conjunto de casos de teste.

Exemplo # 2:

Certa vez, fui incluído em um pequeno projeto que envolvia a adição de um novo fundo mútuo na aplicação. Minha tarefa era testar o aplicativo para ter certeza de que o novo fundo mútuo está disponível para os usuários comprarem e verificar se a avaliação associada está correta. Tive apenas 2 dias para completar meu teste.

Dado o prazo apertado e a severidade dos testes, usei a abordagem exploratória de testes. Meu objetivo era testar novos recursos e encontrar violações dos requisitos de compatibilidade.

A meta mencionada acima tornou-se minha regra para esta sessão de teste.

Os seguintes casos de teste foram desenvolvidos durante este teste:

  • Teste para certificar-se de que o novo fundo mútuo foi adicionado ao aplicativo.
  • Novo MF comprado com sucesso.
  • A avaliação do novo MF está correta.
  • Tentei comprar um novo MF para um portfólio existente.
  • Um novo MF pode ser adicionado a todos os portfólios?
  • Impacto do Novo MF na avaliação dos existentes.
  • Portanto, em outros casos de teste foram evoluídos.

Preparei notas e relatórios durante meu teste para discutir minha observação com o BA e o cliente envolvido.

A estratégia fundamental do teste exploratório é ter um plano de ataque. Comece a testar com sua ideia e improvise novos casos de teste com base em seu conhecimento e observação.

Exemplo # 3:

Teste exploratório do site IRCTC

=> Clique aqui para baixar os exemplos de casos de teste de Testes Exploratórios do site do IRCTC.

Abordagem de Teste

  • Faça uso de heurísticas para orientar os testes.
  • A execução e a criação de casos de teste andam de mãos dadas.
  • Os casos de teste continuam evoluindo com base na observação e no aprendizado do testador.
  • Diferentes técnicas de teste como Análise de valor limite , testes de equivalência, etc. podem ser aplicados a ET.
  • O ET baseado em sessão pode ser usado para torná-lo mais estruturado e focado.
  • Os testadores podem ramificar suas ideias, mas nunca se desviar de sua missão.
  • O teste de ET não usa scripts, em vez disso, depende da intuição, habilidade e experiência do testador.

Benefícios

Os benefícios deste teste incluem:

  • Promova o pensamento em tempo real e ajuda a descobrir mais defeitos.
  • Promova casos de uso e testes baseados em cenário.
  • Documentação mínima, teste máximo.
  • A ênfase está mais no aprendizado e na ampliação do horizonte de um testador.
  • Evite trabalho duplicado.
  • Útil quando você deseja auditar o trabalho de outro testador.

Deméritos

Os deméritos são listados abaixo:

  • O teste depende da experiência, habilidade e conhecimento do testador.
  • Requer tempo para aprender o aplicativo. O testador tem maior probabilidade de falhar se souber menos sobre o aplicativo.
  • Não apropriado para projetos com longo tempo de execução.

Teste exploratório baseado em sessão

Ao fazer testes exploratórios, é muito difícil para os testadores colocar em palavras o quanto ele testou e com que base.

Basicamente, é difícil quantificar o trabalho e o tempo gasto. No entanto, em cada projeto, precisamos fornecer métricas, estimativas e relatório de progresso para líderes de equipe e gerentes. Como diz o ditado, “se você não pode quantificar, você não pode administrar”.

O teste baseado em sessão é uma abordagem baseada no tempo para realizar este teste, o que ajuda no gerenciamento e rastreamento. Inclui uma sessão de teste de tempo limitado sem interrupção de e-mail, telefone, mensagens, etc.

Aproximação:

As tarefas de teste são divididas em sessões.

A seguir estão os componentes do teste baseado em sessão (SBT):

  • Missão: A missão expressa o propósito da sessão e de certa forma fornece o foco para o testador. Também incluirá a duração do tempo da sessão.
  • Carta: Inclui o escopo do teste. Basicamente, uma agenda detalhando as metas que precisam ser concluídas durante a sessão.

Exemplo de regulamento de teste para funcionalidade de login do site de serviço de atendimento domiciliar:

Exemplo de regulamento de teste para funcionalidade de login

  • Sessão: Sessão de teste com limite de tempo predefinido sem qualquer interrupção. Cada sessão pode ter a seguinte duração:
    • “Curto” (60min)
    • 'Normal' (90min)
    • “Longo” (120 min)
  • Relatório de sessão: Inclua notas e relatório leve para fornecer métricas para os líderes e gerentes. Ele fornece detalhes sobre a sessão charter restante ou concluída, o tempo de configuração da sessão, o cenário testado, sobre o processo de teste, uma lista de bugs e os problemas encontrados e outras informações para as métricas.
  • Resumo da sessão: Uma breve reunião ou stand-up entre o testador e o líder / gerente de teste para revisar as descobertas da sessão de teste.

Os gerentes podem obter as seguintes métricas práticas com base no relatório da sessão:

  • O número de sessões concluídas e restantes.
  • O número de bugs relatados.
  • Tempo gasto na configuração da sessão.
  • Tempo gasto em testes.
  • Tempo gasto na análise de questões ou problemas.
  • Recursos cobertos.

Para resumir o acima:

O SBT permite a prestação de contas em testes exploratórios e oferece melhor gerenciamento do tempo gasto nos testes. Ele também aumenta a produtividade e fornece uma melhor compreensão da detecção de bugs. É uma ótima maneira de fornecer aos líderes de equipe e gerentes métricas para verificar o andamento do projeto.

Teste Exploratório Baseado em Pares

O Teste de Par é uma abordagem em que duas pessoas testam a mesma coisa / recurso do aplicativo ao mesmo tempo, compartilhando um PC. Eles continuamente compartilham seus pensamentos e idéias. Durante esse teste, uma pessoa se encarrega do teclado, enquanto a outra sugere casos de teste e toma nota.

É sempre útil ter uma boa comunicação entre os parceiros para que ambos estejam cientes do que está sendo feito e por quê. Um par em que a força dos testadores complementa mutuamente sua fraqueza é considerado um agrupamento forte.

Esse par beneficia ambas as partes e cada uma pode aprender algo com seu parceiro. Também é uma boa maneira de treinar novos recursos combinando-os com recursos experientes.

Benefícios do teste de pares

  • Ajuda o testador a se concentrar na tarefa em questão.
  • Incentive a confiança mútua e o respeito entre os parceiros.
  • O brainstorming entre testadores emparelhados geralmente leva a ideias mais construtivas.
  • Evite a visão de túnel.
  • Há uma chance menor de outros interrompê-los.

Técnicas de teste exploratório

Passeios: É uma técnica simples que permite ao testador usar sua imaginação e pensar em si mesmo como um turista que explora a cidade que visita. Aqui, um aplicativo para teste é a cidade e os testadores são os turistas. É muito difícil explorar a cidade inteira a menos que você tenha muito tempo e dinheiro na mão, então um turista precisa ter um plano com um determinado objetivo em mente.

Um turista pode fazer os seguintes passeios:

  • Tour do guia - Teste de recurso destacado do aplicativo. Use cenários baseados no usuário.
  • Explorando a história da cidade - Teste recursos antigos de um aplicativo.
  • Tour do dinheiro, o que significa ter certeza de que todos os recursos críticos em referência ao cliente ou cliente são testados e funcionando com êxito.
  • Tour do crime - Insira entradas inválidas e teste cenários negativos.
  • Tour pelo beco - Teste os recursos menos usados ​​do aplicativo.
  • Tour chato - Passe o mínimo de tempo em cada tela do aplicativo, preencha os campos mínimos e escolha o caminho mais curto. Isso ajudará com o valor padrão e o teste de validação.

Ao fazer um passeio, você sempre tem a opção de escolher qualquer caminho. Você pode navegar pelo software e encontrar um caminho exclusivo para testar o recurso.

Abaixo estão algumas dicas / truques que você pode usar no ET:

  • Divida o aplicativo em módulos e bifurque os módulos em páginas diferentes. Comece seu ET nas páginas. Isso dará a cobertura certa.
  • Faça uma lista de verificação de todos os recursos e marque quando estiver coberto.
  • Comece com um cenário básico e, a seguir, aprimore-o gradualmente para adicionar mais recursos para testá-lo.
  • Teste todos os campos de entrada.
  • Teste a mensagem de erro
  • Teste todos os cenários negativos.
  • Verifique a GUI em relação aos padrões.
  • Verifique a integração do aplicativo com outros aplicativos externos.
  • Verifique se há lógica de negócios complexa.
  • Tente fazer o hack ético do aplicativo.

Os fatores que afetam a ET são os seguintes:

  • O objetivo do projeto
  • Estratégia de teste
  • A meta de teste de uma fase específica
  • Ferramentas e instalações disponíveis
  • Função e habilidades do testador
  • Tempo disponível
  • Suporte de gestão
  • Apoio de pares
  • Recursos disponíveis (materiais de estudo, condições de teste, etc.)
  • Interesse do cliente
  • Compreensibilidade do produto.
  • A IU do aplicativo
  • A funcionalidade do aplicativo
  • Resultados de testes anteriores
  • Riscos associados ao aplicativo
  • Defeitos anteriores
  • Mudanças recentes
  • Tipos de dados a serem usados ​​para teste
  • Tipo de usuário que o usará

Em vez de perguntar aos testadores o que executar, deixamos ao critério do testador decidir o que eles querem testar e como querem testar.

Diferença entre teste exploratório e teste ad-hoc

Não confunda ET com Teste ad-hoc .

  • O teste ad-hoc refere-se a um processo de pesquisa de defeitos não planejada, não planejada e improvisada, enquanto o teste exploratório é uma metodologia inteligente para o teste Ad-hoc.
  • O teste ad-hoc é um método de tentativa e acerto para encontrar um bug, enquanto o ET não é. Na abordagem ET, um testador aprende sobre o sistema à medida que explora e, eventualmente, desenvolve os testes usando o conhecimento adquirido.
  • O teste ad-hoc é uma atividade não estruturada, enquanto a ET é, de certa forma, uma atividade estruturada.

Teste Exploratório Automatizado (EAT)

O Teste Exploratório Automatizado é um método que ajuda o testador a otimizar o relatório e a reprodução de bugs, coleta de instantâneos e na preparação de um futuro processo de regressão. É um processo que combina testes de automação com testes exploratórios.

Existem dois tipos de abordagem EAT:

  • Passivo EAT
  • EAT ativo

Passivo EAT

A EAT passiva pode ser realizada por um único testador ou também em um par. Nesta metodologia, geralmente, uma ferramenta, que captura e registra todas as atividades realizadas por um recurso (s) de teste e é instalada no PC do recurso.

O EAT passivo é semelhante ao ET que é executado manualmente, pois não há alteração na forma como os testes são executados, além da elaboração do resultado do teste com base na sessão capturada. Esses resultados de teste podem ser usados ​​para relatar e reconstituir as ações registradas posteriormente.

A ferramenta de vídeo instalada ajuda o testador com a gravação de casos de teste e relatórios de defeitos.

Ele também tem alguns outros benefícios, como:

  • Fornece etapas claras para reproduzir os bugs.
  • Reproduzir defeitos é mais fácil, mesmo quando o relator de defeitos não está disponível.
  • Elimine os conflitos entre a equipe de teste e desenvolvimento quando um bug intermitente for relatado.
  • Ajuda no teste de desempenho, obtendo o tempo de resposta do sistema em um determinado momento.

Aqui estão alguns outros pontos a serem levados em consideração antes da EAT passiva:

  • É aconselhável realizar um teste piloto antes de adaptar completamente a ferramenta para EAT Automatizado. Isso é para garantir que o tempo necessário para redesenhar os logs de teste criados durante a sessão de teste não seja mais do que a execução do teste. Nesse caso, a equipe precisa tomar uma decisão mútua sobre o seguinte:
    • Se houver, a automação de teste é necessária para o projeto específico.
    • Se a ferramenta usada precisar ser trocada.
    • Se o desempenho da ferramenta em uso pode ser otimizado.
  • A ferramenta usada para realizar EAT automatizado precisa ser instalada em todos os recursos de teste envolvidos no teste. Também é uma boa ideia envolver os desenvolvedores, o que pode ser conseguido fornecendo aos desenvolvedores VPN ou acesso remoto para testar máquinas ou instalando a ferramenta no ambiente de desenvolvimento.
  • É sempre uma boa ideia ter o objeto GUI do aplicativo organizado na ferramenta de teste para que, quando chegar a hora de analisar o bug ou um problema, o objeto seja reconhecível devido a um nome significativo.
  • É uma ótima prática dar um nome significativo ao objeto GUI usado no AUT e mantê-lo organizado para uso posterior.

Agora, vamos passar para a segunda abordagem.

EAT ativo

É aconselhável realizar EAT ativo com teste de par. Nesta abordagem, o teste baseado em palavras-chave é usado em sincronia com o teste de sessão. Um testador cria o script de teste automatizado e o segundo testador executa os scripts de teste criados pelo primeiro testador.

A criação de scripts de teste de automação nesta abordagem segue um caminho diferente do teste convencional. Os scripts de teste automatizados são feitos durante o teste e o que foi descoberto nos testes anteriores determina seu design.

Uma fase de fechamento é executada no final da sessão de teste. E deve ter as seguintes tarefas:

  • Os testadores envolvidos devem trocar de função para que o recurso de teste que criou o script de teste tenha a chance de reexecutar os scripts para confirmar a confiabilidade e robustez do conjunto criado.
  • Uma breve descrição junto com algumas características de identificação deve ser fornecida para cada script de teste automatizado.
  • Um critério precisa ser definido para identificar quais scripts de teste automatizado podem ser usados ​​para o teste de regressão.

Benefícios do EAT

  • No início de cada sessão, scripts de teste automatizados já criados são executados, aumentando assim a cobertura do teste a cada vez.
  • Melhor relatório de bugs e documentação para reprodução de defeitos.
  • O EAT fornece evidências e documentação suficientes para que uma parte interessada veja o progresso.

Tipos de teste exploratório

Abaixo estão alguns tipos de ET:

1) Estilo livre E:

Exploração do aplicativo em estilo ad-hoc.

Neste tipo de ET, não existem regras, nenhuma conta para cobertura, etc. No entanto, este tipo de teste é bom quando você precisa se familiarizar com o aplicativo rapidamente, quando deseja verificar o trabalho dos outros testadores e quando você deseja investigar um defeito ou deseja fazer um teste rápido de fumaça.

2) ET baseado em cenário:

Como o próprio nome sugere, o teste feito é baseado em cenários. Ele começa com cenários reais do usuário, cenários de ponta a ponta ou cenários de teste. Após o teste inicial, os testadores podem injetar variação de acordo com seu aprendizado e observação.

Os cenários são como um guia genérico do que fazer durante a ET. Os testadores são incentivados a explorar vários caminhos possíveis durante a execução de um cenário para garantir todos os caminhos possíveis para o trabalho do recurso. Os testadores também devem reunir o maior número possível de cenários de diferentes categorias.

3) EstratégiaET baseado:

Técnicas de teste conhecidas, como análise de valor limite, técnica de equivalência e técnica baseada em risco, que são combinadas com testes exploratórios. Um testador experiente ou familiarizado com o aplicativo é indicado para esse tipo de teste.

Teste Exploratório Ágil

Mesmo que você não tenha trabalhado em um ambiente ágil, tenho certeza de que deve ter lido ou ouvido falar nele por causa de sua popularidade crescente. A metodologia ágil tem sprints curtos e prazos apertados, o que dá a uma equipe algumas semanas para concluir o planejamento, estimativa, desenvolvimento, codificação, teste e lançamento.

O teste exploratório torna-se útil em prazos tão apertados porque, nesta abordagem de teste, a ênfase está no resultado rápido e útil. Depois de entender o requisito, você pode começar a testar com base em sua experiência e conhecimento.

Depois de se familiarizar com os recursos e o comportamento do aplicativo, você pode criar mais casos de teste para validar a funcionalidade do aplicativo e detectar bugs não planejados. Como é uma abordagem de teste de estilo livre, você precisa documentar tudo. No entanto, você precisa manter notas e um breve relatório sobre o que testou, bugs e problemas encontrados, etc.

Méritos de Exploratório em Agile

  • Fornecer feedback aos desenvolvedores o mais rápido possível.
  • Uma ampla variedade de defeitos é descoberta.
  • Um grupo diversificado de um recurso, como desenvolvedor, testador, BA e designers, pode realizar ET, pois não há casos de teste com script e cada um traz uma perspectiva diferente.
  • O reconhecimento feito em ET ajuda a explorar novos territórios e expor bugs críticos.
  • No caso de codificação iterativa de um aplicativo, o ET pode se concentrar em testar novos recursos enquanto a automação faz testes de regressão e compatibilidade com versões anteriores.
  • Em caso de requisito instável, o ET pode ajudar no teste de novo requisito dentro de um tempo limitado.

Pontos para lembrar:

1. Requer habilidades diferentes: Os testadores que executam TE precisam ter boas habilidades de escuta, leitura, pensamento e reportagem. A experiência de domínio é necessária, pois não há scripts e casos de teste.

2. Às vezes é difícil reportar um erro: Enquanto em um fluxo de ET, podemos encontrar um defeito, mas não podemos reproduzi-lo. Isso ocorre porque não estamos rastreando as etapas de teste e podemos esquecer as etapas exatas para reproduzir esse problema.

3. Pode ser feito como atividade recreativa: Eu pessoalmente faço ET quando quero interromper meu ciclo regular de execução de testes. Mas muitas equipes têm ET como uma fase separada de seu ciclo de teste.

4. Isso pode ser feito para todas as fases de teste: Podemos implementar ET antes do início de qualquer fase de teste. Você pode realizar ET antes mesmo da fase de teste funcional.

5. Feedback rápido: O ET requer um feedback rápido sobre os problemas e quaisquer anomalias encontradas.

6 Pensamento crítico e ideias diversas: Este teste requer pensamento crítico. Os testadores devem ser capazes de reproduzir, revisar e expressar suas ideias de maneira lógica. Um testador pode implementar sua experiência nas várias tecnologias e domínios em que trabalhou.

Como pensar além dos limites dos testes tradicionais em testes exploratórios

“Eu realmente aprecio sua preocupação com o produto e nos tornar úteis na compreensão da perspectiva do usuário final. Vai ser muito útil. Obrigado pelo bom trabalho e continuem !!! ”

Este foi o último e-mail de uma rede de e-mail com 21 e-mails de nosso cliente. Era meia-noite e o lançamento do nosso produto foi adiado devido a um bug crítico que encontramos. Você pode pensar, o que há de novo nisso? Isso pode acontecer muitas vezes. Mas isso era realmente diferente, pois o bug crítico que relatamos não era resultado de nenhum caso de teste documentado.

Depois de completar teste de regressão pela última vez naquela noite, eu estava apenas brincando com o produto. O que isso significa? Você é livre para fazer o que não deve fazer. Com base na minha experiência e conhecimento do projeto, tive algumas idéias sobre como testar o produto além de nosso repositório de teste típico, chamado Teste Exploratório .

O teste exploratório feito encontrou um bug crítico relacionado a um problema de travamento do servidor ao fazer algo inesperado.

Sendo um fã de testes exploratórios, adoro explorar o produto de maneiras diferentes. Para mim, a definição de software é:

“Deve fazer o que deve fazer, e não deve fazer o que não deve fazer.”

Processo de teste exploratório

Limitar os limites de teste para verificar se os produtos que deveriam funcionar estão funcionando torna você um testador incompleto. Na verdade, a vida de um testador começa quando o teste de regressão documentado termina e os resultados são atualizados. Olhar para produtos de diferentes perspectivas e entender os requisitos do usuário final em diferentes cenários faz uma grande diferença. Então, hoje, vamos entender juntos como essa diferença pode ser feita:

Como ver um produto de diferentes perspectivas?

teste exploratório

ferramenta de conversão de vídeo do youtube para mp3

# 1. Entenda o cliente / usuário final

O teste de software consiste em verificar a qualidade do produto em termos de satisfação do cliente. Como você conhece o ponto de vista de um cliente? A resposta é simples - você tem que ser o cliente. OK, deixe-me fazer uma correção. Ser cliente não será suficiente. Você precisa entender como o cliente deseja lidar com o produto. Dois clientes que compraram a mesma matéria-prima nunca irão preparar a mesma receita. Sim, o produto que desenvolvemos / entregamos é uma matéria-prima para os negócios dos clientes e eles têm uma mentalidade diferente ao usá-lo.

Como testadores de software, precisamos verificar a finalidade do produto e não o objeto ou aspecto dele.

Deixe-me dar alguns exemplos práticos da vida real:

  • Tesouras nunca se limitaram a cortar apenas papel. O corte é o propósito e não o papel (objeto).
  • Os telefones celulares nunca se limitaram a apenas chamadas, mas “poder ligar” sempre foi o propósito básico.
  • Caixas de armazenamento são usadas para armazenar, mas a segurança do material armazenado é tão importante quanto o armazenamento.

Compreender as partes interessadas e uma ampla gama de suas expectativas deve ser a linha de base dos testes exploratórios.

# 2. Uma mentalidade

Enquanto procura (digamos) um anúncio de emprego, você vê aquele jackpot e entre as páginas com a fonte em negrito? A maioria de nós não (acredite, é verdade). Porque instruímos nossa mente a procurar o que é útil ou a ser verificado. Qualquer outra coisa é inútil, então a mente nos nega o reconhecimento.

Abra sua mente e não crie expectativas quando começar a explorar um produto . Lembre-se sempre, não está tudo bem se o produto está fazendo o que deveria. Também é importante que não faça o que não deve fazer.

Lembro-me de um exemplo clássico:

No Linux, o comando 'cat' é usado para verificar o conteúdo de um arquivo e o comando 'ls' é para verificar o conteúdo do diretório. Trabalhando com Linux e fazendo testes de software há cinco anos, nunca pensei em fazer gato porque minha mente estava definida; se eu precisar de conteúdo dir, preciso usar 'ls'. Isso funcionou, mas o reverso da expectativa é que o produto não deveria se comportar da maneira que não deveria, estava errado. Um de nossos clientes, que não conhecia bem o Linux, fez gato por engano e o sistema travou. Pagamos por essa mentalidade.

Esteja sempre pronto para cometer erros com o software porque é isso que o usuário final fará. Para testar o software, você foi treinado, mas o usuário final não será tão treinado quanto você ou ele / ela não será um especialista técnico tanto quanto você. Além disso, ele fará qualquer coisa com o software quando tiver problemas.

Pense sobre esses cenários e forneça feedback de teste. A vida do software e a sua (como um testador) serão demais.

# 3. Conheça os concorrentes

Ao testar qualquer aplicativo de software para seu cliente, você já tentou conhecer e compreender outro software com o mesmo propósito? Você já sugeriu alguma funcionalidade útil que observou no produto de um concorrente? Não se enquadra em nossa descrição de trabalho, é a resposta típica. Mas você conhece a vantagem de fazer isso?

Aqui estão alguns exemplos da vida real para fazer você entender o ponto:

  • Você não gosta do estilista que não apenas costura seu vestido, mas também fornece informações sobre os acessórios que mais combinam?
  • Você não gosta da marca de pizza que não só faz ótimas pizzas, mas também as entrega em casa na hora certa?
  • Você não gosta do fotógrafo que não só tira boas fotos, mas sugere um tipo diferente de moldura para a sessão de fotos?

Todo mundo quer ter algo extra pelo que pagam. Nossa análise de software competitivo pode funcionar da mesma maneira para nós. O cliente sempre gosta de ouvir sugestões valiosas - principalmente sugestões comparativas para tornar o produto mais útil ou comercializável.

Além disso, esse tipo de comparação e análise da mesma gama de produtos torna nossa análise mais poderosa e, eventualmente, criamos um tesouro ao qual podemos voltar a qualquer momento e encontrar algo útil.

Conclusão

Exploratório não vem em uma forma convencional de teste, mas ainda assim, é uma forma muito poderosa de teste.

Ele traz à tona o pensamento pronto de um testador e o incentiva a criar casos de teste práticos e em tempo real para encontrar um defeito. Sua natureza freestyle lhe dá uma vantagem sobre os outros tipos de teste e pode ser executado em qualquer lugar, seja um projeto usando Agile ou cascata ou qualquer outro projeto que requeira documentação mínima.

O sucesso do teste exploratório depende de vários fatores intangíveis, como a habilidade de um testador, a capacidade de criar casos de teste eficazes, sua experiência e a habilidade de seguir seu instinto.

É imperativo lembrar que ET é um processo adaptativo em vez de preditivo e é essencial para manter um equilíbrio saudável entre testes exploratórios e com script ou regulares.

Você é um testador com experiências típicas de teste exploratório? Estamos esperando para ouvir seus pensamentos. Sinta-se à vontade para compartilhá-los na seção de comentários abaixo.

Próximo tutorial nº 2: Como usar passeios para garantir testes exploratórios completos

Leitura recomendada

^