Experiência usando BDD

Há cerca de sete anos, Dan North, em seu artigo, descreveu a aplicação prática da abordagem BDD, que permite tornar o processo de desenvolvimento mais compreensível e gerenciável, estabelecendo comunicações internas. O setor mostra cada vez mais interesse nessa metodologia todos os dias, visando a interação produtiva de equipes padrão, como “analytics-development-testing”.

No entanto, agora apenas uma pequena parte das empresas decide usar o BDD. Porque

Então, vamos descobrir. O BDD (Behavior Driven Development) é uma metodologia flexível intimamente relacionada ao TDD (Test Driven Development - “Desenvolvimento através de testes”). Por experiência, mesmo testadores experientes geralmente não vêem a diferença entre essas metodologias. De fato, à primeira vista, é difícil isolar: ambas as abordagens envolvem escrever documentação e testes antes do início da fase de desenvolvimento. E a diferença é esta: no BDD, para descrever os testes, você precisa usar uma linguagem natural que seja compreensível para cada participante do projeto, a fim de, de fato, combinar a declaração do problema, os testes e a documentação. Em outras palavras, é definida a DSL (linguagem específica para o assunto) e, em seguida, é criado um conjunto limitado de frases padrão que descreve o comportamento dos elementos necessários. Então, com a ajuda deles, um cenário é desenvolvido usando a nova funcionalidade, que ficará clara para todos.

Vamos ver a diferença uma vez, e ela ficará aparente:

Vamos tocar neste exemplo, mas primeiro, vamos olhar para toda a variedade de metodologias que atualmente são de relevância diferente de zero.

Compare várias metodologias

O diagrama abaixo mostra uma comparação de três abordagens: TDD, TLD (Test Last Development) e BDD:

• Quando trabalhamos de acordo com a metodologia do BDD, as especificações de autoteste e desenho acompanham cada estágio do ciclo de desenvolvimento de software, o que garante a relevância constante dos autotestes e da documentação.
• As metodologias TDD e ATDD (Teste de aceitação) são combinadas em um diagrama em um bloco, porque escrito na fase de análise. Como mencionado acima, o TDD é baseado em testes de gravação antes de desenvolver a funcionalidade. O desenvolvedor deve escrever testes para escrever a funcionalidade do teste.
• O TLD (Test Last Development) inclui testes após a implementação da funcionalidade.
• O BDD é universal e pode ser incluído em qualquer estágio do desenvolvimento.

O segundo diagrama mostra o envolvimento dos participantes no processo de desenvolvimento na escrita de scripts.

• No BDD, qualquer membro da equipe pode se conectar aos testes em qualquer estágio, por exemplo, analista, usuário comercial, desenvolvedor e testador, pois os testes são claros para todos os participantes do processo.
• O BDD também é útil, pois você não precisa gastar muito tempo escrevendo vários tipos de documentação. O esquema de desenvolvimento clássico requer, no mínimo, especificações e scripts de teste que geralmente são escritos por pessoas diferentes. No BDD, uma especificação é um caso de teste, enquanto também é um autoteste. Os testadores não precisam escrever documentação de teste separada - para eles, o analista já fez isso, escrevendo uma especificação a partir de construções de linguagem natural (que é legível e compreensível por qualquer membro da equipe).

Sem dúvida, o BDD é uma boa ferramenta para alcançar a qualidade do produto. Testes e documentação são gravados mais rapidamente. Para uma empresa, um projeto se torna mais transparente, graças a construções de linguagem natural que são compreensíveis para qualquer pessoa longe da programação.

Isso é sobre os profissionais. No entanto, como já foi dito, apesar de um grande número de vantagens, poucos implementam essa metodologia.

O BDD é bom para todos, mas por que não usá-lo?

A resposta é simples: é longa e cara. A maioria das empresas de TI concorda com esta declaração. E a princípio não fomos exceção. O BDD é inconveniente, mesmo que exija o envolvimento de especialistas em testes já no estágio de elaboração de requisitos.

O BDD vira a diretriz clássica de desenvolvimento (TLD) de cabeça para baixo. É mal implementado porque é difícil. O ciclo de desenvolvimento está se prolongando.

O BDD é, sem dúvida, uma maneira de obter qualidade. Mas nem todos estão dispostos a pagar tempo e especialistas por essa qualidade.

No entanto, o que devo fazer se ainda quiser implementar o BDD?

Você pode tentar usar estruturas prontas. Por exemplo Pepino, Squish, Yulup.

