Critérios de aceitação para casos de borda

Sou proprietário de um produto em uma equipe ágil. Quando faço testes de aceitação de pedidos, geralmente tomo nota para tentar alguns casos extremos. Não é incomum eu descobrir algo e depois o passo de volta para os desenvolvedores. Estou sendo pressionado por um dos desenvolvedores quando rejeito suas histórias. Ele diz que é injusto, já que não especifico os casos extremos e como o programa deve responder nos critérios de aceitação, pois ele tende a codificar apenas o que descrevo na história. Eu o incentivei a me perguntar enquanto ele esbarra em quaisquer casos extremos durante a codificação, mas ele acha que não é seu trabalho pensar nos casos extremos, é meu e eu devo criar novas histórias para o próximo sprint.

Em minha defesa, não conheço o design dele para a história até que ele a implemente, por isso é difícil iterar todas as possibilidades (a configuração será em um banco de dados ou arquivo de propriedades?). Por uma questão de simplicidade, digamos que temos uma história para adicionar divisão a um aplicativo de calculadora. No mundo ideal do SCRUM, caberia a mim adicionar um "cenário de divisão por zero por zero" aos critérios de aceitação ou ele deveria estar trabalhando nesses casos à medida que se desenvolve para que o aplicativo não imploda em 5/0? Para ficar claro, nesse caso, eu não aceitaria se o aplicativo falhasse em 5/0, mas eu passaria se ele registrasse, imprimisse DIV0 ou qualquer outra maneira de lidar com o erro ... desde que não falhar.

Acho que a resposta é que vocês dois deveriam pensar em seu próprio conjunto de casos extremos. Ele, como desenvolvedor, deve lidar com casos extremos que são específicos de dados, como o aplicativo trava em qualquer entrada do usuário, 5/0 certamente cai nessa parte do espectro. O desenvolvedor deve perguntar sobre você o que você acha que seria uma mensagem de erro apropriada quando a entrada fornecida como parte da interação do usuário levar a algo inválido.

Sua parte do espectro é o lado comercial das coisas. Como a calculadora deve se comportar se a conta do usuário não puder usar o botão de dividir? Como deve se comportar quando a conta tem permissão para usar a operação Mod, mas não tem acesso ao recurso de divisão?

A mensagem importante que acho que você precisa transmitir e tem a aceitação de todos os membros da equipe é que todos estão na mesma equipe. Se o produto não estiver completo, o produto não estará completo e a equipe será responsável, e não por um membro.

A equipe precisa trabalhar em conjunto, em vez de ter um tipo de atitude / mantra "Não é meu trabalho, não é minha responsabilidade".

Os critérios de aceitação vêm na forma de:

• Aceitação de Negócios
• Aceitação de garantia de qualidade

Normalmente, a aceitação da empresa geralmente está respondendo à pergunta:

• O recurso implementado faz o que eu quero?

O recurso terá vários requisitos orientados para os negócios, como se eu pressionar esse botão, espero que essa ação ocorra. Ele listará os cenários de negócios esperados e o comportamento esperado, mas não cobrirá todos os casos possíveis.

Espera-se que os requisitos de negócios sejam definidos antes de uma iteração, para que a garantia de qualidade possa desenvolver qualquer requisito técnico sobre requisitos não comerciais. A garantia da qualidade deve desenvolver casos destrutivos e casos extremos, conforme necessário.

Ambos os conjuntos de requisitos devem ser revisados ​​antes de iniciar qualquer trabalho de história, para que uma estimativa e comprometimento formal possam ocorrer para a unidade de trabalho. Feito isso, as matérias / matérias podem ser trabalhadas. Nesse ponto, todos estão claros sobre o que deve ser entregue, tanto do ponto de vista comercial quanto técnico.

A história alcança aceitação final quando os membros da equipe de negócios e garantia de qualidade assinam a história. Isso deve acontecer durante a iteração para aceitação de negócios e aceitação de garantia de qualidade. Esta é a definição de done (DoD) que indica que um trabalho adicional da história pode ser iniciado.

Quaisquer novas descobertas podem ser registradas como defeitos ou picos adicionais na história. Em um mundo perfeito, isso nunca aconteceria, mas, na realidade, geralmente há uma certa quantidade de "descoberta" que ocorre quando se trabalha em um recurso / matéria. Isso é natural.

A equipe deve trabalhar em conjunto (empresa, controle de qualidade, desenvolvedor) para definir os requisitos de qualquer tipo de descoberta nebuloso. Se isso for ágil, todos eles devem estar sentados à mesma mesa para promover a comunicação e a resolução rápida de qualquer dúvida que possa surgir. Deve ser algo como isto:

QA:

"Ei, desenvolvedor, devemos lidar com esse cenário em particular. Descobri que, se eu inserir esses dados, recebo um erro."

DEV:

"Isso não foi coberto por nenhum requisito, mas podemos adicionar algumas funcionalidades adicionais para cobrir isso. OK, Hey Business Person, como você gostaria que o aplicativo se comportasse neste caso?"

O NEGÓCIO:

"Vamos mostrar nossa mensagem de erro padrão e permitir que o usuário tente novamente neste cenário. Quanto esforço adicional será necessário?"

DEV:

