Aqueles envolvidos com a engenharia de software já devem ter ouvido falar de testes de aceitação e dos seus benefícios para a implementação de sistemas que atendam as necessidades do cliente. A despeito disso a adoção da técnica ainda está longe de ser ideal; na maioria das vezes as empresas se limitam apenas a criar documentos de casos de uso para os seus projetos.
Acredito que o nome utilizado para denominar a técnica seja um dos entraves para uma maior adoção; a idéia de que teste é algo que deva ser considerado depois e não antes é muito enraizada e eu fico imaginando se não devêssemos usar um nome que reforçasse a idéia de testes de aceitação como guia do processo de captura de requisitos, algo como o que Test-Driven Development (TDD) faz com testes unitários. Há quem acredite que testes de aceitação façam parte do escopo TDD mas se analisarmos a questão com cuidado percebemos que se tratam de animais completamente diferentes. Testes de aceitação servem desde stakeholders até os programadores e durante todo o processo, não é algo que deva ser considerado apenas como artefato de desenvolvimento.
A imagem a seguir ilustra minha visão dos testes de aceitação sob o contexto das metodologias ágeis:
Reapre como testes de aceitação aqui estão para os requisitos assim como testes unitários (red-green-refactor na imagem) estão para o desenvolvimento. Claro que os testes de aceitação influenciam o desenvolvimento mas isso se deve mais a característica “onipresente” dos requisitos já que quando desenvolvemos software o fazemos com alguma motivação, afinal a intenção deveria ser de atender as necessidades de alguém ou alguma coisa não é mesmo?
Aqueles que também analisam a evolução da nossa área no decorrer do tempo já devem ter percebido como é comum velhos conceitos serem reconsiderados mais à frente em um momento mais “oportuno” e sob um novo enfoque. Enquanto as metodologias ágeis demonstram o seu valor no desenvolvimento de software talvez seja hora de aproveitar o bonde e reconsiderar testes de aceitação sob um ponto de vista que melhor reflita a sua importância para a comunicação entre os membros de uma equipe. Um nome que expressasse melhor a idéia por detrás do que chamamos hoje de testes de aceitação seria super bem-vindo!
3 Comentários
Muito bom!
Vc já deve ter ouvido falar do rspec, um framework de Behavior-Driven Development em ruby. Ele tem os 2 níveis: testes unitários e testes de aceitação.
O Behavior-Driven Development usa o nome “especificação” no lugar de “teste”.
Para o nível de testes de aceitação, o rspec fornece uma DSL onde você escreve user stories num formato proposto pelo XP, e acrescenta um pouco de código tornando essas user stories em especificações executáveis. Ou seja, o cliente/usuário consegue escrever, ler e validar as user stories e com um comando elas são “executadas” para testar se o sistema faz o que deveria.
Esse é um assunto novo pra mim. Estou começando a estudar afundo as metodologias ágeis de desenvolvimento, mas mesmo sendo iniciante nessa área eu concordo com você que é necessário um nome melhor. Mas já que o BDD escreve o comportamento e depois o executa para testar, o nome melhor seria “Teste de Comportamento”.
@Guilherme
Interessante pois minha experiência com Behaviour-Driven Development (BDD) até então tinha sido apenas com desenvolvimento middle-out. Vou procurar me informar sobre esse segundo nível do rspec mas não creio que DSLs internas sejam a melhor resposta para os stakeholders.
@Diogo
Na adoção de um novo processo por uma empresa “tradicional” é preciso ter cautela com a palavra teste já que ela pode evocar práticas incompatíveis com o mind-set ágil que se deseja introduzir. De fato essa foi a motivação inicial para o surgimento do BDD como substituto ao TDD.