Menu

Cosa dovrebbe sapere il tester QA sul processo di gestione del rilascio e della distribuzione

what qa tester should know about release

Prova Il Nostro Strumento Per Eliminare I Problemi

Nella riunione del nostro team di oggi, il manager ha verificato con tutti il ​​proprio disponibilità per l'esecuzione del test . Ha detto che 'il codice sarà pronto per QA entro domani mattina'. Cosa intendeva quando ha detto che 'il codice sarà pronto', significa che gli sviluppatori scriveranno il codice in ambiente QA stasera?

In realtà voleva dire che la distribuzione è pianificata per essere eseguita di notte e il nuovo codice verrà distribuito nell'ambiente di controllo qualità per i test.

Molti di voi ora potrebbero chiedersi, cos'è la distribuzione e cosa ci fanno veramente?

processo di gestione del rilascio e della distribuzione per qa

Cosa imparerai:

Processo generale di gestione del rilascio e della distribuzione e importanza per il team di controllo qualità

  • Perché manteniamo davvero ambienti diversi?
  • Come viene migrato il codice da un ambiente all'altro?

Tratterò i seguenti argomenti in questo articolo

  1. Perché è importante che i tester siano a conoscenza del processo di rilascio e distribuzione?
  2. Ambienti diversi
  3. Cosa intendi per Build e Deployment?
  4. Distribuzione pianificata e di emergenza
  5. Elenco di controllo QA - Prima e dopo la distribuzione

# 1. Perché è importante che i tester siano a conoscenza del processo di distribuzione?

Il nostro compito principale di esecuzione del test dipende dal successo della distribuzione. Se il team di distribuzione ha affrontato sfide e ha riscontrato diversi problemi e non è stato in grado di distribuire correttamente il codice, sicuramente indicherà che il team QA identificherà molti bug che potrebbero essere legati all'ambiente o al processo di distribuzione.

software desktop remoto per Windows 7
  • Se i tester sono a conoscenza del processo di distribuzione, capiranno l'importanza di completare le loro attività entro il periodo di tempo pianificato.
  • I tester avranno un'idea se il problema è davvero un bug di funzionalità o qualcosa causato durante la distribuzione, ad esempio un tester è assegnato per testare la funzione di report ma quando tenta di accedere al sito Web, viene visualizzato un errore che significa che l'ambiente non è attivo , tali questioni non possono essere considerate come questioni funzionali ma ambientali. Se il tester è a conoscenza della distribuzione, può correlare il problema a un problema di distribuzione.
  • Molti non problemi potrebbero essere evitati se i tester fossero veramente consapevoli dell'elenco che è stato distribuito. A volte capita di testare e segnalare un problema per aree che non sono mai state distribuite.

# 2. Ambienti diversi

Ambienti diversi

Nella classificazione precedente ho trattato i 4 ambienti più importanti seguiti dalla maggior parte delle organizzazioni, tuttavia, molti client mantengono molti più ambienti come staging, pre-staging ecc. Inoltre, la convenzione di denominazione potrebbe differire.

  • DEV - L'ambiente di sviluppo è quello creato e gestito dal team di sviluppo per la scrittura del codice. L'accesso a questo ambiente è concesso solo al team di sviluppo. Di solito il team QA non ha accesso a questo ambiente. Questo ambiente viene utilizzato principalmente dal team di sviluppo per i test di unità.
  • QA - L'ambiente di controllo qualità è quello in cui si svolgono effettivamente i test. Questo ambiente è di proprietà del team QA. Il team DEV non ha accesso a questo ambiente. Dopo il completamento della progettazione e della codifica, il codice viene spostato nell'ambiente di controllo qualità per consentire al team di controllo qualità di condurre l'esecuzione del test.
  • UAT - Test di accettazione dell'utente è un ambiente in cui il test viene condotto dagli utenti aziendali. Questo viene fatto dopo che il test del sistema è stato completato. L'intenzione principale è testare il sistema dal punto di vista aziendale. L'accesso a questo ambiente è consentito solo agli utenti aziendali. Tuttavia, in alcune occasioni cercano assistenza QA, in tali circostanze, al team QA viene concesso un accesso temporaneo all'ambiente.
  • PROD - L'ambiente PROD è l'ambiente live effettivo che è esposto agli utenti reali e nessuno dei team DEV e QA ha accesso in lettura / scrittura a questo ambiente. I team di supporto alla produzione vengono mantenuti per risolvere i problemi relativi all'ambiente di produzione.

Leggi anche=> Come preparare in modo efficace il 'banco di prova' e ridurre al minimo i difetti dell'ambiente di prova

# 3. Cosa intendi per Build and Deployment

Una build contiene principalmente il pacchetto compilato che potrebbe includere l'eseguibile bat, exe, le librerie come dll, lib e archivi come i file zip. Il team di sviluppo crea la build e la fornisce al team di distribuzione per l'installazione.

La compilazione del codice sorgente è principalmente curata dal team di sviluppo e dopo aver generato la build, lo posizionano in una posizione specificata che è accessibile dal team di distribuzione per la distribuzione in un ambiente diverso.

Una volta che la build è stata distribuita, il team QA viene avvisato di eseguire il costruire test di verifica (BVT) e se ha successo, la squadra esegue il resto del test funzionali .

In alcune organizzazioni in cui non mantengono un team di distribuzione separato, il team di sviluppo fornisce la build al QA e il team QA stesso completa la distribuzione. Esiste un grosso rischio, in questi casi le risorse di controllo qualità dovrebbero essere tecnicamente valide per comprendere il processo di distribuzione generale della build e dovrebbero anche sapere come rimediare se si verifica un problema.

