Testes de Automação com Cucumber BDD em times Ágeis

Nos últimos anos, há cada vez mais equipes de software implementado a metodologia de software Ágil em seu processo de desenvolvimento para se adaptar a esse mercado volátil. Essa tendência desafia as equipes de teste na gerência de casos e scripts de teste que precisam ser mantidos de acordo com os requisitos em constante mudança. Encontrar um método de teste apropriado desde o início é um dos elementos-chave para um projeto de software Ágil bem-sucedido.

O que é o Cucumber?

Muitas equipes Ágeis implementaram com sucesso o método BDD (Behavior-Driven Development - Desenvolvimento Orientado por Comportamento) em seu processo de teste usando a ferramenta Cucumber. Mas o que é Cucumber? E por que essa estratégia é a adequada e sugerida para projetos Ágeis, junto com o BDD?

O Cucumber é uma ferramenta usada para executar testes de aceitação automatizados que foram criados em um formato BDD. Um de seus recursos mais destacados é a capacidade de realizar descrições funcionais de texto simples (escritas numa linguagem chamada Gherkin) como testes automatizados. Vamos dar uma olhada no exemplo:

Feature: Update password
  Scenario: Admin user can update the user password
Given I am in the HR system with an Admin account
When I update password of another user
Then I receive a message for updating password successfully
And user password is updated to the new password

Esta característica incrível da abordagem BDD apresenta as seguintes vantagens:

• Escrever testes de BDD em uma linguagem onipresente, estruturada em torno do modelo de domínio e amplamente usada por todos os membros da equipe incluindo desenvolvedores, testadores, analistas de negócio e clientes;
• Conexão técnica com membros não técnicos de uma equipe de software;
• Permitir a interação direta com o código do desenvolvedor; os testes de BDD são escritos em um idioma que também podem ser criados pelos stakeholders envolvidos;
• Por último, mas não menos importante, os testes de aceitação podem ser executados automaticamente, enquanto são executados manualmente pelos stakeholders.

O Cucumber ajuda a melhorar a comunicação

O Cucumber ajuda a melhorar a comunicação entre membros técnicos e não técnicos em um mesmo projeto. Isso pode ser observado no requisito abaixo e seus testes de automação:

1 As an Admin User,
2 I would like to change the password of other user's accounts.
3 Feature: Update password
4   Scenario: Admin user can update the user password
5     Given I am in the HR system with an Admin account
6     When I update password of another user
7     Then I receive a message for updating password successfully
8     And user's password is updated to the new password

Com TestNG, o cenário de teste acima pode ser implementado conforme abaixo:

1 @test
2 public void testAdminUserCanUpdateUserAccountPassword() {
3   // criar usuários
4   User userAdmin = new User(UserRole.ADMIN, username, password);
5   User user = new User(UserRole.VIEWER, user_username, user_password);
6
7   // use o Admin user para atualizar a senha de um usuário
8    String message = userAdmin.updatePassword(user, user_new_password);
9
10 // verifica a mudança de senha
11    Assert.assertEquals(message, "Password changed successfully");
12    Assert.assertEquals(user.getPassword(), user_new_password);
13 }

O mesmo caso de teste pode ser escrito usando o Cucumber:

1 Feature: Update password
2  Scenario: Admin user can update the user password
3    Given I am in the HR system with an Admin account
4    When I update password of another user
5    Then I receive a message for updating password successfully
6    And user's password is updated to the new password

Ambos os scripts de teste de automação apresentam um bom desempenho para concluir o teste automaticamente. Mas todos os testadores do seu time fazem esses testes? Outros analistas de negócios e stakeholders podem usar esses testes novamente no estágio de teste de aceitação?

O teste de automação com o TestNG pode ser difícil para a maioria dos testadores manuais e analistas de negócio. Além disso, é impossível usar este teste novamente para o teste de aceitação. Como resultado, com base nessas falhas mencionadas anteriormente, isso não pode ser considerado como um método adequado.

