Come eseguire i test post-rilascio in modo efficace e ridurre al minimo l'impatto del rilascio sui client attivi

how perform post release testing effectively

Quando ho iniziato la mia carriera come QA, lavoravo con un'azienda che offriva i suoi prodotti come SaaS. Le versioni di produzione erano fondamentali e c'era la possibilità di influenzare la funzionalità per i client live.

Man mano che la nostra base di clienti cresceva, per gestire il rischio e ridurre al minimo l'impatto del rilascio sui clienti attivi, il team QA ha adottato la pratica di test post-rilascio.

Era tutto nuovo per me e avevo così tante domande e dubbi nella mia mente:

• Cos'è il test post-rilascio?
• Ho testato tutto correttamente, perché dobbiamo fare dei test post-rilascio?
• Provo di nuovo tutto da capo? Cosa devo fare esattamente nella verifica post-rilascio?
• Cosa succede se trovo un problema? Eccetera.

Sono felice di ammettere di aver trovato tutte le mie risposte nelle mie prime versioni di produzione.

Qui sto condividendo questa conoscenza con tutti voi. Ho scelto di scrivere l'articolo in un formato di domanda e risposta per mostrarti il ​​modo in cui ho scoperto le risposte.

Cosa imparerai:

• Che cos'è la verifica del rilascio post-produzione?
• Quali compiti e attività sono inclusi nella fase di verifica post-rilascio?
• Devo provare di nuovo tutto da capo?
• Come formulo la strategia di verifica del rilascio post produzione?
• Chi crea il piano di test del rilascio post produzione?
• Chi approva il piano di test del rilascio post produzione?
• Quando creo il piano di verifica del rilascio post produzione?
• Ho completato la verifica del rilascio post produzione. Qual è il prossimo?
• Cosa succede se trovo un problema?
• Cos'altro devo sapere sul processo di verifica del rilascio post produzione?
• Conclusione:
• Lettura consigliata

Che cos'è la verifica del rilascio post-produzione?

Per definizione, Inviare si intende Dopo , Rilascio di produzione si riferisce alla distribuzione agli ambienti LIVE / di produzione e Verifica include assicurandosi che le funzionalità rilasciate soddisfino i requisiti .

Lettura consigliata=> Come preparare in modo efficace un 'ambiente di test' prima di iniziare il test

L'obiettivo è verificare il rilascio su ambienti di produzione / LIVE.

cos'è un buon downloader di musica per Android

Ma poi sorgono le domande:

• Perché è necessario eseguire test di rilascio post produzione quando ho testato tutto in un ambiente QA?
• Perché prevediamo che si verifichino problemi in produzione anche se abbiamo testato a fondo il rilascio nell'ambiente di test?

Ci sono molte ragioni per cui avremmo avuto problemi con la produzione anche se avremmo potuto seguirli completamente Processo di garanzia della qualità (cioè pianificazione dei test , revisione del piano di test, ciclo di test, test di regressione eccetera.)

Motivi per cui avremmo problemi con la produzione:

1) Emissione di dati - I dati disponibili sugli ambienti di produzione e di test possono variare. Ciò può causare la perdita di alcuni problemi di caso d'angolo negli ambienti di test.

2) Problema di distribuzione - Se la tua azienda ha un processo di distribuzione della build manuale, la tua versione potrebbe essere più soggetta a problemi di distribuzione. Alcuni scenari comuni possono essere, configurazione o impostazioni del sito mancanti, script DB mancanti, ordine di distribuzione non seguito (prima il codice, poi DB ecc.), Dipendenze installate in modo errato, ecc.

Leggi anche=> Cosa dovrebbe sapere il QA Tester sul processo di distribuzione

3) Aree di impatto non identificate - Ci possono essere alcuni scenari per i quali le aree colpite potrebbero non essere state identificate correttamente e completamente dal team.

Per esempio, considera un SaaS ambiente.

Se il team non ha identificato l'impatto di una tabella DB rifattorizzata su un client utilizzando uno schema di tabella precedente (ad es. Perdita di dati, necessità di migrazione dei dati prima del rilascio, ecc.), ecc. È meno probabile che questo problema si verifichi per progetti ben pianificati con requisiti precisi. Ma la possibilità esiste ancora.

