Ho cercato e ho trovato alcune domande che parlavano di test in relazione al branching delle funzionalità. La mia domanda è un po 'diversa.
Siamo un team di scrum * composto da 4 a 5 sviluppatori con un controllo di qualità dedicato all'interno della squadra. Facciamo lo sviluppo attivo su una famiglia di applicazioni con grandi quantità di codice legacy. La famiglia di applicazioni include un portale Web e anche applicazioni lato server che eseguono lavori, ecc.
Negli ultimi due anni abbiamo migliorato lentamente il prodotto con nuove funzionalità, architettura e pratiche migliorate. Cose come il codice che non è mai stato scritto con test unitari in mente o nella pratica, spostando webform in mvc / webapi, winforms in wpf e così via.
Durante quel periodo il CQ ha sviluppato una suite di test automatizzata per il sito Web, quindi, quando abbiamo terminato un ciclo di sprint e abbiamo preparato una versione per un gruppo QA separato per i test della scatola nera, non abbiamo dovuto prendere un paio di giorni con un foglio di calcolo per testare tutti i browser supportati per i difetti prima della nostra caduta al QA. I test automatici vengono eseguiti su ogni modifica al ramo del trunk e i passaggi / gli errori vengono visualizzati sul monitor per consentire al nostro team di vedere, le email TFS vengono inviate al team anche in caso di errore.
Usiamo la funzionalità di branching con il test QC e la correzione / lo sviluppo di nuovi test automatizzati nel ramo delle funzionalità sul loro computer locale, simile agli sviluppatori che scrivono il codice e testano il proprio lavoro. Quindi la funzionalità viene unita al nostro trunk una volta che il nostro QC accetta la nuova funzione.
Da quando abbiamo adottato la funzionalità branching e abbiamo mantenuto il trunk come codice rilasciabile, abbiamo assistito a una drastica riduzione dei bug restituiti dal QA o dalla produzione.
Ora il nostro manager diretto vuole cambiare il nostro processo per essere coerente con altri team di sviluppo. (che hanno più alti tassi di errori di QA e problemi di produzione che devo dire)
Il gestore vuole che il QC on-team non esegua più test e correzioni sulla propria macchina locale, ma piuttosto, una volta che lo sviluppatore ha completato il proprio lavoro e viene revisionato dal codice da un peer, verrà unito al trunk dove il eseguire test nell'ambiente di integrazione, correggere i test automatici o sviluppare nuovi test automatici per nuove funzionalità.
Dato che questo è stato menzionato dal manager, ho cercato di fare ricerche per vedere come i team di sviluppo esterni alla nostra azienda si avvicinano ai test. La mia opinione sull'argomento è stata che il controllo qualità dovrebbe essere testato e sviluppato nelle sezioni di funzionalità, quindi lasciare che i test automatizzati e i test unitari garantiscano che non si verifichino regressioni quando i rami di funzionalità vengono uniti nel ramo del tronco.
* Uso il termine 'mischia' con qualche esitazione dovuta ai cambiamenti nella compagnia, lentamente e silenziosamente, che si allontana dalla mischia e dalle pratiche agili, ma questa è una discussione per un altro giorno e thread.