Testes de aceitação automatizados: por onde começar?

A ideia deste post é compartilhar uma dica a qual creio ser importante quando se fala da escrita de testes de aceitação automatizados.

Enquanto lia o capítulo sobre a implantação de estratégias de testes do livro Continuous Delivery, de Jez Humble e David Farley, passei por um sub-capítulo que fala de testes voltados a perspectiva de negócio e os quais suportam o processo de desenvolvimento de software.

No livro, os autores fazem referência ao quadrante dos testes, pela primeira vez citado por Brian Marick, no qual existem atividades de teste tanto da perspectiva de negócios, como voltados à tecnologia, e atividades de testes que suportam o processo de desenvolvimento, como atividades que criticam o projeto.

Os testes de aceitação automatizados ficam no quadrante voltado ao negócio e que suportam o projeto, como já mencionado. Este é o quadrante foco deste post.

Quando se fala de testes de aceitação automatizados neste contexto, podemos pensar em diferentes cenários de testes: os caminhos felizes (happy paths) e os caminhos alternativos (alternate paths).

Os cenários de caminho feliz são basicamente aqueles que exercitam a aplicação  para completar com sucesso algum tipo de transação, como por exemplo, um login bem sucedido, a finalização de uma compra em um sistema de e-commerce ou a criação de uma nova conta no sistema.

Já os cenários de caminho alternativo são aqueles que exercitam a aplicação para os casos em que o usuário, por exemplo, não deve conseguir completar uma ação, tais como um login com usuário e/ou senha inválida, uma compra com um cartão de crédito roubado, a submissão de um formulário sem o preenchimento de algum ou todos os campos obrigatórios, etc.

Agora que já temos alguns fundamentos básicos, segue minha dica de por onde começar, quando se está iniciando na escrita de testes de aceitação automatizados. Comece pelos cenários de caminho feliz! =D

Digo isso com base no que é proposto pelo próprio livro, visto que criando tais testes, você garante que as funcionalidades principais de sua aplicação estão funcionando após alterações, tais como: adição de novas funcionalidades, correções de bugs ou refatorações. O importante é no mínimo garantir que o usuário final conseguirá percorrer este caminho feliz sem problemas. Caso não haja cobertura em uma funcionalidade de compra com sucesso, em um sistema de e-commerce, por exemplo, isso pode acarretar em prejuízo financeiro. Pense nisso!

Como uma dica extra, testes automatizados de aceitação do cenário feliz podem ser utilizados para a criação de uma suite de smoke test, para um rápido feedback após alterações na aplicação, garantindo que o mais importante está ok, podendo a suite de testes de regressão ser executada em um momento posterior no pipeline de integração contínua, visto que tais testes tem um maior custo com relação ao seu tempo de execução, quando comparados a uma suite de smoke test. Caso após uma alteração na aplicação o smoke test falhe, não há a necessidade de perder tempo executando toda a suite de testes de regressão.

Depois de uma boa base de testes do caminho feliz, daí então comece a pensar nos cenários dos caminhos alternativos.

Abaixo seguem alguns links de conteúdos interessantes, também sobre testes de aceitação automatizados:

Teste de aceitação automatizados – série de contradições em teste de software (#TalkingAboutTesting)

Testes automatizados? Por onde eu começo?

Teste de aceitação e suas boas práticas

5 boas práticas para se aplicar em testes de aceitação

Espero que tenham gostado e aguardo seu feedback nos comentários.