4) Aree di impatto sconosciuto - Ciò può verificarsi se l'ambito e le aree interessate del rilascio non sono noti. Ad esempio, in un'azienda con diversi prodotti software che condividono DB e architettura comuni, anche una piccola modifica può interrompere la funzionalità di molti prodotti.

Quali compiti e attività sono inclusi nella fase di verifica post-rilascio?

Le attività e le attività di rilascio post produzione generalmente includono:

• Verifica del rilascio post produzione
• Segnala i risultati della verifica
• Segnalazione di eventuali problemi riscontrati in produzione
• Pulizia dei dati di verifica dopo il rilascio
• Monitoraggio post rilascio (se applicabile)

Devo provare di nuovo tutto da capo?

Non necessariamente. Ciò dipende dalla build da rilasciare e dall'analisi dell'impatto.

È necessario eseguire test dettagliati durante il normale ciclo di controllo qualità. La verifica post-rilascio deve essere eseguita seguendo un piano di test di verifica post-produzione del rilascio che dovrebbe essere un derivato del piano di test completo per quella versione.

Come formulo la strategia di verifica del rilascio post produzione?

La pianificazione della verifica del rilascio post-produzione deve essere eseguita in modo simile alla normale pianificazione dei test.

La strategia dovrebbe essere sulla stessa linea del flusso di test seguito durante il ciclo di QA. È importante includere i passaggi più importanti e critici che consentono la massima copertura delle funzionalità.

qual è il miglior firewall gratuito

Una buona strategia di rilascio post produzione dovrebbe:

• Includere passaggi per testare nuove funzionalità e le principali funzionalità esistenti
• Verifica le principali aree di impatto
• Consenti la massima copertura delle funzionalità
• Facoltativo: includi eventuali bug critici rilevati nell'ambiente di test
• Facoltativo: includi la priorità dei casi di test

Chi crea il piano di test del rilascio post produzione?

Ciò varierà tra le società e dipenderà dalla struttura organizzativa.

Facciamo un esempio della seguente organizzazione del team QA.

In questo scenario, il QA che lavora sul progetto specifico formulerà il piano di test di rilascio post produzione iniziale.

Chi approva il piano di test del rilascio post produzione?

Ciò varierà tra le società e dipenderà dalla struttura organizzativa.

Sempre considerando la stessa struttura organizzativa mostrata nella domanda precedente, il piano di test del rilascio post produzione dovrebbe essere rivisto e approvato da il Test Lead o il QA Manager .

Quando creo il piano di verifica del rilascio post produzione?

Il piano di test del rilascio post produzione può essere creato in qualsiasi momento durante il ciclo di sviluppo del software dopo che i requisiti, l'ambito di sviluppo e le aree di impatto sono stati identificati e bloccati. Di solito è più facile per il QA creare il piano di test del rilascio post produzione a metà dello sprint. Ciò garantisce che ci sia tempo sufficiente per la revisione e l'approvazione.

È una buona pratica includere questo piano di test insieme a qualsiasi file QA formale firmare i documenti prima che il progetto entri nella fase di distribuzione e rilascio.

Ho completato la verifica del rilascio post produzione. Qual è il prossimo?

Dopo che la verifica post-rilascio è stata completata, i passaggi successivi sarebbero

1) Comunicazione dei risultati della verifica - I risultati della verifica devono essere comunicati alle parti interessate, inclusi eventuali problemi riscontrati durante la produzione.

2) Segnalazione di eventuali problemi riscontrati sulla produzione nello strumento di gestione dei difetti - Per facilitare l'analisi della causa principale e tracciabilità .

3) Pulizia dei dati di verifica dopo il rilascio - La pulizia dei dati deve essere eseguita dopo il completamento della verifica.

Per esempio, considera un rilascio per un'applicazione di e-commerce e diciamo che hai creato un ordine di prova in produzione. Questo ordine di prova deve essere annullato al termine della verifica.

4) Monitoraggio del rilascio post produzione (se applicabile) - Alcune versioni richiedono il monitoraggio in produzione.

