A revisão do código está atrasada no ciclo de entrega / teste

14

Em nosso processo Agile, temos Sprints de 2 semanas. As tarefas são entregues diariamente (compilações diárias) e a Equipe de Teste conclui seus testes imediatamente no dia seguinte ou mesmo no mesmo dia.

Também temos análises de códigos de desenvolvimento, que requerem algum tempo (de 1 a 2 horas), portanto, elas são agendadas 3 vezes por semana: seg-casados-sex. Os desenvolvedores se reúnem e sugerem como melhorar / refatorar o código.

Nosso problema é que, quando os itens de ação aparecem após uma revisão de código, a maioria das tarefas já foi testada. Os testadores não querem testar novamente o que já passou nos testes. Eles não se importam com alterações internas de desenvolvimento.

Estamos entendendo mal o processo Agile? As revisões de código são incompatíveis com um ciclo diário de liberação / teste? Não podemos realizar revisões de código todos os dias, pois elas ocupam o tempo de todos.

— gene b.
fonte

Encontrei algumas sugestões que podem ser úteis - Revisão de código em equipes ágeis - parte II (encontrada em uma pesquisa muito rápida no Google - você pode encontrar mais).

— Dukeling 6/08/15

1

Seus testadores estão trabalhando em tarefas "liberadas"? A definição de "lançado" da sua equipe inclui a revisão do código e a resolução do item de ação? Ou a revisão do código está acontecendo fora da definição de pronto de sua equipe?

— Kent A.

1

Sua equipe de teste não possui um conjunto de regressão automatizado?

— Telastyn

5

Como você faz "revisões de código"? Esse é um processo formal demorado, em que os revisores precisam trabalhar com uma lista completa de métricas de qualidade (esforço: várias horas-pessoa)? Ou é apenas qualquer outro membro da equipe examinando o código e fazendo perguntas se algo parecer errado (esforço: 10 a 30 minutos para codificador e revisor)? Por que você faz revisões de código? Para garantir a qualidade do código? Para pegar bugs? Divulgar o conhecimento do sistema entre várias pessoas? Seu mecanismo de revisão de código ajuda a cumprir esses objetivos ou é apenas a burocracia que ninguém deseja fazer?

— amon

Gosto de todas as respostas, mas deixe-me acrescentar um ponto que considero importante. Você está perguntando se está interpretando mal o Agile, mas não diz qual metodologia. Você está seguindo o Scrum? Mais importante: você tem uma definição de "Concluído"? Estou perguntando, porque acho muito ... estranho que você esteja pensando em algo "entregue" antes de terminar de realmente trabalhar nele. Parece que a revisão de código é algo "extra" que você faz apenas porque.

— Lorenzo Dematté 20/08/2015

8

Os testadores não querem testar novamente é como dizer "os codificadores não querem refatorar". É parte do trabalho. O processo pode ser reapresentado da seguinte forma: As tarefas são criadas. Código é gerado. O código é testado. O código é revisado. Imperfeições são encontradas no código. Novas tarefas são criadas para solucionar essas imperfeições (por exemplo, o código é refatorado). Essas novas tarefas requerem novos testes.

— John
fonte

2

+1 Em uma metodologia Agile de release diário, não reabra as tarefas. Crie uma nova tarefa para resolver os problemas encontrados e agende-a de acordo com as prioridades da sua equipe. Novas tarefas = nova ação de controle de qualidade (o que provavelmente significa executar os mesmos testes novamente). Se o controle de qualidade não gostar, há muitas outras carreiras.

— A.

Isso claramente funciona, mas parece ineficiente.

— usr

7

Se você estiver revisando o código em algum momento, não será mais caro fazer a revisão mais cedo. E parece que você tem um processo de teste caro, por isso não deseja testar duas vezes. Portanto, é mais barato revisar o código antes do teste. A revisão do código após o teste não torna o trabalho mais rápido. Isso o torna mais lento e tenta fornecer código mal escrito, mas testado com êxito. Com o tempo, todo esse código não revisado tornará o trabalho cada vez mais lento. Então, um concorrente mais eficiente entrega um produto melhor a um custo menor e acaba o jogo.

Além disso, automatize o teste. O teste manual é tão 1970.

— Kevin Cline
fonte

5

Se você está achando difícil fazer com que as revisões de código ocorram no tempo que você tem atualmente antes do controle de qualidade, considere tornar as revisões de código mais leves, como a Revisão de Código nas Agile Teams, Parte II que o @Dukeling postou.

Descobri que mesmo a coisa mais simples que poderia ser chamada de revisão de código dava benefícios: antes de confirmar o código (ou inserir um DVCS), chame outro desenvolvedor e acompanhe-o na sua alteração. Isso pode levar cinco ou dez minutos. O objetivo desta revisão de código é "Isso faz sentido para o outro desenvolvedor?" O objetivo não era detalhar as implementações de design ou se conformar completamente às idéias pessoais do revisor sobre como deveria ter sido escrito. Deu estes benefícios:

Conhecimento compartilhado aprimorado de como o código funcionava
Captura de código confuso ou potencialmente incorreto, porque o ato de explicar o código foi suficiente para fazer o autor repensar as coisas
Ajudou a evoluir gradualmente os idiomas e o estilo da equipe, porque tornou mais fácil explicar as coisas
Muito pouco resmungando da equipe

Revisões mais profundas do código funcionam absolutamente melhor para encontrar problemas. Mas você deve ser capaz de fazê-las e agir de acordo com elas para obter o valor. Um processo leve que você pode executar o tempo todo pode ser mais útil do que um processo pesado que continua sendo adiado ou simplesmente adiciona coisas à lista de pendências.

— Alan Shutko
fonte

1

Uma solução para esse problema é fazer uma rápida revisão do código por outro colega assim que a história do usuário terminar, para que não ocorram erros básicos / óbvios no código.

Mas isso tem que acontecer antes do ciclo de teste. Depois, haverá menos alterações de código após o teste, quando você fizer uma revisão maior com toda a equipe.

— Pelicano-voador baixo
fonte

1

Pelo que parece, os testadores não querem testar novamente porque o teste é um processo doloroso / caro.

A automação de teste, tanto por desenvolvedores quanto por testadores, é um bônus enorme para as equipes que tentam trabalhar de maneira ágil. Quanto mais baratos, fáceis e reprodutíveis forem seus testes, mais você poderá executá-los - e menos resistência terá à mudança de algo.

Você fez um refatoramento rápido com base em algum feedback do desenvolvedor? Pressione o grande botão vermelho que executa sua suíte de regressão / fumaça e faça uma rápida revisão manual para verificar se há problemas visuais que possam ter surgido. Fácil!

Quando você estiver em um lugar como esse, o novo teste não será uma tarefa árdua - será uma segunda natureza.

— f1dave
fonte