Cucumber utilizado como documentacao de requisitos

[Juliane Bentivoglio]

Ola pessoal,

A empresa onde trabalho esta querendo comecar a usar Cucumber e eu recentemente (ontem!) comecei a estudar a respeito.

Pelo que ja li ate agora, parece que esta 'ferramenta' pode ser usada para muito mais alem de apenas automacao de testes, por examplo: documentacao de requisitos e a validacao dos mesmos com stakeholders, com a vantagem de acabar virando a documentacao do sistema tambem.

Alguem aqui no grupo ja usou ou esta usando Cucumber? 

Do ponto de vista de AN, vcs acham uma boa forma de documentacao de requistos? 

Alguem ja usou para validar requistos com stakeholders e achou que deu certo?

Quaisquer experiencias que possam compartilhar - boas e ruins - serao muito uteis.

Obrigada desde ja!

Abracos

Juliane

[Jorge Diz]

Juliane:

O Cucumber é parte de uma categoria de ferramentas que ajuda a definir o comportamento

do sistema através de especificações executáveis. Em particular, o Cucumber segue o gabarito

conhecido como BDD. Como ... eu quero .... para .... Dado que ....quando ... então....

Para todos os envolvidos, e em particular para o analista de negócios e afins, isto significa 

reavaliar vários conceitos:

A documentação passa a ser viva. O que muitos não se dão conta é que a maior parte da documentação que tradicionalmente é gerada não é apenas desperdício, mas gera ruido que atrapalha a comunicação entre os envolvidos e desmotiva autores e possíveis leitores.

Dependendo da bagagem de cada um, o uso da ferramenta acaba sendo diferente. Quando usada por um desenvolvedor, vira sintaxe alternativa para testes de unidade. O testador vai ver uma linguagem especializada para scripts de teste, e o analista funcional vai enxergar uma forma de escrever casos de uso.

Lembra muito a história dos monges cegos tateando as partes de um elefante.

O desafio é utilizar a ferramenta como apoio a uma documentação executável, para criar uma linguagem

comum a todos os atores do processo. Na metáfora anterior, fazer com que todos falem sobre o elefante.

As fórmulas do BDD são um gabarito, e na minha opinião são um guia útil para começar, mas engessam a construção dessa linguagem comum.

Há outros formatos baseados em wiki, planilhas e gabaritos de trechos de texto. Tenho usado na prática e vejo bons resultados: vale a pena explorar esse caminho sim.

Jorge Diz

 

 implementa o conceito de BDD

(behavior driven development)

2013/4/24 Juliane Bentivoglio <julia...@gmail.com>

--
--
Mensagem do grupo AN-BR {Análise de Negócios}.
Para publicar mensagens, mande um email para: an...@googlegroups.com
Para cancelar sua participação, mande um email para: an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR
 
Este grupo é administrado pelo Capítulo SP do IIBA - http://www.theiiba.org.br/
 
---
Você está recebendo esta mensagem porque se inscreveu no grupo "Análise de Negócios . br" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para an-br+un...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Juliane Bentivoglio]

Ola Jorge,

Acho que você tocou exatamente no ponto em que eu estou em duvida quando você disse: "O que muitos não se dão conta é que a maior parte da documentação que tradicionalmente é gerada não é apenas desperdício, mas gera ruido que atrapalha a comunicação entre os envolvidos e desmotiva autores e possíveis leitores."

Eu to lendo o livro The Cucumber Book (Matt Wynne e Aslak Hellesoy) e tem um capitulo que fala exatamente sobre isso - "When cucumbers go bad" - e explica que muitos stakeholders podem perder interesse em ler a documentação, por isso deve-se procurar sempre usar uma linguagem bem simples e evitar termos tecnicos.

Ate agora, esta me pareceu ser a unica desvantagem, porque se for realmente possivel escrever casos de uso que podem ser utilizados como criterios de aceite para clientes, casos de teste e ainda uma documentação posterior, isso nao me parece desperdicio de forma alguma, pelo contrario.

