Menu

Teste Orientado ao Contexto: 7 Princípios Básicos com um Exemplo

context driven testing

Experimente Nosso Instrumento Para Eliminar Problemas

7 princípios básicos de testes orientados ao contexto com um exemplo:

como escrever casos de teste em teste manual com exemplo

Quando vou para o aeroporto, costumo pegar a rodovia que me leva em um tempo mínimo e evita pedágios. Mas naquele dia, peguei uma estrada local mais longa com pedágio. Porque eu queria alguns minutos extras com meu amigo no caminho, que viajou uma distância muito longa para passar o fim de semana com nossa família. A pior escolha normal, neste caso, acabou sendo a melhor.

Mas, considere isso.

E se eu estivesse com pouca gasolina?

E se eu estivesse com pouco dinheiro?

Eu escolheria a opção diferente. Por quê? O contexto.

O que é teste orientado ao contexto

(imagem crédito )

Quando você toma decisões com base em, o seguinte é uma decisão baseada no contexto:

  • As pessoas envolvidas
  • Circunstâncias
  • Metas
  • Opções disponíveis
  • Emoções, etc.

Então, o que é teste orientado ao contexto?

O Teste Orientado ao Contexto é uma mudança de mentalidade (ou Escola de testes) desenvolvida por Cem Kaner, James Bach e Bret Pettichord. Detalhes sobre isso podem ser encontrados em seu famoso livro: Lições aprendidas em teste de software .

Existem 7 princípios básicos para isso. Os itens a seguir foram escolhidos diretamente de seu livro:

# 1) O valor de qualquer prática depende de seu contexto.

#dois) Existem boas práticas no contexto, mas não há melhores práticas.

# 3) Pessoas, trabalhando juntas, são a parte mais importante do contexto de qualquer projeto.

# 4) Os projetos se desenvolvem ao longo do tempo de maneiras que muitas vezes não são previsíveis.

# 5) O produto é uma solução. Se o problema não for resolvido, o produto não funciona.

# 6) Um bom teste de software é um processo intelectual desafiador.

# 7) Somente por meio de julgamento e habilidade, exercidos cooperativamente ao longo de todo o projeto, somos capazes de fazer as coisas certas na hora certa para testar nossos produtos com eficácia.

Não vou explicar cada um deles porque é feito para nós pela os próprios especialistas aqui .

Vou simplesmente fazer uma explicação baseada no cenário em minha opinião sobre o Teste Orientado ao Contexto.

Um exemplo de teste orientado ao contexto:

Digamos que estou iniciando um projeto de teste - Projeto A, que inclui testes de ponta a ponta para um aplicativo baseado na web.

Qual seria a minha estratégia?

De acordo com os processos padrão, esta será a sequência de eventos:

  • Reúna os requisitos e entenda a aplicação
  • Crie um plano de teste
  • Criar documentação de teste - cenários de teste, casos de teste, matriz de rastreabilidade, etc.
  • Ter toda a documentação revisada e aprovada
  • Configurar ambiente de controle de qualidade e dados de teste
  • Realizar execução de teste
  • Crie relatórios de bug
  • Gerar e compartilhar relatórios de status de execução de teste, etc.

Se eu me perguntar: 'Como decidi que isso é o que preciso fazer?' Minha resposta seria: práticas recomendadas, padrões de controle de qualidade, diretrizes do setor, linhas de base de experiências anteriores, etc., certo?

Estou repetindo o que fui ensinado a fazer ou o que vi outras pessoas fazerem.

Agora, há algo errado com isso? De jeito nenhum. Isso pode até funcionar também porque há uma certa sensação de repetibilidade e comprovação de tempo nessa abordagem. No entanto, isso abre o caminho para resultados ideais?

Duvidoso. Por quê?

