O BDD é realmente gravável por não programadores?


24

O Desenvolvimento Orientado a Comportamentos, com sua sintaxe dos cenários emblemáticos "Dado quando", ultimamente tem sido bastante elogiado por seus possíveis usos como um objeto de limite para a avaliação da funcionalidade do software.

Concordo definitivamente que o Gherkin , ou o script de definição de recurso que você preferir, é um DSL legível para os negócios e já fornece valor como tal.

No entanto, não concordo que seja gravável por não programadores (como Martin Fowler ).

Alguém tem relatos de cenários sendo escritos por não programadores e depois instrumentados por desenvolvedores?

Se realmente houver um consenso sobre a falta de capacidade de gravação, você veria um problema com uma ferramenta que, em vez de começar com os cenários e instrumentá-los, geraria cenários legíveis aos negócios a partir dos testes reais?

Atualização: com relação à ferramenta "gerador de cenário", é claro que não adivinharia a linguagem de negócios;) Mas, assim como atualmente usamos os correspondentes regexp para criar testes em uma abordagem de cima para baixo (na dimensão de abstração), podemos usar construtores de strings para criar cenários em uma abordagem de baixo para cima.

Um exemplo "apenas para ter uma ideia":

Given I am on page ${test.currentPage.name}
And I click on element ${test.currentAction.element}
…

Levará muito tempo até que os seres humanos possam vir com uma linguagem comum legível por outros seres humanos da maneira exata, mesmo depois que os computadores já possam escrever código para os computadores.

Ironicamente, o JBehave 1 (a primeira ferramenta BDD) começou gerando cenários legíveis pelos negócios. Nós não analisamos o inglês até o Pepino. Acho JBehave 1 foi útil para realmente lembrar as pessoas que tinham que falar sobre eles em primeiro lugar ...
Lunivore

Respostas:


20

Eu vi isso. Não acabou bem.

Eu acho que pepino é uma abstração complicada (<- lol: D) por essa razão exata. Muito difícil para pessoas não técnicas escreverem sozinhas; muito detalhado para pessoas técnicas.

Pessoas não técnicas simplesmente não aprenderam a pensar como programadores. É nosso privilégio entender o conhecimento abstrato, decompô-lo, edificá-lo novamente e ainda ser capaz de fugir da ambiguidade com sucesso. É para isso que somos pagos.

Se realmente houver um consenso sobre a falta de capacidade de gravação, você veria um problema com uma ferramenta que, em vez de começar com os cenários e instrumentá-los, geraria cenários legíveis aos negócios a partir dos testes reais?

A própria ferramenta não será capaz de gerá-los. Computador não sabe nada sobre o domínio comercial. No final - o programador seria responsável por desenhar o que precisa ser gerado de qualquer maneira e mesmo assim - provavelmente esses cenários seriam muito detalhados / enigmáticos para seus usuários finais.


20
Non technical people just haven't learned to think like programmers. A verdade. Esse mesmo conceito foi exagerado e reinventado várias vezes nos últimos 20 anos e quase sempre acaba com resultados ruins. As empresas gostam do conceito de obter software sem ter que pagar aos gananciosos desenvolvedores de sanguessugas sugadores de sangue, mas esquecem que a parte mais difícil do desenvolvimento de software é na maioria das vezes entender as regras da empresa de maneira mais profunda e complexa do que os próprios executivos.
Maple_shaft

2
“Pessoas não técnicas simplesmente não aprenderam a pensar como programadores.” Sim, a capacidade de decompor problemas e expressá-los dentro de termos lógicos atômicos especificados é provavelmente o que faz de um programador / analista. A ideia de que parecer inglês torna o Gherkin utilizável por qualquer pessoa me parece incrivelmente ingênuo. Obrigado por confirmar :) Computer knows nothing about business domain.Claro. Não deixei minha ideia muito clara, desculpe por isso. Vou adicionar informações à pergunta.
precisa saber é o seguinte

8
@maple_shaft: Nos últimos 20 anos? Experimente os últimos 60 anos. Alguns dos exageros em torno do COBOL eram que as pessoas de negócios podiam escrevê-lo, eliminando a necessidade de programadores. Quando isso não aconteceu, as pessoas criaram um monte do que chamavam de linguagens de quarta geração que deveriam fazer a mesma coisa.
precisa

11

Parte da dificuldade em termos de o cliente redigir um documento de especificações é que o cliente geralmente não sabe como traduzir as coisas que o cliente deseja para um idioma que realmente descreve o que o cliente precisa. Embora o cliente possa dizer que deseja que determinado comportamento exista em um sistema, geralmente não se preocupa tanto com as minúcias até que tenha visto, usado e experimentado o software trabalhando de uma maneira que o cliente considera que não corresponde exatamente à sua. necessidades.

