Categoria:Livros

Baseado nos princípios/diretrizes identificados por Myers (2004) como de vital importância para a atividade de teste de software, será discutido em maiores detalhes cada principio nos parágrafos que se seguem.

Princípio 1: Uma parte necessária de um caso de teste é a definição dos resultados esperados.

Este princípio óbvio é um dos erros mais comuns no teste de programa. Novamente, é algo que se baseia na psicologia humana. Se o resultado esperado de um caso de teste não tenha sido pré-definidos, as chances são de que uma plausível, mas errada, o resultado será interpretado como um resultado correto por causa do fenômeno de "o olho que vê é o que queremos ver." Em outras palavras, apesar da definição adequada dos testes destrutivos, ainda existe um desejo inconsciente de ver o resultado correto. Uma forma de combater isto é incentivar um exame detalhado de toda a produção com precisão enunciada, antecipadamente, o resultado esperado do programa. Portanto, um caso de teste deve ser constituído por duas componentes: 1.A descrição dos dados de entrada para o programa. 2.Uma descrição precisa do resultado correto do programa para esse conjunto de dados de entrada. Um problema pode ser caracterizado como um fato ou conjunto de fatos para os quais não temos explicação aceitável, que parecem anormais, ou que não se encaixam com as nossas expectativas ou preconceitos. Deveria ser óbvio que algumas crenças prévias são necessárias se alguma coisa parece problemática. Se não houver expectativas, não pode haver surpresas.

Princípio 2: Um programador deve evitar a tentativa de testar o seu próprio programa. Qualquer escritor sabe - ou deveria saber - que é uma má ideia tentar editar ou revisar seu próprio trabalho. Você sabe o que a peça é suposto a dizer e não pode reconhecer quando ele diz o contrário. E você realmente não quer encontrar erros em seu próprio trabalho. O mesmo se aplica aos autores de software. Outro problema surge com a mudança de foco em um projeto de software. Depois que um programador projetou e codificou um programa de forma construtiva, é extremamente difícil, de repente, mudar a perspectiva de olhar para o programa com um olho destrutivo. Como muitos proprietários sabem, remover papel de parede (um processo destrutivo), não é fácil, mas é quase insuportavelmente deprimente se for tuas mãos que penduraram o papel. Da mesma forma, a maioria dos programadores não pode efetivamente testar os seus próprios programas, porque eles não podem trazer-se para mudar as engrenagens mentais para tentar expor erros. Além disso, um programador pode subconscientemente evitar encontrar erros, por medo de retaliação dos colegas ou de um supervisor, um cliente, ou o proprietário do programa ou sistema que está sendo desenvolvido. Além dessas questões psicológicas, não há um segundo problema significativo: O programa pode conter erros devido ao programador entender mal a declaração do problema ou a especificação. Se este for o caso, é provável que o programador vai levar o mesmo equívoco no teste de seu próprio programa. Isso não significa que é impossível para um programador para testar seu próprio programa. Pelo contrário, implica que o teste é mais eficaz e bem sucedido, se alguém faz isso. Note-se que este argumento não se aplica à depuração (correção de erros conhecidos); depuração é mais eficiente realizada pelo programador original.

Princípio 3: A organização de programação não deve testar os seus próprios programas.

O argumento é similar ao argumento anterior. Um projeto de programação ou organização é, em muitos sentidos, uma organização que vivem com problemas psicológicos semelhantes aos programadores individuais. Além disso, na maioria dos ambientes, uma organização de programação ou um gerente de projeto é em grande parte medido pela a capacidade de produzir um programa em determinada data e por certo custo. Uma razão para isso é que é fácil de medir os objetivos tempo e custo, mas é extremamente difícil quantificar a confiabilidade de um programa. Portanto, é difícil para uma organização de programação ser objetiva nos testes dos seus próprios programas, porque o processo de testes, se aproximado com a definição adequada, pode ser visto como diminuir a probabilidade de cumprimento do cronograma e os objetivos de custo. Novamente, isto não quer dizer que é impossível para uma organização de programação encontrar alguns dos seus erros, porque as organizações fazem isso com algum grau de sucesso. Pelo contrário, isso implica que é mais econômico para o teste ser realizado por uma parte objetiva, independente.

Princípio 4: Inspecione os resultados de cada teste.

Este é provavelmente o princípio mais óbvio, mas, novamente, é algo que muitas vezes é negligenciado. Temos visto inúmeras experiências que mostram que muitos indivíduos não conseguiram detectar alguns erros, mesmo quando os sintomas desses erros foram claramente observáveis na lista de saída. Dito de outra forma, os erros que são encontrados em testes posteriores são muitas vezes perdidos nos resultados dos testes anteriores.

