Come si ottiene un test manuale completo da parte del QA in un processo di sviluppo del flusso git / hg?

5

Ho una domanda su come lavorare con tester indipendenti che eseguono test manuali (non su unità automatizzate e test di regressione.)

In un processo di flusso faccio il mio lavoro su un ramo di funzionalità finché non sono sicuro che funzioni e non ho introdotto bug. Mi unisco dal ramo di sviluppo alla mia funzione, in ritardo e spesso, per assicurarmi di non aver infranto nulla in combinazione con altri lavori recenti. A volte lo faccio anche durante la fase di test, in modo che il tester possa lavorare con l'istantanea più recente. Eppure, c'è sempre una piccola finestra di tempo dopo aver provato dove può fare il nuovo lavoro - e in tempi di traffico elevati - venire da altre funzionalità.

Ciò significa che l'unione con il ramo di sviluppo / rilascio a volte non è banale, nonostante lo trattiamo come dovrebbe essere. (A volte è persino iterativo: quando ho finito, assicurandomi di aver integrato correttamente una funzione che è stata inserita, eseguendo i test di regressione, controllando il codice e facendo test manuali, ne è entrato un altro ancora.)

La mia domanda è, c'è un flusso di lavoro per sviluppatori e tester in cui non si perda sulla rete di sicurezza dei tester per l'ultimo passaggio (ma speriamo anche che non ci sia bisogno di chiedere ancora e ancora per i test ripetuti testati lavoro)? Quali sono le migliori pratiche del settore qui? Se potessimo assicurare che i rami non interferiscano l'uno con l'altro, staremmo bene, ma in pratica otteniamo conflitti a volte.

Aggiungerò che sono sicuro che non vogliamo fare i nostri test principali sul ramo di sviluppo / rilascio. È stata una grande vittoria e un riduttore di stress da quando siamo passati al flusso. Possiamo facilmente rimandare il rilascio del lavoro che ha creato un problema o sollevato una domanda durante il test. Nella nostra pratica di pre-flusso, siamo finiti con le emergenze in prossimità di un rilascio, in cui è stato trovato un problema che avevamo per trattare con urgenza prima di rilasciarlo perché il lavoro di una funzione non critica era già fuso in il ramo principale per i test.

    
posta Joshua Goldberg 16.04.2015 - 17:42
fonte

2 risposte

1

Quindi il tuo problema alla fine non ha nulla a che fare con i test, ma il problema delle difficili fusioni del tuo ramo di funzionalità torna a svilupparsi?

Direi perché non vuoi sottoporre i tuoi test al ramo di sviluppo? Stai testando la singola funzione che stai sviluppando o l'integrazione completa delle tue e di altre funzionalità? Direi che il test delle feature branch è una questione per lo sviluppatore, solo quando pensi che sia completo ti unisci per sviluppare e poi costruisci un pacchetto per il team di test da lì (personalmente rinominerei il branch "develop" in " integrazione'). In questo modo, il team di test ha una versione corrente del prodotto e può testare le funzionalità completate, restituendo bug allo sviluppatore per correggere e iterare nuovamente il processo feature = merge-to-develop finché il test non trova bug, quindi la funzione è chiuso. Quando il team di test dichiara il prodotto testato, può essere unito dallo sviluppo al master.

In genere, ti consigliamo di eseguire test di controllo qualità anche nelle versioni, ma se il master è semplicemente una copia snapshot di sviluppo a scopo di rilascio, puoi saltare questo passaggio.

    
risposta data 10.06.2015 - 12:26
fonte
-2

Se di solito si incontrano difficoltà, probabilmente c'è qualcosa di sbagliato nel modo in cui si sta usando git.

Sembra che tu abbia dei rami che non vengono cancellati entro un giorno lavorativo dalla loro creazione. Questo è generalmente , se not universally , considerato una cattiva idea . La maggior parte delle volte, i rami git sono un ulteriore passaggio (facoltativo) nel processo di commit-staging che ti fa ottenere una bella storia pulita. In generale, evita di utilizzarli per memorizzare varianti di prodotti, funzioni, biglietti o qualsiasi altra cosa che abbia un significato al di fuori di tale cronologia.

Ovviamente, se risolvi il problema, il problema del test manuale scompare, poiché i tester testano naturalmente la versione corretta in primo luogo (ovvero l'impostazione dei tag dal sistema CI ogni volta che passano tutti i test automatici) .

    
risposta data 10.06.2015 - 16:29
fonte

Leggi altre domande sui tag