Quando os clientes descrevem um processo de negócios, geralmente deixam de fora muitas informações relevantes. Frequentemente, essas informações estão relacionadas a coisas sobre um processo que são comumente entendidas no domínio específico do cliente e, portanto, são consideradas um dado adquirido e muitas vezes não são transmitidas ao programador. Em outros momentos, o cliente não sabe como lidar com todas as condições de contorno de um sistema e procura orientação para o programador. Às vezes, é tudo um caso simples de usabilidade, com o cliente pensando que quer que algo funcione de uma maneira, mas depois mudando de ideia quando fica mais claro que as coisas devem funcionar de maneira diferente.

Ok, chega de "relações com clientes 101 para programadores". A questão é se ainda há valor em fazer com que o cliente use uma DSL legível para negócios para definir como definir uma especificação. Acredito que, com orientação, a resposta é uma tentativa de 'sim', e digo tentativa porque a próxima pergunta que vem à mente é: por que um cliente criaria uma DSL quando você pode ter um programador que defina mais facilmente uma que fornecer ao cliente uma linguagem simples e rica para definir como um sistema precisa funcionar?

Quando você fornece a um cliente um idioma para descrever como ele gostaria que um sistema funcionasse, você terminaria com instruções que diziam algo como:

"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".

Esse tipo de declaração acaba descrevendo um requisito de uma maneira muito clara, fornecendo a forma geral que o cliente basicamente deseja que o sistema assuma, ou outra maneira de encará-lo é que o cliente está descrevendo o que é o sistema. Se você deseja que seu cliente pense um pouco mais sobre as coisas, peça-lhes que descrevam as regras às quais o recurso deve obedecer, usando várias declarações semelhantes, talvez:

"Given 'some system state', When 'some action occurs', Then expect 'some result'

Novamente descrições muito claras, desta vez sobre comoo sistema deve se comportar. O fato é que isso não substituirá a necessidade de um desenvolvedor de software preencher todos os espaços em branco e fornecer detalhes adicionais dos quais o cliente pode estar apenas perifericamente ciente. Embora o cliente possa ser 'treinado' pelo programador para descrever os recursos e comportamentos em um bom formato amigável para o programador, ele não terá realmente as habilidades ou o conhecimento para gerar casos de teste significativos nem fornecer a implementação código. Acho que esse foi o ponto do artigo de Martin Fowler ao qual o OP se referiu. Portanto, sim, o software em si não é gravável pelo cliente, mas a descrição do software certamente pode - e o IMHO deveria - ser escrita pelo cliente. Pelo que vale, eu não li o artigo de Fowler dizendo que o cliente não deveria '

Eu sinto que nós programadores às vezes esquecemos que nossos clientes geralmente são muito inteligentes em termos de compreensão de seus negócios e processos de negócios, certamente muito melhores do que nós. Quando eles não têm um programador para lhes dizer como construir um sistema de software, os clientes geralmente recorrem a outros meios - talvez menos eficientes - para resolver seus problemas específicos de gerenciamento de negócios. Com isso, quero dizer bancos de dados simples (pense em Access) ou planilhas, ou mesmo livros escritos à mão, e com regras e procedimentos bem definidos para gerenciar esses processos. A falta de muitos clientes não é um meio de determinar como um sistema precisa funcionar, mas como ele deve ser construído e, mais importante, como descrever com eficiência as regras comportamentais de um sistema para as pessoas quenão tem as habilidades para realmente construir o sistema.

Se realmente houver um consenso sobre a falta de capacidade de gravação, você veria um problema com uma ferramenta que, em vez de começar com os cenários e instrumentá-los, geraria cenários legíveis aos negócios a partir dos testes reais?

Eu acho que isso está olhando para o problema da maneira errada. Eu veria um grande problema com uma ferramenta que gera documentação a partir de testes se essa documentação pretendesse representar uma especificação de alguma forma. Para testar um cenário, é necessário entendê-lo; portanto, o cenário já deve existir para que você defina um teste para ele. Se você descreve o cenário em uma sintaxe BDD, já o especificou e, portanto, só pode instrumentar os cenários após o fato. Se, por outro lado, você tivesse uma ferramenta que permitisse ao cliente descrever um sistema em uma boa DSL otimizada para programação, e se essa ferramenta pudesse ser usada para gerar os modelos de código que seriam usados ​​como suíte de testes, então eu ' Eu diria que haveria um grande valor nessa ferramenta. Ele não veria o cliente tirando programadores da equação e ajudaria a reduzir o esforço necessário para atender aos desejos do cliente e gerar requisitos codificados para teste de uma maneira BDD, e talvez tornasse os desejos do cliente mais facilmente compreendidos. No entanto, não seria um substituto ter um desenvolvedor de software experiente à disposição para ajudar o cliente a separar as necessidades do cliente e as necessidades do cliente.


