sexta-feira, janeiro 15, 2010

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.

6 comentários:

Victor Gonçalves disse...

Show de bola!, muito bom esse post sobre TDD

Koiti disse...

Mtoooo firme o post pigor!

tava pensando em construir (ferramenta ou algo do tipo) algo novo e invador em termos de ferramentas CASE principalmente voltado para testes e automatizacao, vlw mesmo o post!

mateus disse...

Fala Pigão!!

Excelente post.
A analogia foi muito válida.

Além de tudo que você falou eu diria que software testado é software 'documentado'.
Ler o teste de uma funcionalidade economiza consideravelmente o tempo que você levaria pra entender aquilo que comumente a gente se pergunta: 'pq diabos fizeram isso'!! hehehe

Abração!

Marcelo Andrade disse...

Bem colocado, Pigor. A questão que talvez muita gente não entenda é que TDD não é "teste", na acepção real da palavra, mas apenas uma outra forma de especificar software. Já tenho até visto o termo "specification driven development". Basta só as empresas 1.0 acordarem :-P

Diego Farias disse...

Aê garoto! Voltar a ler os seus posts é mto bom
=D
Esse exemplo do restaurante foi ótimo
Um abraço!

pamelagatinho disse...

Excelente post, Pigor! A analogia foi ótima! Como o Marcelo disse, espero que as empresas 1.0 acordem pra realidade!

Parabéns!