Porque em cada projeto você vai lidar com circunstâncias diferentes:

  • Requisitos documentados vs. não documentados
  • Equipes que trabalham de perto versus equipes distribuídas geograficamente
  • Equipes de desenvolvimento e teste pertencentes à mesma empresa vs. concorrência
  • Tempo suficiente vs. Horários apertados
  • A composição de sua equipe - Novatos vs. experientes. Treinados vs. não treinados.
  • Disponibilidade de ferramentas - uso de ferramenta de gerenciamento manual vs. teste
  • Tipo de projeto - precisa de cumprimento estrito das regras (FDA ou bancos) vs. experimental (como mídia social)
  • A tecnologia do projeto.Por exemplo:você não testaria a web e um aplicativo do Windows da mesma maneira
  • Requisitos dos clientes (alguns querem relatórios diários detalhados, outros querem apenas os destaques)
  • Processo seguido (Agile x tradicional, com script x teste exploratório)

Esta lista não é exaustiva e você sabe tão bem quanto eu que existem muitas variáveis ​​para cada projeto.

O teste orientado ao contexto é quando você permite que essas circunstâncias decidam suas práticas de teste, técnicas e até mesmo definições, em vez de padrão, percebido pelo setor ' Melhores Práticas' .

Agora, digamos que estes são os detalhes com os quais estou trabalhando para o Projeto A:

  • Estou trabalhando com uma equipe de 5 a 4 novatos e 1 testador experiente.
  • Não tenho requisitos documentados.
  • Minha equipe está na Índia e a equipe de desenvolvimento está nos EUA, então trabalhamos em fusos horários opostos.
  • O cliente deseja um relatório de status detalhado diário
  • Usamos uma ferramenta de rastreamento de bugs baseada na web, como Mantis ou Bugzilla e isso é tudo que temos.
  • Tenho que fazer 2 rodadas de teste em 10 dias com 3 dias para documentação de teste

Aqui está um plano de jogo básico:

1) Uma vez que muitos novatos estão na equipe, precisamos de muitas revisões por pares.

dois) Também precisamos de pelo menos 2 reuniões de discussão de requisitos com a equipe de BA e Dev. Isso tem que ser formal porque as equipes estão localizadas em outro lugar e há pouco espaço para eu ir até elas com perguntas.

3) É um cronograma de teste agressivo para documentação. Quanto mais documentação escrevermos, mais revisões precisaremos, o que significa mais tempo. Portanto, teremos que manter a documentação mínima. Vamos documentar apenas o principal TCs ponta a ponta e o resto vai ser testado exploratoriamente .

4) Relatórios diários de status durante a execução do teste serão criados e enviados EOD todos os dias.

como implementar gráfico em java

5) A maioria dos testes é exploratória, portanto, aconselhe-os na hora de tentar fazer um breve esboço de cada teste executado. Assim sabemos o que é testado e o que não é.

6) Os defeitos serão relatados em tempo real no Mantis. Como a equipe está trabalhando em um fuso horário diferente, eles podem ter que esperar um dia inteiro antes de ouvir a equipe de QA, caso precisem de um esclarecimento. Portanto, agende uma chamada diária em uma equipe conveniente, onde a equipe de QA demonstrará a recriação de bugs. Dessa forma, não haverá necessidade de espera ou acompanhamento.

E assim por diante.

Depois de ter uma estratégia geral, escreva um plano de teste básico explicando esses pontos. Agora, você está pronto para entrar em um projeto de teste após uma consideração cuidadosa e uma estratégia personalizada para o sucesso.

Resumindo:

Isto é Teste orientado ao contexto; tornando suas circunstâncias (não os padrões) as entradas e influenciadores principais para sua estratégia de teste. Exorta-nos a olhar ao redor e levar em consideração tudo ao seu redor.

Pessoalmente, adoro este conceito porque muitas vezes as práticas de teste são percebidas como rígidas e baseadas em imitações. Alguém fez isso e foi bem-sucedido, então vou fazer também. Esse é o tipo de imagem que assusta as pessoas de tentar e permanecer em uma carreira de teste.

Mas, há muito espaço para pensamento criativo, habilidades analíticas e tomada de decisão. Para saber mais, leia sobre o assunto nos links fornecidos acima.

Feliz teste orientado ao contexto

Leitura recomendada

^