Planos de teste e a melhor forma de escrevê-los

Question

Estamos tentando descobrir a melhor maneira de escrever testes em nosso plano de testes.Especificamente, ao escrever um teste que deve ser usado por qualquer pessoa, incluindo a equipe de controle de qualidade, as etapas do teste devem ser muito específicas ou mais amplas, dando ao testador mais liberdade sobre como a tarefa pode ser realizada.Como um exemplo muito simples, se você estiver testando a abertura de um documento em um documento de processamento de texto, o teste deve ser:

1. Usando o mouse, abra o menu arquivo
2. Escolha "Abrir arquivo..." no menu arquivo
3. Na caixa de diálogo de abertura de arquivo que aparece, navegue até x e clique duas vezes no documento chamado y

OU

1. Abra a caixa de diálogo de abertura de arquivo
2. Abra o arquivo y

Agora percebo que uma resposta provavelmente será "depende do que você está tentando testar", mas estou tentando responder a uma pergunta mais ampla aqui:Se as etapas do teste forem muito específicas, corremos o risco de a) tornar o processo de teste muito trabalhoso e tedioso e, mais importante, b) corremos o risco de perder alguma coisa porque escrevemos um caminho muito específico para atingir um objetivo.Alternativamente, se o ampliarmos, dependeremos demais dos caprichos do testador no momento e perderemos testes cruciais de caminhos que são mais comuns aos clientes/clientes?

Answer 1

Minha primeira pergunta seria: por que seu departamento de controle de qualidade não escreve os planos de teste?Normalmente, os desenvolvedores de software fornecem ao controle de qualidade uma especificação funcional de como o software deve funcionar e, em seguida, o controle de qualidade cria planos de teste com base nisso.

Dito isso, sugiro ser muito específico com as etapas, já que você está detalhando como as coisas estão suposto trabalhar.É então função do testador garantir que suas etapas específicas obtenham os resultados desejados e também é função dele se desviar do plano e tentar quebrar as coisas.

Se houver várias maneiras de atingir uma meta, você precisará descrever cada caminho para chegar lá.

Answer 2

Não sou um testador, mas na minha opinião é vital documentar a "rota da IU" que o teste deve seguir para evitar qualquer confusão.

Trabalhei em inúmeros defeitos que não consegui reproduzir simplesmente porque não estava acessando a função no mesmo caminho da UI que o testador.por exemplo.Menu do botão direito versus barra de ferramentas ou funções que podem ser executadas em várias caixas de diálogo, etc.etc.

Answer 3

Parece que sua equipe de controle de qualidade é realmente controle de qualidade (controle de qualidade) se não for responsável por escrever testes.Se eles realmente forem responsáveis ​​por escrever testes, seus testes serão úteis, mas especificações claras seriam uma fonte melhor para eles mesmos escreverem os testes.Melhor ainda seria tê-los como parte do processo de revisão das especificações, para que possam solicitar detalhes que lhes permitirão escrever testes.

Se você realmente está em uma posição em que escreve testes para outras pessoas, há algumas considerações.Você desejará um nível doloroso de detalhes se:

• as pessoas que realizam os testes não podem fazer perguntas
• as pessoas que executam os testes não estão familiarizadas com o seu produto

Você pode evitar alguns detalhes se estes não forem verdadeiros.No entanto, ainda depende :)

Dito isto, o que você escreveu não é o que geralmente é considerado um 'plano de teste'.Um Plano de Teste descreve quais tipos de testes serão executados (funcionais, de regressão, de segurança, etc.), quais recursos serão testados, talvez até quais testes serão escritos, quem fará os testes, quando os grupos de testes serão atividades programadas e outros tipos de planejamento.

O que você descreve acima é simplesmente um conjunto de testes.

Answer 4

O primeiro é o teste de recursos.Teste com etapas detalhadas contendo a rota da IU, pois possivelmente há mais rotas de uma para o destino.Teste todas as rotas.Este último parece mais um teste de usabilidade.Isso também deve ser feito, mas não apenas pelos testadores, mas também por pessoas externas.

Answer 5

Vamos distinguir Plano de Teste e Suítes de Teste :)

Test Suite é o próprio conjunto de testes

O Plano de Teste é [parte do] Test Suite + recursos disponíveis (pessoas, hardware, tempo, ...).

Não há problema em ter ambas as variantes (detalhadas e "aproximadas") descritas em sua documentação de teste, basta colocar testes detalhados e "aproximados" em documentos diferentes e priorizar esses documentos.

