Escrevendo seu primeiro cenário Cucumber

Previamente postei neste blog alguns artigos a respeito do que é BDD, para que serve e como aplicá-lo. Veja exemplos aqui: artigos-bdd-ciclosw

Hoje vamos dar continuidade aos estudos sobre implementação do BDD como método de ATDD, ou seja, a utilização dele para o processo de escrita de cenários de aceite. O foco aqui estará para os testes automatizados implementados pela figura do QA em um contexto de entrega incremental, onde as funcionalidades de um sistema de UI é separado por casos de uso.

Eu também descrevi aqui como implementar seu primeiro cenário de teste automatizado  com BDD utilizando a ferramenta SpecFlow e código C#. Mas hoje quero dar ênfase à escrita de uma feature, que vem a ser a parte de negócio da implementação BDD através do Cucumber, com base na sintaxe Gherkin.

 

Origem do Cucumber

Segundo a documentação do cucumber.io: “Cucumber é uma ferramenta que suporta Desenvolvimento guiado a comportamento (BDD, na tradução livre) – um processo de desenvolvimento de software que visa melhorar a qualidade do software e reduzir custos de manutenção.”.

Essa ferramenta foi criada em 2008, por Aslak Hellesøy, que foi desenvolvedor na ThoughtWorks e em 2014 fundou a empresa Cucumber Ltd. De acordo com suas palavras à uma entrevista da InfoQ: “Eu fui consultor por 10 anos antes de criar a ferramenta Cucumber. Nos primeiros 5 anos de minha carreira, todos os projetos nos quais trabalhei tinham os mesmos problemas:

  • Eu muitas vezes não sabia se tinha entendido todos os requisitos;
  • Eu achei difícil confiar no resultado daquilo que estávamos construindo
  • Eu tinha medo de mudar código pré-existente, sem saber o que poderia quebrar com as mudanças
  • Nós estávamos constantemente atrasados com as entregas

E continua: “Com o BDD, * todos * os testes são testes de aceitação do cliente, escritos em linguagem simples (humana) para que os interessados ​​não técnicos possam compreendê-los. Então, o Cucumber combina especificações de requisitos, testes automatizados e documentação viva em um único formato chamado Gherkin, que é simplesmente inglês com um pouco mais de estrutura.”.

 

Como escrever sua primeira feature

É importante salientar que, tecnicamente, existem diversas ferramentas que podem ser utilizadas para implementar BDD: Cucumber, SpecFlow, JBehave, RSpec, Jasmine, Cucumber-js, Lettuce, Lettuce, etc. E que BDD é um processo maior que a automação de testes!!!

Mas, considerando o cenário que utiliza automação de testes, como citado acima, o fluxo de desenvolvimento BDD pode ser ordenado da seguinte forma:

1. Descrever funcionalidades      2. Implementar cenários   3. Executar cenários

Na etapa Descrever Funcionalidades é a qual: entendemos requisitos e prioridades; listamos cenários de uso, seus fluxos e resultados esperados.

Na etapa Implementar Cenários é a qual: escrevemos os cenários de ATDD com gherkin; implementamos seus steps e page-objects; gravamos os cenários em uma ferramenta de controle de versão.

Na etapa Executar Cenários é a qual: organizamos os cenários em suítes de testes; configuramos variáveis de ambiente, drivers e runners dos testes para a execução dos cenários; integramos os cenários a uma  ferramenta de  integração contínua, caso necessário.

 

 

Agora vamos para a parte prática!

Continuar lendo

Por quê aplicar BDD?

Behavior Driven Development, ou simplesmente BDD, é uma metodologia para desenvolvimento de produtos que foi criada como técnica para atender às demandas que o TDD não conseguiu suprir. Ela surgiu como proposta ao contexto da codificação de software. A diferença entre as duas técnicas, TDD e BDD, foi explicada aqui: diferenca-entre-tdd-e-bdd/

Hoje, enxergo o BDD como prática colaborativa, porque sua aplicação efetiva é proveniente da interação entre pessoas, com propósito na melhoria da comunicação entre elas. Ou seja, esta é uma ferramenta que não está mais restrita ao âmbito técnico da construção do produto, porque passa por diversas camadas anteriores ao seu desenvolvimento: entendimento das necessidades do cliente e domínio de negócio por toda a equipe desenvolvedora do produto.

Benefícios

O BDD é uma ferramenta que detalha a camada do negócio e chega à área técnica para a correta implementação de comportamentos do produto. Isso porque ela:

  • Facilita o entendimento do negócio;
  • Descreve o resultado esperado pelo cliente;
  • Promove a discussão do negócio;
  • Delimita escopo do produto;
  • Previne a ocorrência de falhas no produto.

Todos os benefícios listados acima contam com esta origem: especificação por exemplos, ferramenta que deve participar nas conversas com o cliente. Assim, quando em sua aplicação, o negócio passa a ser especificado em formato de pequenos exemplos de uso: cenários, contando com critérios de aceite bem definidos: comportamento do produto, o cliente tem sua visão entendida e detalhada para a equipe técnica que irá construir seu produto. E isso resulta em qualidade na entrega do produto, já que ele contará com as funcionalidades desejadas por quem o solicitou.

Como aplicar?

Continuar lendo

