Passando de uma história do usuário para o código enquanto estiver usando TDD (scrum)

8

Estou entrando no scrum e no TDD e acho que tenho alguma confusão sobre a qual gostaria de receber seus comentários. Vamos supor que eu tenha uma história de usuário em minha lista de pendências. Para começar a desenvolvê-la como parte do TDD, preciso ter requisitos, até agora?

É verdade dizer que o gerente de produto e o controle de qualidade devem ser responsáveis ​​por pegar a história do usuário e dividi-la em testes de aceitação?

Eu acho que o exposto acima é verdadeiro, pois os testes de aceitação precisam ser formais, para que possam ser usados ​​como testes, mas também legíveis por humanos, para que o produto possa aprovar que são os requisitos, certo?

Também é verdade que, posteriormente, faço esses testes de aceitação e os uso como meus requisitos, ou seja, são um conjunto de casos de uso que eu implemento (por meio do TDD)? Espero não estar bagunçando muito, mas esse é o fluxo atual que tenho em mente agora.

Atualização
Acho que minhas intenções iniciais não eram claras, então tentarei reformular. Quero saber mais detalhes sobre o fluxo scrum de transformar uma história de usuário em código enquanto estiver usando TDD.
O ponto de partida é óbvio: um usuário apresenta uma necessidade (ou o representante do usuário como produto), que é uma descrição curta de 1 a 2 linhas no formato conhecido e que é adicionada à lista de pendências do produto.
Quando há um planejamento de primavera, as histórias de usuários são retiradas da lista de pendências e atribuídas aos desenvolvedores.
Para que um desenvolvedor escreva código, eles precisam de requisitos (especialmente no TDD, pois os requisitos são de onde os testes são derivados).
Quando, por quem e em qual formato os requisitos são compilados?
O que eu tinha em mente era que o produto e o controle de qualidade definem os requisitos por meio de testes de aceitação (estou pensando em usar o FitNesse automaticamente ou o tipo, mas esse não é o principal, acho) que ajuda a servir a dois propósitos ao mesmo tempo:

  1. Eles definem "Concluído" corretamente.
  2. Eles dão ao desenvolvedor algo para derivar testes.

Eu não tinha certeza de quando eles foram escritos (antes da sprint eles são escolhidos, isso pode ser um desperdício, pois informações adicionais chegarão ou a história não será escolhida. Durante a iteração, o desenvolvedor pode ficar parado esperando por eles. ..)

Ittai
fonte
1
Você escreve testes à medida que codifica, testes de aceitação não são os que você escreve durante o TDD.
CaffGeek
Eu sei, mas escrevo TDD contra alguns requisitos, certo? de que forma eles devem entrar?
Ittai 23/11
4
Eu imploro para diferir - testes de aceitação certamente podem impulsionar seu desenvolvimento. Você pode definir uma série de testes (unidade, integração, sistema e aceitação) para indicar quando um aplicativo funciona e é aceitável. Você pode codificar o aplicativo até que ele passe nos testes. Esse certamente é o desenvolvimento orientado a testes.
Matthew Flynn
1
@ Ittai: Eu acho que o que Chad está tentando dizer é que o TDD começa com testes de unidade, que o desenvolvedor define a si mesmo. À medida que o desenvolvedor converte os casos de uso / requisitos em design de código de nível inferior, ele está trabalhando em uma classe por vez e escrevendo testes de unidade para essa classe. Nesse nível, é "ad hoc" porque o desenvolvedor está criando os testes conforme necessário para provar a validade do código.
Sam Goldberg
1
"de onde derivo os requisitos"? Histórias. Não está claro por que isso não é suficiente como resposta. Você pode explicar por que as histórias são magicamente diferentes desses "requisitos" que você deseja ver?
S.Lott

Respostas:

11

É verdade dizer que o gerente de produto e o controle de qualidade devem ser responsáveis ​​por pegar a história do usuário e dividi-la em testes de aceitação?

Na maioria das vezes. Eles podem realmente não escrever o teste de aceitação real. Eles podem aprovar algo que você escreveu. Mas eles aprovam os testes de aceitação. Sim.

os testes de aceitação precisam ser formais, para que possam ser usados ​​como testes, mas também legíveis por humanos, para que o produto possa aprovar que são os requisitos, certo?

Irrelevante. Eles podem ser formalizados como testes automatizados. Ou eles podem ser informais e pode ser seu trabalho criar testes automatizados a partir dos critérios de teste de aceitação informal.

Além disso. Os "requisitos" são a história do usuário. Não há necessidade real de criar mais uma versão da história chamada "requisitos". Algumas pessoas gostariam de elaborar a história antes de codificarem. Você pode chamar isso de requisitos, mas "design" é uma palavra melhor. "Elaboração" é a melhor palavra.

Também é verdade que, posteriormente, faço esses testes de aceitação e os uso como meus requisitos, ou seja, são um conjunto de casos de uso que eu implemento (por meio do TDD)?

Sim. A história leva a testes de aceitação. A história é um comportamento necessário (ou seja, "requisitos"). A história leva a testes que conduzem o design e desenvolvimento de software.

esse é o fluxo atual que tenho em mente agora.

Não há realmente muito "fluxo" para isso.

História -> testes de aceitação.

História -> elaboração ("design", "requisitos") -> testes de unidade -> código.

História -> Usuário capaz de fazer algo de valor.

História -> Pontos da história -> cálculo de velocidade.

Observe o padrão. A história basicamente guia tudo.


Quando, por quem e em qual formato os requisitos são compilados?

Primeiro. Defina "requisitos". Qual a diferença da história em si?

O que eu tinha em mente era que o produto e o controle de qualidade definiam os requisitos por meio de testes de aceitação