Eu ja estou escrevendo documentação usando cucumber e os desenvolvedores estao adorando, mas nada concreto aconteceu ainda, apenas uma empolgação geral. Eu também vejo claramente o beneficio do uso de cucumber para automacao de testes no futuro. O ponto em que eu ainda estou meio cética é com relação a receptividade dos stakeholders. Quando eu li no livro que escrevendo cenarios desta forma vc consegue transformar a documentação em algo muito mais visual e, consequentemente, consegue validar requisitos com os clientes bem antes de comecar a implementar, eu tive um sentimento de 'e bom demais pra ser verdade'. Se e tao bom assim, por que nao ta todo mundo usando, sabe? Sera que nao usam porque analistas de negócios nao querem escrever requisitos seguindo este padrao, ou sera que tentaram e nao deu certo? Por isso postei a pergunta aqui no grupo.

Entao quando voce diz que tem visto bons resultados, sao estes resultados baseados em usar cucumber apenas como automação de testes ou tambem para documentar requisitos?

Obrigada,

Juliane

[Jorge Diz]

Juliane:

Parece que temos visões bastante parecidas. Vou comentar por partes:

[

Eu to lendo o livro The Cucumber Book (Matt Wynne e Aslak Hellesoy) e tem um capitulo que fala exatamente sobre isso - "When cucumbers go bad" - e explica que muitos stakeholders podem perder interesse em ler a documentação, por isso deve-se procurar sempre usar uma linguagem bem simples e evitar termos tecnicos.

]

A palavra chave ai é *ler*. Tendemos a pensar na documentação como um suporte de informação que flui num sentido só. Autor ---(documento)---> leitor. Precisamos passar a pensar nela como um suporte para facilitar a comunicação permanente entre todos os envolvidos: para isso, ela tem que ser viva, maleável e de autoria coletiva. Não se trata propriamente de evitar termos técnicos, mas ficarmos abertos a modificar formato e conteúdo para fazer com que todos se sintam parte. O conteúdo mais técnico pode estar presente, desde que fique clara sua natureza para quem navega na documentação. Como analogia, se eu leio um jornal e não ligo para esportes, a organização do jornal me ajuda a não desperdiçar minha atenção.

[

Ate agora, esta me pareceu ser a unica desvantagem, porque se for realmente possivel escrever casos de uso que podem ser utilizados como criterios de aceite para clientes, casos de teste e ainda uma documentação posterior, isso nao me parece desperdicio de forma alguma, pelo contrario.

]

Sim. A questão é que o papel do caso de uso no ciclo de vida do software precisa ser repensado.

Vamos lembrar que os casos de uso quase sempre são tratados como um formato de especificação que vira  insumo para uma fase posterior de projeto da solução, codificação e dai corredeira abaixo (implicitamente, assume-se um processo em cascata). Nesse modelo mental, as fábricas de casos de uso fazem sentido.

As fábricas de desenvolvimento e as fábricas de teste, que usam casos de uso como insumo, também.

Precisamos quebrar o paradigma de que casos de uso precisam ser abrangentes. Eles são apenas exemplos de utilização do sistema para ilustrar o entendimento comum. Este último não é insumo, mas é produto do processo de desenvolvimento. O sincronismo entre os artefatos que especificam como o sistema deve se comportar (no papel duplo de requisitos e testes) e sua implementação é o reflexo da saúde desse entendimento comum. 

[

Eu ja estou escrevendo documentação usando cucumber e os desenvolvedores estao adorando, mas nada concreto aconteceu ainda, apenas uma empolgação geral. 

]

Para o desenvolvedor, a representação de requisitos em formato executável é bem vantajoso mesmo,

em termos de clareza do que precisa ser feito.

[

Eu também vejo claramente o beneficio do uso de cucumber para automacao de testes no futuro

]

