Um pouco sobre simples. Projeto de teste. Parte 1

Hoje, o teste de software é um dos principais processos para a criação de um produto. Não importa qual metodologia, abordagem, processo ou teste de software que você usa, de qualquer forma, sempre existe em seu processo. Nos últimos anos (e talvez até uma década), os testes de software evoluíram para uma área separada de TI, que está em constante evolução na comunidade global.

E sim, hoje falaremos sobre testadores manuais (funcionais) comuns, sem viés de automação, carga de trabalho e outros tipos técnicos de teste!

Agora, a profissão de testador manual é um dos processos de TI mais populares e uma das maneiras mais fáceis de entrar nele.

Porque

Como os testadores não fazem nada, eles não precisam de conhecimento. Todo mundo pode testar!

Porque a profissão de testador manual na fase inicial não requer conhecimentos e habilidades específicos. O principal "conhecimento" para o testador é a capacidade de "destruir" e o pensamento analítico. E o mais importante - ter uma mentalidade não padrão, encontrar soluções não triviais para as tarefas. Um certo monstro que sabe esmagar e quebrar :)

As habilidades duras sempre podem ser ensinadas, mas infelizmente as habilidades leves são muito difíceis de ensinar, porque esse é o caráter da pessoa, sua atitude em relação a algo etc. Normalmente, olho para os gerentes que estão recrutando especialistas em testes manuais para habilidades difíceis. Por que você está fazendo isso ??? (você pode deixar respostas nos comentários) Bem, ok, vamos continuar :)

Se considerarmos os recursos técnicos do teste que um testador manual deve conhecer, eles podem ser divididos em duas partes principais; talvez muitos discordem de mim; eles gritarão assim, você está errado, o teste é muito difícil - é uma preparação para o teste.

Vamos considerar a parte mais interessante e fascinante do teste - a preparação para o teste. É nessa parte do processo de teste que depende de quão bem e corretamente você realiza o teste, encontra os defeitos necessários e garante a cara satisfeita do Cliente (ou o produto do parceiro), a qualidade da tarefa após a implementação.

Muitos de vocês envolvidos nos testes, de uma forma ou de outra, estavam se preparando para os testes. A diferença geralmente está apenas no quanto você formaliza essa etapa do processo de teste. Se você estiver realizando testes de pesquisa, não escreva scripts de teste, eles fornecerão um sistema e você imediatamente entrará na batalha, de qualquer forma, estará se preparando para o teste. Freqüentemente, em projetos simples, o testador pode não perceber isso, porque o estágio de análise e preparação para o teste ocorre em um nível inconsciente. Mas, mesmo assim, ele ainda está lá.

E nesta série de artigos, falaremos sobre isso.

No meu local de trabalho, geralmente ofereço treinamento para testadores portáteis e encontro situações em que todos parecem ter ouvido falar sobre técnicas de design de teste, mas ninguém as usa no trabalho.

É assim:

• Por que precisamos de técnicas de design de teste?
• Identificar corretamente validações para teste.
• Você os usa em seu trabalho?
• Explicitamente não, nós mesmos determinamos o que precisa ser verificado.

Por que isso está acontecendo? Afinal, técnicas de design de teste são a base para escrever scripts de teste. É o mesmo que dirigir um carro, mas sem conhecer as regras de trânsito. Por que os testadores não os usam em seu trabalho?

A resposta é simples.

Primeiro, quando os testadores são ensinados em cursos de teste (ou auto-estudo em livros e artigos), eles são instruídos a aplicar técnicas de design de teste em exemplos elementares. E o principal problema desse treinamento é que os testadores não podem transferir o conhecimento adquirido para suas tarefas reais. Ou seja, use técnicas de design de teste no trabalho diário.
Segundo, ao ensinar técnicas de design de teste, esse processo é muito formalizado, que parece que um testador precisa formalizar tudo em seu trabalho. E geralmente ninguém precisa disso para ninguém.

Em palavras simples, as técnicas de design de teste são um conjunto de regras que permitem determinar corretamente a lista de verificações para teste. E o mais importante é usar essas regras sempre e em qualquer lugar :) para poder aplicar essas regras em um nível intuitivo. É a capacidade de "conduzir análises na cabeça" que distingue um bom testador!

