StratEx is an application deployed on “the Cloud” (Public-Private SaaS) and “On-Premise” onto the customer’ environment. One single line of code is deployed onto three diverse systems. In order to achieve such result we use a concept of code generation to shorten the development cycle, hereby being able to quickly implement new features and functionality. It also provides for a nice uniform User…
"How do we test software at StratEx? – Part 2" published on Testing Experience magazine
How do we test software at @StratExApp? Part-2 on Testing Magazine @TE_Mag
StratEx experience has been published in the December issue of “Testing Experience” the magazine for professional testers.
“In part 1 of this article (Testing Experience Issue No. 27), we outlined a number of criticisms and roadblocks that we have encountered while looking for the best way to test our application [using Test Driven Developments techniques]…”
I’ve been working with BDD for years and felt that it needed an application that would facilitate the Behaviour-driven developmentwork-flow. It would need to be made in a away that anyone can use it. By anyone I mean people with or without technical skills. Coders, testers, analysts, managers, business, etc. In that spirit, I started working on BDD Assistant. It is an open source application that…
BDD (Behavior-Driven Development): Missing Piece in the Continuous Integration Puzzle
BDD (Behavior-Driven Development): Missing Piece in the Continuous Integration Puzzle
Behavior-Driven Development (BDD) is a process or it can be a tool. In many cases, BDD is both. However, it should not be a goal in itself. The goal of software development is to deliver quality as fast and as cheap as possible. The only real measure of quality is whether it fulfills user needs in a reliable manner. The best way we can take to accomplish that goal is through continuous…
Documentation needs to be comprehensive, always up-to-date and accessible. By comprehensive I mean that it must cover all important areas of the code as well as all functions of the application. While importance of documentation is obvious to most, many struggle without success to have it accurate and up-to-date. Response to “poor” documentation is often assignment of more resources and more…
When moving from the traditional waterfall process with manual testing towards BDD with automated execution of scenarios, one of the often asked questions is “how do you measure your test coverage?”. What it really wants to say is “we have high test…
Since years, many software companies have their Quality department, which in many cases implies that they have the responsibility to assess the quality of the releases. This department is typically called QA department (standing for Quality Assurance),…
Desenvolvimento Comportamental Orientado é uma metodologia de "fora para dentro". Ele começa no exterior, identificando os resultados do negócio, e depois vai a fundo no conjunto de recursos que permite alcançar esses resultados. Cada recurso é capturado como uma "história", que define o âmbito do recurso, juntamente com os seus critérios de aceitação. Este artigo apresenta a abordagem BDD (Behaviour-Driven Development, ou Desenvolvimento Comportamental Orientado) para definir e identificar histórias e seus critérios de aceitação.
Introdução
Entrega de Software é escrever um software para alcançar resultados de negócios. Parece óbvio, mas muitas vezes fatores políticos ou ambientais distraem nos de lembrar isso. Às vezes, a entrega de software pode parecer uma produção de relatórios otimistas para manter a gerência feliz, ou apenas criar "ocupação no trabalho” para manter as pessoas no trabalho remunerado, mas isso é assunto para outro dia.
Normalmente, os resultados do negócio são muito grosseiros para serem usados para escrever diretamente software (onde você começar a programar quando o resultado é "salvar 5% dos custos operacionais"?) por isso precisamos definir os requerimentos em algum nível intermediário, a fim de ter o trabalho feito.
Desenvolvimento Comportamento Orientado (BDD) assume a posição de que você pode transformar uma idéia para um requerimento implementado, testado, o código pronto para produção simples e eficaz, desde que a exigência seja específicada o suficiente para que todos saibam o que está acontecendo. Para fazer isso, precisamos de uma maneira de descrever a exigência de tal forma que todos - as pessoas de negócios, o analista, o desenvolvedor e o testador - possam ter um entendimento comum do escopo do trabalho. Com isso, pode concordar com uma definição comum de pronto (“Done”), e escapar das duplas armadilhas gumption de "isso não é o que eu pedi" ou "eu esqueci de te dizer sobre esta outra coisa".
Este, então, é o papel da uma história. Tem que ser a descrição de um requisito e seu benefício de negócios, e um conjunto de critérios pelos quais todos concordam de que isto foi pronto (“Done”). Esta é uma definição mais rigorosa do que em outras metodologias ágeis, onde é descrito como uma "promessa de uma conversa" ou uma "descrição de um recurso (feature)". (A história BDD pode facilmente descrever um requerimento não-funcional, desde que o trabalho possa ser delimitado, estimado e acordado.)
A estrutura de um história
BDD fornece uma estrutura para uma história. Isso não é obrigatório - você pode usar um formato de história diferente e ainda estar fazendo BDD - mas o que estou apresentando aqui, é porque foi comprovada em muitos projetos de todas as formas e tamanhos. No mínimo, sua história deve conter todos os elementos descritos no modelo. O modelo de história é assim:
Título (uma linha que descreve a história):
Narrativa
Como (papel, quem):
Eu quero (recurso, feature):
Para que (benefício):
Critérios de aceitação (apresentado como cenários):
Cenário 1 (título):
Dado (contexto):
E (mais contexto):
Quando (evento):
Então (resultado):
E (mais resultado):
Cenário 2 ...
Contando a história
A história deve ser o produto de uma conversa envolvendo várias pessoas. O analista de negócios conversa com o interessado(stakeholder)1 sobre o recurso ou requerimento, e os ajuda a moldá-la como narrativa da história. Em seguida, o tester ajuda a definir o escopo da história - sob a forma de critérios de aceitação - por meio da determinação dos cenários que interessam e quais são menos úteis. A representação técnica irá fornecer uma estimativa aproximada da quantidade de trabalho envolvido na história, e propor abordagens alternativas. Muitas grandes ideias para sistemas vêm das pessoas que desenvolvem eles, bem como as pessoas que as pediram, em primeiro lugar.
Isso provavelmente vai ser um processo interativo. O stakeholder terá uma idéia do que eles querem, mas geralmente não sabem quanto trabalho será envolvido, ou como esse trabalho será alocado. Com a ajuda de peritos técnicos e testers, eles vão entender o custo / o benefício trade-off de cada cenário e poder fazer um julgamento sobre se eles querem. É claro que isso também é equilibrado contra os outros requisitos: é melhor analisar mais casos dessa história, ou passar para uma outra história?
Às vezes, a equipe de desenvolvimento simplesmente não sabe o suficiente para ser capaz de fazer até mesmo uma estimativa. Neste caso, eles podem optar por realizar algum trabalho de investigação, conhecido como um "spike", a fim de compreender mais sobre a exigência.
As características de uma boa história
Usando o exemplo do artigo Apresentando o BDD,vamos olhar para os requerimentos para retirar dinheiro de um caixa eletrônico:
Título: Titular da conta saca dinheiro no caixa eletrônico
Narrativa
Como titular da conta
Eu quero Retirar dinheiro do caixa eletrônico
Para que eu possa ter dinheiro quando o banco estiver fechado
Critérios de aceitação
Cenário 1: A conta tem fundos suficientes
Dado o saldo da conta é R$100
E o cartão é válido
E a máquina contém dinheiro suficiente
Quando o titular da conta requisita R$20
Então o caixa eletrônico deve sacar R$20
E o saldo da conta deve ser de R$80
E o cartão deve ser dispensado do caixa
Cenário 2: A conta não tem fundos suficientes
Dado o saldo da conta é R$10
E o cartão é válido
E a máquina contém dinheiro suficiente
Quando o titular da conta requisita R$20
Então o caixa eletrônico não deve sacar nenhum dinheiro
E o caixa eletrônico deve informar que não tem fundos suficientes para o saque
E o cartão deve ser dispensado do caixa
Cenário 3: O cartão está desativado
Dado o cartão está desativado
Quando o titular da conta requisita R$20
Então o caixa eletrônico não deve sacar nenhum dinheiro
E o caixa eletrônico deve informar que o cartão é inválido e o titular deve entrar em contato com o banco
Cenário 4: O caixa eletrônico não tem fundos suficiente
...
Como você pode ver, há um número de cenários a considerar, algumas relacionadas com o saldo da conta, outros sobre o cartão e outros ainda sobre a ATM em si. Vamos dissecar a história para determinar se ele é bom.
O título deve descrever uma atividade
O título da história, de "Titular da conta saca dinheiro", descreve uma atividade que o titular da conta quer realizar. Até implementar esse recurso, o titular da conta não será capaz de retirar dinheiro do caixa eletrônico. Uma vez que o entreguei, eles vão. Isso nos dá um ponto de partida óbvio para determinar com o que o "pronto"(Done) parece.
Se tivéssemos um título como "gestão de conta" ou "comportamento do caixa eletrônico", teríamos que olhar mais atentamente para entender quando foram feitas, e as curvas para entender seriam muito mais vagas. Por exemplo, "gestão de conta" pode incorporar aplicação de um empréstimo, e "comportamento do caixa eletrônico" pode abranger a alteração da senha no meu cartão. O título da história deve sempre descrever o comportamento real por um usuário do sistema.
A narrativa deve incluir um papel, uma característica e um benefício
O modelo de "Como [o papel] Eu quero [recurso] para que [benefício]" tem uma série de vantagens. Especificando o papel dentro da narrativa, você sabe com quem falar sobre o recurso. Especificando o benefício, você faz com que o escritor da história considere o porque eles querem um recurso.
Isso fica interessante se você encontrar o recurso que não vai realmente entregar o benefício atribuído a ele. Isso normalmente significa que você tem uma história faltando. Há uma história com o recurso atual, que oferece um benefício diferente(e é, portanto, ainda útil), e uma história oculta em que você vai precisar de um diferente recurso para oferecer o benefício descrito.
O exemplo da história nos diz que existe o Titular da Conta que se preocupa com o recurso que está sendo entregue, de modo que sabemos por onde começar a explorar o que deve-se fazer.
O título do cenário deve dizer o que é diferente
Você deve ser capaz de alinhar os cenários lado a lado, e descrever como eles diferem usando apenas o título. No nosso exemplo, podemos ver que as descrições de cenários dizem somente o que há de diferente entre cada cenário. Você não precisa dizer "um titular da conta saca o dinheiro de uma conta com fundos suficientes e é dito que não foi capaz de realizar a transação". É óbvio que a partir do título este é o cenário que lhe interessa, em comparação com os outros.
O cenário deve ser descrito em termos do que foi Dado, Eventos e Resultados
Esta é a mudança mais poderosa do comportamento que vi em equipes adotando BDD. Simplesmente fazendo com que os usuários, os analistas, os testers e os desenvolvedores a adotar este vocabulário de "dado/quando/então" (given/when/then), eles descobrem que um mundo de ambiguidade cai fora.
Nem todos os cenários são tão simples. Alguns estão melhor representados como uma seqüência de eventos, descrito como: dado [algum contexto] quando [eu fazer algo], então [isso acontece] quando [eu fazer outra coisa], então [essa coisa de novo acontece] e assim por diante. Um exemplo é um site assistente de estilo, onde você passa por uma seqüência de telas para construir um modelo de dados complexos. É perfeitamente apropriado misturar as sequências de eventos e resultados, desde que você adquira o hábito de pensar nestes termos.
Um comportamento emergente interessante é a qualidade das conversações de mudanças. Você vai logo descobrir que você esqueceu de esclarecer um “Dado” ("bem claro a conta está negativa"), ou esqueceu de verificar um resultado ("bem, naturalmente, o titular da conta recebe seu cartão de volta"). Observei isso em um projeto particular, onde o principal desenvolvedor me disse que podia sentir os analistas e desenvolvedores falando de propósitos, mas não podia ver uma maneira de demonstrar isso a eles. Dentro de alguns dias de introduzir o vocabulário Dado / Quando / Então, ele podia ver uma melhora dramática na qualidade de suas interações.
Os Dados devem definir todos, e não mais do que, o contexto exigido
Qualquer “Dado” adicional distraí, o que fica difícil para alguém que esteja olhando para a história pela primeira vez - se do lado técnico ou empresa - para entender o que eles precisam saber. Da mesma forma que qualquer “Dado” faltante seja feito suposições. Se você pode obter um resultado diferente do “Dado” fornecido, então deve haver algo faltando.
No exemplo, o primeiro cenário diz algo sobre o saldo da conta, o cartão e o caixa eletrônico em si. Todos estes são necessários para definir completamente o cenário. No terceiro cenário, não diz nada sobre o saldo da conta ou se o caixa eletrônico tem algum dinheiro. Isto implica que o caixa eletrônico irá notificar o usuário sobre o problema no cartão, independentemente do saldo da conta.
O evento deve descrever o recurso(feature)
O evento em si deve ser muito simples, tipicamente apenas uma única chamada para o código de produção. Como discutido acima, alguns cenários são mais complicados, mas a maioria dos cenários de uma história iram girar em torno de um único evento. Eles diferem apenas no contexto (“Dado”) e os resultados correspondentes esperados.
A história deve ser pequena o suficiente para caber em uma iteração
Não existem regras duras e rápidas sobre como fazer isso, desde que você dividi-la em pedaços demonstráveis. Em geral, se há mais de cinco ou seis cenários, a história provavelmente poderá ser quebrada e agrupada por cenários semelhantes.
Nós não podemos dizer a partir do exemplo do caixa eletrônico quantos cenários mais existem para esta história, mas estou desconfiado de que pode haver vários outros. Essencialmente nós temos três "partes móveis" nesta história, ou seja, o saldo da conta, o estado do cartão e do estado do caixa eletrônico. Poderíamos entrar em mais detalhes com o cartão: E se está desatualizado, então por isso não posso usá-lo para retirar o dinheiro, mas o caixa eletrônico ainda retorna para mim? E se o caixa eletrônico quebra no meio da transação? E se minha conta tem uma facilidade?
Poderia ser melhor quebrar a história em várias histórias menores:
Titular da Conta saca dinheiro (suposição: Caixa eletrônico está funcionando e cartão é válido)
Titular da Conta saca dinheiro com cartão inválido (suposição: caixa eletrônico está funcionando)
Titular da Conta saca dinheiro de caixa eletrônico defeituoso (suposição: cartão é válido)
Embora isso possa parecer artificial, isso permite demonstrar o progresso em termos de negócios e lhe dá mais dados para seguir. O importante é sempre quebrar a história ao longo dos termos de negócios por cenários (e fazendo suposições explícitas), ao inves de linhas técnicas (por exemplo, fazer as coisas de banco de dados nesta iteração e as coisas de GUI na próxima iteração). Então a empresa pode ver um progresso comprovado em seus próprios termos, em vez de apenas tomar sua palavra para ela.
Então, como isso é diferente dos Casos de Uso?
Há casos de uso e há casos de uso. Eu sou um grande fã da maneira Alistair Cockburn descreve casos de uso (ao contrário das versões sobre-engenharia que eu encontrei em projetos RUP-como-cachoeira). Tendo em conta que eu não tenho muita experiência em caso de uso de projetos orientados, eu vou deixar para os outros as comparações.
Certamente concordo com o seu processo de começar pela menor precisão (de um resultado, ou objetivo) e trabalhando para maiores precisões, tomando mais exceções em cenários que você vá. No BDD, isto significa começar com o resultado do negócio, e trabalhando em um alto nível de áreas funcionais para criar histórias específicas com critérios de aceitação.
Na realidade, não importa o que o seu processo identifica e elabora requerimentos. É bom para você escrever documentos de requerimentos que ajudam a organizar seus pensamentos. Não é bom, no entanto, passar por esses documentos como se eles realmente já encapsularam todos os seus pensamentos, porque eles não fazem. Em vez disso, você deve colocar o documento de requerimentos, ou pilha de casos de uso, pro lado e começar de novo a definição de histórias de resultados de negócios, seguro no conhecimento de que seu trabalho duro significa que você tem todas as respostas em sua cabeça - ou pelo menos um bom entendimento suficiente para delinear o trabalho como atualmente você ve.
Resumo
Desenvolvimento Comportamento Orientado usa uma história como a unidade básica de funcionalidade, e, portanto, de entrega. Os critérios de aceitação são uma parte intrínseca da história - na verdade, eles definem o escopo de seu comportamento, e nos da uma definição comum de "pronto". Eles também são usados como base para a estimativa de quando vamos fazer o nosso planejamento.
Mais importante ainda, as histórias são o resultado de conversas entre as partes interessadas no projeto, analistas de negócios, testadores e desenvolvedores. BDD é tanto sobre as interações entre as várias pessoas no projeto quanto sobre os resultados do processo de desenvolvimento.
1. Na verdade, deve ser a pessoa que realmente se preocupa com o recurso, de modo que pode igualmente ser um operacional, legal ou pessoa de segurança, dependendo da história.
