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

15

Eu 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 uma cascata / SDLC iterativo. Os BAs escrevem documentos de requisitos, passam para o dev e test, começam a desenvolver e serão liberados para testes em iterações. Os testadores demoram muito tempo para testar um release pelo qual os desenvolvedores continuam o desenvolvimento, mas também as correções de bugs da versão atual. Eu tenho algumas perguntas

  1. Em um sprint com cinco histórias quando você lança para testes? É assim que uma história é completada pelo desenvolvedor ou depois que todas as histórias são completadas, mas antes do final do sprint, dando o tempo necessário para testar.
  2. Se o BA gravar histórias do usuário, qual deve ser o detalhe. Tradicionalmente, leva muito tempo para escrever uma especificação com todo o layout da interface do usuário, comportamento, texto etc. a ser finalizado. Eu acho que minha pergunta é como escrever histórias que são 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 uma sólida experiência de desenvolvimento usando métodos ágeis (TDD, revisões de código, refatoração etc.), mas novos no scrum.

Editar: Por iterações, quero dizer que, se houver 100 requisitos, poderemos liberar para testes quando terminarmos com 30, 35, 35 requisitos, em vez de esperar até que todos os 100 requisitos tenham sido concluídos.

    
por softveda 29.12.2011 / 10:27
fonte

5 respostas

11

Se o teste for separado do desenvolvimento, você terá duas equipes de scrum separadas. É uma má ideia ter uma mão a trabalhar para a outra.

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

In a sprint ... when do you release for testing ?

Quando o sprint terminar. Totalmente feito. Isso significa que você fez seu próprio teste de unidade e está certo de que funciona. Após a conclusão da equipe de desenvolvimento, você a libera para outras equipes para "teste" ou "implantação" ou qualquer outra coisa que ocorra na organização.

I guess my question is how to write stories that are implementable and testable.

Isso varia de equipe para equipe. O BA faz parte da equipe de desenvolvimento. Você tem que trabalhar nisso como uma 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.

How important it is to have automated UI testing for Scrum.

Essencial. Completamente necessário para qualquer desenvolvimento de interface do usuário. Os desenvolvedores devem fazer todos os testes antes de , 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 de interface do usuário automatizado não será necessário. O teste é necessário e uma interface do usuário deve ser testada. O teste automatizado é a prática recomendada atual.

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

    
por 29.12.2011 / 13:15
fonte
9

A maioria das respostas que vou dar relacionam-se com um método Ágil de desenvolvimento de software versus um método de Cascata Iterativa. O Scrum é apenas uma implementação Agile popular.

  1. No típico Scrum, não há fase de teste separada, porque o teste formal deve ocorrer durante todo o sprint. Quando um desenvolvedor conclui uma história de 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, aceite a história do usuário e passe para a próxima. Depois que todas as Estórias de Usuário forem concluídas e Aceitas, a sprint termina e você começa a próxima. Isso tudo depende, é claro, 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 ideia para os BAs escreverem histórias de usuários, mas para um controle mais detalhado e específico, as Estórias de Usuário podem acompanhar documentos formais de Requisitos. O User Story deve ser escrito da perspectiva de um único usuário por função. Ele expressa uma necessidade do ponto de vista do usuário, então, naturalmente, se o software atualmente satisfaz todos os aspectos dessa necessidade, então a história do usuário está sendo satisfeita. As histórias do usuário podem ser compostas de histórias de usuários e Tarefas atribuíveis. Pode haver sobreposição em Tarefas para várias histórias de usuários.

  3. Testes automatizados de interface do usuário podem ser uma coisa boa, mas eu pessoalmente sinto que mais esforço em métodos TDD e 100% de cobertura de teste unitário de toda a Business Logic é mais importante. A maioria das equipes de desenvolvimento de software não consegue atingir 100% de cobertura da Business Logic, portanto, na minha opinião, o Automated UI Testing seria um desperdício de tempo valioso que poderia ser usado para escrever mais testes de unidade para o BL. É um luxo, não uma necessidade, na minha opinião.

