Como foi o 9º Meetup DevTests HST com apoio da Matera

Confira tudo o que rolou no 9º Meetup DevTests!

Por ARIANE IZAC

 

Fiquei muito feliz com o convite do Jhony Asanuma para participar deste meetup, nós temos um polo tecnológico muito forte em Campinas, precisamos mover mais a comunidade, compartilhar mais informações.

 

Nós estávamos acompanhando as movimentações no grupo mas foi uma surpresa a casa cheia, que maravilha!

 

 

E sem delongas, com uma breve apresentação das empresas apoiadoras do evento, HST e Matera Systems, já iniciaram as palestras.

 

Um adendo para nosso novo mascotinho da Matera que roubou a cena, ele marcou presença também.

 

 

A Jacqueline abordou o tema planejamento de testes ágeis, passou primeiro uma base de agile testing para em seguida entrar no tópico automação. Trouxe algumas citações sobre o tema que são referências para ela e ressaltou a importância de se fazer um pair entre desenvolvedor e testador.

 

Para fechar, indicou algumas referências que a ajudou consolidar entendimento no assunto, principalmente no que diz respeito a estratégias de automação. Gostei bastante, e me identifiquei, com a frase da Janet Gregory que ela encerrou a palestra:

 

“Without the attitude, the skill is nothing”

 

 

 

Clique aqui para ver os slides da palestra.

Ao terminar muitas dúvidas foram levantadas e algumas discussões também. Essa é uma das minhas coisas preferidas em eventos, as discussões. E, principalmente, como você poderá refletir na sequência sobre tudo que falaram.

 

A Jacqueline Costa também quer deixar sua percepção da participação do evento:

 

“Há um tempo eu venho participando de alguns meetups (desdes de meetups voltados para reunir um grupo e conversar somente em inglês até entender sobre desenvolvimento de software) e sentia uma falta de haver algum que aborda assuntos também sobre testes. Pois bem, foi aí que um dia vi uma notificação falando sobre o “DevTests”, fui nos primeiros meetups e adorei: os organizadores foram super receptivos.

 

Então, o que eu posso falar deste meetup que tive a oportunidade de palestrar: foi incrível ver que antes reunia-se poucas pessoas no evento em uma salinha e agora vemos um espaço com mais de 80 pessoas e o melhor EU estava lá compartilhando meu conhecimento com estas +80 pessoas! Esta foi a primeira vez que palestrei para tanta gente e fiquei muito feliz pelo simples fato que eu comprovei: eu não sei tudo, mas o pouco que eu sei pode ser compartilhado, pode ajudar alguém, pode tirar a dúvida de alguém muito experiente e de alguém que está começando!

 

A organização está de parabéns! a equipe foi super atenciosa, ajudou em tudo o que foi preciso. Eu agradeço o convite, agradeço a HST para compartilhar o espaço e também a Matera pelo apoio!”

 

Outro momento bacana é o coffee. Calma gente! Não sou a morta de fome da turma. Encare esse momento como uma oportunidade. Oportunidade de conhecer pessoas e reencontrar outras que conheceu em outros eventos, e é claro, trocar ideias. Enfim, diria que é uma das partes mais ricas do evento, e é construída pelos participantes. Vá de mente aberta para contato, famoso networking. Alguma dúvida de que sempre há algo para agregar e muitas para receber nessa abordagem?

 

Na sequência, compartilhei um pouco sobre minha experiência com testes de performance, com dicas de alguns pontos que deveriam ser considerados antes de começar esse tipo de teste, entender os conceitos e principalmente, montar uma estratégia para esses testes não funcionais. O mais importante nessa etapa é a consciência de mudança de mindset para a condição desses testes. Lembrando que, não só no teste de performance, mas para outros tipos de testes também haverá um ciclo em planejar, construir o que planejou, medir se o executado está próximo  do previsto, aprender com erros e acertos e aprender a compartilhar também suas experiências.

 

 

Os slides da palestra estão disponíveis aqui.

 

Para fechar, fizemos sorteios de alguns brindes fornecidos pela Matera, e é claro, não poderia faltar a foto com os felizardos.

 

 

Agradecimentos a organização, foi um evento bem bacana e esperamos ter oportunidade de participar mais vezes. E principalmente, a todos participantes que contribuíram também, com essa troca de experiências, ideias e fizeram com que o evento fosse tão bacana, os mais sinceros, obrigada galera!

 

Por falar em agradecimentos, o Jhony Asanuma deixou seu comentário também:

 