Na minha organização, bem como padrões e práticas geralmente aceitos, as tarefas de design de teste são:

• Requisitos de teste e análise de riscos
• Definindo verificações para testes
• Formalização de verificações na forma de scripts de teste
• Priorização de verificações
• Definindo abordagens de teste

Nesta série de artigos, tentarei falar não apenas sobre técnicas de design de teste, mas também sobre como usar TODAS elas (ou seja, todas juntas e não uma ou duas específicas) na prática, incluindo o exemplo da funcionalidade do nosso banco. Como gerar verificações para teste usando técnicas de design de teste para grandes sistemas e processos. E o mais importante, você receberá uma resposta sobre quando e em quais testes aplicar as técnicas de design de teste.

Então, vamos começar.

E começaremos pela mais simples, a saber, duas técnicas básicas de design de teste que todos ouviram falar, e tenho certeza de que foram aplicadas, mas provavelmente em um nível intuitivo em seu trabalho.
Essas são classes de equivalência e valores de limite.

O que são classes de equivalência?

Classe de equivalência é um conjunto de dados de software de entrada (ou saída) que são processados ​​por um programa de acordo com um algoritmo ou levam a um resultado.

Ou seja, esse é um determinado conjunto de valores que você pode substituir no programa e obter o mesmo resultado. O resultado pode ser não apenas valores específicos, ações do programa, mas também apenas o escopo. Portanto, as classes de equivalência mais simples nas quais os testes são divididos são 2 classes principais: cenários positivo e negativo.

Eles estão sempre lá. Cada testador divide as verificações nessas classes, mas nem todo testador sabe por que ele faz isso. A resposta é classes de equivalência.

Além disso, cada classe de equivalência pode ser dividida em classes adicionais, etc. até que as verificações não levem a resultados pontuais e específicos do teste.

Considere um exemplo:

O sistema de pontuação calcula a taxa de juros de um empréstimo para um cliente com base em sua idade, inserida no formulário:

• De 18 a 25 anos - 18%
• De 25 a 45 anos - 16%
• Mais de 45 anos - 20%

Definimos 2 classes principais - são cenários positivos e negativos .

Cenários positivos serão todos os valores que levam ao resultado, cenários negativos serão os valores cujos resultados não serão descritos como o resultado esperado.

Em seguida, dividimos a classe de cenários positivos em 3 classes de valores de entrada 18-24, 25-44 e 45 +

Na classe de cenários negativos, formamos valores com base na necessidade de verificar falhas no programa, para que tenhamos 0, 1-17, valores negativos, entrada de caracteres etc.

O resultado dessa partição será um valor ou intervalo de valores em que precisamos executar apenas uma verificação com qualquer valor do intervalo de dados. Situações como um valor único em um intervalo podem ocorrer. Essa também é uma classe de equivalência separada e também requer verificação.

Total que temos.

• Verificações positivas: Inserir valores: 19, 30, 48 (os valores podem ser qualquer um de um determinado intervalo da classe)
• Verificações negativas: 0, 3, -1, A, etc.

É muito importante que as técnicas de design de teste não sejam aplicadas independentemente das outras! Agora, vamos examiná-los separadamente, mas no final, ensinarei como usá-los juntos.

Outra característica das classes de equivalência é a sua aplicação. Distingo três níveis de aplicação das técnicas de design de teste para se preparar para o teste.

• O primeiro nível é verificar os elementos do sistema (por exemplo, campos, caixas de seleção, botões, etc.)
• O segundo nível - checando a lógica do sistema ao combinar dados nos elementos do sistema
• O terceiro nível está verificando o processo de negócios do sistema e a lógica do programa.

Visualmente, fica assim:


As classes de equivalência são mais relevantes para o 1º nível e são usadas para testar os elementos do programa. Mas ideologicamente, essa abordagem pode ser aplicada a outros níveis.

Uma parte integrante da verificação de qualquer elemento é outra técnica - valores de limite .

Os valores de limite complementam classes equivalentes, cobrindo assim completamente as verificações do elemento de software.

