Como ajustar o teste nos sprints do Scrum e como escrever histórias de usuário no Scrum

Sou o líder da equipe de desenvolvimento de um novo projeto na minha empresa. Este é o primeiro projeto em que a empresa utilizará o Scrum. Temos um SDLC em cascata / iterativo. Os BAs escrevem documentos de requisitos, passam para dev e test, dev iniciam o desenvolvimento e serão lançados para teste em iterações. Os testadores demoram muito tempo para testar uma versão em que os desenvolvedores continuam o desenvolvimento, mas também as correções para a versão atual. Eu tenho algumas perguntas

1. Em um sprint com digamos 5 histórias, quando você libera para testar? É assim que uma história é concluída pelo desenvolvedor ou depois que todas as histórias são concluídas, mas antes do final do sprint, dando ao teste o tempo necessário para o teste.
2. Se o BA escrever histórias de usuários, quais devem ser os detalhes. Tradicionalmente, leva muito tempo para escrever uma especificação com todo o layout da interface do usuário, comportamento, texto etc. para ser finalizado. Acho que minha pergunta é como escrever histórias que sejam implementáveis ​​e testáveis.
3. Nossa equipe de teste não é técnica. Quão importante é ter testes automatizados de interface do usuário para o Scrum. A interface do usuário é baseada no WPF.

Tenho sólida experiência em desenvolvimento usando métodos ágeis (TDD, revisões de código, refatoração etc.), mas novo no scrum.

edit: Por iterações, quero dizer que, se houver 100 requisitos, poderemos liberar para teste quando tivermos concluído 30, 35, 35 requisitos, em vez de esperar até que todos os 100 requisitos sejam concluídos.

Se o teste for separado do desenvolvimento, você terá duas equipes de scrum separadas. É uma má idéia ter uma mão trabalhando na outra.

Seus desenvolvedores devem escrever seus próprios testes, separados dessa outra equipe. Você deve tratar essa outra equipe de "teste" como seus clientes.

Em uma corrida ... quando você libera para testar?

Quando o sprint estiver pronto. Totalmente feito. Isso significa que você fez seu próprio teste de unidade e tem certeza de que funciona. Após a conclusão da sua equipe de desenvolvimento, você a libera para outras equipes para "teste" ou "implantação" ou o que mais acontecer na organização.

Acho que minha pergunta é como escrever histórias que sejam implementáveis ​​e testáveis.

Isso varia de equipe para equipe. O BA faz parte da equipe de desenvolvimento. Você precisa trabalhar nisso em equipe (BA mais desenvolvedores) para obter a quantidade certa de detalhes. É um esforço de equipe para obter as informações corretas da BA para o restante da equipe.

Quão importante é ter testes automatizados de interface do usuário para o Scrum.

Essencial. Completamente necessário para qualquer desenvolvimento de interface do usuário. Os desenvolvedores devem fazer todos os testes antes de serem entregues à "equipe de teste". Se houver uma interface do usuário, eles devem testá-la. Se não houver interface do usuário, o teste automatizado da interface do usuário não será necessário. O teste é necessário e uma interface do usuário deve ser testada. O teste automatizado é a melhor prática atual.

Linha de fundo. Uma equipe de "teste" separada e um BA que escreve todos os pequenos detalhes não são uma organização ideal para o Scrum. Scrum significa que você precisa repensar sua organização e seus processos.

A maioria das respostas que vou dar refere-se a um método Agile de desenvolvimento de software versus um método Iterative Waterfall. O Scrum é uma implementação popular do Agile.

1. No Scrum típico, não há fase de teste separada, porque testes formais devem ocorrer durante todo o sprint. Quando um desenvolvedor termina uma História do usuário, o recurso de controle de qualidade já deve ter seus casos de teste preparados e começar a testar nesse ponto. Se os casos de teste forem aprovados, eles aceitam a história do usuário e passam para a próxima. Depois que todas as histórias de usuário forem concluídas e aceitas, o sprint terminará e você começará a próxima. É claro que tudo depende da integração contínua, portanto, as alterações de desenvolvimento estão imediatamente disponíveis para o controle de qualidade. Desenvolvimento adicional deve seguir as diretrizes do TDD para garantir que o teste de regressão seja o mais rápido e indolor possível.

2. É uma boa idéia para os BAs escreverem histórias de usuários, mas, para um controle mais detalhado e específico, as Histórias de Usuários podem acompanhar documentos formais de Requisitos. A história do usuário deve ser escrita da perspectiva de um único usuário por função. Ele expressa uma necessidade do ponto de vista do usuário, tão naturalmente que se o software atualmente atender a todos os aspectos dessa necessidade, a história do usuário será atendida. As histórias de usuário podem ser compostas por histórias de usuário filho e tarefas atribuíveis. Pode haver sobreposição no Tasks para várias histórias de usuários.

3. O teste automatizado da interface do usuário pode ser uma coisa boa, mas pessoalmente considero mais importante o esforço dos métodos TDD e a cobertura 100% dos testes unitários de toda a lógica de negócios. Parece que a maioria das equipes de desenvolvimento de software não consegue atingir 100% de cobertura do Business Logic, portanto, na minha opinião, o Teste automatizado de interface do usuário seria um desperdício de tempo valioso que poderia ser usado para escrever mais testes de unidade para BL. É um luxo, não uma necessidade na minha opinião.

1. No Scrum, você deve produzir um incremento de software potencialmente entregável no final de cada sprint. Como resultado, o Scrum promove o conceito de equipe inteira ou equipe multifuncional, onde todas as habilidades necessárias para conduzir uma determinada história do usuário devem estar presentes na equipe.

   No meu projeto atual, como uma história totalmente testada faz parte da nossa definição de concluído, incorporamos testadores nas equipes. Durante os primeiros dias de um sprint, enquanto os desenvolvedores começam a trabalhar nas primeiras histórias de usuários, os testadores preparam cenários de teste e configuram alguns dados de teste. Assim que o desenvolvedor de uma das histórias de usuário terminar, eles o testarão.

