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

Estimativa de Testes por Caso de Uso

Atualmente estou estudando algumas técnicas para estimar os esforços de testes, seja para as atividades de criação de casos de testes, criação de massa de dados de testes e execução dos testes. Com isso, resolvi reler o livro base para a certificação CBTS (Certificação Brasileira em Teste de Software) disponibilizada pela ALATS.

Tomando como base o capítulo 11 do livro, o qual trata do tema Estimativa, eu criei uma planilha contendo a forma básica para calcular as horas gastas com as atividades citadas. Trata-se do uso da técnica de Estimativa baseada no tamanho e na complexidade do caso de uso. Esta técnica se utiliza de medidas como tamanho e complexidade do caso de uso para estimar esforços de testes. O critério do Tamanho relaciona-se com a quantidade fluxos descritos e seus passos, incluindo os fluxos de exceção <pequeno, médio, grande ou muito grande>. Já o critério de Complexidade avalia a dificuldade das regras de negócio <simples, média ou complexa>. Neste quesito eu considerei também as dependências entre as regras (precedência).

Fiz uma adaptação do modelo descrito no tópico 11.2 Estimativa baseada no tamanho e na complexidade do caso de uso, o qual serve para estimar o tempo gasto na criação dos cenários de testes. Incrementei também os cálculos para a criação da massa de dados e a própria execução dos cenários.

Inseri algumas fórmulas na planilha que automatizam a realização dos cálculos. Também deixei comentários nas células que ajudam a entender o fluxo de preenchimento da planilha para o correto cálculo dos esforços.

Link para o Download da planilha

No momento estou criando uma planilha com fundamento na técnica de estimativa de esforço de testes por Análise de Pontos de Função. Espero que ajude vocês e que me enviem dúvidas/sugestões. Até mais! 🙂

Curso de Selenium WebDriver – Aula 6 – Exportando classes do IDE e Importando no WebDriver

Olá gente,

Primeiro venho me desculpar pela demora em postar a aula final do curso de Selenium WebDriver. Eu bem sei que quem quer faz, que desculpas não servem muito. Mas é que passei por momentos turbulentos nesse último semestre. Enfim recuperada e tendo devidamente superado todos os obstáculos da vida, volto a humildemente escrever-vos.

A ferramenta Selenium é muito poderosa! Ela te permite gravar e reproduzir ações, diretamente na interface de um sistema, através da sua versão IDE. Ela te permite também criar esses mesmos passos via código-fonte, com o uso da sua versão WebDriver. Mas… e se eu precisar utilizar as duas coisas?

O Selenium IDE sempre disponibilizou a opção de criar um script de teste “codificado”. Lembro que ao utilizá-lo, anos atrás, já era possível exportar os casos de testes gravados nele para classes dos tipos C#, PHP, Java, Phyton, até mesmo Ruby. Sei que hoje existem muito mais tipos que estes citados.

Dito isto, tendo voltado o curso para a plataforma Java, você irá precisar das seguintes ferramentas para executar a exportação do IDE e importação no WebDriver:

  • Browser Firefox e plugin Selenium IDE – versão mais nova e compatível entre os dois
  • IDE para programação Java, equipado com o Maven (vide aula 1) e bibliotecas do WebDriver – recomendo o Eclipse IDE
  • JUnit – versão mínima 4
  • OBS.: Lembrando que utilizo o sistema operacional Ubuntu

Partindo da instalação do Selenium IDE, vamos seguir esses passos:

  1. Acessar o link de download da ferramenta pelo browser Firefox (estou utilizando a versão 34, a mais recente no momento);
  2. Clicar no link de download mais recente (2.7.0 atualmente). No popup que irá abrir, permitir a instalação.
  3. Permitir a instalação dos complementos associados (incluir o Java Formatters para este exemplo);
  4. Reiniciar o Firefox.
Confirmando a instalação do Selenium IDE

Confirmando a instalação do Selenium IDE

Gravando um caso de teste no Selenium IDE e o exportando

  1. No browser Firefox, escolher o menu Ferramentas > Selenium IDE;
  2. Clicar na ação Gravar, realizar uma ação no navegador e “pausar” a gravação;
  3. Exportar o teste no Selenium IDE, acessando o menu Arquivo > Exportar Teste Como > Java / JUnit 4/ WebDriver para uma pasta no sistema operacional. É importante manter a extensão .java do arquivo.
Concluindo a gravação de um teste com o Selenium IDE

Concluindo a gravação de um teste com o Selenium IDE

Importando o caso de teste gravado no IDE para o projeto Java

  1. Abrir a IDE de programação (estou utilizando o Eclipse JavaEE for Web Developers);
  2. Criar um projeto Java contendo o integrador Maven associado (Ver primeira Aula para saber como configurar);
  3. Configurar a dependência do JUnit na IDE [Ver este vídeo para saber como]. Sua versão deve ser compatível com o resultado oferecido pelo Selenium IDE (estou utilizando a versão 4.11);
  4. Copiar a suíte de testes exportada do IDE para dentro do projeto Java. O arquivo .java deve ser inserido na pasta scr/test/java;
  5. Resolver os conflitos de projeto que ocorrem com a inserção da nova classe, ex.: importação da classe, nome da classe, chamada aos métodos, anotações. Lembrar de realizar “extends” para a classe TestCase e a importar.
    OBS.: Eu adicionei um construtor à classe passando o nome do caso de testes public PesquisaGoogle(String nomeTeste){super(nomeTeste)}, além do método public void testApp(){assertTrue(true);}
