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 que ainda precisamos falar sobre diversidade nos ambientes de TI?

Por que?

Quem atua no mercado formal de trabalho hoje lida com as constantes mudanças comuns à cultura da inclusão. Em escritórios nos deparamos com pessoas de diferentes gerações, anseios e responsabilidades.

As pluralidades da sociedade: gênero, etnia, condições físicas e de vida, já estão refletidas no mundo corporativo. Nos ambientes de TI as equipes multidisciplinares são utilizadas como base para a aplicação de metodologias de trabalho capazes de garantir entregas “rápidas”. Isso, por formar times heterogêneos, contendo um pouco de cada especialidade necessária ao antedimento de produtos específicos, restringindo com isto os seus focos de atuação e por consequência ganhando em produtividade.

A esses times  deu-se a responsabilidade de decidir estratégias às soluções: o que fariam e em quanto tempo; com qual o grau de prioridade; e, com quais custos e ferramentas. Eles ganharam a capacidade de discutir ideias. Mas como ser eficaz se só ouço a minha parte da  clientela, a minha “face da moeda”, quando o mundo a quem atendo me apresenta múltiplas?


Por que uma figura “diferente” em meu time ainda me incomoda tanto?

Pela falta de representatividade. E o que isto significa? Que embora eu tenha contato com pessoas “diferentes” de mim em meu meio de convivência ou ambiente trabalho eu não as tenho como modelo, eu ainda não as enxergo como um exemplo a ser seguido ou muitas vezes não valorizo o seu discurso:

  • Apenas 2% dos funcionários das maiores empresas brasileiras são pessoas com deficiência (o mínimo exigido pela lei);
  • As mulheres representam 58,9% dos estagiários e apenas 13,6% das vagas executivas;
  • As mulheres recebem 70% da massa salarial obtida pelos homens;
  • Não existe um executivo de origem indígena nas empresas estudadas;
  • 94,2% dos cargos executivos pertencem a brancos, enquanto apenas 4,7% dos negros ocupam cargos nesse nível. Superatualizado

E por isso é tão importante incluir, para que pela noção de representatividade, cada pedacinho da sociedade se sinta motivada a colaborar com novas ideias. Soluções essas que poderão ser usadas por todos.


É lacração? É vitimismo? É mimimi?

Continuar lendo

Algumas aplicações para a ferramenta Selenium IDE

big-logoA ferramenta Selenium IDE é um plugin desenvolvido para o navegador Firefox. Sua principal função é gravar e executar scripts automatizados de testes funcionais. Ela atualmente apresenta também a possibilidade de edição destes scripts em linguagens de programação como: Java, Ruby, C#, Python e JavaScript.

Em um passado recente, período entre 2007 e 2012, seu uso foi difundido nas empresas que produzem software do Brasil. Isso impulsionou uso de automatização dos testes como meio de promover e facilitar a regressão na manutenção dos sistemas-produto e inclusive motivou estudos a respeito das atividades do testador, neste contexto.

Recentemente, diversas fontes têm apontado a ferramenta Selenium IDE de uso não recomendado, apesar de sua evolução. O discurso comum é de que ela enrijece a automação e por isso provoca a constante necessidade de revisão dos scripts gerados. Ela também apresenta limitações quanto ao: compatibilidade (gravação restrita ao Firefox, incompatível com algumas versões), integração aos scripts automáticos de páginas web (ex.: AJAX, JavaScript) e interação com as janelas do sistema operacional (não oferece suporte).

Continuar lendo

1º Encontro de Testers de Salvador

O Grupo Teste de Software Salvador está promovendo o 1º Encontro de Testers de Salvador. Integrantes do grupo responderam a um questionário para promover o 1º Encontro de Testers de Salvador/BA.

Eles decidiram que:
  • O espaço deve ser virtual – Hangout, Skype, etc.
  • O formato deve ser discursivo, onde todos os participantes devem interagir para expor assuntos e ideias;
  • O evento deve estar aberto a todos os profissionais de TI, interessados pelo tema de testes de software;
  • A duração deve ser aberta, com o mínimo de 30 minutos;
  •  Nossos encontros devem ser bimestrais.
Dito tudo isso, reserve tempo na agenda para nosso primeiro encontro. Ele acontecerá daqui 1 semaninha, dia 20/07, à partir das 19:30, via Skype.
A pauta também foi elaborada por eles. Os temas citados foram:
  • Mercado de testes em Salvador/Bahia, principais empresas, tendências em certificações, perspectivas da área;
  • Perfil e atividades do testador;
  • Automação de testes;
  • Movimento Ágil – teste ágil;
Não deixe de participar e enviar sugestões para o evento!
logo

Introdução ao Teste de Software

Você estudante de TI, quer iniciar a carreira em testes e não sabe por onde começar? Você desenvolvedor já atuante na área deseja estar preparado para o mercado e potencializar sua atuação?

Estão abertas as inscrições para o curso EAD de Formação em testes de Software – Introdução ao Teste de Software.

Data: 29 e 30 de junho
Investimento = R$120,00 (valor promocional até dia 22/06)
Carga horária: 4 horas
* Acompanha emissão de certificado

Para mais detalhes, confira os dados abaixo ou clique no link:

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

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