Dove dovrebbe fare il test del team di QA nel modello di ramificazione di Gitflow

Il QA dovrebbe probabilmente essere testato due volte.

Il primo test dovrebbe riguardare le modifiche specifiche e fatto sul ramo della funzione. Ciò consente al QA di testare le modifiche specifiche e di vedere che il cambiamento particolare è completo come specificato e si comporta come previsto. Fornisce anche un'anteprima anticipata per il secondo round di test, che è ciò che conta davvero per il controllo qualità.

Venendo dal mio passato in vari ambienti regolamentati, il secondo test deve essere fatto su un tag sul ramo di sviluppo che corrisponde a un rilascio, il ramo di rilascio o forse il ramo principale. Prima di un rilascio, il controllo qualità dovrebbe testare il codice completo e completo che verrà distribuito prima di essere distribuito e dovresti essere in grado di affermare che tutto ciò che è stato testato dal QA è esattamente identico a ciò che viene distribuito alla produzione. La mia preferenza sarebbe che dopo un blocco del codice, un tag venga applicato al ramo di rilascio e il QA lo verifichi. Le modifiche verrebbero eseguite in un ramo di sviluppo, verificato in loco e quindi testate nuovamente in un nuovo tag nel ramo di rilascio. Questi tag sul ramo di rilascio corrisponderebbero ai candidati al rilascio. Un candidato approvato per il rilascio verrebbe fuso in master e quindi identificato come versione rilasciata.

Sto facendo alcune supposizioni qui. Innanzitutto, hai una copertura di test abbastanza decente basata sugli sviluppatori. Idealmente, questo sarebbe un test di integrazione e di unità automatizzato che gli sviluppatori eseguono e lo fanno prima di inviare qualsiasi codice su qualsiasi ramo al QA. Gli sviluppatori potrebbero anche voler eseguire alcuni test esplorativi sull'interfaccia utente per assicurarsi che le cose sembrino giuste prima del test del QA. In secondo luogo, esiste un buon coordinamento tra lo sviluppo e la garanzia della qualità per pianificare le modifiche che vengono incorporate per garantire un tempo sufficiente per il controllo qualità in base alle funzionalità.

Ottima domanda. Non penso che ci sia una risposta corretta "ufficiale" a questo. Dipende da quanto velocemente puoi testare.

Il problema essenziale è che ogni fusione, compilazione o distribuzione può potenzialmente creare un bug. L'ulteriore "up" della catena testate, prima saprete dei bug, ma anche più volte dovrete ripetere il test.

Per essere certi di aver testato il software utilizzato dai clienti, è necessario testare la distribuzione live prima che il traffico dei clienti (supponendo un'app Web) venga indirizzato a tali server tramite un modello di distribuzione blu / verde.

Ma ovviamente è un po 'tardi nella giornata per essere la prima volta che controlli il codice!

Se provi un ramo di rilascio in un qa env, puoi correre il rischio e ridurre i test dal vivo solo per testare il fumo. e applicare correzioni di bug al ramo di rilascio. Ma non puoi valutare se una funzionalità è completa prima di creare un rilascio

Se esegui test di sviluppo, ottieni mini rami di bug-fix-feature. Le caratteristiche sono ancora unite prima di essere valutate, inoltre le funzionalità per la prossima versione possono scontrarsi con il test della versione corrente.

Se si testano le filiali di feature, è necessario disporre di un milione di ambienti e devono orchestrare l'ordine di unioni e test delle segnalazioni. oltre a un nuovo test.

Dalla mia esperienza consiglierei:

test rapido del ramo di funzione sulla macchina di sviluppo. assicurati che la sua funzionalità sia completa e che i tester / sviluppatori siano d'accordo su cosa significano i requisiti.

Test giornalieri / test automatici sul ramo dev distribuito ai server qa. Ti consente di testare tutte le funzionalità insieme e di dire quando sei pronto per il rilascio.

Se tutte le funzionalità sono presenti ma il testing non è terminato. per esempio lo sprint è completo. creare un ramo di rilascio e distribuirlo in un secondo ambiente qa. Ciò consente di correggere / testare bug sulla versione 1 per continuare contemporaneamente alle funzionalità per la versione 2.

(i devoti di Scrum diranno che dovresti mettere solo correzioni di bug in sprint 2 ma che sia pratico)

Test dei fumi sulla distribuzione verde / blu dal vivo prima di passare. Questi sono super importanti in quanto raccogli errori di configurazione / ambientali che nessuno cerca davvero durante lo sviluppo.

Sono d'accordo con Thomas Owens. Probabilmente dovresti provare due volte. Una volta sul ramo della funzione prima che venga unito e una volta sul ramo principale prima del rilascio.

In effetti, amo tanto il flusso di lavoro che ho creato uno strumento, Topico , che crea automaticamente e esegue versioni usa e getta della tua app per ogni tiro richiesta, ognuno con il proprio URL di test unico. Ciò consente al team addetto al QA di testare i rami di funzionalità in isolamento senza la necessità di disporre di una sorta di ambiente di test dinamico installato sulla propria macchina.

Questo approccio significherà che solo il codice che ha superato i test umani arriverà mai al tuo ramo principale, mantenendo così la sua integrità.

L'ho presentato ad un paio di società e ha aiutato molto il nostro ciclo di rilascio. Ora siamo in grado di pianificare con precisione le versioni e siamo in grado di capire meglio cosa è probabile che arrivino alla prossima versione e cosa dovrà aspettare per una versione futura. Ti dà molta più sicurezza.