Como você integra o Testing em um processo Scrum? [duplicado]

15

Isso está realmente me intrigando. Nós temos uma 'definição de feito' e isso inclui dev 'done', testes de unidade 'done', dev test 'done'. No entanto, também temos um teste de aceitação do usuário que precisa ser 'concluído', mas a empresa quer saber quando as histórias dos usuários estão completas para que possam ver o material (o uat realmente não é uma prioridade até o lançamento). Mas porque isso está fora do que foi feito inicialmente (onde passamos nossas histórias de usuários), como podemos dizer que está feito? E onde isso se encaixa na estimativa?

Onde posso encontrar informações sobre a integração de testes com um processo scrum? Eu acho que preciso ler isso ...

    
por Pete2k 27.02.2012 / 12:09
fonte

5 respostas

19

but the business wants to know when users stories are complete

Não é feito até que seu cliente diga que está pronto: qualquer outra definição de "feito" é delirante. Os testes de aceitação do usuário são os critérios de sucesso de uma história do usuário: por isso eles são chamados de "histórias do usuário" e não "histórias de gerenciamento".

    
por 27.02.2012 / 12:24
fonte
4

Normalmente, a definição de concluído inclui mais do que você está incluindo, como testes de integração, testes de aceitação e documentação (orientados ao desenvolvedor e ao usuário). Depois que os testes de unidade passarem, você poderá integrar o novo recurso / componentes e executar testes de integração. Depois que o recurso estiver integrado, você executará os testes de aceitação. Depois que os testes de aceitação passarem, você pode certificar-se de que qualquer documentação reflita quaisquer alterações recentes e que o recurso esteja concluído. Um problema é que o teste de aceitação não deve ser uma prioridade para um lançamento, mas uma prioridade para verificar e validar a conclusão de uma matéria.

No que diz respeito à estimativa, sua estimativa deve incluir tudo, desde a validação da história do usuário até o teste de aceitação. Se você não levar em conta todas as atividades e tarefas necessárias para concluir, integrar, verificar e validar completamente a história do usuário, a estimativa não agrega muito valor. Pode ser um recurso bastante simples de criar e testar, mas incrivelmente difícil de integrar ao seu design atual, o que significa que outros recursos precisam ser refatorados e testados novamente. Não contabilizar isso significa que seu rastreamento de velocidade estará desativado.

    
por 27.02.2012 / 12:20
fonte
1

Eu recomendaria que você se sentasse com os usuários ou com a gerência apropriada e analisasse esse problema com muito mais detalhes. Desenvolvimento de software profissional significa que você faz testes, inclusive para histórias de usuários.

Você precisa fazer disso uma prioridade. É sempre mais fácil não resolver o problema e continuar escrevendo mais código e fornecendo mais funcionalidade. No entanto, este não é um software que conta e pode ser contado, se parte do processo de QA não estiver funcionando.

Foco no processo e benefícios a longo prazo. "Mudar o óleo leva tempo", mas você não o detém para sempre ou, de repente, um dia, você tem uma surpresa desagradável! Então, você agenda a manutenção, o teste, qualquer que seja, como parte do processo de desenvolvimento de software. Desde que você está tentando mudar um sistema existente, eu recomendaria fazer isso um pouco mais formal inicialmente para iniciar o processo. Concentre-se nos benefícios (as pessoas gostam de ouvir) em vez de questões atuais (as pessoas ficam defensivas e questionam).

Se a organização não entender completamente o desenvolvimento de software profissional, você poderá educá-lo ou procurar outro lugar que o faça.

    
por 27.02.2012 / 16:30
fonte
1

A única coisa que eu 'RECOMENDO' fazer é implementar testes automatizados. Por exemplo; Se você estiver testando coisas no Windows Forms ou C # ou WPF, use White.Core para teste. Isso permitirá que você teste novas implementações, construções, recursos o mais rápido possível.

Eu trabalho como Engenheiro de Automação e uso o White.Core em C ++ / C # enquanto testo as GUIs para verificar as correções dev antes que a iteração termine.

    
por 27.02.2012 / 17:55
fonte
0

A desconexão entre estados diferentes de done geralmente é uma fabricação de gerenciamento de projetos querendo desesperadamente acreditar que os desenvolvedores podem entregar o código completamente para recursos não-projeto para o UAT e seguir em frente.

Isso não é Scrum. Isso não é Agile. Este é um Anti-Padrão Ágil.

Existe apenas um estado "concluído" para uma determinada história de usuário e que é Aceito . Uma sprint NÃO é executada até que todas as histórias de usuário atribuídas na sprint tenham sido excluídas do sprint ou aceitas.

Agora, um desenvolvedor pode ser Completo com uma história do usuário, o que significa que está pronto para o UAT, mas o desenvolvedor não está fora de si até que a história do usuário seja aceita, pois vários problemas ser encontrado durante o UAT que o desenvolvedor deve abordar antes do final do sprint.

Todas as fases de projeto, documentação, implementação e todos os tipos de testes devem ser levadas em conta na estimativa de uma história do usuário. O QA ou a entidade que deve executar o UAT deve ser um recurso do projeto durante o planejamento da sprint.

    
por 27.02.2012 / 19:07
fonte