“Eu não sou muito bom em falar, só queria agradecer vocês duas pelas excelentes palestras! Tivemos um recorde de participação, foram 89 pessoas presenciais e 11 pessoas que acompanharam a transmissão online.

 

Obrigado a Matera, HST e Assertiva por ajudarem a fazer este evento acontecer.”

 

Se quiser acompanhar as palestras na íntegra, acesse:  9º Meetup DevTests .

 

Se ainda não participa do grupo Devtests, junte-se a nós em: DevTests Campinas

 

E para fechar, por falar em eventos em Campinas, no dia 27/09/2018 será realizado o evento do GDG Campinas, Quality Fest 18. Esse evento aborda qualidade e tem muitas palestras interessantes. E vamos marcar presença lá também falando novamente sobre testes de performance.

 

 

Para mais informações:

 

Site: https://gdg-campinas.github.io/qualityfest/

Inscrição: https://www.eventbrite.com.br/e/qualityfest-2018-tickets-48899865815

Tenho um cupom de 30% de desconto: ariane-izac-quality-fest-30

 

Bora?

ESCRITA DE TESTES FUNCIONAIS UTILIZANDO SEMÂNTICA BDD

Escrever casos de testes funcionais é uma atividade de extrema importância, pois neste momento consistimos o entendimento do escopo e criamos um documento que poderá ser utilizando por qualquer membro do time ou até mesmo pelo cliente em fase de homologação.

No entanto, escrever esse documento pode ser uma tarefa longa e exaustiva dependendo da complexidade da funcionalidade trabalhada e o detalhamento que está sendo atribuído.

As consequências de casos de testes extensos podem ser variadas, como por exemplo:

  • Difícil entendimento de quem está lendo
  • Falta de entendimento do objetivo do que está sendo testado
  • Muito tempo sendo investido na etapa de escrita
  • Difícil manutenção dos templates de testes
  • Difícil reutilização dos templates
  • Entre outros

Entrando mais afundo sobre o tempo investido nessa etapa sabemos que, em times ágeis tentamos sempre trabalhar com tarefas que sejam rápidas de serem concluídas. Considerando que o real objetivo do caso de teste é descrever de forma clara a regra de negócio que deve ser validada, quando inserimos muitos passos podemos deixar o documento confuso e incoeso dificultando sua leitura e entendimento.

Considerando os problemas citados anteriormente que tal aprendermos uma nova forma diferente de escrever casos de testes funcionais utilizando a semântica do BDD que atualmente já está sendo fortemente utilizada em testes automáticos. (Para saber mais sobre BDD clique aqui).

Então vamos ao que interessa!

1º Critério de Aceite

O Guia PMBOK® define em seu glossário:

“Critérios de aceitação / Acceptance Criteria. Os critérios, inclusive requisitos de desempenho e condições essenciais, que devem ser atendidos antes que as entregas do projeto sejam aceitas.” (PMI, p.425)

Em outras palavras, é onde descrevemos a regra de negócio definida pelo Product Owner para cada cenário levantado avaliando se o que foi entregue é testável e está de acordo com o que foi definido no requisito.

2º Contexto

O contexto é composto pelas pré-condições, massa de dados, etc que se repetem para todos os cenários de um critério de aceite e que são necessários para execução do teste.

3º Cenário

Descreve o comportamento que o sistema deverá possuir. O cenário deve ser único e claro referente ao que será validado.

4º Construção do Teste

Agora vem o momento em que utilizaremos a semântica do BDD para estruturar o cenário de teste. Iremos utilizar as palavras chaves Dado, Quando e Então da seguinte maneira:

Dado: Quais pré-condições devem ser verdadeiras para que eu execute o teste?

Quando: Qual ação será executada no sistema que fornecerá o resultado validado?

Então: De acordo com a ação disparada qual o resultado esperado?

Também podemos utilizar a palavra chave E, quando for necessário adicionar uma sentença positiva, seja para Dado, Quando ou Então.

Exemplo:

Dado: que sou uma correntista
E: tenho R$ 500,00 de saldo na minha conta
Quando: eu solicitar um saque de R$ 600,00
E: possuir valor de cheque especial disponível em minha conta
Então: devo receber o valor de R$ 600,00
E: minha conta deve ficar com saldo em R$ 100,00 negativos

E o passo a passo?

É necessário?

Perceba que já temos na nossa documentação o critério de aceite com a regra de negócio, o contexto com as pré-condições do nosso teste, o cenário que será validado e qual o dado de entrada que junto com uma ação minha disparará um resultado que será positivo ou negativo dependendo do critério de aceite.

