Quale modello di branching Git da scegliere dipende completamente dal processo di sviluppo che si desidera utilizzare. Il famoso "flusso git" che hai menzionato riguarda i prodotti che hanno versioni chiare e funzionalità di grandi dimensioni sviluppate in modo indipendente. Il ramo di sviluppo rappresenta quelle caratteristiche che dovrebbero far parte della prossima versione.
Questo apre due opportunità in cui è possibile eseguire il QA: il QA può essere fatto orientato al rilascio o orientato alle funzionalità.
In un processo di controllo qualità orientato alla versione, viene avviato un ramo di rilascio e QA lo esamina. Se il QA trova dei problemi, puoi correggerli sul ramo di rilascio che verrà successivamente reimmesso nel ramo di sviluppo. Ciò presuppone che non ci saranno problemi enormi che comporterebbero il rifiuto totale di una funzione, quindi è necessario eseguire alcuni test molto prima.
Un processo di QA orientato alla versione può funzionare molto bene con versioni semi-frequenti ma regolari, ad esempio una versione al mese. Gli sviluppatori trascorrono un mese a preparare la prossima versione. Quindi il QA ha un mese di revisione della versione. Durante questo periodo, eventuali problemi riscontrati vengono risolti. Alla fine del mese, la versione può essere rilasciata e QA ottiene la versione successiva dagli sviluppatori. Ciò evita il tempo di inattività sia per il controllo della qualità che per gli sviluppatori, al costo di allungare il tempo di ciclo tra l'inizio di una funzione e il suo rilascio.
In un processo di controllo qualità orientato alle funzionalità, la funzionalità viene revisionata quando viene unita al ramo di sviluppo. Quindi lo stato del ramo di sviluppo è sempre QA'd e pronto per il rilascio. Questo espande il rischio per un periodo di tempo più lungo e consente di rifiutare una funzione non ancora presente prima di essere inclusa in una versione, senza ritardare le funzionalità non correlate.
Lo svantaggio è che puoi QA al massimo una funzione alla volta, oppure potresti perdere l'interferenza tra diverse funzionalità. Questo potrebbe essere un collo di bottiglia di un processo e scoraggia le funzionalità piccole e facilmente revisionabili.
Alcune attività di controllo qualità possono essere eseguite anche prima che qualcosa venga unito. Per esempio. se una funzionalità comporta modifiche all'interfaccia utente, i test UX focalizzati possono essere eseguiti separatamente per quella funzione molto tempo prima che possa essere rilasciato. Ciò richiede che gli sviluppatori possano chiedere assistenza QA quando pensano che sia utile, senza dover navigare in nessuna burocrazia. Ciò richiede anche che il QA sia sufficientemente flessibile per soddisfare queste richieste.
Tutte queste strategie possono e devono essere combinate. Più ti avvicini a un rilascio, più il QA è più importante, ma i feedback precedenti sono più efficienti in termini di costi perché le modifiche possono essere apportate più facilmente.
Si noti che l'automazione e gli utensili possono avere enormi vantaggi qui. Ciò accelera e ottimizza il processo, che può avere un effetto esponenziale sulla produttività. Ciò inizia con la semplice automazione di build e deployment in modo che il QA possa eseguire facilmente il software di qualsiasi ramo che vorrebbero rivedere. L'automazione del test può liberare il controllo qualità per svolgere attività di alto livello più preziose, come la convalida delle funzioni, il test del fumo, i test esplorativi manuali e lo sviluppo di nuovi scenari di test. Questo non è propriamente specifico per qualsiasi processo o schema di ramificazione, ma una solida strumentazione può rendere più facile coinvolgere il QA in precedenza nel processo di sviluppo.