Sim, mas o fato de forçar uma especificação clara é vantajoso independentemente de implementar a cola 

que permita a execução automática.

[ 

Quando eu li no livro que escrevendo cenarios desta forma vc consegue transformar a documentação em algo muito mais visual e, consequentemente, consegue validar requisitos com os clientes bem antes de comecar a implementar, eu tive um sentimento de 'e bom demais pra ser verdade'. Se e tao bom assim, por que nao ta todo mundo usando, sabe? Sera que nao usam porque analistas de negócios nao querem escrever requisitos seguindo este padrao, ou sera que tentaram e nao deu certo? Por isso postei a pergunta aqui no grupo.

]

Na verdade, acho que não dá para se adiantar muito. Seguindo a ideia de um modelo comum, e não de um pacotão a ser gerado e passado para a frente, estes instrumentos devem ser trabalhados um paralelo com o desenvolvimento: todas as partes precisam aprender a usar uma linguagem comum.

Acho que não tem mais gente usando porque ainda estamos presos a criar especificações no formato de casos de uso mais tradicional, e porque focamos nas telas antes de focar no modelo. Casos de uso detalhados não descrevem o problema, mas a solução, e o fazem muito precocemente.

Quando usamos esse nível de detalhamento, estamos no espaço da solução. Precisa haver sensibilidade por parte do analista quando esse nível de detalhe afasta o interesse do cliente, que foca no negócio. Ou, pior, quando delegamos ao cliente a definição dos detalhes técnicos da interface de usuário e perdemos boa parte de nossa interação discutindo coisas irrelevantes para o negócio.

O formato do Cucumber (BDD) ainda tem muita cara de desenvolvimento. Por isso, é bom lembrar que formatos de planilhas e desenvolvimento de linguagem de domínio são outros caminhos a trilhar.

[

Entao quando voce diz que tem visto bons resultados, sao estes resultados baseados em usar cucumber apenas como automação de testes ou tambem para documentar requisitos?

]

Vi bons resultados usando planilhas executáveis, que são documentação e testes ao mesmo tempo.

O analista se sente muito a vontade com planilhas, onde pode validar os resultados entregues pelo sistema sendo desenvolvido com o modelo que ele cria na planilha. A conversa fica no espaço dos serviços que expõem a lógica de negócio, mais que nos detalhes da interface usuário;

Já com BDD (Cucumber, EasyB), minha experiência mostrou que o pessoal acaba focando em passos da interface de usuário e validação do conteúdo que vai aparecer. Poderiamos fazer diferente, mas é fácil cair na armadilha.

Espero ter contribuído,

Jorge Diz

 

2013/4/25 Juliane Bentivoglio <julia...@gmail.com>

[Fabrício Laguna]

É possível mostrar alguns exemplos desta documentação? 

Achei o tema deveras interessante.

Fabrício Laguna Consultor e Instrutor celular: (11) 99659-8948 skype: flaguna

[Eduardo Cristiano Negrão]

Boa Fabrício! Também tive esta curiosidade! 

Att,

2013/4/26 Fabrício Laguna <fla...@giganteconsultoria.com.br>

--

Eduardo Cristiano Negrão - eduardo...@gmail.com

Software Engineer

portalengenhariadesoftware.blogspot.com
portalarquiteto.com.br

[Juliane Bentivoglio]

Ola todos,

@Jorge, 

Obrigada por compartilhar sua opiniao, vc contribuiu sim. E desculpe os textos destacados em amarelo - eu uso um teclado que nao tem portugues instalado entao eu tento colocar pontuacao aceitando as sugestoes de auto-correcao do gmail. Nao sei o que eu fiz de errado pro amarelo ficar dessa vez...rs

@Fabricio, @Eduardo,

Um exemplo (tirado do livro que eu citei acima) seria:

Feature: Sign Up

Sing up should be quick and friendly

Scenario: Successful sign up

New users should get a confirmation email and be greeted personally by the site once signed in.

Given that I have chosen to sign up