Princípio 5: Os casos de teste devem ser escritos para as condições de entrada que são inválidas e inesperadas, bem como para aquelas que são válidas e esperadas.

Há uma tendência natural ao testar um programa para se concentrar sobre as condições de entrada válidas e esperadas, a negligência das condições inválidas e inesperadas. Por exemplo, essa tendência aparece frequentemente nos testes do programa triângulo no Capítulo 1. Poucas pessoas, por exemplo, alimentam o programa os números 1,2,5 para se certificar de que o programa não interpreta erroneamente como triângulo escaleno, em vez de um triângulo inválido. Além disso, muitos erros que são subitamente descobertos em programas de produção, aparecem quando o programa é usado, de alguma forma nova ou inesperada. Portanto, os casos de teste que representam as condições de entrada inesperadas e inválidas parecem ter um maior rendimento de detecção de erros do que os casos de teste para condições de entrada válidas.

Princípio 6: Examinar um programa para ver se ele não faz aquilo que é suposto fazer é apenas metade da batalha, a outra metade é ver se o programa faz o que não é suposto fazer.

Este é um corolário do princípio anterior. Os programas devem ser examinados para os efeitos colaterais indesejados. Por exemplo, um programa de folha de pagamento, que produz os cheques corretos ainda é um programa errado, se ele também produz cheques extras para funcionários inexistentes ou se substitui o primeiro registro do arquivo de pessoal.

Princípio 7: Evitar casos de teste descartáveis a menos que o programa é realmente um programa descartável.

Esse problema é visto com mais frequência com sistemas interativos para testar programas. Uma prática comum é sentar-se em um terminal e inventar casos de teste em tempo real, e, em seguida, enviar esses casos de teste através do programa. O grande problema é que os casos de teste representa um investimento valioso que, neste ambiente, desaparece depois que o teste tenha sido concluído. Sempre que o programa tem de ser testado outra vez (por exemplo, depois de corrigir um erro ou fazer uma melhoria), os casos de teste devem ser reinventados. Mais frequentemente do que não, pois essa reinvenção requer uma quantidade considerável de trabalho, as pessoas tendem a evitá-la. Portanto, o reteste do programa raramente é tão rigoroso quanto o teste original, o que significa que se a modificação faz com que uma parte previamente funcional do programa falhar, esse erro costuma passar despercebido. Salvar os casos de teste e executá-los novamente após alterações de outros componentes do programa é conhecido como teste de regressão.

Princípio 8: Não planeje um teste de esforço sob o pressuposto tácito de que nenhum erro seja encontrado.

Este é um erro que gerentes de projeto geralmente fazem e é um sinal do uso da definição incorreta de testes - ou seja, no pressuposto de que o teste é o processo de demonstrar que o programa funciona corretamente. Mais uma vez, a definição de teste é o processo de executar um programa com a intenção de encontrar erros.

Princípio 9: A probabilidade da existência de mais erros em uma seção de um programa é proporcional ao número de erros já encontrados naquela seção.

À primeira vista, faz pouco sentido, mas é um fenômeno presente em muitos programas. Por exemplo, se um programa é composto por dois módulos, classes ou sub-rotinas A e B, e cinco erros encontrados no módulo A e um único erro foi encontrado no módulo B, e se o módulo A não foi submetido a um propósito de teste mais rigoroso, então este princípio nos diz que de máxima verossimilhança há mais erros no módulo B. Outra forma de dizer este princípio é dizer que os erros tendem a entrar em blocos e que, no programa típico, alguns setores parecem estar muito mais propensos a erros do que outras seções, embora ninguém tenha fornecido uma boa explicação de por que isso ocorre. O fenômeno é útil na medida em que nos dá uma visão de experiência no processo de testes. Se uma seção especial de um programa parece ser muito mais propensa a erros do que outras seções, então esse fenômeno nos diz que, em termos de rendimento do nosso investimento em testes, os esforços de testes adicionais são apostas focadas contra erros desta seção.

Princípio10: O teste é uma tarefa extremamente criativa e intelectualmente desafiante

É provavelmente verdade que a criatividade necessária para testar um programa de grande criatividade ultrapassa o exigido na elaboração desse programa. Nós já vimos que é impossível testar um programa o suficiente para garantir a ausência de todos os erros. Metodologias discutidas mais tarde neste livro permitem que você desenvolva um conjunto razoável de casos de teste para um programa, mas esses métodos continuam a exigir uma quantidade significativa de criatividade.

Referencias: Glenford J. Myers. The Art of Software Testing, Second Edition