Importando uma suíte de testes do Selenium IDE como uma classe de testes JUnit no Eclipse

Importando uma suíte de testes do Selenium IDE como uma classe de testes JUnit no Eclipse

Executando o teste:

  1. Abrir a classe de testes importada no projeto (no projeto em questão é a classe PesquisaGoogle.java inserida na pasta scr/test/java).
  2. Verificar o resultado da execução na barra de execuções do JUnit na IDE.
Resultado de execução do teste

Resultado de execução do teste

Link para download do projeto

Enfim, nosso querido curso de Selenium WebDriver chega ao seu fim. Querendo Deus, este será o primeiro de muitos. Fica então o espaço de Comentários aberto para receber dúvidas, críticas, sugestões, melhorias/alternativas de conteúdo a estes posts.

Estou muito grata pelo retorno de vocês! Feliz 2015 a todos! =]

Padrão para Testes ISO/IEC/IEEE 29119

A instituição ISO está lançando o padrão internacional ISO/IEC/IEEE 29119 como um conjunto de práticas que devem ser seguidas por “qualquer organização, contendo qualquer ciclo de vida de desenvolvimento de software”. Ele deverá ser constituído por 5 parte, das quais 4 já foram divulgadas entre os anos de 2013 e 2014 [partes 1 a 4] e 1 está prevista para 2015 [parte 5]:

  1. Conceitos e Definições
  2. Processos de Teste
  3. Documentação de Teste
  4. Técnicas de Teste
  5. Testes baseados em Keyword

Esse padrão emprega as especificações de outros: IEEE 829 e 1008 e BS 7925-1 e 2. Por isso sua função será também substituí-los. Ele começou a ser escrito no ano de 2007 e desde de então vem sendo formulado por um comitê, a equipe WG26.

Apesar das críticas e movimentos contrários à sua formação, o padrão IEEE 29119 parece estar atendendo a pedidos do mercado, pois inúmeros gestores têm cobrado a normatização do processo de testes com vistas ao estabelecimento e garantia de melhor funcionamento deste setor e entrega de resultados por suas empresas. Ainda que isso não possa ser inferido pela prática de adoção de um padrão, seja este ou não, a simples tentativa em fazê-lo tem ganho entusiasmo no meio executivo de TI.

A principal preocupação da comunidade de testes em relação a esse padrão tem sido: 1- falta de consenso entre o comitê e a comunidade de testes; 2 – necessidade de documentação extensa e de difícil implementação prevista no padrão; 3 – engessamento ou retrocesso do processo de testes pela adoção do padrão; 4 – impacto em outras áreas do ciclo que não sejam teste.

Com isso, só nos resta ponderar as questões referentes à adoção do padrão e os impactos que isso poderá causar à TI. Os pontos citados foram considerados por representar maior criticidade à essa adoção.

Pontos à favor do padrão:

  • Empresas e Governo = As empresas e o governo enxergam uma certificação como referencial de correto funcionamento e garantia de qualidade do processo;
  • Opções de Certificação = O padrão passará a ser mais uma opção de certificação para as empresas;
  • Documentação = Tanto a equipe de testes como as demais, que constituam o ciclo de desenvolvimento de software, precisarão escrever mais a respeito de seus processos, técnicas e produtos de trabalho;
  • Discussão = A possibilidade de adoção do padrão fomentará conversas a respeito do processo de testes da empresa.

Pontos contra o padrão:

  • Comunidade de Testes = Uma das principais abordagens de testes utilizadas pelos testadores/empresas está sendo suprimida no padrão, conforme discussão da comunidade de testes: Context-Driven Testing;
  • Testers = Os profissionais de testes precisarão adequar suas atividades às diretrizes do padrão e o setor como um todo estará submisso, no que tange à produção de artefatos, ao que for produzido previamente como documentação de projeto;
  • Empresas e Governo = O setor responsável pela adoção dos padrões geralmente não tem visão geral do processo de desenvolvimento do software. Isso porque ele não é constituído por técnicos de TI ou os profissionais que efetivamente projetam/programam/testam o software;
  • Influência = O peso de uma certificação ISO conta pontos ao favor da empresa que a adotar. O risco é influenciá-la o mercado ao ponto de o cliente passar a exigi-la como pretexto para o fechamento de negócios.

Na minha visão, qualquer outra inferência a respeito da adoção ou não do padrão ISO 29119 pelas empresas que desenvolvem software seria prematura. Portanto, só nos resta aguardar a completa publicação do padrão e novos capítulos da discussão comitê WG26 x comunidade de testes para opinar a respeito.

Uma visão geral do padrão pode ser encontrada no link: http://www.bcs.org/upload/pdf/sreid-120913.pdf