Per esempio, se il team ha apportato miglioramenti per migliorare i tempi di caricamento della pagina nell'applicazione, questo dovrebbe essere monitorato per un certo periodo di tempo per garantire che il miglioramento sia stato effettivamente visto dopo il rilascio. La persona o le persone responsabili del monitoraggio dovrebbero essere chiaramente identificate e comunicate a.

Cosa succede se trovo un problema?

Eventuali problemi devono essere segnalati nel file Strumento di gestione dei difetti e comunicati agli stakeholder. Se vengono rilevati problemi critici sulla produzione, la comunicazione dei risultati deve avvenire immediatamente poiché è necessario prendere una decisione se è necessario eseguire il rollback della build per indagare ulteriormente sul problema.

È importante che tutti i problemi rilevati siano segnalati nello strumento di tracciamento dei difetti. Si consiglia di sollevarli come tipo di problema separato (ad esempio bug di post produzione) per mostrare la separazione dai normali bug del ciclo di controllo qualità. Questi problemi possono essere filtrati facilmente se necessario ai fini dell'analisi della causa principale.

Cos'altro devo sapere sul processo di verifica del rilascio post produzione?

Oltre all'effettivo processo, piano e strategia di verifica del rilascio post produzione, di seguito sono riportati alcuni suggerimenti:

• È importante stabilire aspettative chiare in merito all'ambito e allo scopo della verifica successiva al rilascio. Gli stakeholder (interni ed esterni) dovrebbero essere consapevoli di quanto segue
  • Il team non può testare tutto in produzione
  • Il team non può spremere giorni di test in poche ore riservate per la verifica post-rilascio

Pertanto, il test sulla produzione sarebbe essenzialmente basato sul piano di test di rilascio post produzione approvato.

Limitazioni:

Occorre prestare la dovuta attenzione mentre si decide la portata dei test di rilascio post-produzione. Ci sono limitazioni a cosa e quanto possiamo effettivamente testare sulla produzione. L'ambiente di produzione ha dati del cliente in tempo reale e deve essere gestito con molta attenzione. È necessario eseguire una pianificazione aggiuntiva per le modifiche che comportano la migrazione, l'aggiornamento, la cancellazione dei dati, ecc.

Esempio 1): Per un'azienda di eSurvey, se il test prevede la risposta e l'invio del sondaggio, il QA dovrebbe inviare una richiesta per eliminare il sondaggio di prova dopo la verifica in modo da non influire sui dati di raccolta del sondaggio del cliente e sulle loro statistiche.

E xample # 2): Per una società di e-commerce, supponiamo che un processo SQL di aggiornamento dei prezzi venga eseguito ogni giorno a mezzanotte e carichi il prezzo definitivo sul sito web. Non possiamo eseguire questo SQL su richiesta, più volte ai fini della verifica post-rilascio poiché ciò potrebbe causare il push dei dati non finalizzati alla produzione.

Inoltre, può aumentare le possibilità di Deadlock DB e un elevato consumo di CPU e risorse di memoria durante le ore lavorative di punta, che può influire sulle prestazioni dell'applicazione client.

la migliore app gratuita per scaricare musica per Android

• Lo sforzo richiesto per i test post-rilascio e tutte le attività correlate dovrebbe essere integrato e incluso nel Piano di progetto. A seconda delle regole di business e delle specifiche del progetto, questo può essere considerato come overhead del progetto o incluso nel ciclo di QA o incluso come parte del piano di gestione del rilascio.
• Per i problemi segnalati durante la verifica post-rilascio, è necessario condurre un'analisi della causa principale per scoprire il motivo per cui il problema non è stato individuato nella fase iniziale e cosa si può fare meglio la prossima volta per evitare di affrontare il problema. L'analisi della causa principale può aiutare il team a imparare da questi problemi passati e a colmare eventuali lacune nell'implementazione. In base alla struttura organizzativa, il Test Lead o il QA Manager può completare l'analisi della causa principale con il contributo del team di progetto. Alcune cause principali comuni possono essere un problema di codifica, un problema di requisiti, un problema di progettazione, un problema di dati, limitazioni di terze parti, scenario di test mancante, ecc. È possibile creare e tracciare azioni correttive e preventive corrispondenti.
• Registri del server può essere utilizzato anche per monitorare la build dopo il rilascio. Registro del server può contenere eventi o problemi che potrebbero non essere visibili al cliente ma che causeranno problemi nel back-end. Questo monitoraggio può essere assegnato come elemento di azione al responsabile dello sviluppo e al team DevOps.