Por outro lado, o teste de automação usando o Cucumber é criado em uma linguagem de domínio do negócio, ou em uma linguagem natural, que pode ser facilmente produzida por todos os membros do projeto. A comunicação é crucial para qualquer time de desenvolvimento, especialmente para um time Ágil. Geralmente, há muitos bate-papos, discussões e longas argumentações entre desenvolvedores e testadores para descobrir qual é o comportamento correto de uma funcionalidade. Usando o Cucumber, a mesma especificação da funcionalidade agora é usada para o desenvolvimento pelos desenvolvedores, e para testes pelos testadores. É considerada uma ferramenta poderosa porque pode ajudar a reduzir o risco de mal-entendidos, bem como a falha na comunicação.

O Cucumber é uma ferramenta de teste de aceitação automatizada

O teste de aceitação geralmente é realizado por analistas de negócio/clientes para garantir que o time de desenvolvimento tenha construído as funcionalidades exatas. A atividade típica neste estágio de teste é verificar o sistema em relação aos requisitos originais com dados reais específicos da produção. O teste do Cucumber não apenas segue os requisitos como seus cenários de teste, mas também ajuda os analistas de negócios ou o gerente de produto a ajustar facilmente os dados de teste. Aqui está uma demonstração com um pequeno ajuste:

1 As an Admin User,
2 I would like to change the password of other user's accounts.
3            
4 Feature: Update password
5   Scenario: Admin user can update the user password
6     Given I am in the HR system with an Admin account
7     When I update password of another user
8     Then I receive a message for updating password successfully
9     And user's password is updated to the new password

O teste de automação escrito no framework do Cucumber:

1  Scenario Outline: Verify Updating user password feature
2    Given I am in the HR system with "<account_type>" account
3    And there is another user with "<old_password>" password
4    When I update password of the user to "<new_password>"
5    Then I got the message "<message>"
6    And the user password should be "<final_password>"
7 
8  Examples:
9  |account_type  |old_password  |new_password |message                |final_password |
10 |Admin     	|$Test123      |@Test123 	|Password changed.. 	|@Test123   	|
11 |Viewer        |$Test123      |@Test123 	|Invalid right access.. |$Test123   	|

Todos os testadores podem participar do teste de automação com Cucumber

Além de melhorar a comunicação entre os membros de um mesmo time de testes, o Cucumber também ajuda a aproveitar as habilidades do testador com eficiência. A lacuna de conhecimento sempre existe em todas as empresas. Em outras palavras, existem alguns testadores que possuem alta especialização técnica em programação utilizando testes automatizados, enquanto outros realizam testes manuais com habilidades de programação limitadas - e tudo isso na mesma equipe. Graças ao Cucumber, todos os testadores, independentemente de seus níveis de habilidade, podem participar do processo de execução dos testes de automação.

Vamos dar uma olhada no exemplo acima:

• Qualquer testador que esteja ciente das regras de negócio e do fluxo de trabalho pode escrever arquivos de funcionalidades, adicionar mais cenários e testar conjuntos de dados;
• Qualquer testador que tenha um conhecimento básico de programação e saiba como criar objetos, acessar propriedades e chamar métodos, pode gerar definições de etapas;
• Qualquer testador com nível de habilidade de programação mais alto pode participar do processo de criação de um framework, definir a conexão da fonte de dados e assim por diante.

Porém, ainda existem alguns problemas potenciais ao implementar o Cucumber:

• O Cucumber ajuda a executar cenários de teste específicos em um arquivo de texto simples usando o conhecimento do domínio de negócio. Assim, o uso de linguagens e a percepção de quem cria o teste pode influenciar diretamente os cenários de teste, levando ao risco de mal-entendidos. Os cenários de teste devem ser apresentados com clareza e sua implementação deve ser realizada com precisão para cada passo. Por exemplo, quando quiser verificar a funcionalidade de pesquisa do Google, o teste deveria ser: 

1 Scenario: performing a search on google
2 Given I am on "www.google.com" site
3 When I search for "Cucumber and BDD"
4 Then ...

Esses passos podem ser incorporados para se obter o seguinte teste:

1 Scenario: performing a search on google
2 When I search for "Cucumber and BDD"
3 Then ...

