É correto corrigir erros sem adicionar novos recursos ao liberar software para teste do sistema?

Esta pergunta é para testadores ou leads de teste experientes. Este é um cenário de um projeto de software:

Digamos que a equipe de desenvolvimento tenha concluído a primeira iteração de 10 recursos e a liberada para teste do sistema. A equipe de teste criou casos de teste para esses 10 recursos e estimou 5 dias para o teste. É claro que a equipe de desenvolvimento não pode ficar ociosa por 5 dias e começa a criar 10 novos recursos para a próxima iteração. Durante esse período, a equipe de teste encontrou defeitos e levantou alguns bugs. Os bugs são priorizados e alguns deles precisam ser corrigidos antes da próxima iteração. O problema é que eles não aceitariam a nova versão com novos recursos ou alterações nos recursos existentes até que todos esses erros fossem corrigidos. A equipe de teste diz que é assim que podemos garantir uma versão estável para o teste, se também introduzirmos novos recursos junto com a correção de erros. Eles também não podem fazer testes de regressão de todos os seus casos de teste a cada iteração.

Isso significa que a equipe de desenvolvimento precisa criar uma ramificação de código exclusivamente para correção de bugs e outra ramificação onde eles continuam o desenvolvimento. Há mais sobrecarga de mesclagem, especialmente com refatoração e alterações arquiteturais.

Você pode concordar se esse é um princípio comum de teste. A preocupação da equipe de teste é válida. Você já encontrou isso na prática em seu projeto.

Eu diria que cada versão de novos recursos deve estar em um ramo separado. Isso permite que o desenvolvimento e as versões sejam dissociados.

Como sua versão para usuários finais trabalha nesse processo? Sua equipe de teste do sistema deve se preocupar menos com o cronograma de desenvolvimento e, em vez disso, se concentrar no cronograma de liberação do cliente.

Há pouco sentido em tentar testar formalmente novos recursos enquanto o desenvolvimento continua, porque há boas chances de seus próximos 10 recursos tocarem na mesma funcionalidade e exigir que eles testem essas áreas novamente.

Eles podem continuar a testar informalmente versões internas intermediárias durante o desenvolvimento e aperfeiçoar seu design de teste (esperançosamente capturando a maioria dos bugs nesses novos recursos), mas precisarão de um período adicional no final do desenvolvimento para testar formalmente os novos recursos e a regressão. teste.

Quando eles estimam 5 dias necessários para testar seus 10 novos recursos, o que eles devem considerar é que eles precisam de 5 dias no final do ciclo de desenvolvimento, antes do lançamento para os clientes, para validar os novos recursos (e provavelmente mais tempo para iterar). se erros forem encontrados). Durante esse período, a versão do cliente pode ser ramificada para teste e o desenvolvimento de novos recursos pode continuar para a próxima versão.

Utilizamos uma abordagem híbrida. Para a liberação do cliente, definitivamente temos uma filial própria, que é estritamente apenas para correções de erros críticos.

O desenvolvimento regular continua em várias versões de software. Por exemplo, digamos que a versão estável mais recente seja a 2.0. Todos os recursos arriscados serão adicionados à ramificação 3.0. Somente correções de erros entram nas ramificações 2.0. Os testes da equipe dedicada de controle de qualidade são feitos apenas em filiais estáveis. Certamente, as liberações dos clientes são feitas a partir de outra filial baseada no 2.0. Recursos de longa duração, como o próximo desenvolvimento da plataforma gen, serão feitos na versão 4.0 e nem na versão 3.0.

Tudo isso parece bom no papel. Mas se um cliente deseja um recurso específico, ele precisa ser adicionado à ramificação 2.0, pois o 3.0 não é estável o suficiente para ser liberado para os clientes. Isso significa que a equipe de controle de qualidade terá que executar novamente todo o conjunto de regressão.

Uma coisa que fazemos é fazer a cobertura do código de cada caso de teste de regressão. Somente os casos de teste de regressão são executados que serão afetados pelas alterações de código do recurso. Obviamente, para uma liberação do cliente, o pacote de regressão completo é executado.

Isso realmente depende de como os novos recursos estão intimamente ligados às partes que exigem correções de bugs. Por exemplo, se você adicionar um novo recurso de arrastar e soltar em uma pequena parte da interface do usuário, ele 'não' afetará o bug relacionado à análise do arquivo carregado pelo usuário.

Dito isto, é compreensível (não necessariamente justificado) que os testadores desejem testar as correções 'Ceteris paribus' (todas as 'outras' coisas são iguais).

Pode haver outras preocupações com a maneira de liberação e a expectativa dos usuários finais. Por exemplo, você pode precisar liberar somente após uma iteração de correções de bugs + teste e mais um novo recurso + teste porque os usuários SOMENTE desejam reinstalar ou atualizar quando houver novos recursos. Alguns podem exigir correções como prioridade máxima o mais rápido possível.

Você pode resolver esse problema (comum) mesclando as duas equipes.

Os testadores da equipe de desenvolvimento, testando à medida que os recursos são produzidos, podem ajudar a maioria das equipes a aumentar a qualidade da saída.

Sugiro que você leia este excelente post de Henrik Kniberg que explica Kaban . Você encontrará muitas idéias no processo Scrum (um livro gratuito também de Henrik Kniberg ).

Ele também escreveu um excelente artigo sobre o Kanban VS Scrum em seu blog.

Desfrutar.