When I sign up with valid details

Then I should receive a confirmation email 

And I should see a personalised greeting message

Scenario: Duplicate email

Where someone tries to create an account for an email address that already exists

Given I have chosen to sign up

When I enter an email address that has already registered

Then I should be told that the email is already registered

And I should be offered the option to recover my password

Cucumber permite as palavras chaves (em negrito) sejam interpretadas como comandos e, dessa forma, tanto um computador quanto um humano possam rodar os mesmos testes.

Ainda estou estudando... por enquanto estou usando apenas como documentacao mas estamos conversando muito sobre transforma-los em testes o quanto antes. Compartilharei minhas experiencias quando comecarmos a usar Cucumber oficialmente.

Abracos

Juliane

[Fabrício Laguna]

Obrigado por compartilhar, Juliane.

[Rafael Barbosa camargo]

Boa Jorge.

Muito legal este tema aqui.

Lembro que, como o Cucumber, temos vários outros.

Concordion, Jbehave e etc.

O formato da declaração (When, So, Than) é muito bom a ser seguido, mesmo quando eles não são "implementados" via código neste tipo de ferramenta.

Particularmente, nesta via de mão dupla da documentação (detentor do conhecimento - receptor do conhecimento) fazer este meio de campo escrevendo desta forma facilita uma compreensão do negócio.

Vale ressaltar que, um trabalho em par Analista de Negócios/Analista de Teste para realizar esse meio de campo e iniciar a criação desta documentação quando necessário, é fundamental.

Um analista de teste tem uma visão, seja pela qualidade do profissional e/ou sua experiência, de saber se as coisas são "testáveis" e reconhecer mais fácil a granularidade do cenário. 

Envolvendo também o desenvolvedor nesta conversa, antes de gerar a documentação (cenário ideal) fica sensacional.

Você terá o cliente, com sua visão de negócio e desejo, o analista de testes com sua visão de o que testar e granularidade e o desenvolvedor com sua visão lógica e entendendo as regras e manjando a dificuldade técnica que vem pela frente.

E o analista de negócio deixa de ser uma ponte (algo que eu considero muito importante) e começa a ser facilitador da conversa. 

Particularmente é assim que tenho direcionado minha atuação nos projetos. Não me faço proxy entre contato Time x Cliente. Não me coloco como responsável numa sequência "criar documento" -> "desenvolver".

Sou um facilitador para que o domínio do negócio flua pelo time, auxiliando o cliente a por forma na sua ideia. Não é incomum ao longo de algumas sprints minha atuação ir diminuindo e ver que o time as vezes sabe muito mais das regras do que eu.

Quando necessário, faço a parte "chata" do nosso trabalho, escrevendo UCs, User Stories ou que for para uma entrega formal.

Um bom exemplo disso é o post do Cláudio, O dia em que me tornei desnecessário: http://blog.claudiobr.com/o-dia-em-que-me-tornei-desnecessario

Alguns analistas de negócio tem "medo" de serem desnecessário, e acabam se firmando como proxy ou estágio de uma cascata.

Temos de transcender este nível. 

As vezes vejo aqui na lista uma dualidade: o que do papel de Analista de Negócios bate com o papel de Gerente de Projetos?

Na minha visão, não tem NADA a ver. A transcendência não é esta, não é por esse caminho. 

Pelo menos, na minha visão, criação de Gantt Chart, se for pra ser feito, que seja em grupo. Status Report, faço rodizio, cada vez pode ir um do time. Gerenciar equipe então, muito menos...

A importância do papel do Analista de Negócio não está numa possível liderança de Time ou maior responsabilidade de domínio do negócio. Está sim em como o negócio flui pelo Time, na facilidade que o cliente consegue se expressar, na rapidez do entendimento e das correções normais de desvios de entendimento.

Gostaria de ouvir a opinião de vocês

P.S: Lembro que baseio minha visão dentro de um Cenário de TI.

[]s.