Os valores de limite são uma técnica de design de teste que complementa as classes de equivalência com verificações adicionais no limite das condições.

Parece que tudo é simples!

Vamos voltar ao nosso exemplo anteriormente.

O sistema de pontuação calcula a taxa de juros de um empréstimo para um cliente com base em sua idade, inserida no formulário:

• De 18 a 25 anos - 18%
• De 25 a 45 anos - 16%
• Mais de 45 anos - 20%

Qual será a fronteira aqui?

Se você pensou no tamanho do campo na página Habra, ou nas férias em países quentes, quero incomodá-lo, não é assim :)

O que determinar os valores dos limites precisa de algo mais. Ou seja, determine quais valores são o início e o fim da nossa classe. E a coisa mais importante !!! Anos de pesquisa no campo de testes mostraram que a maioria dos defeitos é encontrada pelos testadores na junção de valores que alteram as condições de trabalho do programa.

Portanto, além do valor do limite, usamos 2 valores adicionais para teste, o valor antes do limite e o valor após o limite.

Como resultado, temos:

Os limites de nossas classes: 17, 18, 19, 24, 25, 26, 44, 45, 46 e máx.

Além disso, temos uma classe negativa, é de 0 a 18. Portanto, aqui também devemos usar os valores de contorno para testar: -1, 0, 1, 17,18

Em seguida, excluímos valores duplicados e obtemos valores para verificar o elemento de entrada de dados.

-1, 0, 1, 17, 18, 19, 24, 25, 26, 44, 45, 46, máx.

O valor máximo é geralmente especificado pelo cliente ou analista. Se você não pode fornecer, você deve descartá-lo e não verificar, precisa escolher o valor que corresponde ao bom senso (quase ninguém vai pedir empréstimos aos 100 anos).

O próximo passo é impor valores limites nos valores das classes de equivalência, excluir verificações desnecessárias usando a regra “um valor é suficiente para verificar uma classe” e finalizar a lista.

Se anteriormente tivéssemos 3 valores para 3 classes, 19, 30 e 48, depois de determinar os valores limite, podemos remover os valores 30 e 48 da lista e substituí-los por valores pré-limite, como 26 (em vez de 30) e 46 ( em vez de 48).

Os valores de limite são determinados não apenas para valores numéricos, mas também para valores alfabéticos (por exemplo, os limites do alfabeto e codificação), data e hora e valores semânticos. O limite dos valores numéricos depende do formato de entrada; se você tiver números inteiros, por exemplo 2, os valores dos limites serão 1 e 3. Se os valores fracionários, os limites do número 2 já serão 1,9 (1,99) ou 2,1 ( 2.01) etc.

As técnicas de design de teste de nível 1 são simples e diretas. Eu acho que você dirá que é fácil, mas por que verificar minuciosamente cada elemento. E você estará certo! ..

Na maioria das vezes, eles são usados ​​no desenvolvimento de novos softwares, porque uma vez após a verificação dos elementos do sistema durante o desenvolvimento, eles geralmente não são sujeitos a alterações no nível de operação do elemento. Você não precisa verificar constantemente cada valor de elemento em cada tela do seu programa, mas lembre-se de que, se a lógica de processamento dos elementos do programa mudar, será necessário verificar novamente se os valores do elemento foram processados ​​corretamente.

Bem, muito fácil ??? Agora vamos começar a analisar técnicas mais complexas, prepare-se.

Os técnicos de projeto de teste de nível 2 são responsáveis ​​pela variabilidade e combinatória dos dados ao testar o software.

A principal técnica do design de teste é o teste parwise (teste par a par) . A essência da técnica é minimizar a variabilidade das combinações de verificações suficientes para garantir software de alta qualidade.

Em palavras simples, a regra de Pareto é aplicada nesta técnica; 80% da qualidade pode ser alcançada em apenas 20% das verificações da combinação de dados.

Essa técnica foi desenvolvida por mais de 15 anos de pesquisa do IEEE no campo de análise das causas de defeitos no sistema. Os resultados do estudo mostraram que 98% de todos os defeitos ocorrem quando um conflito de pares de dados de entrada ou um parâmetro de entrada.

Por que o casal foi escolhido? Mergulhe na selva de estatística matemática e teoria das probabilidades para encontrar a resposta .