por 29.12.2011 / 13:26
fonte
4
  1. No Scrum, você deve produzir um incremento de software potencialmente utilizável ao final de cada sprint. Como resultado, o Scrum promove o conceito de equipe inteira ou equipe multifuncional onde todas as habilidades necessárias para levar uma determinada história de usuário a ser feita precisam estar presentes na equipe.

    No meu projeto atual, uma vez que uma história totalmente testada é parte de nossa definição de feito, temos testadores incorporados 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 do usuário terminar, eles testarão.

  2. Esta é uma das maiores dificuldades no Scrum IMO. Você precisa encontrar a quantidade certa de especificação necessária para obter uma história de usuário testável e passível de ser testada. Muitas análises antecipadas, documentação e especificação resultarão em um plano rígido que inevitavelmente se mostrará errado ao longo do sprint. Por outro lado, uma história de usuário que não tenha sido claramente definida e expressa pelo Product Owner resultará em uma largura de banda de comunicação saturada entre os desenvolvedores e o PO durante o Sprint e atrasos no desenvolvimento enquanto o PO toma decisões sobre histórias do usuário na metade do sprint .

    No nosso caso, definimos a quantidade certa de detalhes para uma história de usuário para ser 1 / uma descrição na forma de "como um ... eu quero ... para que ..." e 2 / a série de critérios de aceitação. Nós raramente fazemos mockups da interface de usuário de antemão, isso pode acontecer durante os planejamentos de sprint, mas eles são mais esboços que são descartados depois.

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

por 01.02.2012 / 14:23
fonte
2

Trabalhar em iterações cada vez mais curtas torna todos esses handoffs cada vez mais caros. Você pode reduzir esses custos seguindo uma regra simples e estúpida: corte tamanhos de lotes pela metade, mude o modo de trabalhar para ficar confortável, repita até ficar feliz.

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

For example, more people will work on each story together, so try more pairing and see if that helps you work more steadily. Or, perhaps, the testers will find problems in story 2 that distracts some programmers while they're trying to work on story 5, so encourage the programmers and testers next sprint to discuss earlier how to test one of the story in the "first batch" so that the programmers are less likely to make a mistake that a tester can easy catch with a test.

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. Uma vez que se torne confortável, corte o tamanho do lote ao meio novamente. E de novo. Dentro de um ano, a equipe estará testando confortavelmente as histórias, já que os programadores acreditam ter terminado com elas e , provavelmente cometendo menos erros ao longo do caminho. Cada história será feita mais cedo.

Naturalmente, neste ponto, agora você pode fazer a mesma coisa 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. Neste ponto, você pode abordar o "quanto os BAs devem escrever para as histórias?" problema.

A propósito: para que os testadores possam reduzir seu tempo de resposta, eles precisarão adotar alguma automação, por meio de alguma combinação de aprendizado de como automatizar e programadores ajudando-os a automatizar. Ao tentar reduzir o tamanho do lote, você descobrirá quando precisará corrigir esses problemas. Não adicione automação apenas porque um livro diz que é necessário.

Espero que isso ajude você.

    
por 30.10.2014 / 02:16
fonte
0

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

In a sprint with say 5 stories when do you release for testing ? Is it as soon as a story is completed by dev or after all stories are completed but before end of sprint giving test the required time to test.

Para cada grande história de usuário, ela deve ser dividida em várias subtarefas e, quando as sub-tarefas forem completamente realizadas pelo desenvolvedor, elas devem ser liberadas para o CQ para teste imediatamente. O defeito deve ser corrigido após o teste para o teste de conclusão das sub-tarefas.

If the BA writes user stories what should be the detail. Traditionally it takes long time to write a spec with all UI layout, behaviour, text etc to be finalised. I guess my question is how to write stories that are implementable and testable.

No Scrum, as histórias de usuários devem estar em qualquer formato, desde que ocorram conversas em torno das histórias e não se espere que sejam concluídas ou estáticas. Uma pequena história, chamada simplesmente de uma história de usuário, é bem conhecida e pode ser implementada em um sprint.  A prioridade de uma história pode basear-se no ROI, no valor da empresa ou no que mais o usuário concordar ser importante. Isso é atividades por PO.

Our test team is non-technical. How important it is to have automated UI testing for Scrum. The UI is based on WPF

Aplicar o teste de automação no Scrum é uma atividade bastante difícil. Porque todas as funções são implementadas de forma incompleta e não são realmente estáveis para permitir que o QC implemente o caso de teste por alguma ferramenta de teste automático. Isso deve ser feito para um sprint chamado: regression.

    
por 26.10.2014 / 03:44
fonte

Tags