Então, quando você tiver tempo suficiente para testar o produto completamente, você pega todos os documentos, digamos, da categoria A e testa o produto de acordo com esses documentos.Se você não tem tempo, mas precisa de uma conclusão rápida sobre a qualidade, você pega os documentos da categoria B e passa nas verificações ali descritas.

lado bom:você pode selecionar como testar o produto

lado ruim:você precisa de documentos "duplicados"

Answer 6

É perfeitamente normal querer etapas de reprodução exatas e detalhadas quando alguém encontra um problema.Mas se você escrever seus planos de teste dessa forma, você correrá o risco dos seguintes problemas:

1) Cegueira desatenta - Tenho observado pessoas executando um script de teste de procedimento detalhado, percorrendo e registrando cada passo meticulosamente, e PERDENDO TOTALMENTE o erro flagrante bem na frente deles.Porque "não estava no roteiro".A atenção deles estava tão focada em todas aquelas etapas meticulosas do teste que eles literalmente não conseguiam ver os problemas que tinham pela frente.

2) Você sentirá falta de TODOS aqueles bugs que estão a apenas um passo do seu caminho altamente detalhado e muito específico.Quando os clientes adquirirem seu produto, eles não seguirão o plano de teste detalhado.Eles navegarão pelo seu aplicativo de várias maneiras.Eles vão mudar de ideia.Eles terão nomes mais longos ou mais curtos do que você pensava provável ou possível.Eles chegarão na metade de uma transação e a abandonarão.Eles vão vagar.Eles não seguirão um caminho.E toda vez que alguém repetir o teste, sentirá falta desses bugs novamente.

3) Você gastará um tempo incrivelmente longo tentando escrever scripts de teste "qualquer um pode seguir isto".Acredite, passei anos tentando aperfeiçoar isso, e simplesmente não é humanamente possível.Pior ainda, a quantidade de tempo que você perde tentando fazer isso poderia ser gasto de forma muito mais lucrativa de alguma outra forma, de modo que seu produto ficaria em pior situação.

4) Você acabará com muitas repetições e será difícil dizer qual é o objetivo do seu teste sem ler tudo.Não será fácil examinar rapidamente os testes para ver quais casos de uso você pode ter perdido.

Mantenha seus planos de teste amplos e permita que as pessoas que realizam os testes exerçam seu julgamento.Se você tiver informações sobre cenários de uso específicos que devem ser testados ou sobre como o grupo de usuários-alvo deseja operar, forneça-as também aos testadores junto com os planos de teste - talvez na forma de personas de usuário, talvez apenas em a forma de casos de uso.Se você precisar de itens específicos marcados, considere usar uma lista de verificação.(Para mais informações, veja a excelente apresentação de Cem Kanerwww.kaner.com/pdfs/ValueOfChecklists.pdf).

Alternativamente, escreva seus planos de teste como breves cartas exploratórias.Você poderia, por exemplo, dar orientações como:“Os usuários do callcenter usarão estações de trabalho sem mouse conectado.Explore o processo de geração de um ticket em nome de um cliente, garantindo que seja possível concluir todas as atividades usando apenas atalhos de teclado." É muito mais provável que isso faça com que seus testadores encontrem defeitos do que dizendo "Tab no campo 1.Digite "Reclamação sobre qualidade da linha".Tabule no campo 2.Selecione "Chamada telefônica" no menu suspenso.Entre em ....campo 68."

Answer 7

há prós e contras em tratar seu testador como se ele não tivesse conhecimento do sistema ou dos computadores em geral.

se você explicar as coisas nos mínimos detalhes (por ex."no menu arquivo, selecione 'Abrir'..."), a vantagem é que você pode usar fornecedores que não estejam familiarizados com seu sistema. mas você demora mais para escrever assim

se você pular muitos detalhes (por ex."abrir um arquivo de documento..."), é mais provável que quem usa seu plano de teste fique preso e interrompa você para esclarecimentos. mas é muito mais rápido escrever

pode ser uma falsa economia pensar que é mais rápido se você fizer a versão rápida, se você acabar gastando tempo extra explicando o sistema para a pessoa de controle de qualidade

tenho um artigo onde aprofundo esse assunto: Escrevendo um plano de teste de sistema

neste artigo, sou a favor da abordagem mais detalhada.mas ultimamente tenho desenvolvido um 'ponto médio' entre essas duas abordagens (chamado de Plano de teste de RECURSO), mas ainda não estou em um ponto em que esteja maduro o suficiente para compartilhar

-LM