2. Essa é uma das maiores dificuldades do Scrum IMO. Você precisa encontrar a quantidade certa de especificações necessárias para obter uma história de usuário implementável e testável. Muitas análises, documentação e especificações iniciais resultarão em um plano rígido que inevitavelmente se mostrará errado ao longo do sprint. Por outro lado, uma história do usuário que não tenha sido claramente definida e expressa pelo Dono do Produto levará a uma largura de banda de comunicação saturada entre os desenvolvedores e o OP durante o Sprint e atrasará o desenvolvimento enquanto o OP toma decisões sobre as histórias do usuário no meio do sprint .

   No nosso caso, definimos a quantidade certa de detalhes para que uma história de usuário seja 1 / uma descrição na forma de "como ... quero ... para que ..." e 2 / uma série de aceitação critério. Raramente fazemos maquetes da interface do usuário de antemão, isso pode acontecer durante os planejamentos do sprint, mas são mais esboços que são descartados posteriormente.

3. Na minha experiência, o teste automatizado da interface do usuário é extremamente demorado e extremamente frágil. Existem maneiras de fazer isso no WPF, mas eu ponderaria cuidadosamente o custo de manutenção desses testes com os benefícios antes de seguir esse caminho.

Trabalhar em iterações cada vez mais curtas torna todas essas transferências cada vez mais caras. Você pode reduzir esses custos seguindo uma regra estúpida e simples: corte pela metade o tamanho dos lotes, mude a maneira como trabalha para tornar isso confortável e repita até ficar satisfeito.

Veja o seu exemplo de sprint de 5 andares. Se suas equipes estão acostumadas a escrever o código para todas as 5 histórias, testando todas as 5 histórias, o tamanho do lote é 5 histórias. Corte isso ao meio. No próximo sprint, trabalhe primeiro nas três histórias mais urgentes, preparando-as para os testes o mais cedo possível. Como os testadores estão testando essas três histórias, o restante pode preparar as duas histórias restantes para teste. Isso causará algumas dores de crescimento. Mude a forma como trabalha para tornar isso mais confortável.

Por exemplo, mais pessoas trabalharão juntas em cada história, então tente mais emparelhamento e veja se isso ajuda você a trabalhar de forma mais constante. Ou, talvez, os testadores encontrarão problemas na história 2 que distraem alguns programadores enquanto tentam trabalhar na história 5; portanto, incentive os programadores e testadores a seguir o sprint a discutir mais cedo como testar uma das histórias no "primeiro lote" "para que os programadores tenham menos probabilidade de cometer um erro que um testador possa capturar facilmente com um teste.

Pode levar alguns sprints para resolver os grandes problemas associados aos testadores que testam um pequeno lote de histórias enquanto os programadores trabalham no próximo lote de histórias. Quando ficar confortável, corte o tamanho do lote pela metade novamente. E de novo. Dentro de um ano ou mais, a equipe estará testando confortavelmente histórias, pois os programadores acreditam que terminaram com elas e provavelmente cometendo menos erros ao longo do caminho. Cada história será feita mais cedo.

Obviamente, neste momento, agora você pode fazer o mesmo com os lotes que a equipe recebe dos proprietários do produto ou que a equipe envia para a organização de operações. E assim por diante. Nesse ponto, você pode abordar a questão "quantos detalhes os BAs devem escrever para as histórias?" problema.

A propósito: para que os testadores possam reduzir seu tempo de resposta, eles terão que adotar alguma automação, combinando alguma coisa para aprender como automatizar e programadores ajudando-os a automatizar. Ao tentar reduzir o tamanho do lote, você descobrirá quando precisa corrigir esses problemas. Não adicione automação apenas porque um livro diz que você precisa.

Espero que isso te ajude.

Só quero compartilhar algumas experiências, como abaixo, espero que seja útil para você.

Em um sprint com digamos 5 histórias, quando você libera para testar? É assim que uma história é concluída pelo desenvolvedor ou depois que todas as histórias são concluídas, mas antes do final do sprint, dando ao teste o tempo necessário para o teste.

Para cada grande história de usuário, ela deve ser dividida em várias subtarefas e, quando as subtarefas são completamente executadas pelo desenvolvedor, elas devem ser liberadas para o QC para teste imediato. O defeito deve ser corrigido após o teste para essas subtarefas concluírem o teste.

Se o BA escrever histórias de usuários, quais devem ser os detalhes. Tradicionalmente, leva muito tempo para escrever uma especificação com todo o layout da interface do usuário, comportamento, texto etc. para ser finalizado. Acho que minha pergunta é como escrever histórias que sejam implementáveis ​​e testáveis.

No Scrum, as histórias do usuário devem estar em qualquer formato, desde que as conversas em torno das histórias ocorram e não se espere que sejam concluídas ou estáticas. Uma pequena história, chamada simplesmente de história do usuário, é bem compreendida e pode ser implementada em um sprint. A prioridade de uma história pode ser baseada no ROI, no valor comercial ou em qualquer outra coisa que o usuário concorde que seja importante. São atividades da PO.

Nossa equipe de teste não é técnica. Quão importante é ter testes automatizados de interface do usuário para o Scrum. A interface do usuário é baseada no WPF

A aplicação do teste de automação no Scrum é uma atividade bastante difícil. Como todas as funções são implementadas incompletamente e não são realmente estáveis ​​para permitir que o CQ implemente o caso de teste por alguma ferramenta de autoteste. Isso deve ser feito para um sprint chamado: regressão.