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

Siamo un grande team (10-12 sviluppatori e 4 qa) che lavora su più progetti con lo stesso repository git. È un servizio web back-end basato su avvio a molla. Stiamo cercando una buona strategia di ramificazione e distribuzione. abbiamo anche un team di qa che assicura che le nostre funzionalità funzionino come previsto (in una certa misura privo di bug).

Dopo aver letto alcuni articoli, ho avuto la sensazione che il modello Gitflow avrebbe funzionato bene per noi. Ecco la mia domanda.

Dove dovrebbe essere testato il nostro team di controllo qualità?

1. nel caso in cui testassero sul ramo delle funzionalità, dove genereranno bug e lo sviluppatore lo risolverà e una volta superato il test QA ci uniremo allo sviluppo. e il QA eseguirà nuovamente i test di integeration nel ramo di sviluppo.
2. dovremmo unire tutte le funzionalità (dopo i test unitari e i test di base da parte dello sviluppatore) per sviluppare il ramo e lasciare il test qa da lì. correzioni e test accadranno anche in fase di sviluppo.

Sono curioso di sapere quale approccio ha funzionato bene per gli altri.

Il QA dovrebbe probabilmente essere testato due volte.

Il primo test dovrebbe riguardare le modifiche specifiche ed essere eseguito sul ramo delle funzionalità. Ciò consente al QA di verificare le modifiche specifiche e di vedere che la modifica particolare è completa come specificato e si comporta come previsto. Fornisce inoltre un'anteprima anticipata del secondo ciclo di test, che è ciò che conta davvero per il controllo qualità.

Provenendo dal mio background in vari ambienti regolamentati, il secondo test deve essere eseguito su un tag sul ramo di sviluppo che corrisponde a un rilascio, o sul ramo di rilascio, o forse sul ramo principale. Prima di un rilascio, il QA 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 quello 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 testerebbe. Le modifiche verrebbero apportate in un ramo di sviluppo, verificate a campione e quindi testate nuovamente in un nuovo tag nel ramo di rilascio. Questi tag nel ramo di rilascio corrisponderebbero ai candidati al rilascio.

Sto facendo alcune ipotesi qui. Innanzitutto, hai una copertura dei test basata sugli sviluppatori piuttosto decente. Idealmente, si tratterebbe di test automatici di unità e integrazione che gli sviluppatori eseguono e lo fanno prima di inviare qualsiasi codice su qualsiasi filiale al QA. Gli sviluppatori potrebbero anche voler fare alcuni test esplorativi sull'interfaccia utente per assicurarsi che le cose appaiano subito prima dei test di controllo qualità. In secondo luogo, esiste un buon coordinamento tra sviluppo e QA per pianificare le modifiche da incorporare per garantire un tempo sufficiente per il QA in base alle funzionalità.

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

Il problema essenziale è che ogni unione, compilazione o persino distribuzione può potenzialmente creare un bug. Maggiore è il livello della catena testata, prima si conoscono i bug, ma anche più volte è necessario 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 (presupponendo un'app Web) venga instradato a tali server tramite un modello di distribuzione blu / verde.

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

Se si verifica un ramo di rilascio in un ambiente qa, è possibile correre il rischio e ridurre i test in tempo reale solo per i test del fumo. e applicare correzioni di bug al ramo di rilascio. Ma non puoi valutare se una funzionalità è completa prima di creare una versione

Se si verifica lo sviluppo, si ottengono rami di funzionalità mini bug-fix. Le funzionalità vengono ancora unite prima di essere valutate, inoltre le funzionalità per la versione successiva possono scontrarsi con il test della versione corrente.

Se si testano i rami delle caratteristiche, sono necessari un milione di ambienti e è necessario orchestrare l'ordine delle fusioni e testare le approvazioni. oltre a numerosi test.

Dalla mia esperienza, consiglierei:

test rapido del ramo delle caratteristiche sulla macchina di sviluppo. assicurati solo che la sua funzionalità sia completa e che i tester / sviluppatori concordino sul significato dei requisiti.

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

Se tutte le funzionalità sono presenti ma il test non è terminato. ad es. lo sprint è completo. crea un ramo di rilascio e distribuiscilo in un secondo ambiente qa. Ciò consente la correzione dei bug / test sulla versione 1 per continuare contemporaneamente alle funzionalità per la versione 2.

(i devoti scrum diranno che dovresti mettere solo correzioni di errori nello sprint 2 ma siamo pratici)

Prove di fumo su distribuzione verde / blu dal vivo prima della commutazione. Questi sono molto importanti poiché rileverai errori di configurazione / ambientali che nessuno cerca realmente 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, adoro quel flusso di lavoro così tanto che ho creato uno strumento, Topico , che crea ed esegue automaticamente versioni usa e getta della tua app per ogni richiesta pull, ognuna con il suo unico URL di test. Ciò consente al team addetto al controllo qualità di testare i rami delle funzionalità in modo indipendente senza la necessità di creare un ambiente di test dinamico sulla propria macchina.

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

L'ho presentato a un paio di aziende e ha aiutato molto i nostri cicli di rilascio. Ora siamo in grado di pianificare accuratamente le versioni e siamo molto più bravi a capire cosa è probabile che arrivi alla prossima versione e cosa dovrà aspettare una versione futura. Ti dà solo molta più fiducia.