Codificação e teste no mesmo sprint

22

Como o teste é realizado dentro do mesmo sprint que a codificação, se toda ou a maior parte da codificação não é feita até o final do sprint? (Estou me referindo ao desenvolvimento e teste "de sopa para nozes" de um único PBI em um sprint.)

A maioria das respostas que eu vi on-line envolve automação de controle de qualidade, mas mesmo isso não é possível, pois geralmente você precisa de uma interface de usuário funcional para registrar ou criar testes automatizados. Só tenho storyboards que continuam a evoluir à medida que desenvolvo recursos e descubro novos requisitos.

No meu caso, estou desenvolvendo um novo aplicativo de desktop. Geralmente, os aplicativos de desktop não se prestam muito bem a testes automatizados. Tenho alguns testes de unidade automatizados, mas eles não são os testes funcionais / de integração manuais que um profissional de controle de qualidade executaria.

Então, onde eu estou agora é que meu sprint termina amanhã, ainda tenho a codificação para terminar, e meu pessoal de controle de qualidade ainda não tem nada para testar e não tem idéia de como testar o que eu daria a eles sem eu segurar suas mãos.

Tenho certeza de que não sou a primeira pessoa a ter esse dilema.

No passado, eu fiz um pipeline: no sprint atual, a equipe de teste testa os recursos implementados durante o sprint anterior. No meu trabalho atual, o PM refere-se a essa abordagem como "cascata" e, como tal, inaceitável.

Mark Richman
fonte
2
Você não é a primeira pessoa a ter esse dilema. Você pode usar um pipeline: no sprint atual, a equipe de teste testa os recursos implementados durante o sprint anterior.
Giorgio
2
PM forçando equipe para fazer coisas que seus sons caminho como um Half-arsed Agile
mosquito
8
@ Mark Richman: Cachoeira? Você não tem ciclos de desenvolvimento de 1-2 semanas em cascata. Acho que ele não faz ideia do que está falando.
Giorgio
2
@gnat: se a equipe não tiver um desempenho particularmente alto (e parece que essa equipe se encaixa nessa descrição), você pode ver isso como o gerente geral que orienta a equipe a desenvolver uma estratégia de desenvolvimento mais eficaz. Talvez o gerente de contas pense que entregar constantemente um código não testado não seja bom para os negócios. Agile não significa necessariamente "deixar as equipes fazerem o que quiserem", deve haver alguns limites até que uma equipe esteja madura o suficiente para decidir por si mesma.
Bryan Oakley

Respostas:

13

Se você não testar uma história do usuário (EUA) e verificar se os critérios de aceitação foram atendidos, essa história não foi concluída. Se isso não for feito, os EUA vão para o próximo sprint, é claro. E se todos os seus EUA estiverem nesse estado, o seu sprint terminou sem nenhum valor agregado ao projeto. Do ponto de vista do cliente, não consigo distinguir isso de toda a equipe de desenvolvimento que sai de férias.

Um dos princípios enxutos (o ágil não termina com o scrum) diz que "a qualidade está embutida". Algo é feito apenas se atender aos critérios de qualidade definidos por você. É crucial ter um processo ágil real, terminar a primavera com valor zero ou separar os testes do desenvolvimento são sintomas de um grande problema.

Há muitas coisas que você pode fazer:

  • a automação é a chave do sucesso. Pelo menos no nível do teste de unidade, e algumas outras práticas como o IC também são importantes. Isso não é suficiente, mas se bem feito, esses tipos de teste resultam em poucos ou nenhum erro descoberto em testes manuais (geralmente pequenas coisas da interface do usuário). Se você dedicou pessoal de controle de qualidade, eles podem automatizar o teste de aceitação, e parte dessa automação pode começar antes de você terminar um sprint.

  • Veja o tamanho das suas histórias de usuário. Se você tem um EUA que terminou os dois primeiros dias do sprint no terceiro dia, uma pessoa de controle de qualidade pode testá-lo. Na minha opinião, ter um histórico pequeno de usuários (SMART) é uma das coisas mais importantes para o sucesso no desenvolvimento ágil, e muitas pessoas parecem não perceber isso.

  • A colaboração entre testador e desenvolvedores é outra parte essencial do sucesso. No meu projeto anterior, quando os EUA são finalizados por um desenvolvedor, uma pessoa de controle de qualidade faz um "teste de pares" com o desenvolvedor (pode ser manual, pode ser através do lançamento de alguns automatizados, ou melhor, ambos), isso funciona muito bem.

AlfredoCasado
fonte
8

