Opzioni di test paralleli nello sviluppo agile?

2

Ho letto alcune ottime risorse su Internet cercando di scoprire se la mia proposta iniziale di test è un'opzione valida. Quindi, per favore, qualsiasi consiglio o raccomandazione è apprezzata.

Attualmente disponiamo di un ambiente Dev e Test che finora ha soddisfatto abbastanza bene le nostre esigenze. Stiamo effettuando il test QA e UAT sullo stesso ambiente Test , tuttavia i nostri tester del QA si lamentano che avere entrambi i team test nello stesso ambiente sta causando problemi con la verifica degli script di test e posso vedere come questo potrebbe essere un problema. Tuttavia, non voglio aspettare che il QA venga eseguito prima che UAT ci dia un'occhiata, questo sembra essere contro lo sviluppo ideale dell'ideale.

Ho suggerito il seguente nuovo processo / architettura per consentire test QA e UAT paralleli:

Dispone di ambienti separati QA e UAT che consentono di testare in parallelo moduli / versioni differenti. Quindi possiamo avere QA testing ModuleA mentre UAT sta testando ModuleB .

Fondamentalmente è necessario / volere che testano moduli diversi (o lo stesso) in parallelo senza interferire l'uno con l'altro.

L'ho presentato ai nostri ingegneri di sistema (in modo che possano creare l'ambiente) e hanno affermato che UAT non dovrebbe mai accadere fino a quando non viene eseguito QA . Dalla mia comprensione del processo agile in questo momento, vorrei spingere ulteriormente il mio processo, ma forse trascuro qualcosa?

Grazie!

    
posta MisterIsaak 02.05.2012 - 22:43
fonte

2 risposte

2

I tuoi ingegneri di sistema hanno ragione; in quasi tutti gli SLDC, incluso Agile, ai tuoi utenti non deve essere fornita una versione del software per i test fino a quando il QA non lo illumina in verde.

Tuttavia, Agile consente lo sviluppo di software in sprint, e quando ogni sprint è completo e illuminato di verde dal QA, dovrebbe essere spinto a UAT per consentire agli utenti di interagire e dare feedback. Questo è paragonato a Waterfall o SLDC simili in cui i deliverable sono distanziati e l'utente non fa testare il software fino a quando lo sviluppo iniziale non è quasi completo.

Quindi, dico in questa situazione che entrambe le parti hanno ragione, ma tu hai più ragione. Avete bisogno di ambienti UAT e QA separati in modo che il QA possa testare ciò che stanno testando e UAT può testare ciò che il QA ha evidenziato per la versione UAT. Queste saranno quasi certamente versioni differenti del software; Il QA dovrebbe essere una o due iterazioni precedenti all'AT, e Dev dovrebbe probabilmente rimanere almeno uno sprint prima del QA.

    
risposta data 02.05.2012 - 23:17
fonte
1

Il fascicolo di consegna continua rende il punto qui che ha senso alludere 'software in ambienti paralleli in quanto offre una maggiore velocità e flessibilità nei test.

link

Questo suona bene sulla carta, ma l'ovvio lato negativo di questo è che potresti testare una build UAT che verrà rifiutata dal QA.

Per questo motivo, probabilmente mi collegherò con la pipeline seriale e aggiungerò un nuovo ambiente UAT, ma inserirò le build dopo il test del QA.

Dico questo perché l'ultima cosa che vuoi è entrare in una situazione in cui tu chiami UAT e firma X, e poi devi andare a vivere con build X + 1 che include solo una piccola correzione per soddisfare il team di QA.

    
risposta data 02.05.2012 - 23:25
fonte

Leggi altre domande sui tag