Quer melhorar a qualidade do código? Use evidências de testes

Isso era muito estressante pois terminávamos o programa, testávamos, e quando íamos fazer o teste com os dados que o analista passou… dava erro. Logo, tínhamos que rever todo o programa, encontrar o que não estava certo e resolver até tudo estar ok e de acordo com os dados do analista. Para ajudar, o analista somente recebia o programa com as telas (evidências de testes) confirmando que havíamos passado por todos os testes que ele solicitou.

Naquela época (meados de 90) ninguém lá (nós programadores) gostava disso, mas, com o passar do tempo acabamos percebendo o quanto aquilo era importante e contribuía para a qualidade.

Estas confirmações, ou, vamos chamar de evidências de testes, ajudavam muito na qualidade pois, ninguém entregava programas com erros (na verdade até entregava). Os analistas solicitavam evidências de teste das regras mais críticas e criavam cenários que faziam com que passasse por cada “IF”.

Imagine uma função de bonificação onde você entra com dois valores e retorna o bónus do vendedor. Eles passavam algo assim:
Bonus (100.000,30.000) retorna 5.700
Bonus (50.000,4.000) retorna 0
Bonus (60.000,10.000) retorna 0

Criavam-se cenários que verificassem as principais regras de negócio. Nossos programas tinham que dar o resultado definido pelo analista, se desse algo diferente, provavelmente o programa estaria errado (e em 99% das vezes estava), e, para garantir que tínhamos feito estes testes, os programas só eram aceitos com um print da tela com o resultado.

Claro que ainda assim apareciam alguns erros, mas eram poucos. O fator psicológico ajudava bastante.

O que vemos hoje é que a qualidade em TI caiu. Muitos programadores não testam seus programas, apenas “verificam se funciona”. Com o advento das “fábricas de testes” isso normalmente piora pois normalmente quando a fábrica é interna, os programadores deixam de testar pois “a fábrica de testes vai pegar mesmo”. Isso é péssimo pois o custo de idas e vindas entre programador e tester é muito alto. Se o programador realizar estes testes e garantir que seu programa esta correto, o tester terá menos trabalho, apenas verificando se o trabalho teoricamente bem feito, esta de fato bem feito.

Se você tem ou pensa em ter uma fábrica de testes, considere colocar como critério de entrada entre o desenvolvimento e os testes as evidências e testes. Você não precisa ter evidências de tudo não, até porque os custos iriam nas alturas, apenas instrua seus analistas a criarem uns 5 ou no máximo 10 cenários que tentem passar por tudo. E só aceitem para testes os programas que chegarem com estas evidências.

Outro ponto importante, é que os analistas devem pensar nesses cenários. Comece pelo bom e velho teste de mesa, você verá que suas dores de cabeça com qualidade tendem a diminuir.

Por fim, as empresas que conheço que utilizam este método não se arrependem.