“Para testar um cenário, é preciso entendê-lo; portanto, o cenário já deve existir para que você defina um teste para ele.” Eu concordo. O que estou questionando é se a aplicação de restrições de linguagem vale alguma coisa. Não afirmo que devemos escrever apenas testes; mas me pergunto se não devemos aceitar o fato de que a descrição do negócio será (e provavelmente deveria) sempre ser descrições simples e gratuitas . Portanto, teríamos descrições puras de negócios e geraríamos cenários legíveis, permitindo que os humanos decidissem se eles combinavam; em vez de fingir, usamos descrições reais para testar.
MattiSG

@MattiSG ...whether enforcing language constraints is worth anything. Essa é uma boa pergunta. As descrições de forma livre são mais expressivas e naturais para o escritor, mas resultam em comentários desmedidos que exigem dissecação para obter uma especificação útil. Ao definir 'regras' formais (também conhecidas como DSL) para escrever requisitos e especificações, você tem uma linguagem comum que cliente e programador podem entender, limitando mal-entendidos. Se você acertar as descrições, elas podem ser usadas literalmente como modelo para seus testes. Portanto, não há necessidade de ferramentas complexas para "gerar" nada.
58512

@MattiSG FWIW, usando DSL e BDD é o sistema que eu mesmo uso. Os requisitos são definidos como declarações de Entidade-Recurso-Benefício e acompanhados de uma especificação que estende as declarações de requisitos iniciais usando instruções AAA (Ie: Given-When-Then) ... essencialmente declarações de cenário. A dificuldade ao tentar decodificar o texto livre é que, sem uma DSL, você não tem um meio fácil de definir um algoritmo que pode gerar cenários de coleta significativos. Meu argumento foi que usar os testes como ponto de partida para gerar cenários é meio que inverso.
31412 S.Robins

5

Eu já vi desenvolvedores escreverem cenários; os testadores escrevem cenários e até o proprietário de um produto escreve cenários. Eu também tive conversas explicitamente projetadas para trazer à tona cenários - "Dado <neste outro contexto>, quando o que deve acontecer então?" - e anote as palavras que os negócios usam.

Os melhores resultados que obtive foram conversando com o proprietário do produto enquanto ele estava no escritório, capturando-os em um wiki e enviando-os a ele para que ele pudesse corrigir e adicionar mais. Ele encontrou um casal que perdemos em nossas conversas. Isso foi demais.

Os piores cenários que eu já vi são aqueles que os desenvolvedores escreveram sem nenhuma conversa com a empresa. Percebo porque eles usam termos como "Quando faço uma pesquisa" ou "Quando envio o formulário com uma data de hoje + 3". Geralmente, eles não são cenários muito interessantes, muitos deles, um nível de detalhe muito baixo e, portanto, completamente insustentável. Os negócios também não os leem.

Muito melhor focar nas conversas da IMO. Vi algumas equipes fazendo isso agora há alguns meses com grandes melhorias na qualidade, independentemente da automação. Uma equipe conseguiu fazer a automação funcionar em um ambiente muito difícil algumas semanas depois, para a alegria do testador! Mas, na verdade, enquanto a equipe estiver conversando e usando cenários para desenhar outros cenários, acho que não importa quem os anote.


A comunicação +1 é realmente a chave, e os cenários realmente precisam estar nos termos que as pessoas de negócios nos têm, portanto, de acordo com a pergunta dos OPs, se criarmos uma DSL, ela realmente precisará ser uma correspondência mais próxima ao que o cliente vai dizer, e não ao que os programadores pensam que o cliente deveria estar dizendo.
S.Robins

0

Minha experiência é que é melhor deixar para o BA (Business Analyst) escrever o GWT ( Given-When-Then ) s (experiência usando SpecFlow). O BA pode traduzir os requisitos do Cliente no GWT e a empresa pode lê-lo. Os clientes entendem os sistemas, mas eles não têm a tecnologia para escrever os requisitos de uma maneira que possamos usar.

Idealmente, o BA escreveria algum GWT, eu faria algumas revisões, o BA revisaria / revisaria a repetição até que o BA e os negócios estivessem confiantes na cobertura. Praticamente o BA me daria um rascunho que eu limparia e faria o trabalho. A empresa encolhe os ombros dizendo que com certeza se pergunta por que não cobriu algumas áreas em que ninguém pensava.


Você poderia, por favor, explicar o que o GWT significa para você? :)
MattiSG

@MattiSG: acho que é para o dado quando e depois (consulte OP).
sleske

@MattiSG - Atualizada a publicação boa captura.
SoylentGray 6/06/12
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.