O principal problema da complexidade do BDD não está no processo, mas na implementação e nas ferramentas existentes. Tome a WEB como um exemplo de desenvolvimento de um sistema de informações corporativas. Tendo uma implementação na Web, encontramos um WebDriver, atualmente o padrão para automatizar aplicativos em execução em um navegador da Web. Ele tem muitas oportunidades. Para levar em consideração várias personalizações dos elementos da página, é necessário criar opções para acessá-los. E aqui, para facilitar o desenvolvimento do teste, várias bibliotecas vêm em socorro (Selenide, etc.), que cria seu próprio ecossistema que você precisa conhecer. Para trabalhar com o WebDriver, você precisa de um programador ou de automação de testadores, porque tudo é implementado usando códigos e designs astutos.

Começar com a estrutura do BDD é difícil e demorado.

Nosso foco está em um instrumento chamado Gauge. Essa é uma estrutura flexível e leve, distribuída sob uma licença gratuita. Francamente, nós realmente não estudamos as alternativas, porque O uso do Gauge foi ditado agressivamente pelo nosso cliente.

No Gauge, os testes são gravados em arquivos de especificação (arquivos com extensão .spec). A especificação contém etapas de teste escritas em linguagem natural. Essas etapas são implementadas em uma linguagem de programação (usamos a linguagem de programação Java). Ao implementar as etapas, é importante cumprir a Convenção de Nomenclatura, tanto nos nomes do script quanto nos arquivos de implementação, e nos nomes dos métodos e etapas de implementação do script, eles devem ser completamente idênticos. Uma flexibilidade adicional para esta ferramenta é que as etapas podem ter parâmetros.

O Gauge nos permitiu usar os benefícios do BDD. No entanto, ainda encontramos problemas que são a complexidade da implementação: os problemas das ferramentas e a implementação do processo.

Descobriu-se que o envolvimento dos testadores em um estágio inicial tem um efeito ruim no resultado final. Maior tempo para desenvolver testes. O uso de qualquer estrutura requer grandes esforços do testador, que, sem dúvida, deve ter um bom domínio de programação. No início, o processo de trabalhar com o script era o seguinte: o analista contou o teste ao testador e o escritor técnico anotou. Enquanto o testador lidava com a implementação do software, o significado da funcionalidade testada mudou. Isso afeta a separação do ponto de entrada, e deve ser um, pois o processo é dividido e se transforma em um processo "normal", do qual eu apenas queria sair. I.e. o ponto de entrada foi dividido, as comunicações se espalharam, o testador entrou de cabeça na implementação do teste, o escritor técnico entendeu à sua maneira e o analista reescreveu suas docas e mudou de idéia, o desenvolvedor entrou em "seu mundo").

O testador passou muito tempo no código. Mas o mesmo testador ainda teve que pensar na busca por elementos na página. A situação lembrava um famoso jogo infantil: "Telefone mimado". Ocorreu um colapso. E decidimos: o BDD funcionará apenas se os analistas puderem escrever testes. É necessário reduzir a complexidade dos testes de escrita, simplificá-los. Mas para isso, você precisa simplificar significativamente as interfaces de teste. Ferramentas de teste, a implementação do processo em conjunto com todas as abordagens e bibliotecas deve ser mais simples.

O trabalho do testador a princípio ficou assim:

1. Exame da documentação, se houver;
2. Elaborando uma lista de verificação;
3. Teste ad-hoc
4. Elaborar um plano de teste;
5. Refinamento da visão de mundo do analista;
6. Refinamento da imagem do mundo pelo desenvolvedor;
7. Se tudo crescer junto, escrevendo a documentação do teste, em paralelo com o teste;
8. Esperando por bugs, testando bugs;
9. Descrição das páginas, controles, procure elementos na página usando o Web-Driver. Pesquise o que já foi implementado no sistema de teste;
10. Escrevendo lógica de teste;
11. Lançamento
12. Suporte bug / Regress bug;
13. Atualização de especificação;
14. Fix bug
15. Atualização de autoteste, atualizando um grande número de controles alterados;
16. Lançamento
17. ...
    Os itens em itálico (1, 5, 6, 7, 9, 13, 15) levam a custos de tempo. Eles podem e devem ser otimizados.

Esta lista é brevemente ilustrada no diagrama do processo de desenvolvimento:

Nossa empresa é especializada em projetos com implementação na web de interfaces. Com base nisso, usamos a ferramenta Driver da Web para interagir com o navegador.