Palestra no LinguÁgil 2016

Oi pessoal,

Estou de volta e desta vez com uma novidade. Fiz uma palestra recentemente em um evento super importante de TI para a Bahia, o LinguÁgil. Na palestra falei sobre testes: a necessidade de realizar teste de software; a realidade do nosso mercado; o processo de testes padrão; e uma abordagem ágil, o SBTM.

Confiram os dados do evento acessando este link!
A minha apresentação está disponível aqui!

No final de abril tem mais, irei palestrar na faculdade Unijorge, unidade Comércio, no evento GDG Tech Tour #2. Fiquem ligados!

Sistemas autonômicos: O que o futuro em TI nos reserva

Hoje temos a disposição inúmeras ferramentas e linguagens de programação que nos permitem construir sistemas voltados à gestão de recursos do mundo físico. Os sistemas computacionais embarcados além de apoiarem diversas atividades do nosso dia, de forma que percebemos: cadastro de dados para a consulta médica, uso do internet banking, etc.; nos rodeiam de outras tantas que não observamos: veículos, eletrodomésticos, etc.  A esta última condição damos o nome de ubiquidade, que é fazer uso de tecnologias em nossas atividades de forma tão natural, que não atentamos a estes acessórios.

O que acontece é que, a cada vez que um sistema se comunica com outro, o nível de complexidade desta relação aumenta os cuidados que precisam estar envolvidos em ambos os lados. E aí estão inseridos esforços em construir e mais ainda em manter tais funcionalidades. Pelo ritmo em que vivemos, essa integração tende a crescer exponencialmente, pois estamos fazendo uso de diversas ferramentas integradas para que desta forma consigamos gerir várias rotinas de nossas vidas: hora de acordar, hora de tomar água, quantos quilômetros corremos, qual o menor caminho para chegar ao trabalho, qual o bar mais badalado ou bem aceito da cidade, entre outras.

O sistemas ubíquos são uma modalidade dos sistemas autonômicos, que são aqueles sistemas que possuem a responsabilidade de manterem a si próprios. Dentre os sistemas autonômicos mais pesquisados no momento, estão os sistemas self-organizing, aqueles que não conhecem a si próprios: mapas e componentes, mas possuem a capacidade de manterem-se. Eles se baseiam nas funções biológicas da natureza e são voltados à computação de alta performance, pois devem atuar em cenários altamente dinâmicos.

Continuar lendo

Hangout with tester NE

Na quinta-feira, 28/05, aconteceu o primeiro Hangout with tester NE. NE é sigla para Nordeste. Dele participaram, a anfitriã, Kamilla Queiróz do Ceará, Deyvison Mendonça, também de Pernambuco, Samanta Cicilia do Rio de Janeiro,  Frederico Moreia de Minas Gerais, Gabriel Oliveira do Rio Grande do Sul e euzinha, Lorena Caldas, representante da Bahia.

Nesse encontro foram apresentados os perfis dos testadores de cada região e dados de pesquisa sobre onde encontrar informações sobre testes. Foram discutidos também temas como: mercado de cada região, ensino formal em testes, automação, movimento ágil, mentalidade dos gestores de TI, questões salariais, entre outros.

Posso dizer que foi um encontro muito produtivo e divertido. Acredito que o objetivo principal do evento se cumpriu, que foi o de estabelecer um comparativo entre a área de testes nos estados do NE e sudeste/sul. Espero que outros ocorram para que possamos discutir novas técnicas, processos, ferramentas de testes e meios de superar as barreiras que encontramos neste campo de atuação.

Confira a transmissão do evento neste Link e a divulgação oficial neste outro.

Logo do evento

Logo do evento

Estimativa de Testes por Análise de Pontos de Teste (APT)

Completando o grupo de posts relacionados à Estimativa de Testes baseado no livro Base de Conhecimento em Teste de Software, estou disponibilizando neste texto a planilha para cálculo de esforços de testes baseado no método de Análise de Pontos de Teste (APT).

Esta técnica, a APT, tem fundamento na análise de pontos de função (APF), que por sua vez é uma técnica da Engenharia de Software utilizada para estimar o tamanho dos projetos de software de acordo com as entradas e saídas de funcionalidades de um sistema. O volume dos arquivos de entrada e saída, assim como as consultas internas e externas ao sistema são utilizadas .

APF verus APT

A planilha é condução prática ao modelo de APT estabelecido no tópico 11.1 Estimativa baseada na análise de pontos de teste, o qual serve para estimar o tempo despendido nas atividades de teste. Implementei o modelo prevendo sua utilização para apenas uma funcionalidade por vez, sendo necessário, então, criar réplicas dela para realizar a somatória de 2 funcionalidades ou mais.

A planilha está dividida em dois fluxos de preenchimento: Parte I e Parte II. Elas correspondem, respectivamente, ao grupo de cálculos para a obtenção de Pontos de Teste e ao grupo de cálculos para a obtenção de Horas de Teste. O grupo I de cálculos se relaciona com os aspectos de:

  • Quantidade de Pontos de Função;
  • Pontos de Teste Estáticos;
  • e Pontos de Teste Dinâmicos;

para encontrar o total de Pontos de Teste. Já o grupo II de cálculos se relaciona com os aspectos de:

Continuar lendo