O problema essencial é que você tem programadores que codificam, mas não testam, e testadores que testam, mas não codificam.

Resolva esse problema e você não o terá, e uma equipe sem dúvida mais eficiente.

Uma maneira que funcionou para mim no passado foi sugerir codificadores e testadores para parear histórias com a tarefa explícita de fornecer uma história totalmente testada. Junto com isso, eu apaguei todas as formas de pensamento "dev complete": nenhuma coluna "dev complete" no quadro scrum / kanban / trello, nenhuma atitude "dev done" dos programadores.

O que aconteceu foi:

  • Os pares eram responsáveis ​​pela entrega de histórias e ambos fracassariam se uma história não fosse concluída. Eles foram tratados como profissionais responsáveis ​​encarregados de fornecer software e, na maioria dos casos, o fizeram.

  • Houve muito menos trabalho de teste porque os testadores foram expostos aos testes de unidade e integração, portanto, eles não repetiram o mesmo teste manualmente.

  • Alguns testes foram automatizados quando os desenvolvedores entenderam melhor o que os testadores precisavam.

  • Algumas pessoas ficaram chateadas.

  • As histórias foram entregues mais rapidamente, em média, porque o ciclo de código-confirmação-puxar-teste se tornou quase instantâneo

Claro, essa é apenas a minha experiência anedótica, mas você pode tentar fazer isso sozinho, se puder.

No seu caso, dado o seu comentário de que testadores e desenvolvedores são separados por autoridade na sua empresa, a mensagem parece clara para mim. Há uma barreira óbvia à comunicação e colaboração colocada pelas regras da empresa.

Este é um problema de comunicação , não um problema ágil . Adotar uma metodologia ágil é simplesmente torná-la evidente. As equipes silo'd são um anti-padrão de gerenciamento conhecido ; portanto, adote a não adaptabilidade do ágil neste caso!

Sklivvz
fonte
2
Esta organização criou limites claros e papéis de "promotores" e "testadores", e N'er a dois devem se encontrar;)
Mark Richman
Então, mude a regra!
Sklivvz
3
@ MarkRichman, em um dos meus trabalhos anteriores, também havia limites claros nos papéis de "desenvolvedores" e "testadores", mas essa organização não colocou nenhum bloco encontrado para eles se comunicarem (que idéia ruim!); Lembro-me de fazer sprints em par com o "testador designado" e foi ótimo. Sua empresa simplesmente separa as funções ou estabelece uma barreira de comunicação / colaboração entre os engenheiros que desempenham essas funções?
mosquito
1
"O problema essencial é que você tem programadores que codificam, mas não testam, e testadores que testam, mas não codificam.": Hein? Por que isso é um problema? Um programador deve, bem, programar e um testador deve testar. Além disso, você precisa de algum recurso mínimo implementado antes de poder testá- lo: não é possível paralelizar duas tarefas se a saída de uma tarefa for a entrada da outra tarefa.
Giorgio
@Giorgio é uma vista em cascata. No ágil, as pessoas que podem agregar valor independentemente são muito favorecidas. Não há razão para o desenvolvimento e o teste serem profissões separadas. É uma escolha respeitável, mas pouco adequada ao desenvolvimento ágil.
precisa saber é o seguinte
4

O papel real do seu controle de qualidade está próximo do teste de aceitação. Eu imagino que isso seja feito por uma equipe separada, que atua mais como proprietária do produto do que como parte da equipe de desenvolvimento.

Exemplo: durante um sprint, você precisa adicionar um recurso que permita filtrar os resultados da pesquisa por diferentes critérios. Você já tem seu mecanismo de pesquisa implementado, mas os resultados são ordenados alfabeticamente.

  • Durante o sprint:

    1. A equipe esboça o design do novo recurso e o impacto na base de código real.

    2. Os desenvolvedores escrevem testes de unidade que garantem que o pedido esteja funcionando conforme o esperado e, ao mesmo tempo, escrevem o código real.

    3. O novo recurso é cuidadosamente testado para garantir que não quebre nada (teste de regressão) e que esteja funcionando conforme o esperado (testes de unidade).

    4. Se possível e apropriado , o que não é o caso na maioria dos projetos , o proprietário de um produto (e, portanto, sua equipe de controle de qualidade) pode avaliar constantemente o novo recurso para impedir que a equipe vá na direção errada. Isso requer integração contínua com dezenas de compilações todos os dias.

  • Após o sprint, o proprietário do produto avalia o novo recurso para verificar se ele corresponde às necessidades do cliente. Sua equipe de controle de qualidade está aqui, depois que o sprint terminou.