De fato, o Selenium Web Driver é o padrão e é usado para descrever objetos da Web em qualquer estrutura, incluindo as bibliotecas Gauge, jUnit, Masquerade e outras. Ele tem muita flexibilidade para tarefas diferentes, o que cria muita trabalho em problemas do tipo local. Precisamos encontrar uma solução para reduzir a complexidade.

Por exemplo, vamos mostrar no diagrama como o Selenium Web Driver, a estrutura Gauge, a biblioteca Masquerade e a linguagem de programação Java estão relacionadas.

Nesse esquema, em vez da estrutura do BDD, você pode colocar jUnit, TestNG ou qualquer outro, qualquer pacote funcionará, dependendo das necessidades. O Selenium e o Masquerade permanecerão, a linguagem de programação pode ser alterada.

Acelerando a Escrita de Código - Conectando Mascarada

Nossa empresa está desenvolvendo na plataforma CUBA . E especificamente para esta plataforma, foi desenvolvida uma ferramenta para autoteste: O Masquerade é uma biblioteca que fornece uma API concisa e conveniente para trabalhar com código na implementação de testes usando o WebDriver. Esta biblioteca funciona no Selenium Web Driver, é amiga do selenide e de qualquer estrutura.

Nos projetos CUBA, cada elemento da página da web contém cuba-id, que não muda. O CUBA usa uma abordagem de componentes , e a biblioteca Masquerade simplifica a interação com os elementos da página da web. A biblioteca pode executar ações com elementos da página da web implementados usando o CUBA de uma maneira mais simples. Portanto, ao procurar elementos na página, você não precisa usar construções volumosas com o XPath, como era antes:

