Testando as Expectativas antes...

Estou estudando bastante sobre a atividade de testes ultimamente e sempre me encontro em um questionamento que acredito que seja comum entre as pessoas que praticam ou estudam essa prática...

Como provar ou avaliar que estou atendendo as expectativas do cliente?

Testar segundo nosso amigo Dicionário é: Pôr a prova, submeter a avaliação, submeter a teste ou experimentação. Refletindo sobre o contexto de software percebemos no dia-a-dia o quanto é difícil ter certeza que o software desenvolvido está de acordo com as expectativas do cliente.

Imaginem um restaurante que você vai pela primeira vez! O Restaurante novo requintado possui um cardápio com nomes esquisitos, molhos e massas com nomes nunca vistos antes e ai ficam as dúvidas: Como será esse prato? Que gosto vai ter essa mistura? Será que a quantidade é suficiente?... Nesse momento são criadas as expectativas, o cliente tem a necessidade (fome!!!) e viu as possíveis soluções dentro da realidade que ele se encontra (restaurante novo!!!), quando ele realiza seu pedido ele acredita que aquilo vai atender as suas necessidades, mas ele não tem certeza disso (notou alguma semelhança?).

O cozinheiro vai simplesmente pegar o pedido e fazer o que ele sempre faz, para atender aquele pedido. Apesar de diferente o contexto, o cozinheiro também está preocupado em atender as expectativas do cliente, mas mesmo ele fazendo o que está especificado no cardápio, ele não tem certeza que vai atender as expectativas do cliente (e agora notou a semelhança?).

Após o prato servido ao cliente inicia-se o processo de prova, ou experimentação (Teste). O cliente experimenta com o olhar (prato bonito!), com o cheiro (ta cheirando bem!) e finalmente com a degustação (eca...ta muito salgado!), e ai chegamos ao final do teste... o cliente sai insatisfeito e talvez nunca mais volte, ou na próxima vez ele da o feedback para o cozinheiro e ele refaz o prato (iterativo), com menos sal e então o cliente ficará mais satisfeito (agora tenho certeza que você notou a semelhança!).

Geralmente a atividade de teste é realizada ao final do processo de construção do software e isso gera um custo que poderia ser minimizado caso tivéssemos as expectativas do cliente mapeadas em teste para orientar o desenvolvimento (TDD – Test Driven Development), assim teríamos critérios melhores para dizer que o software desenvolvido está de acordo com as expectativas do cliente, mas mesmo assim ainda não podemos afirmar com toda a certeza que estamos atendendo 100%, por que temos que lembrar que o cliente ainda está descobrindo o que ele realmente necessita e por isso precisamos receber esse feedback constantemente para melhorar nossos critérios de aceite e melhorar o software desenvolvido. O objetivo no final é o mesmo que o do restaurante, cliente satisfeito!

A prática de TDD possui princípios simples e importantes que ajudam a desenvolver software de maneira iterativa, com design simplificado e evolutivo, código enxuto e organizado (refatoração constante).  E o que orienta tudo isso são os testes, ou seja, as expectativas mapeadas do cliente.

No TDD primeiramente procura-se mapear o que o cliente espera do software,  para depois construí-lo – simplesmente – atendendo aquela expectativa mapeada. Assim o software vai evoluindo junto com o esclarecimento das expectativas do cliente.

Os testes vão evoluindo e o software juntamente vai evoluindo também, sempre que a expectativa é atendida, analisa-se a solução e o código, para avaliar sua qualidade e verificar se pode ser melhorado (refactoring). Como temos a solução funcionando, caso algo seja feito incorretamente na refatoração, rapidamente será percebido durante a execução dos testes novamente (código blindado), além de perceber o teste ainda irá lhe indicar aonde ocorreu o erro, diminuindo o custo de depuração e correção, o ciclo é simples e bastante eficiente.

O processo é simples, mas não tão simples de realizar, pois exige muita disciplina da equipe. Mas acho que o mais importante durante o TDD é o exercício de construir coisas simples de pouco em pouco, acho que SIMPLICIDADE é a palavra em TDD.

Para não prolongar muito esse post, vou dividí-lo e no próximo colocarei um exemplo do desenvolvimento com TDD, sei que foi um post muito teórico, mas a idéia era passar a importância da automatização dos testes e mostrar a forma que é feito com TDD.

Abraço.