#DesafioAgileTesters SpecFlow e BDD

Pronto pessoal, desafio dado é desafio concluído!

images

Conforme expliquei anteriormente, decidi sair um pouco da série do Specflow, para fazer esse post sobre o specflow…. pode não fazer muito sentido, mas eu sentia que seria trapaça no desafio rs.

Enquanto a série vai ser um resumo dos meus estudos da documentação, esse post vai tratar de alguns pontos diferenciados, como utilidade da ferramenta e metodologia, que foram pontos que preferi não abordar na série para evitar excesso de informações.

“Esse post vai ser muito técnico?”

Sei que a proposta do desafio leva para um post mais técnico, mas contudo como não tenho pleno conhecimento sobre a ferramenta, vou ficar devendo nesse sentido ( sem código…sem github….  desculpem), mas gostaria de lembrar que a série sobre o specflow vai ser mais técnica, pois é exatamente esse o intuito dela.

Antes de falar do specflow em si, quero comentar sobre o BDD (behavior driven development ou desenvolvimento baseado no comportamento) , ou seja o desenvolvimento é baseado no comportamento da aplicação, uma linguagem simples e compreensível por qualquer pessoa que venha a ler o documento, ao invés de ter algo como “TestParameterResponseWhenNullIsInformed” (testar resposta do parametro quando é informado valor nulo) nós temos um  “ValidateWhatIsDisplayedWhenIDontFillAMandatoryField” (validar o que é exibido quando não preencho um campo mandatório), você pode estar se perguntando quais são as vantagens dessa metodologia, eis alguns pontos que considero relevantes:

  • Como o teste está escrito de uma forma simples, ele pode ser usado como documentação, pois já demonstra os cenários que estão sendo testados, as vezes mesmo quem não conhece a aplicação em questão já pode entender alguns aspectos (se tiver um cenário “ValidarAcessoComSenhaIncorreta” já sabemos que a aplicação vai ter uma tela de login)
  • A comunicação entre clientes e desenvolvedores fica muito mais fácil, com o cliente lendo os cenários e vendo a cobertura dos teste de uma forma simples, fica muito mais fácil de ele dar opiniões relevantes sobre a visão do projeto, sendo assim ele pode até mesmo incluir um cenário ou corrigir algum já existente
  • Mesmo que algumas alterações sejam feitas na aplicação, os cenário raramente mudam, ou mudam pouco… ou seja uma correção do teste é muito mais simples, digamos que o Front sofra algumas alterações para melhorar o desempenho da aplicação, os testes provavelmente vão quebrar (já que os elementos da página irão sofrer alterações), mas o cenários continuam os mesmos, então pequenas alterações no código do teste já deve fazer com o teste passe novamente
  • O retorno dos testes é muito simples de entender…. uma bolinha verde significa que o teste passou, uma vermelha significa que não…. e caso você seja daltônico, eles ficam separados em “passou” e “não passou”

Mas, se você está se perguntando “O desafio era Specflow….por que você está falando de BDD?”  e bem… Specflow é BDD (simples assim rs), então  acho super justo começar falando sobre o BDD, claro que existem outras formas de utilizar o BDD ( depende da linguagem que você está usando), mas o specflow tem alguns detalhes bem interessantes que eu gostaria de ressaltar:

  • Integração com VisualStudio, que é uma ferramenta bem padrão.
  • Aceita qualquer linguagem .NET
  • Tem o debugger (não que eu saiba usar isso direito ainda, mas dá pra ter uma ideia legal de onde exatamente o problema está)

(Agora estou naquele momento mais delicado, onde quero entrar em maiores detalhes, mas não quero atropelar a série do specflow)

Uma coisa que estou sentindo é que o Specflow é um ótimo ponto de partida para programar/testar, você entra em contato com o código do front das páginas, que costuma ser bem simples, e ajuda bastante a entender a lógica da programação

Screenshot_1
Sim, estava brincando com a página do Google, conseguem ver as diferenças rs?

É algo que pode até parecer simples e bobo, mas aos poucos vai mostrando ser uma ótima de conhecer não apenas os códigos e lógica, mas também algumas boas práticas e padrões que existem por aí (para quem desconhece a parte de baixo da tela, é o inspetor de elemento, para acessá-lo é bem simples, se você estiver no Chrome, basta clicar com o botão direito na tela, e clicar em inspecionar…. vale a curiosidade), e é algo que tem me ajudado com alguns testes de segurança mais simples (por exemplo se um botão está “disabled” e eu mudo para “enabled” (desabilitado/habilitado), será que o sistema vai bloquear a operação mesmo assim?)…. opa olha eu colocando a carroça na frente dos bois….

Esse item de inspeção é muito importante para o Specflow, você acaba utilizando e MUITO  (sim, usei o “muito” em seguida para reforçar isso) esses elementos da tela, são com esses dados que o Specflow se orienta, sendo dessa forma temos que acessar a página da aplicação e buscar um elemento para adicioná-lo ao código, seja para que o specflow saiba em qual campo ele deve preencher com certa informação, ou em qual botão ele deve clicar… e mais uma vez, é muito mais fácil se você souber inglês 🙂

 

Mas nem tudo são flores na vida… o BDD tem alguns problemas a serem considerados

  • O envolvimento do tester tende a ser menor no começo do projeto, como o teste começa a ser preparado após a interface, o tester pode ficar um pouco limitado durante o desenvolvimento (mas convenhamos que esse tempo pode ser aproveitado para preparar a área de cobertura e entendimento do projeto junto com o Stakeholder)
  • A manutenção é simples, mas CONSTANTE
  • É um processo mais caro, como requer manutenção e desenvolvimentos contantes durante o projeto… demanda muito tempo, e como diria o Tio Sam “Time is money”
  • Os testes demoram….sério…. Abre a página, busca elemento, clica em elemento, espera carregar outro elemento, clica em elemento… não é difícil ver cenários que duram mais que um minuto (ou 3, ou 5…) agora pensa naqueles 300 testes criados…. pois é.

 

Pontos que gostaria de mencionar, mas não soube como encaixar eles de uma boa forma no texto:

  • Uma coisa que devemos ficar atentos, é se os cenários criados no specflow são independentes uns dos outros, digamos que eu tenho um teste aonde preciso deletar uma foto do meu perfil (ou seja preciso ter uma foto no meu perfil), se ele estiver dependendo por exemplo do teste “IncluirFotoNoMeuPerfil”, que por sua vez está relacionado ao “CriarUmPerfil”…vai virando uma bola de neve, é mais fácil o próprio teste “DeletarFotoDoMeuPerfil” já ter como passo dele a inclusão da foto… entenderam por que tem alguns cenários que demoram muito? (Mas se não fosse assim, eu teria que rodar 3 testes ao invés de um apenas, e isso inclui abrir o navegador três vezes, que iria demorar mais ainda)
  • UM teste faz UMA validação, ou seja, não faça testes onde cada passo faz uma validação diferente, crie cenários únicos…. até pra evitar nomes como “ValidaSeSalvaAFotoDoPerfilESeConsigoEditalaFuturamente”

E meu post para o desafio será esse 😉

Espero que atenda as expectativas , por que realmente fui pego de surpresa, e fiz ele em dois dias (para substituir o post das minhas metas rs da mentoria), o meu desafio já foi feito no post anterior, e continuarei a falar de specflow em breve.

Por favor, sintam-se a vontade para opinar sobre esse (e qualquer outro) post 😉

 

 

Anúncios

Um comentário sobre “#DesafioAgileTesters SpecFlow e BDD

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s