Le build vengono mantenute utilizzando numeri come 1.0.01 o 1.0.03. Quindi, è possibile che la build 1.0.01 esegua la DLL v0.2 e la build 1.0.03 possa eseguire la DLL v0.5. Diventa importante per il team di controllo qualità assicurarsi che la build corretta sia distribuita nell'ambiente prima dell'inizio del test. È sempre una buona idea tenere traccia delle modifiche fornite come parte di ogni build.

Mantenere un team di distribuzione separato è sempre una buona pratica in quanto aiuta a spostare senza problemi il codice da un ambiente all'altro.

La distribuzione è un processo attraverso il quale il codice / build viene spostato da un ambiente a un altro. La maggior parte dell'organizzazione in questi giorni segue un canale appropriato per la distribuzione e mantiene un team separato che si occupa di tutto ciò.

Build e distribuzione

convertitore semplice gratuito da youtube a mp3

Prima del giorno della distribuzione, si incontra un team composto da sviluppatore, responsabile dello sviluppo, ingegnere della distribuzione, responsabile del test e altri stakeholder aziendali. Durante l'incontro, allo sviluppatore viene solitamente chiesto di descrivere il suo cambiamento. Di solito devono compilare un modulo particolare con i dettagli sulle modifiche e sul piano di ripristino.

Nel caso in cui alcuni dettagli vengano persi, le modifiche non vengono approvate per la distribuzione. Il team decide quindi se la modifica può far parte della distribuzione del giorno successivo. Al responsabile del test QA viene richiesta l'approvazione per garantire che la modifica non influisca su nessuno dei test esistenti. Nella riunione vengono pianificati gli elementi di distribuzione finali.

L'elenco approvato viene elaborato dal team di distribuzione il giorno della distribuzione. Il team esegue una serie di programmi come definito in ogni modulo delle modifiche (fornito dagli sviluppatori) e quindi invia la comunicazione al completamento della distribuzione.

Il messaggio Distribuzione completata fornisce un'indicazione al team QA che le modifiche / il nuovo codice sono pronti per essere testati.

È responsabilità del team di distribuzione spostare le modifiche da DEV a QA. Al termine del test QA, il codice viene spostato in UAT. Lo spostamento dei dati PROD è la parte più importante e deve essere fatto durante le ore non lavorative, perché durante la distribuzione l'ambiente deve essere disattivato e deve essere fatto con la massima cura poiché ciò potrebbe avere un grave impatto sul business.

La maggior parte delle distribuzioni di Prod vengono eseguite a tarda notte quando le possibilità che l'ambiente venga colpito dagli utenti finali sono minori.

# 4. Distribuzione pianificata e di emergenza

Ogni organizzazione mantiene un calendario di distribuzione. Molti clienti seguono l'implementazione una volta alla settimana e molti scelgono una distribuzione bisettimanale, affermano che l'implementazione pianificata dovrebbe avvenire solo il martedì o potrebbe avvenire il martedì e il venerdì. I giorni per la distribuzione possono cambiare se il giorno pianificato per la distribuzione cade in un giorno festivo.

Nella sezione precedente, ho coperto il processo seguito per qualsiasi distribuzione pianificata .

Le distribuzioni pianificate possono avere la propria sfida. Pensa a un caso in cui il nuovo codice viene distribuito nell'ambiente QA e durante il test di integrità il team identifica un difetto di blocco e il test deve essere interrotto. Il team di test attende una settimana fino alla prossima distribuzione?

Per gestire tali situazioni, vengono eseguite correzioni di emergenza e implementazioni in cui il team di distribuzione non deve attendere fino al giorno di implementazione pianificato. Devono seguire e cercare l'approvazione anche per le implementazioni di emergenza, ma queste approvazioni di solito avvengono rapidamente e le nuove modifiche possono essere implementate nell'ambiente di controllo qualità lo stesso giorno o il prima possibile.

# 5. Elenco di controllo QA - Prima e dopo la distribuzione

Prima della distribuzione -

L'intero fase di progettazione del test avviene prima che il codice venga effettivamente spostato nell'ambiente. È l'esecuzione del test che dipende dalla disponibilità del codice nell'ambiente QA mentre il team di distribuzione lavora per ottenere il codice distribuito in QA, il team QA dovrebbe assicurarsi di aver completato le seguenti attività:

Dopo la distribuzione -

miglior anti spyware gratuito per windows 10

Dopo la distribuzione, la prima cosa che facciamo come team QA è iniziare con il nostro test di sanità mentale. Ma prima di iniziare il nostro test di sanità mentale, dovremmo assicurarci che quanto segue sia stato curato:

  • Il team di controllo qualità dovrebbe aver ricevuto una notifica dal team di distribuzione sulla corretta implementazione e pronto per il controllo qualità.
  • Il team QA dovrebbe tenere traccia della build distribuita.
  • Assicurati che il team QA abbia l'elenco delle modifiche implementate correttamente e anche degli elementi non distribuiti anche se erano stati pianificati. Può accadere che il team di distribuzione non possa eseguire il deployment a causa di dettagli mancanti, ecc.

Conclusione

Spero che l'articolo precedente ti abbia dato un'idea del processo di gestione del rilascio e della distribuzione generale seguito come parte del ciclo di sviluppo software complessivo. Questa era solo una procedura generica seguita nella maggior parte delle organizzazioni, tuttavia molti clienti hanno protocolli diversi.

Autore : Questo fantastico articolo è stato scritto dal membro del team STH Priya R.

Hai trovato utile questo processo? Comunicaci il processo di distribuzione che segui nella tua organizzazione.

Lettura consigliata

^