Testes de comportamento

No último post, comentei sobre a importância da boa comunicação para a correta interpretação dos requisitos. Também escrevi sobre o gap de comunicação. Para continuar nessa linha, gostaria de introduzir um assunto que vai auxiliar bastante no processo de elicitação dos requisitos e, de brinde, vai gerar um ativo importante na automação dos testes. Trata-se do emprego das ferramentas de testes de comportamento.

Quando algum stakeholder solicita algo para o sistema, o faz num linguajar próprio, não técnico, muitas vezes vago ou ambíguo. Dizemos que se trata de uma necessidade. Esta não é passível de teste, por ser subjetiva. Então, precisamos transformar uma necessidade em um requisito. Este, por sua vez, é objetivo, claro e passível de verificação. Uma necessidade pode ser evoluída para um ou mais requisitos, que podem ser funcionais ou não funcionais.

As ferramentas de testes de comportamento permitem registrar os textos dos requisitos de uma maneira mais formal, mas de uma forma simples de entender. Algo do tipo:

Dado que o produto Jogo Civilization VI para PC está disponível para venda
Quando esse produto é selecionado
Então esse produto é adicionado ao carrinho de compras

Esse cenário reflete um requisito funcional do sistema. Está escrito em linguagem natural, sem detalhes avançados. Um stakeholder ligado ao negócio, sem conhecimentos técnicos, poderia validar esse requisito. Só ai já dá para ver uma enorme vantagem na adoção da ferramenta, já que nivela a forma de comunicação. Para cada necessidade, poderia ser criado um conjunto desses cenários, cobrindo a funcionalidade esperada pelo sistema.

Sabe qual a parte mais interessante? A ferramenta permite traduzir o texto do cenário em um código executável de testes. Isso possibilita que sejam criados os cenários de testes e, em seguida, o código seja desenvolvido já com uma bateria de testes pronta. Pode-se estabelecer como critério de pronto (done) da tarefa o fato dos testes estarem passando. Basicamente, a ideia do TDD, mas com testes mais complexos, exercitando cenários de negócio, e não apenas unidades de código.

Vantagens? Várias! Testes de regressão muito mais baratos, rapidez de feedback em caso de mudanças de regra de negócios, facilidade maior de corrigir problemas e (por que não citar?) profissionalismo. Trabalhar sem testes é ser amador (ou gostar muito de sofrer).

Importante: isso não invalida os testes unitários, que devem continuar existindo. Trata-se apenas de mais uma forma de garantir a qualidade, exercitando mais que uma unidade por teste de comportamento.

Recomendo plugar esse tipo de testes na camada de negócios ou de serviços, sem exercitar a interface, para que o teste fique mais robusto. Envolver a interface, que muda com certa frequência, torna o teste mais frágil. Além disso, o objetivo aqui não é validar telas.

Para conhecer mais, as ferramentas, sugiro consultar Cucumber, SpecFlow, Fitnesse, e até mesmo a Wikipedia

Ainda não está trabalhando com esse tipo de testes? Demorou para começar!

Provocações finais

Como você sabe que o desenvolvimento acabou e que todos os cenários discutidos foram cobertos?
Quanto tempo gasta para testar tudo isso de forma manual?
Se uma regra de negócio mudar, como você calcula o impacto disso no sistema?
Como você discute requisitos com seu cliente / product owner / stakeholder?
Será que é mais caro escrever o teste automático ou executar manualmente? E se precisar executar os testes mais umas cinco vezes? Cinquenta? Quinhentas?

Comentários

Postagens mais visitadas deste blog

Arquitetura em projetos de aplicações em nuvem - noções iniciais

Requisitos conflitantes e dilemas no projeto de software

Levantamento de requisitos