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

Abrangência dos Testes Unitários

Os testes unitários são costumeiramente escritos pelos programadores dos módulos de um sistema. Ferramentas como JUnit e NUnit auxiliam na automação desta tarefa porque fornecem métodos próprios ao desenvolvimento e execução dos testes.

Os métodos dos testes unitários devem estar implementados em uma classe à parte que acompanhe as funcionalidades programadas para aquele módulo em questão. Um exemplo seria: na arquitetura de sistemas MVC (Model-View-Controller), de model Usuario, controller UsuarioController e view cadastrarUsuario.xhtml, o módulo de cadastro de usuário conteria a classe UsuarioTest. Esta classe deve conter basicamente a validação da função principal do módulo: cadastrar a entidade usuário. Mas, para que o teste cumpra o objetivo de detectar falhas no módulo, é adequado que se valide também os caminhos alternativos à ação cadastrar usuário. Exemplos são: testar nulidade de dados obrigatórios para a entidade, duplicar cadastro de usuário, entre outros.

Por permissão da arquitetura projetada ou por opção do programador, é possível que se realize teste unitário para todas as camadas de uma arquitetura: camada de banco de dados, de modelagem, de controle, de manipulação da apresentação, de apresentação, de integração, etc. No entanto, por conta do próprio conceito de unicidade, é adequado que se analise apenas um escopo de código-fonte por vez. Esse escopo pode corresponder a um método específico ou a um pequeno conjunto deles que levem ao caminho de cadastro com sucesso ou sem sucesso. Um exemplo da primeira situação seria o método testarCadastroUsuario(), relacionado com o método de cadastro com sucesso do UsuarioController, inserirUsuario(). Um exemplo do segundo seria testarUnicidadeUsuario(), relacionado aos métodos inserirUsuario() e validarUnicidade() do UsuarioController.

O ideal é que se reserve os testes unitários para as camadas de banco de dados e controle/serviço. Isso porque este é o espaço da arquitetura que geralmente abriga a maior parte da implementação das regras de negócio, à nível de código-fonte. Evidente que, caso haja mais camadas de persistência de funções/transações e validação dos dados da entidade, elas devem participar deste conjunto.

A camada de apresentação também pode ser validada com o auxílio das ferramentas de testes unitários, a exemplo do Selenium WebDriver que se relaciona com o JUnit, NUnit entre outras. Mas é importante que se observe o objetivo do teste deixará de ser “avaliar uma função unitária” (teste unitário) para “avaliar um fluxo de atividade sobre o sistema” (teste de sistema).

O teste unitário avalia unidades de código-fonte, ele é intrinsecamente, um teste de caixa branca voltado para a análise de uma função específica do sistema. Ele se relaciona com cada método codificado para a persistência ou validação de regra de negócio. Já o teste de sistema tem foco na execução de um fluxo de sistema que conclua uma atividade. Ele pode até ser à nível de código-fonte, mas seu resultado só pode ser observado à nível usual. Ele se relaciona a uma ação sobre o sistema: clique do botão inserir, na tela do sistema; disparo da trigger de atualização da lista de usuários, no banco de dados, etc.

No final das contas, além do conceito de testes unitários os seguintes fatores irão influenciar na abrangência de aplicação deles: o nível de flexibilidade da arquitetura do software, se o projeto permite que se crie classes integradas à todas as camadas do projeto; o ritmo do projeto: qual a frequência de entrega das atividades -final do dia, semana, mês; tamanho e objetivo do projeto: o custo X benefício deve ser avaliado; entre outros.

Curso de Selenium WebDriver – Aula 5 – WebDriver além do Firefox

O navegador Firefox é o browser oficial do Selenium. Isso porque o Selenium IDE foi criado inicialmente para ser um plugin deste navegador. Antes da criação do Selenium WebDriver, ou Selenium 2, era necessário utilizar o Selenium RC para rodar os testes criados no Selenium IDE remotamente ou em outros navegadores.

Ao informar o seguinte trecho de código-fonte na classe de testes suportada pelo Selenium WebDriver, o teste roda sem problemas no navegador Firefox (para ver as configurações gerais do projeto acesse a aula 1 do curso neste blog):

  • WebDriver driver = new FirefoxDriver();

Seria bastante óbvio e cômodo apenas substituir a classe FirefoxDriver pelos demais navegadores a que o Selenium oferece suporte – Chrome, Internet Explorer, Safari, entre outros. No entanto, não é bem assim. Antes, é necessário configurar o arquivo Pom.xml do projeto, informando novas referências ao browser em questão e informar no código do teste o caminho que o executável dele está disponível.

Vejamos o exemplo do navegador Chrome, em ambiente Linux, IDE Eclipse, plataforma Java  e projeto integrado com o plugin Maven:

  1. Abrir o arquivo Pom.xml do projeto e informar a dependência para o chromedriver.
    1. <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-chrome-driver</artifactId>
      <version>2.43.1</version>
      </dependency>

    chrome-driver

    chrome-driver

  2. Realizar o download do “executável” do chromedriver no link < lembrar de baixar o executável compatível com a versão do seu sistema operacional – 32 ou 64 bits – no meu caso é a versão 64bits >;
  3. Descompactar o pacote do executável do chromedriver em uma pasta do sistema operacional;
  4. Passar o caminho da pasta do executável do chromedriver no código-fonte do teste
    1. System.setProperty(“webdriver.chrome.driver”, “/home/lorena/workspace/chrome64/chromedriver”);
  5. Escrever um método de teste:

    Método de testes básico para execução sobre o Google Chrome

    Método de testes básico para execução sobre o Google Chrome

  6. Executar o teste [utilizei o JUnit 4 para rodar o teste]:
    Teste em execução no Google Chrome

    Teste em execução no Google Chrome

    Resultado do teste no JUnit

    Resultado do teste no JUnit