O como fazer (passo a passo) poderia ser substituído, por exemplo, com a prática do pair testingonde além de disseminarmos conhecimento estamos criando uma cultura de exploração das funcionalidades e requisitos do sistema e evitando o desperdício de tempo em atividades que não serão bem reaproveitadas.

Caso o cliente solicite nossos casos de testes, partimos do pressuposto de que ele já saiba operar o sistema que irá homologar e, portanto ter um documento que esteja claro e objetivo agrega muito mais valor.

Caso vejamos a necessidade de criação do passo a passo não há uma regra que nos impeça de criá-los. O importante é pensarmos se o que estamos criando hoje poderá ser reaproveitado amanhã e se está claro e objetivo.

Vantagens da escrita dos testes utilizando a semântica BDD
  1. Maior entendimento do requisito proposto
  2. Menos tempo investido em escrita de casos de testes
  3. Mais tempo investido em análise de cobertura de testes
  4. Estes testes podem ser utilizados por desenvolvedores na automatização
  5. Fácil manutenção de templates
Exemplos Completos

Exemplo 1:

Critério de Aceite: um caixa eletrônico deve permitir a retirada de dinheiro, quando o cliente não possuir saldo suficiente em conta e possuir limite de crédito aprovado.

Contexto: cliente deve ser correntista, estar com R$ 500,00 de saldo em sua conta e possuir limite de crédito aprovado maior que R$ 600,00.

Cenário: saque em dinheiro em conta corrente com saldo menor que o solicitado e com limite de crédito aprovado.

Dado: que sou uma correntista
E: tenho R$ 500,00 de saldo na minha conta
Quando: eu solicitar um saque de R$ 600,00
E: possuir valor de cheque especial disponível em minha conta
Então: devo receber o valor de R$ 600,00
E: minha conta deve ficar com saldo em R$ 100,00 negativos

Exemplo 2:

Critério de Aceite:  quando o usuário acessar a tela inicial do Facebook deverá ser apresentado os campos para novo cadastro e após preenchê-los e clicar no botão “Criar Conta” uma nova conta no Facebook com os dados informados deverá ser criada.

Contexto: usuário deve possuir uma conta de e-mail ou número de celular.

Cenário: cadastro de nova conta no Facebook

Dado: que estou na tela inicial do Facebook
Quando: eu preencher os campos de cadastro
E: clicar no botão “Criar conta”
Então: a mensagem “Conta cadastrada com sucesso” deverá ser apresentada
E: serei redirecionado para a página inicial da minha conta no Facebook

Perceba que não especificamos passo a passo o que deve ser feito e sim o comportamento de uma história dentro do sistema.

Uma boa prática é levantarmos os cenários que serão validados dentro do projeto e então estruturarmos eles utilizando a semântica BDD antes da reunião de planejamento. Dessa forma os cenários podem discutidos com a equipe e apresentados ao Product Owner para garantir que estes estão de acordo com as especificações do escopo. Para entender melhor sobre planejamento de testes clique aqui.

Boas Práticas:
  • Os casos devem descrever um comportamento e não um passo a passo;
  • Precisam seguir uma linguagem ubíqua, ou seja, qualquer pessoa que ler entenderá o objetivo;
  • O time integrante do projeto deve ser envolvido no refinamento dos casos;
  • Todos os cenários devem ser independentes;
  • Os casos devem ser validados com o Product Owner
Conclusão

A escrita de casos de testes é um processo importante na nossa área, pois este provê um documento com todos os cenários de negócio que serão exercitados durante o projeto. Porém, gastamos muito tempo na criação desses documentos aumentando a sua complexidade em termos de manutenção, entendimento, etc. Na era ágil em que estamos desperdício de tempo quase chega a ser um pecado e portanto buscamos aplicar técnicas que nos ajudam a diminuir o tempo das tarefas cotidianas mantendo ou aumentando a qualidade das mesmas. O BDD é uma técnica que inicialmente foi aplicada somente para testes automatizados, mas que pode perfeitamente ser aplicada em testes funcionais. Com a escrita de testes funcionais utilizando semântica BDD conseguimos criar um caso de teste muito mais claro, objetivo e enxuto nos dando muito mais tempo para análise de cobertura dos testes e consequentemente nos dando a oportunidade de melhorar a qualidade do produto entregue.

Referências

[1] https://escritoriodeprojetos.com.br/expectativas-requisitos-criterios-de-aceitacao-restricoes-premissas

[2] http://www.matera.com/br/2016/10/26/bdd-validando-o-comportamento-sistema/