Acredito que seus problemas reais sejam os seguintes:

  • Âmbito . Um sprint diz respeito à sua equipe e apenas à sua equipe, não ao seu controle de qualidade real, que atua mais como proprietário de um produto.

  • Teste . O fato de você ter uma equipe de controle de qualidade não significa que tudo o que você precisa fazer é escrever código. O trabalho da sua equipe é fornecer um recurso que funcione conforme o esperado, não jogar fora o código para os outros testarem. Se você contar com a equipe de controle de qualidade para fazer o teste, isso aumentará o custo geral, pois os bugs serão corrigidos uma a duas semanas depois, em vez de serem corrigidos quase instantaneamente.

Arseni Mourzenko
fonte
Na verdade, acho que grande parte do problema desta organização (do qual sou novo) é que há pouco tempo gasto analisando requisitos e definindo uma solução que pode ser decomposta em pequenas unidades atômicas. Com o estado atual do projeto e da equipe, acho que o sprint atual não deveria ter sido nada além de um sprint de análise, onde os resultados finais são PBIs completos com tarefas e casos de teste. No entanto, eles parecem se concentrar no dinheiro que me pagam a cada hora e, a cada hora, não estou "codificando no teclado", eles estão perdendo valor.
Mark Richman
@ MarkRichman, a cada hora em que eles pagam para você digitar bobagens na base de código, estão perdendo não apenas a hora em que pagam, mas todas as horas necessárias para tirar essa bobagem da base de código.
Moz
4

se toda ou a maior parte da codificação não for feita até o final do sprint?

Por que não está terminando mais cedo? Essa limitação chave é a fonte dos seus problemas e vi duas abordagens serem bem-sucedidas. Um se encaixa bem na abordagem ágil (mas não em outras práticas comuns) e o outro tende a se agilizar um pouco (mas é mais comum).

A primeira é que você não codifica até o final do sprint. Na verdade, escrever código é uma parte relativamente pequena do desenvolvimento. Se você terminar na metade do sprint, isso fornecerá bastante tempo para o controle de qualidade executar seu trabalho. Também lhe dá tempo de sobra para escrever documentação, limpar dívidas técnicas, projetar itens de lista de pendências ... Todas as outras coisas que você precisa fazer para obter um produto de qualidade. A única desvantagem disso é que é quase impossível obter a funcionalidade e os testes de unidade rapidamente. Pessoalmente, acho que é completamente bom fazer testes de unidade depois de deixar o controle de qualidade começar a analisar a funcionalidade, mas os defensores do TDD (e outros) discordam.

A segunda opção é fazer com que o controle de qualidade opere um sprint atrás da equipe de desenvolvimento, como seu gerente de desenvolvimento odeia. Eu também tendem a não gostar disso. Ele elimina o conceito de "produto liberável" no final do sprint, mesmo se você tiver um processo de escalação para seus lançamentos. Pior, os desenvolvedores se concentrarão em coisas "novas" quando o controle de qualidade chegar a elas com perguntas ou bugs dos testes. É mais improvável que os desenvolvedores consertem bugs nesse arranjo. Mas já vi produzir software de qualidade a tempo.

Telastyn
fonte
1
Estou acostumado a fazer com que o controle de qualidade seja um sprint nos testes. As pessoas aqui querem ver o todo SDLC completar cada duas semanas. Só não vejo como isso é possível.
Mark Richman
5
@ MarkRichman - Por que não? 1 dia para planejamento, 5 dias para codificação e 4 para testes de unidade, documentação, correções de erros e design para o próximo sprint. O desafio não é realmente fazê-lo, mas ser disciplinado o suficiente como empresa para fazer uma pequena quantidade de trabalho bem.
Telastyn
1
porque eles não se concentrarão nos 5 dias em que estou codificando, mas nos outros 5 dias em que não estou. Eu certamente preencheria os outros 5 dias com codificação, mas, como eles desejam ter todas as tarefas de codificação "completas" (incluindo testes), isso não é consistente com a física da flecha do tempo :)
Mark Richman
1
@markrichman - bom, então deve ser fácil apontar para todas as outras coisas que não são de codificação que você precisa fazer para realmente ser feito .
Telastyn
bem, também descubro trabalho adicional que precisa ser feito para concluir o trabalho comprometido durante o sprint atual. Isso força outro trabalho a não ser implementado para esse sprint. Isso é bom, e acho que está no espírito do ágil, mas me disseram para nunca adicionar nada ao sprint atual e adicionar essas tarefas recém-descobertas (e concluídas) ao Product Backlog, o que não me parece correto .
Mark Richman
1