Link para o download da classe ChromeTest.

Link para o download do projeto.

Referências:

https://sites.google.com/a/chromium.org/chromedriver/home

http://docs.seleniumhq.org/docs/03_webdriver.jsp#chrome-driver

http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/chrome/ChromeDriver.html

Coding Dojo: uma abordagem multiutilitária

O Coding Dojo é uma técnica própria ao aprendizado e passagem de conhecimento a respeito de matérias da Computação como lógica de programação/estrutura de dados/linguagens de programação/testes de software. Se bem avaliado, é também uma abordagem social, pois ele traça uma forma de integrar o time e nivelar o  grau de conhecimento dos seus participantes.

O Coding Dojo acontece em uma reunião, onde um computador com o mínimo de configuração para programação e uma tela de projeção devem estar disponíveis para que duplas de desenvolvedores se juntem e iniciem um ciclo de testes+codificação. As duplas devem atuar na resolução de um problema/programa alvo, definido previamente para aquele dia/ocasião. Exemplos de problemas/programas alvo podem ser encontrados neste link.

Existem diversas metodologias para o desenvolvimento de Coding Dojo, sendo algumas: Kata, Randori e Kake. No entanto, a forma básica de implementar Coding Dojo segue esse esquema:

  • O computador é a ferramenta utilizada para integrar o time. Nele deve estar implantado o ambiente de desenvolvimento do programa. A tela de projeção deve apresentar todas as ações realizadas no ambiente de desenvolvimento para que o time tenha visão de todo o processo;
  • As duplas devem operar o computador e utilizar do ambiente de desenvolvimento para construir o programa. Todo o grupo: dupla atuante no computador + restante do time, pode opinar a respeito da direção e próximos passos a serem implementados no programa;
  • As duplas são formadas por: 1 integrante piloto e 1 integrante co-piloto; A dupla atual da etapa ouve as opiniões alheias, decide o próximo passo a executar para a resolução do problema e discutem a forma de implementá-lo;
  • As duplas não são fixas. Apenas a primeira delas é. No restante do tempo elas se revesam. Na etapa posterior à atual, o integrante piloto retorna para o grupo; o integrante co-piloto passa a ser piloto; e um novo integrante do grupo passa a ser o co-piloto.
  • As duplas têm um tempo fixo para implementar a tarefa atual daquela etapa do processo. Ao final do tempo cronometrado, a dupla passa por substituição e deve: 1 – dar prosseguimento à implementação da tarefa atual; ou 2 – implementar uma nova tarefa.
  • As duplas devem explicar suas ações ao restante do grupo durante a execução da tarefa ou após o seu fim;
  • A implementação do programa é executada através da metodologia TDD. Ou seja, antes que uma função do programa seja construída, o seu teste precisa ser escrito. Sendo assim, o objetivo de cada etapa do processo é fazer o testes passar. Após isso, a dupla atual da etapa decide qual será o próximo destino: refatorar o teste ou seguir para a implementação da outra função do programa.
  • A implementação do programa acaba quando todos os testes do problema/programa alvo definido passam. Neste ponto do processo o grupo decide evoluir o problema ou encerrar a reunião.

Podem existir variações desse formato descrito, como, por exemplo: (i) definir  mais de um problema/programa alvo para resolução no dia/ocasião; (ii) resolver um problema/programa alvo em mais de um dia/ocasião; (iii) dividir o time em subgrupos, para que trabalhem em tarefas paralelas ou compitam entre si \o/ ; (iv) integração de novas técnicas ao processo (ex.: BDD); (v) reunir o time em espaço virtual; (vi) integrar documentação ao processo; (vii) uso de mais de uma linguagem de programação ou ambiente de desenvolvimento (integração de novas ferramentas); entre outros. Essas são variações do processo aplicadas como formas de corresponder ao status/condição atual da equipe, da disposição e disponibilidade local da reunião, do conhecimento do grupo. Elas são responsáveis por enriquecer a experiência e intensificar a troca de conhecimento.

O problema deve ser escolhido de forma a fazer com que todas as pessoas do grupo executem os dois papéis da dupla ao menos 1 vez durante o processo de implementação do programa. Por conta disso, deve ser avaliado o tamanho dele. Deve ser observado também qual o grau de maturidade do time antes do início da reunião, para que sejam escolhidos problemas-alvo compatíveis com o tempo de experiência do assunto da maioria de seus integrantes. O nível de complexidade do problema/programa deve crescer a cada reunião realizada. A entrada de integrantes mais experientes também pode impulsionar a resolução de problemas mais complexos.

Com vistas a todas as características/regras citadas e o intuito de formação das reuniões, é possível atribuir os seguintes benefícios a ele:

  1. Desenvolvimento de raciocínio lógico – resolução dos problemas;
  2. Desenvolvimento profissional multidisciplinar – testes/codificação/instrumental (ferramentas);
  3. Desenvolvimento social – formação de networking, troca de experiências e culturas;
  4. Nivelamento de conhecimento da equipe – profissionais/estudantes de diversas áreas e níveis de conhecimento; Organização e disciplina – o ciclo segue um formato previamente estabelecido; as duplas têm um prazo para cumprir suas atividades;Tolerância e Respeito mútuo – o time deve respeitar todas as opiniões e compartilhar ideias.

Referências:

http://www.codingdojo.org/

http://dojorio.org/

http://www.devmedia.com.br/o-que-e-o-coding-dojo/30517