Como você obtém testes manuais completos pelo QA em um processo de desenvolvimento de fluxo git / hg?

5

Eu tenho uma pergunta sobre como trabalhar com testadores independentes que realizam testes manuais (e não sobre unidade automatizada e testes de regressão).

Em um processo de fluxo eu faço meu trabalho em um ramo de recursos até que eu esteja confiante de que funciona e eu não introduzi bugs. Eu me fundo do ramo de desenvolvimento para o meu recurso, tarde e muitas vezes, para garantir que eu não quebrei nada em fusões com outros trabalhos recentes. Às vezes, até faço isso novamente durante a fase de teste, para que o testador possa trabalhar com o instantâneo mais recente. Ainda assim, sempre há uma pequena janela de tempo após o teste em que o novo trabalho pode chegar - e em tempos de tráfego intenso - de outros recursos.

Isso significa que a fusão de volta ao ramo de desenvolvimento / liberação às vezes não é trivial, apesar de o tratarmos como deveria. (Às vezes é até mesmo iterativo: quando eu terminar de me certificar de que integrei corretamente um recurso que foi inserido, executando testes de regressão, verificando o código e fazendo alguns testes manuais, ainda outro entrou.)

A minha pergunta é, existe um fluxo de trabalho para desenvolvedores e testadores onde você não perde a rede de segurança dos testadores para a última etapa (mas também não precisa perguntar novamente para testar novamente) trabalhos)? Quais são as melhores práticas da indústria aqui? Se pudéssemos assegurar que os ramos não interfeririam uns com os outros, estaríamos bem, mas na prática temos conflitos às vezes.

Acrescentarei que tenho certeza de que não queremos fazer nossos testes principais na ramificação develop / release. Tem sido uma grande vitória e redutor de estresse desde que mudamos para o fluxo. Podemos facilmente adiar o trabalho de liberação que criou um problema ou levantou uma questão durante o teste. Em nossa prática de pré-fluxo, acabamos com emergências perto de um comunicado, onde foi encontrado um problema em que tivemos para lidar com urgência antes de liberar, porque o trabalho de um recurso não crítico já estava mesclado o ramo principal para testes.

    
por Joshua Goldberg 16.04.2015 / 17:42
fonte

2 respostas

1

Então, o seu problema não tem nada a ver com o teste, mas com a dificuldade de mesclar o ramo de recursos para desenvolver?

Eu diria por que você não quer executar seus testes no ramo de desenvolvimento? Você está testando o recurso individual que está desenvolvendo ou a integração de todos os seus e de outros recursos? Eu diria que o teste de ramificação de recurso é uma questão para o desenvolvedor, somente quando você pensa que está completo para se desenvolver e depois construir um pacote para a equipe de teste de lá (pessoalmente eu renomeia a ramificação 'develop' para ' integração'). Dessa forma, a equipe de teste tem uma versão atual do produto e pode testar recursos completos, enviando bugs para o desenvolvedor para corrigir e iterar o processo feature = merge-to-develop novamente até que o teste não encontre bugs nele, então o recurso está fechado. Quando a equipe de teste declara o produto testado, ele pode ser mesclado de desenvolver para mestre.

Normalmente, você também deseja realizar testes de controle de qualidade nos lançamentos, mas se o mestre for simplesmente uma cópia instantânea do desenvolvimento para fins de liberação, você poderá ignorar isso.

    
por 10.06.2015 / 12:26
fonte
-2

Se você está tendo fusões difíceis, provavelmente há algo errado com o modo como você está usando o git.

Parece que você tem ramificações que não são excluídas em um dia útil de criação delas. Isso é geralmente , se não universalmente , considerado uma má ideia . Na maioria das vezes, as ramificações git são mais uma etapa extra (opcional) no processo de preparação de commits, que proporciona um histórico limpo. Geralmente, evite usá-los para armazenar variantes de produtos, recursos, tickets ou qualquer outra coisa que tenha um significado fora desse histórico.

E, claro, se você corrigir esse problema, o problema do teste manual desaparecerá, já que os testadores naturalmente testarão a versão correta em primeiro lugar (ou seja, a configuração da tag pelo seu sistema de CI sempre que todos os testes automatizados forem aprovados) .

    
por 10.06.2015 / 16:29
fonte