A equipe de teste definitivamente tem uma preocupação válida, mas eu questionaria a necessidade de várias iterações de teste para cada versão. Por que passar por uma rodada inteira de testes em uma versão do código que os usuários nunca verão?

Se os testadores estão tentando obter uma liberação definida para um cliente, que não está esperando os novos recursos, a solicitação deles é razoável, justificada e você deve se inclinar para trás para entregá-lo.

Se isso é apenas para ajudar em seus "processos" durante as fases normais de desenvolvimento e garantir que a lista de bugs não esteja ficando fora de controle, sem que isso ocorra, pergunte ao chefe de teste se essa restrição pode ser relaxada um pouco até nos aproximamos do ponto de lançamento.

Considere mudar seu sistema de controle de origem para um produto distribuído. Isso tornará muito mais fácil fornecer uma versão desse tipo.

"Você pode concordar se este é um princípio comum de teste.

Yes

A preocupação da equipe de teste é válida

Yes

Você encontrou isso na prática em seu projeto. "

Yes

:

and Yes Merging is the downside of it 

Você não perguntou quem é a responsabilidade, mas é responsabilidade do Gerenciador de Configurações. Essa estratégia de fluxo deve estar em seu CMP. Caso contrário, demiti-lo. Eu acho que a resposta de Pierre 303 também é muito boa, mas é claro que sempre que possível tecnicamente (por exemplo, pensando em um lançamento do Siebel ...) e organizacional.

O problema é que, se eles testam os bugs em uma ramificação, ainda precisam testá-los novamente e fazer a regressão no tronco, uma vez que eles são mesclados novamente (a menos que confiem muito nos bons testadores raramente). Isso não está apenas dando mais trabalho aos desenvolvedores, está dando mais trabalho aos testadores.

Não há resposta certa aqui, mas algumas coisas que você deve considerar:

• Esses lançamentos de bugs (sem a nova funcionalidade) podem ir para os usuários? Nesse caso, sim, deve ser ramificado e testado e todos precisam aceitar isso como uma sobrecarga.

• É possível dividir a nova funcionalidade de tal maneira que ela exista em áreas totalmente separadas do aplicativo com os pedaços anteriores que foram trabalhados? Nesse caso, isso oferece opções - os testadores podem executar os testes de novo teste e as partes do teste de regressão do aplicativo. Não é o ideal, mas é um compromisso que pode funcionar e dar a eles o que eles querem.

• Quanto trabalho é realmente ramificar um lançamento? Geralmente é uma dor, mas a quantidade real de trabalho normalmente não é tão boa. Obviamente, você precisaria deles para confirmar que não é apenas mais trabalho para eles também (veja a primeira coisa que digo), mas já vi lugares que fazem esse trabalho.

• Existe uma maneira melhor de usar o controle de versão aqui? Algo como o Mercurial (consulte http://hginit.com/ - leia, é bom) ou outro sistema de controle de versão distribuído se ramifica e se funde de uma maneira diferente e pode permitir que você contorne o problema. Realmente, dê uma olhada, porque acho que pode ser a resposta para o seu problema.

Mas boa sorte, é uma dor. Acima de tudo, lembre-se de que o melhor caminho a seguir será muito dependente da sua empresa, produto e situação; portanto, pense nisso e não apenas puxe algo da prateleira e acredite que você deve segui-lo 100%.

Se os erros que você descreve são defeitos reais e não otimizações de design , sim, você deve realmente tentar corrigi-los antes de começar a trabalhar em novos recursos.

Se você criar novos recursos sobre os bugs conhecidos, estará criando um castelo de cartas. É provável que você desenvolva software quebradiço e imprevisível. Dependendo do nível de isolamento entre o código de buggy e seus novos recursos, os erros também podem afetar seus novos recursos. Em caso afirmativo, como você saberia se seus novos recursos funcionam corretamente?

Se você corrigir seus erros primeiro, terá uma base mais forte para quaisquer novos recursos adicionados.

Certamente, há momentos em que forças externas o pressionam a ir contra o seu melhor julgamento. Tente ajudar os tomadores de decisão a tomar uma decisão informada, onde eles estão cientes das consequências de qualquer curso de ação (ou seja, defeitos não resolvidos versus datas de entrega de recursos perdidas) e permita que eles exerçam seu julgamento. Às vezes, existem razões legais e financeiras em que um curso de ação, embora não seja preferível, é necessário.

Sempre tente corrigir erros antes de adicionar novos recursos!

Onde trabalho, lidamos com esse cenário em que cada release pretendido para produção tem sua própria ramificação. Por exemplo, vamos supor por um segundo que haverá um lançamento no final de junho e outro no final de julho. A versão de junho obteria sua própria ramificação e todos os recursos seriam adicionados e enviados ao controle de qualidade. Nesse ponto, começaríamos a trabalhar no lançamento de julho e na filial de junho. Quando o controle de qualidade encontra erros, os corrigimos na filial de junho e, depois que as correções são enviadas para o controle de qualidade, elas são mescladas na filial de lançamento de julho. Isso adiciona um pouco de sobrecarga para lidar com essas mesclagens, mas normalmente as mesclas são bastante simples. De vez em quando, é uma grande dor no que você sabe, mas isso só ocorre quando são feitas alterações no atacado e não devem ocorrer durante o ciclo de controle de qualidade (mas acontecem, mais do que eu gostaria de admitir). Mas com um bom conjunto de testes (unidade e integração), cobertura de código e todas as outras palavras-chave do TDD, os riscos são mitigados um pouco. Para ajudar, normalmente temos uma pessoa responsável por mesclar para cada projeto.