$(new By.ByXPath("//*/div/div[2]/div/div[2]/div/div/div[3]/div/div/div[3).click(); 

Ou construções mais concisas em Java, que, no entanto, ainda são complicadas:

 private static void click(String cssClass, String caption) { $(By.cssSelector(cssClass) .$(byText(caption)) .closest(".v-button") .click(); } 

Após conectar a biblioteca Masquerade, a descrição do controle incorporado parece simples e fácil de acessar. Você nem precisa procurar controles na página, porque ele já tem isso no projeto. Aqui está um exemplo de uma descrição do botão para o formulário de autorização no aplicativo:

No código da página, vemos um elemento claramente reconhecível cuba-id=”loginButton”

Vamos descrever o botão usando a biblioteca Masquerade:

 @Wire(path = {"WebHBoxLayout", "loginButton"}) private Button loginButton; 

Uma implementação de teste simples na estrutura do jUnit é um bloco de autorização executado antes de cada teste:

 @Before public void loginAdm() { Tests loginTest = _$(Tests.class); loginTest.login(); } 

E no corpo do método de login, o seguinte código:

 LoginWindow loginWindow = _$(LoginWindow.class); assertNotNull(loginWindow.getLoginField()); loginWindow.getLoginField() .shouldBe(EDITABLE) .shouldBe(ENABLED); loginWindow.loginField.setValue("admin"); loginWindow.passwordField.setValue("admin"); loginWindow.rememberMeCheckBox.setChecked(true); loginWindow.loginButton().click(); 

O mais importante é como descrevemos a página, como nos referimos a elementos. Descrição da página LoginWindow:

 public class LoginWindow extends Composite<LoginWindow> { @Wire(path = {"loginField"} ) private TextField loginField; @Wire(path = {"passwordField"} ) private PasswordField passwordField; @Wire(path = {"rememberMeCheckBox"} ) private CheckBox rememberMeCheckBox; @Wire(path = {"loginFormLayout", "loginButton"} ) private Button loginButton; } 

Encontrar itens é apenas parte da biblioteca Masquerade. O acesso aos elementos de uma página da web permite executar várias ações com esses elementos. Por exemplo, você pode selecionar um item na lista suspensa:

 getMaxResultsLayout().openOptionsPopup().select("5000") 

Ou ordene a tabela:

 Table tb1 = client.getPaymentsTable(); tb1.sort("column_year", Table.SortDirection.ASCENDING); 

Veja as capturas de tela abaixo para obter uma lista de algumas ações da tabela:

O uso do Masquerade simplificou bastante a gravação de testes. Agora, para escrever um teste para novas funcionalidades, você precisa:

1. Usar o Masquerade para descrever uma página é fácil e não requer habilidades especiais de programação.
2. Colete em uma classe todas as páginas usadas ao verificar a funcionalidade.
3. Nas construções prontas da linguagem natural, colete um script de teste (substituindo os nomes dos elementos necessários), ou seja, escreva uma especificação do Gauge.

Integrando Masquerade e Gauge

Antes de usar o BDD, a abordagem de DPN era usada e, para trabalhar com ela, também otimizamos o processo de escrever o código do teste. Pacotes jUnit / TestNG + WebDriver + Selenide + Masquerade usados.

Agora, para trabalhar com o Gauge, adicionamos o plug-in correspondente ao intellij IDEA. Depois disso, será possível criar um novo tipo de teste - Especificação.

Agora criamos a especificação (script) e implementamos as etapas usando os recursos do WebDriver, Masquerade e Java.

Clicamos na etapa do script e vamos para a implementação:

Na implementação, você pode usar o método login () existente.

Como é essa perfeição?

Lembre-se do exemplo que examinamos no início do artigo:

"Navigation.openMenu(menu)” contém a implementação da abertura de um menu usando a biblioteca Masquerade.

A biblioteca foi posteriormente expandida e surgiram etapas universais que poderiam ser usadas para qualquer aplicativo CUBA. Estas são as etapas que permitem trabalhar com elementos do programa: botões, campos, tabelas. Essas etapas universais se tornaram o conjunto de frases padrão que usamos no BDD para escrever scripts.

Graças ao Masquerade + Gauge, reduzimos significativamente a complexidade da criação de testes. Agora os testes podem ser escritos por pessoas que não possuem habilidades especiais de programação. Um teste pode ser escrito por uma pessoa (antes, um script era inventado por uma, mas implementado por outra, o que gerava confusão). Portanto, atingimos nosso objetivo - as interfaces são simplificadas e não será difícil para os analistas escrever scripts de teste.

As alterações do processo são mostradas abaixo:

Foi:

Tornou-se:

Em comparação, observa-se que os requisitos, a especificação e a documentação do teste são combinados em um parágrafo. A documentação de teste também é um autoteste, com exceção da implementação de etapas de teste específicas.

Sumário

No momento, estamos desenvolvendo com sucesso de acordo com o esquema indicado acima. E conseguimos nos livrar do principal problema do BDD - um aumento sério em termos devido à complexidade da implementação, adicionando e finalizando o kit de ferramentas. No entanto, a qualidade da entrega do produto melhorou.

O tempo necessário para manter a documentação é reduzido proporcionalmente ao número de especificações alteradas, porque uma alteração na especificação (lógica do sistema) leva automaticamente a uma alteração no autoteste em uma iteração. I.e. o testador não precisa entrar no sistema de documentação (como Confluence etc.) para obter uma atualização, e isso também é válido para outros membros da equipe.

O tempo para implementar e dar suporte a testes na presença de uma biblioteca que simplifica o trabalho com objetos de página foi reduzido pela metade em comparação ao trabalho com o driver da web limpo usual e o custo de refazer os links do XP.

No desenvolvimento de qualquer solução comercial e no gerenciamento da qualidade - o custo de eliminar erros na coleta de requisitos e análises está crescendo exponencialmente . Assim, a probabilidade de problemas associados ao retrabalho do produto, de acordo com artigos e cronogramas existentes no desenvolvimento iterativo, com a detecção precoce de um problema, que é um bom estudo dos requisitos, reduz significativamente o custo de desenvolvimento, dependendo do projeto. Pode ser 0% e ~ 40%. É essa melhoria que é alcançada através da introdução do BDD. Isso pode ser implementado sem chamar a palavra BDD, mas existe no BDD. Ser capaz de contornar problemas é uma parte importante da garantia da qualidade.

Concluindo, gostaria de observar que esse esquema de desenvolvimento também está integrado à Integração Contínua e ao sistema de gerenciamento de teste de QA Lens desenvolvido em nossa empresa. No QA Lens, você pode escrever os mesmos scripts que no IDEA usando uma linguagem orientada ao assunto. Esse idioma consiste em um glossário compilado anteriormente de ações disponíveis que foram implementadas anteriormente. Ao executar um autoteste no Gauge a partir da máquina de um desenvolvedor ou IC, o QA Lens anota automaticamente quais etapas do script foram concluídas e quais não. Assim, após executar um autoteste de um script escrito por um analista, o departamento de testes recebe imediatamente informações completas e atualizadas sobre o estado do produto.

Autores: Sunagatov Ildar e Yushkova Julia ( Yushkova )