Normalmente não.

durante a iteração, o desenvolvedor pode ficar parado esperando por eles.

Incorreta. O desenvolvedor pode (e geralmente o faz) ajudar a escrevê-los. Esse é o ponto do "desenvolvimento": elabore a história para um "bem feito" bem definido.

Novamente. Quando você tiver dúvidas ou perguntas, deve ler o Manifesto Ágil. O Manifesto é bastante claro: os desenvolvedores devem conversar com os proprietários do produto, usuários, controle de qualidade e todos os demais que são partes interessadas. A interação é realmente a coisa mais importante que pode acontecer.

S.Lott
fonte
Obrigado, Você pode elaborar,;), um pouco mais sobre o estágio de elaboração da História->? Fiquei com a impressão de que uma história tem mais a forma de: "Eu, como usuário, quero fazer login no site para comprar produtos" Isso não inclui detalhes suficientes para iniciar o TDDing, pois preciso de mais detalhes , mais casos de uso. Mais caminhos, felizes e infelizes.
Ittai 23/11
"Preciso de mais detalhes, mais casos de uso. Mais caminhos, felizes e infelizes." Boa. Não entendo o que mais você precisa saber sobre elaboração. Você forneceu uma descrição completa do que precisa acontecer. O que mais você quer saber? Como pedir informações?
S.Lott
Mais ou menos, o que estou tentando entender é se, no início do sprint, existe apenas uma breve história do usuário e o desenvolvedor precisa "cavar" as informações do produto? Porque fiquei com a impressão (talvez por engano) de que, quando o sprint começa, o desenvolvedor tem um conjunto de requisitos que não são cumpridos, mas são 80% (eles são derivados de uma história de usuário). Estou tentando reunir um fluxo. Quando a transformação de uma história de usuário de uma linha (de duas linhas) vai para um conjunto detalhado de especificações.
Ittai
1. Não há "fluxo"; sem "etapas". É mais simples que isso. Escreva testes e código. 2. A fonte de informação depende da sua organização. A maioria das organizações entrega histórias aos desenvolvedores para elaborar. Alguns tentarão fazer parte da elaboração durante a preparação no início do sprint. 3. Leia o manifesto ágil. agilemanifesto.org . Espera-se que você interaja com o proprietário do produto. Profundamente. Freqüentemente. O ponto é que você colete os dados necessários para criar um código para apoiar a história.
S.Lott
1
"Quando a transformação de uma história de usuário de uma linha (de duas linhas) vai para um conjunto detalhado de especificações". Constantemente. Se você deseja criar design, sinta-se à vontade para fazer design. Algumas pessoas anotam seu design. Alguns não. Se você gosta da ideia de escrever muitas especificações, tudo bem. Não exagere. O objetivo é escrever testes e código. Se um design ajudar você a se concentrar, fique à vontade. Muitas pessoas acham que escrever os testes os ajuda a se concentrar. Se você precisar de um documento de especificação grande e complexo, sua história é muito complexa.
S.Lott
2

Vou responder da perspectiva da Extreme Programming (XP) sobre os testes de aceitação.

Quando eu estava entrando (e lendo os livros), li que era realmente o papel do desenvolvedor trabalhar com o cliente / usuário para desenvolver / documentar os testes de aceitação. Um dos objetivos do XP é aumentar a comunicação direta entre o usuário / cliente e o desenvolvedor. Isso geralmente é ideal, pois reduz a possibilidade de erros de codificação devido à falta de comunicação dos requisitos.

Faço TDD há cerca de 8 anos e segui a abordagem acima. Eu acho que melhorou a velocidade do desenvolvimento e a satisfação com o sistema, porque clientes / usuários veem como estão influenciando diretamente o desenvolvimento do aplicativo.

A principal dificuldade que encontrei (com clientes menores) é que é muito difícil fazê-los participar na especificação de testes de aceitação. (Geralmente, eu tenho que fazer isso por eles e enviá-los para revisão.) Os clientes maiores com quem trabalhei geralmente têm essa mentalidade; portanto, estavam preparados para fornecer testes de aceitação específicos.

Pelo que li sobre scrum, não tenho certeza se define qual função é responsável por definir / escrever testes de aceitação. Presumo que possa variar de equipe para equipe.

Meu conselho é que você, como desenvolvedor, participe o máximo possível do processo de definição de teste. E o objetivo é colocar os resultados do sprint na frente dos usuários o mais rápido possível, para que eles possam dizer tudo o que se esqueceram de pensar (ou o que disseram incorretamente) o mais rápido possível.

Sam Goldberg
fonte
1

A história do usuário não é "Como usuário, quero XXX para que AAAA" ! A história do usuário é uma promessa para a comunicação futura com o PO. Isso resolve seu problema com mais detalhes. Você deve se comunicar com o PO durante o sprint para obter as informações necessárias.

A história do usuário também possui mais recursos do que a frase curta que promete a comunicação. Parte necessária da história do usuário são critérios de aceitação. Os critérios de aceitação devem ser conhecidos antes de se comprometer com a história do usuário (eles devem ser conhecidos antes da estimativa da história do usuário). Os critérios de aceitação são a entrada para os testes de aceitação = os testes de aceitação devem testar os critérios de aceitação.

Portanto, quando você começa a trabalhar na história do usuário com a abordagem TDD, primeiro você (e não o controle de qualidade) deve criar um teste de aceitação automatizado com base em critérios de aceitação para obter uma falha no teste. Você continuará implementando o código necessário usando TDD antes da aprovação no teste de aceitação. Você continuará com o próximo teste de aceitação. Eu escrevi sobre isso também em outra pergunta .

Ladislav Mrnka
fonte