"Será fácil, apenas uma ou duas horas extras. Posso me comprometer com essa iteração. Controle de qualidade, atualize seus critérios de aceitação para este cenário, não precisamos de uma história adicional para isso. Obrigado!"

Ou, se dá muito trabalho, uma nova história é adicionada à lista de pendências. A equipe ainda pode aceitar a história original, pois atende a todos os requisitos originais e, em seguida, escolhe a história de pico na próxima iteração.

Escrever software que se comporte de maneira robusta diante de informações incorretas ou ambíguas é uma parte essencial do trabalho de um desenvolvedor de software.

Se seus desenvolvedores não vêem dessa maneira, inclua requisitos não-funcionais adicionais na especificação de requisitos que declaram esse requisito explicitamente e forneça aos desenvolvedores um exemplo de seu processo de teste para que eles possam aplicar eles mesmos antes de enviar sua versão final. código para revisão.

Os testes de aceitação devem ser uma parte vital de qualquer documento de requisitos de qualquer maneira. Se um requisito também não declarar seus critérios de aceitação, não é realmente um requisito; é um desejo.

O que aconteceu aqui é que você descobriu valor . O valor de entrada não foi pensado quando a história (e os critérios de aceitação) foram escritos ou quando o código foi escrito. Se não faz parte dos critérios de aceitação, você realmente não tem base para rejeitar a história.

O que faríamos na minha equipe é:

1. Crie um bug detalhando o comportamento esperado e real.
2. Atualize os critérios de aceitação para que o novo requisito encontrado seja documentado.
3. Priorize o bug junto com todas as outras histórias e bugs na próxima iteração.

O benefício aqui é que você é forçado a considerar se a correção ou não desse bug é a próxima coisa mais importante a ser feita. Pode ou não ser importante o suficiente para corrigir, mas é importante que seu valor seja considerado.

Obviamente, você ainda precisa encontrar uma maneira de incentivar os desenvolvedores (e você mesmo) a explorar esses casos avançados antecipadamente. Se sua equipe de desenvolvimento não está gastando tempo detalhando as histórias, incentive-as a ter uma sessão de planejamento detalhada antes de começar a trabalhar nelas.

Algumas observações:

... quando rejeito suas histórias

Não conheço sua cultura ou processo de trabalho, mas, para mim, rejeitar uma história é um passo grave. Se eu fosse o desenvolvedor, eu também geraria um empurrão nisso, pois é uma ação gravada que reflete mal em mim e na equipe.

Ele diz que é injusto, já que não especifico os casos extremos.

É injusto da parte dele esperar que você conheça todos os casos extremos. Mas, ao mesmo tempo, é injusto você esperar isso dele. Toda mudança tem risco e, à medida que os problemas são descobertos, vocês precisam trabalhar juntos como uma equipe para resolvê-los.

Não conheço o design dele para a história até que ele a implemente

Você não precisa conhecer o design. Pode ser útil conhecer o design para fazer suposições iniciais sobre quais histórias são mais fáceis ou mais difíceis para o gerenciamento de pendências. Mas evite prender o desenvolvedor em seu design ao escrever histórias. É muito divertido quando você é simplesmente um teclado ativado por voz para o PO.

Parece que vocês devem trabalhar na melhoria de processos e criar alguma equipe. Algumas coisas que posso sugerir para o processo:

• Sugira que o desenvolvedor inclua um tempo na história para a cobertura, corrigindo casos de borda descobertos. Caramba, faça parte de cada história de usuário. Isso é facilmente defensável através do objetivo de 0 novos bugs introduzidos. O problema é que o desenvolvedor não está planejando isso atualmente. E ele está sem tempo quando você descobre problemas. Vai levar tempo de qualquer maneira, então coloque isso na história em que é visível durante o planejamento.
• Após o teste (e obrigado por testar a propósito!), Envie ao desenvolvedor uma lista dos problemas descobertos. A correção desses problemas vai contra a condição de satisfação dos "casos extremos".
• Se algo permanecer sem correção ou for descoberto tarde demais, decida se a história precisa ser enviada com base em se o caso de uso pode ser cumprido. Problemas conhecidos e soluções alternativas acontecem. Divulgou-os em notas de versão e crie novas histórias para corrigi-los.
• Se houver um ponto difícil no processo que gere uma reação, altere seu processo! Afinal, a melhoria de processos faz parte do Scrum. Por exemplo, se seu desenvolvedor fica chateado quando você rejeita a história, sugira à equipe uma mudança no processo para que a rejeição não aconteça. Faça os testes e as correções antes de Concluído e Rejeitado.
• Trabalhe com a equipe e o que eles produziram e faça o melhor uso possível. Eles não fazem um trabalho perfeito e você também não. Então, planeje isso. Minhas equipes costumam ser devops, então temos uma história de usuário do Suporte não planejado a cada sprint para problemas emergentes ... planejando para os não planejáveis.

Os requisitos devem ser claros e concisos. Caso contrário, acontece exatamente o que aconteceu com você. A culpa é sua, e a pior coisa que você pode fazer ao especificar requisitos é assumir as coisas.

Você exemplo específico, sobre a divisão por zero. Se você não especificou que deseja registrar o erro, não reclame se o desenvolvedor imprimir 100 como resultado.

Mas, nesses casos, eu preenchia lacunas ausentes e as passava para o desenvolvedor. Afinal, erros nos requisitos acontecem.