O Guia Scrum exige que as equipes sejam multifuncionais. Todos os membros da equipe são considerados desenvolvedores, independentemente de sua especialização individual. Indivíduos silo'd (codificador, testador, qa, ux, etc) são inúteis no Scrum. Os membros da equipe se ajudam sempre que podem. Não há conceito de 'passar o item para qa'.

Na sua situação, parece que você pode ter um problema de estimativa. Ao estimar os itens de lista de pendências do produto, é necessário considerar todas as atividades, como: Codificação, Teste, Revisão por Pares, Implantação, Integração - qualquer que seja sua definição de demanda realizada.

Como regra geral, espere trazer entre 5 e 15 itens de backlog do produto para um sprint. Isso dá uma idéia do tamanho de cada item da lista de pendências do produto. Também oferece uma excelente chance de realizar o trabalho dentro do sprint.

Por fim, a tarefa da equipe é mover um item da lista de pendências de produtos para 'concluído' e depois passar para o próximo. Às vezes, fazer isso significa que as pessoas estão pisando umas nas outras e, portanto, faz sentido aumentar mais de um estoque de produtos por vez. Sua orientação, porém, deve ser reduzir o trabalho em andamento (WIP) e mover os itens da lista de pendências do produto para concluídos.

Derek Davidson PST CST
fonte
0

Teste e codificação andam de mãos dadas. Você pode agendá-lo módulo por módulo. Quando o módulo estiver concluído, você poderá fornecê-lo aos testadores. Todo esse cenário também depende da fase de teste em que você está trabalhando. O modelo espiral SDLC parece bom. Nesse sentido, o teste e a codificação simultâneos são convenientes. Outra abordagem poderia ser o modelo V .

instinto
fonte
Eu concordo com você, mas os "poderes que existem" parecem ser puristas sobre qualquer coisa que não seja completar o SDLC inteiro em um único sprint de duas semanas. Qualquer coisa que não seja essa metodologia parece ser considerada cascata.
Mark Richman
0

Minha resposta, que provavelmente é bem estranha no começo, seria: você não encontra tempo para testar porque acha que o teste deve ser feito com os efeitos colaterais do código. E com efeito colateral, quero dizer o termo ciência da computação :

é dito que uma função (...) tem um efeito colateral se, além de retornar um valor, também (...) tem uma interação observável com (...) o mundo exterior.

Eu criei a citação para enfatizar a parte "interação com o mundo exterior": você deseja que os testes ocorram na interface do usuário conforme impressa na tela ("[iniciar o teste] não é realmente possível, pois geralmente você precisa de um UI para registrar ou criar testes automatizados a partir de ").

Outras respostas disseram para você automatizar esse "teste de aceitação", para que isso ocorra rapidamente. Isso está certo, mas não resolve completamente o seu problema original: e se não houver tempo suficiente para escrever esses testes de aceitação?

Você deve deixar de lado sua visão de teste depois que o código interagir com o mundo exterior, ou seja, ele imprimiu algo e espera alguma entrada. O problema dos efeitos colaterais é que eles são, na verdade, não testáveis. Isso me ocorreu ao ler uma entrevista com Guido van Rossum, onde ele disse que uma declaração que desliga o computador só pode ser comprovada como sendo executada.

A solução para essa "falta de testabilidade" é entender que, se você tiver provado uma vez que a declaração funciona, poderá usá-la em qualquer lugar e confiar nela para fazer seu trabalho. Isole-o em uma função e teste tudo o resto .

Aproximando esse exemplo da sua pergunta, a função agora é provavelmente uma biblioteca ou estrutura inteira e, em vez de desligar o computador, imprime algo: uma interface do usuário. Mantenha as chamadas o mais burras e o mais estável possível , porque depois de entrar nessa parte do seu aplicativo, você só pode testar através de testes de aceitação caros, ou seja, algum tipo de observação externa.

Considerar a interface do usuário como "território estrangeiro" é na verdade um ponto de vista correto, pois você não precisa testar a lógica de uma biblioteca que não é fornecida por você e, talvez surpreendentemente, é um ponto de vista realista: você realmente espera testar essa chamada, por exemplo MyWidget.draw(), o que você espera, no nível de um único pixel?

Isso não quer dizer que o teste de aceitação não seja importante ou que possa ser ignorado. Está aí para ficar e automatizá-lo, como sugerem outras respostas, traz enormes benefícios. Mas se você quiser encontrar tempo para testar e codificar no mesmo sprint, tente manter seu código o mais livre de efeitos colaterais possível.

logc
fonte