Un esempio:

Panoramica del progetto:

Le seguenti modifiche devono essere apportate a un'applicazione di social media, in particolare al processo di registrazione

1. La convalida del campo del cognome deve essere rimossa. In precedenza era stato implementato come 'Il cognome deve contenere almeno 4 caratteri' (miglioramento per il campo esistente)
2. Implementare il pulsante di attivazione / disattivazione accanto all'indirizzo e-mail in modo che l'utente possa configurare le impostazioni sulla privacy per l'indirizzo e-mail da mostrare sul proprio profilo (richiesta di nuove funzionalità)
3. L'utente dovrebbe essere in grado di scegliere il proprio avatar (richiesta di nuove funzionalità)
4. Riduci le chiamate API durante il processo di registrazione per migliorare le prestazioni dell'applicazione (miglioramento)

Piano di verifica del rilascio post produzione:

Conclusione:

Con la maggior parte delle società di software ora adottando la metodologia Agile , il numero di versioni di produzione è aumentato.

Per esempio, durante l'utilizzo Modello a cascata , un team può avere una versione di produzione ogni 1,5 mesi, tuttavia con il processo Agile, lo stesso team può ora avere una versione di produzione ogni 2-3 settimane.

Con ogni versione di produzione, abbiamo la possibilità di influenzare consapevolmente o inconsapevolmente la funzionalità dei client live. L'adozione della verifica del rilascio post-produzione immediatamente dopo il rilascio può fornire ulteriore fiducia sul rilascio, fornendo allo stesso tempo la rete di sicurezza per ripristinare il rilascio prima che i nostri clienti live incontrino alcuni problemi.

Per progetti ad alto impatto / rischio , il piano di verifica del rilascio post-produzione può essere strutturato in base alla priorità dello scenario di test. È possibile eseguire prima il test di priorità critica e inviare comunicazioni agli stakeholder sui risultati e su eventuali problemi. Se non vengono rilevati problemi critici, la verifica del rilascio post-produzione può continuare, altrimenti è necessario prendere la decisione di eseguire il rollback per ridurre al minimo i tempi di inattività dell'applicazione e l'impatto sui client attivi.

Inoltre, i test di rilascio post-produzione possono essere automatizzati e gli script di test possono essere eseguiti su richiesta dopo ogni rilascio come test di regressione. Anche in questo caso, è necessario prestare la dovuta attenzione durante l'esecuzione degli script di test automatizzati in produzione in quanto potrebbero influire sui dati e sulle funzionalità del client live.

La verifica del rilascio post produzione è il ultima linea di difesa per qualsiasi azienda di software. Se non rileviamo i problemi, i nostri clienti lo faranno e questo può essere devastante per la reputazione di qualsiasi azienda di software.

Per mantenere l'affidabilità del prodotto, è essenziale verificare le modifiche implementate in produzione immediatamente dopo la distribuzione.

Circa l'autore: Questo utile articolo è stato scritto da Neha B. Attualmente lavora come Quality Assurance Manager ed è specializzata nella guida e nella gestione di team QA interni e offshore.

Condividi la tua strategia / suggerimenti / esperienza di test di rilascio post-produzione con i nostri lettori.

Lettura consigliata

• Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
• Download dell'eBook Testing Primer
• Implementazione pratica in 7 fasi del test manuale prima del rilascio in produzione
• Test di carico con HP LoadRunner Tutorial
• Flusso del processo di QA per il test pratico del software (requisiti per il rilascio)
• Differenza tra desktop, test server client e test Web
• Cos'è il Gamma Testing? La fase finale del test
• Che cos'è il test precoce: test in anticipo, test spesso MA come? (Una guida pratica)