É claro que não vamos lá hoje. A teoria da probabilidade é muito complicada para simples especialistas em TI, tudo é simples, faça um jogo de dados comum com 6 faces.

Se a perda do valor 2 é um defeito, a probabilidade de um defeito ao lançar um cubo é 1/6 = 0,167.

Se jogarmos 2 dados, a probabilidade de cair 2 duques (2 defeitos) se torna menor e igual a 0,167 * 0,167 = 0,028, para 3 já 0,005, etc.

Acontece que a probabilidade de um defeito ocorrer com uma combinação de 3 ou mais parâmetros é tão pequena que pode ser descartada.

Quando testamos o programa, sempre há um número n de elementos que afetam o resultado, por exemplo, o formulário para preencher dados em um pedido de empréstimo. Há n número de campos que juntos dão um resultado. É a combinatória dos dados ao preencher os campos que verificamos usando o teste em pares.

Vejamos um exemplo da funcionalidade de um design de cartão remoto em um banco.


Se observarmos com atenção, veremos cinco campos de dados:

• Nome completo
• Data de nascimento
• Telemóvel
• Número do passaporte
• E-mail
• bem como 2 caixas de seleção.

Nossa tarefa, usando técnicas de primeiro nível, é determinar a lista de classes de equivalência que o programa pode executar.

É importante que, ao usar a técnica de teste em pares, não falemos sobre o resultado do teste. É importante verificar a variabilidade dos dados ao preencher o aplicativo.

Então

O campo de nome completo pode receber valores (classes):

• Nome em russo
• Valor inválido
• Valor vazio

Muitas vezes, os testadores não entendem quais valores escolher para uma determinada técnica, se não estiverem limitados pela capacidade de entrar. Por exemplo, se tivermos a oportunidade de escolher o sexo de uma pessoa M ou F, tudo será simples, existem 2 significados. Mas quando temos uma linha para entrada de dados, em testes aos pares não verificamos a exatidão do preenchimento de um campo específico, porque essas verificações devem ser realizadas no primeiro nível do projeto de teste (ou combiná-las com o teste em pares). Usamos a classe de equivalência para esse campo, porque não nos importamos com o tipo de valor que será.

Vamos além, a data de nascimento , o telefone celular, o número de série e o passaporte também podem ter três estados:

• Valor válido
• Valor inválido
• Valor vazio

Porque O email é opcional, este campo possui 2 valores:

• Valor válido
• Valor inválido

As caixas de seleção geralmente têm apenas 2 estados - Y ou N.

Para verificar todas as combinações deste formulário, precisaríamos fazer mais de 1000 testes, mas usando testes em pares, precisamos apenas de 9 testes!
Magia, eu não acho :)

O próximo passo é compor uma matriz ortogonal com combinações de dados. A maneira mais fácil de compilar uma matriz é preencher dados em pares, começando com os elementos que têm o maior número de valores e depois descendo. Como em nosso exemplo existem 4 elementos com o mesmo número de valores, podemos selecionar qualquer par.

Tomamos séries completas de nomes e números de passaportes. Nossa tarefa é separar todos os valores de um determinado par entre si:


Após iterar sobre um par, criamos outro par e começamos a iterar sobre os valores (por exemplo, o número do celular)


Conectamos o próximo elemento e assim sucessivamente até que toda a tabela esteja completamente preenchida, com a seguinte aparência:



Assim, obtemos 9 testes com classes de equivalência específicas que podemos apresentar para testar o trabalho de variabilidade de dados para o formulário. Podemos preencher as classes com valores específicos que obtemos com você usando o 1º nível da técnica de design de teste.

Em conclusão deste artigo, direi que as técnicas de design de teste revisadas abrangem apenas parte das verificações para testar o programa, ou seja, verificar a operação correta dos elementos do programa e o resultado de suas combinações durante sua operação. Na segunda parte, passaremos às técnicas de design de teste que permitem trabalhar as maravilhas do teste para testar a lógica do programa e dos processos. Este é um componente muito importante do teste manual e é exatamente isso que você costuma testar no seu trabalho!

Espero que tenha sido útil!