Os estágios do Cucumber são executados em uma linguagem comum. E podem ser usados novamente em vários cenários de teste. Isso ajuda a reduzir o esforço para criar testes. No entanto, manter o teste legível e reutilizável é realmente um grande desafio. Se o teste for escrito em um nível muito alto para qualquer stakeholder; poucos passos poderão ser reutilizados. Ambos os scripts acima estão corretos; no entanto, o segundo não é aparente porque faz muito mais do que o esperado: abre o site do Google e pesquisa com o texto especificado. Imagine que queira estender o teste para pesquisar mais textos, e provavelmente repetirá o mesmo passo acima para isso, consequentemente, o site do Google estará aberto duas vezes. Se o requisito não for seguido rigorosamente, a ferramenta de teste do Cucumber causará mal-entendidos mais cedo ou mais tarde, e será difícil de manter quando for estendido.

1 Feature: Update password
2   Scenario: Admin user can update the user password
3     Given I am in the HR system with an Admin account
4     When I update password of another user
5     Then I receive a message for updating password successfully
6     And user's password is updated to the new password
7 
8   Scenario: Viewer user cannot update the user password
9     Given I am in the HR system with a Viewer account
10  	When I update password of another user
11  	Then I receive a message for not able to update the user password
12  	And user's password remains the same

Por outro lado, se o teste for genérico e puder ser reutilizado, por exemplo, verificar o sobrenome do usuário de atualização, os stakeholders não-técnicos terão dificuldade em entendê-lo e executar testes de aceitação:

1 Scenario: Admin user can update user password:
2   Given I am in the "$System.HR_Page" with "admin@test.com" username
3 and "$Test123" password
4   And there is another user in "$System.HR_Page" with "user@test.com"
5 username and "$Test123" password
6   When I update "$UserTemplate.Password" of "user@test.com" user to"@Test123"
7   And I save the response message as "response_message"
8   Then "$response_message" should be "Password changed successfully"
9   And the  "user@test.com" user's "$UserTemplate.Password" should be"@Test123"

Durante o processo de teste, deve-se ajustar os cenários de teste regularmente até que alcancem um equilíbrio aceitável completamente, no qual todos os membros possam entender e reutilizar.

1 Scenario: Verify Updating user password feature
2   Given I am in the HR system with "Admin" account
3   And there is another user with "$Test123" password
4   When I update password of the user to "@Test123"
5   Then I got the message "Password changed successfully."
6   And the user password should be "@Test123"

Ou com mais alguns dados de teste:

1 Scenario Outline: Verify Updating user password feature
2    Given I am in the HR system with "<account_type>" account
3    And there is another user with "<old_password>" password
4    When I update password of the user to "<new_password>"
5    Then I got the message "<message>"
6    And the user password should be "<final_password>"
7 
8 Examples:
9   |account_type |old_password |new_password |message       	|final_password |
10  |Admin        |$Test123 	|@Test123 	|Password changed.. 	|@Test123  |
11  |Viewer   	|$Test123 	|@Test123 	|Invalid right access.. |$Test123  |

Notas importantes para o time de testes que deseja começar com o Cucumber

• Considere os testes de automação sendo essenciais como qualquer outro projeto real. O código deve seguir a boas práticas de codificação, convenções, etc.
• Deve ser considerada uma ferramenta de edição apropriada. Este editor deve ajudar a depurar e editar arquivos de funcionalidades no formato de texto padrão. O Aptana (editor gratuito), o RubyMine (editor pago) e o Katalon Studio são opções adequadas que suportam completamente o Cucumber baseado em BDD.
• Por último, mas não menos importante, torne os arquivos de funcionalidades uma camada de "comunicação" real, na qual se pode armazenar dados de testes recebidos e formatar dados de teste. O domínio das regras de negócio não está contido.

Para concluir, oferecendo a camada de comunicação real sobre um framework de teste robusto, o Cucumber não apenas pode executar testes de automação em uma ampla demanda de testes do backend ao frontend, mas também criar conexões profundas entre os membros dos times de teste. Esse recurso dificilmente é encontrado em outros frameworks de teste. Com muitos anos de experiência na área de criação e aplicação de testes de automação, sugiro que o Cucumber para testes de Web UI e Web services seja aplicado a projetos de software Ágeis. Usar o BDD baseado em Cucumber com um editor coerente é uma escolha acertada que pode ajudar significativamente a reduzir o esforço para executar testes de regressão.