BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Automação de Testes de Aceitação – Teoria ou Prática

por Amr Elssamadisy , traduzido por Gisela Nogueira em 17 Jun 2009 |

Existem relatos esporádicos do sucesso em escrever requisitos e automatizá-los como teste de aceitação (algumas vezes chamado de test driven requirements, story driven development, e – dependendo de quem você pergunta - behavior driven development).  Até agora essa prática é utilizada por uma minoria da comunidade. Alguns líderes dizem que é uma idéia ruim e um desperdício de esforço. A automação de testes de aceitação escritos no início de cada interação seria somente uma afirmação teórica que se mostrou ineficaz pela falta de utilização?

Primeiramente, vamos definir o que significa automação de testes de aceitação: são testes escritos geralmente no início de uma interação e são uma forma de execução dos requisitos. Eles são exemplos detalhados de como o sistema supostamente deve funcionar quando o requisito descrito está completo – uma resposta para "Como se parece quando está pronto?" Historicamente FIT and FITNesse são as ferramentas escolhidas, no entanto, atualmente existem novas ferramentas como cucumber e rspec.

Esse tipo de teste realmente não pegou. De fato, houve recentemente uma conversa chamada Is FIT Dead?. Também, em uma entrevista com a InfoQ no Agile 2008, Brian Marick fez seu registro:

InfoQ: Então isso parece interessante. Faz sentido para mim estes testes no nível de negócio em si, coisas que o cliente entende e pretende ver. E você fala sobre exemplos. Não sei se você está utilizando isso para simplificar, para se livrar da palavra teste. Mas você está realmente falando sobre testes para cliente, não está? Você pode nos falar mais sobre isso? 
Brian: O que tenho notado de interessante é que isso não parece funcionar em nenhum ponto tão bem quanto o teste unitário do Test Driven Design, no seguinte sentido: quando você desenha um teste, você geralmente focaliza tudo o que significa, realmente, um ganho. E claro, os testes unitários fazem a mesma coisa que os testes unitários costumavam fazer. Mas a escrita real do código de teste, que é necessário para criar aquele exemplo, aquele teste automatizado para ser executado sem intervenção humana, com muita freqüência, não tem o mesmo resultado tipo “Oh! Estou realmente satisfeito de ter escrito este código, eu realmente aprendi algo, é meu, eu já escrevi um monte de códigos chatos, e não aprendi nada” então não há uma recompensa por ter escrito aquele código, você não tem um real benefício, além do benefício do próprio teste. E também, aparentemente, estes exemplos externos, não são testes de aceitação que realmente geram conseqüências estruturais profundas como uma refatoração faz em testes unitários. Então a pergunta que eu faço é se o valor está na criação do teste, e há um custo substancial para escrever todo esse código, vale realmente a pena gastar o nosso dinheiro automatizando estes testes? Porque se não compensar financeiramente, por que simplesmente não fazer os testes num quadro, com os programadores implementando-os, um de cada vez, checando-os manualmente, e até mesmo mostrando-os ao dono do produto, manualmente, e ao finalizarmos, simplesmente os apagamos e esquecemos? Porque temos esta necessidade de salvar estes testes e executá-los outra vez e mais e mais vezes, diversas vezes novamente?

Então, existem vários outros lideres na comunidade que ainda recomendam a utilização de testes de aceitação automatizados; entre eles incluem-se nomes como Robert C. Martin, Joshua Kerievsky, e James Shore, para mencionar alguns.

Chris Matts apresenta uma forma interessante de olhar o problema, como um problema de chegada das informações. Suponha que você tenha um processo de desenvolvimento de software (não necessariamente Ágil-específico) que não tem testes de aceitação escritos com antecedência. Os times de QA tipicamente executam seus próprios cenários de teste e quando o defeito é localizado é passado para os desenvolvedores. Esses defeitos são localizados randomicamente e, portanto, afetam a velocidade do time do software randomicamente porque um percentual da sua capacidade é utilizado para detectar esses defeitos. Novas informações chegam randomicamente para o time do desenvolvimento.

Agora, considere se o teste é escrito pelo departamento de QA antes que o desenvolvimento comece. A informação fornecida por esses cenários agora ocorrem no início da interação de forma previsível. Portanto, as incertezas são reduzidas, a velocidade se torna mais estável (menos interrupções randômicas), e isso significa mais previsibilidade.

Então, teste de aceitação automatizada é somente alguma coisa que a elite (ou sorte) consegue fazer funcionar? Existe uma falha interna, que não é vista, que causou a utilização menor do que a esperada? Ou é simplesmente difícil e com eficácia comprovada além de ser uma prática que todo time de desenvolvimento de software deveria adotar?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT