how improve test release process
Vediamo il tipico processo coinvolto nella fornitura di software dalla 'fase di sviluppo' alla 'fase di test' per un rilascio del software privo di bug riuscito alla produzione / client .
Questi processi sono trascurati o ignorati dalle società di software, il che si traduce in una cattiva gestione dei test e quindi 'un' buggy 'Versioni del software al client, che porta a' clienti insoddisfatti '.
Nonostante molto tempo e grande impegno dato dal team di test per ogni versione , quando il software rilasciato non ha la qualità definita o definita sul benchmark o non soddisfa i criteri previsti, non solo influirà sulla reputazione dell'azienda presso i clienti, ma demotiverà e demoralizzerà anche il team di progetto, soprattutto il team di test nel suo insieme .
Se fai parte di un team di test in questo scenario, potresti continuare a pensare a te stesso 'come migliorare le mie capacità di test e c'è un modo migliore per superare questa situazione'.
Voglio dare alcuni suggerimenti e suggerimenti, in base alla mia esperienza con vari team di test coinvolti in applicazioni software e versioni di prodotti aziendali con più domini e piattaforme e con più framework di test, su come migliorare i processi di rilascio dei test , che semplificherà la tua vita professionale come ingegnere di test o responsabile di test per la fornitura di software di livello mondiale.
Cosa imparerai:
- Processo di rilascio di prova
- Miglioramento del processo di rilascio del test:
- Gestione e controllo del contenuto della versione di prova
- Modello di rapporto di rilascio di esempio:
- Conclusione:
- Lettura consigliata
Processo di rilascio di prova
La tabella seguente offre una panoramica di un processo di rilascio di prova con tre fasi universali come Input, Process & Output.
framework basato sui dati nell'esempio del webdriver al selenio
| INGRESSO | PROCESSI | PRODUZIONE |
|---|---|---|
| 7 | La lista di controllo per la revisione del codice è stata aggiornata e disponibile in VSS? | |
| Processo precedente Sviluppo | Il processo inizia con • Installazione del software rilasciato nel server di prova | Necessità del processo successivo • Software che ha superato i test di fumo / sanità mentale |
| Riferimento di informazioni / documenti • Documento sui requisiti dell'utente • Specifiche dei requisiti software • Piano di unit test • Standard di codifica • Elenco di controllo per la revisione del codice • Piano di sviluppo • Piano di garanzia della qualità • Allocazione dei compiti • Pacchetto di lavoro • Programma del progetto • Schema del progetto • Piano di gestione della configurazione • Piano di gestione del rischio. | Processi secondari • Preparazione di casi di test per tutte le unità • Sviluppo e unit test • Gestione delle procedure di non conformità • Implementazione del piano di gestione della configurazione. • Implementazione del piano di gestione del rischio • Monitoraggio dell'avanzamento del progetto • Correzione e revisione degli errori | Esigenze interne del cliente • Build software con numero di versione • Rapporto di rilascio • Casi di test / Documento della suite di test • Pianificazione dell'esecuzione dei test • Matrice di tracciabilità • Dati di test |
| Verifica input in entrata • I documenti di progetto vengono esaminati e approvati? • Standard di codifica, lista di controllo per la revisione del codice sono disponibili per riferimento? • Attività assegnate e pacchetto di lavoro aggiornato? • Le specifiche funzionali, il piano di sviluppo e il piano di qualità vengono esaminati e approvati? • Il piano di gestione del rischio ha mitigazione e contingenza per gestire il rischio? • Efficacia della pianificazione del progetto per consegnare il prodotto in tempo? | Specifiche di processo • I casi di test unitario devono essere costituiti da tutti i criteri di ingresso e di uscita • Adesione del codice agli standard di codifica • Il PCN deve essere gestito secondo le linee guida • I passaggi di gestione della configurazione devono aderire al piano di gestione della configurazione • La gestione dei rischi deve aderire al Piano di gestione dei rischi • Il test del fumo supera tutte le principali caratteristiche e funzionalità | Esigenze del cliente esterno • Software privo di bug |
| Processi di supporto • Risorse umane / hardware / software / risorse • Manutenzione in caso di guasti hardware • Formazione ai membri del team | Il processo termina con • Esecuzione di Smoke / Sanity Testing sulla build rilasciata | Parametri di efficienza • Ogni unità dovrebbe superare il primo round di test • Attività da completare secondo la pianificazione del progetto • Il test del fumo deve essere superato prima del rilascio • Testing Team Passione per testare il software |
Ogni team di test dovrebbe creare un file unico lista di controllo per il rilascio del software, secondo il dominio e la piattaforma del software e la metodologia di gestione del progetto (come Agile Scrum ecc.) e secondo il framework di test manuale / automatizzato, accettare la build rilasciata, prima di iniziare l'esecuzione del test per risparmiare tempo e fatica.
Questo è uno dei parametri di efficienza più importanti nella fase di rilascio del test.
Miglioramento del processo di rilascio del test:
1) Esamina il rapporto sul rilascio per le nuove funzionalità, personalizzazione / modifica di funzionalità esistenti, correzioni di bug dalla build precedente, che deciderà di avviare l'esecuzione dello Smoke Testing o Sanity Testing o una combinazione di entrambi.
2) Rivedi l'aggiornamento Documenti di prova secondo le nuove funzionalità e le correzioni di bug, se non già aggiornate. Normalmente, durante il ciclo di vita dello sviluppo del software, questi documenti vengono aggiornati dal team di test in base alle regolari riunioni settimanali di revisione del progetto.
3) Rivedi la build del software nel Repository di configurazione viene aggiornato per il numero di build, il numero di versione, etichettato o commentato con il nome del rilascio secondo gli standard definiti nel piano di progetto. Inoltre, assicurati che la build sia stata compilata e installata correttamente sul server di prova.
4) Pianifica una riunione di revisione rapida del progetto dopo il rilascio per discutere i pro ei contro della build rilasciata, i bug noti e le funzionalità critiche ecc., per evitare qualsiasi comunicazione errata e per rivedere eventuali requisiti importanti del client. Evita rigorosamente qualsiasi comunicazione orale tra i team di sviluppo e test poiché influisce notevolmente sulla qualità del rilascio del software.
5) Assicurati che lo strumento di tracciamento dei bug sia configurato correttamente , per il team di test assegnato e il team di sviluppo del progetto, i numeri di build e rilascio del software, nonché i moduli / funzionalità del software, che aiuteranno a registrare i bug in modo efficiente. In caso contrario, dovrebbe essere inoltrato al project manager o al test manager con priorità alta.
6) Restituire la build al team di sviluppo senza alcun compromesso, se la build fallisce in Smoke o Sanity Testing. Rigorosamente, il test non dovrebbe essere continuato quando il sistema fallisce in Smoke Testing. Ciò consentirà di risparmiare molto tempo e fatica e migliorare la qualità del software rilasciato nelle versioni successive.
7) Pianifica il rilascio del progetto il 1stGiorno della settimana che aiuterà il responsabile del test a pianificare il ciclo di test imminente in base alla stabilità della build e anche a inviare un rapporto di prova veloce al project manager che aumenterà la qualità del software con largo anticipo. Se il team di sviluppo pianifica il rilascio del progetto venerdì, il fine settimana può essere utilizzato per eventuali slittamenti e problemi di compilazione in un framework di compilazione manuale o automatizzato.
8) Assicurati che i tester siano addestrati correttamente sul dominio che aiuterà il team di test ad aderire al programma di test e a raccogliere il tempo per il prossimo round di test. Inoltre, il team di test dovrebbe essere addestrato e avere l'esposizione alla tecnologia richiesta come Scripting e SQL se il progetto richiede il white boxing.
9) Evita l'assegnazione di tester in più progetti poiché influisce notevolmente sulla qualità dell'esecuzione dei test in tempo reale. In pratica, anche i tester esperti trascurano le caratteristiche e le funzionalità oltre a saltare i casi di test assumendo che alcuni casi di test non falliscano mai, quando sovraccarichi di lavoro o allocati su più progetti con scadenze.
10) Apprezzo il team di test per avere passione poiché i tester non dovrebbero lavorare per il 'Giorno' o commentare 'Chiamalo un giorno'. Quando il software ha più moduli e il funzionalista è completamente o parzialmente integrato o interrelato, i tester dovrebbero avere la passione di scrivere / eseguire i casi di test con una grande matrice di copertura e tracciabilità, mirando alla qualità del software / prodotto finale. Perché anche un problema estetico è un 'bug' e conta come '1 bug'.
undici) Assicurati che l'installazione del software sia facile e diretta poiché aiuta il team di test a reinstallare il software quando richiesto invece di aspettare che il responsabile dello sviluppo o un gestore dell'installazione faccia lo stesso lavoro, il che ucciderà inutilmente il tempo di test disponibile. Ad esempio, anche se l'installazione basata su Windows è facile, ma quando coinvolge più server Web e reti geografiche in un ambiente di test multilivello, i tester potrebbero impiegare ore per installare il software. Se la coperture di test del software e installazione, disinstallazione , patch o aggiornamenti del software, è più probabile che venga discusso in dettaglio il processo di esecuzione dei casi di test con il team di test.
12) Assicurati che gli strumenti automatici siano disponibili con la licenza per un framework di test di automazione . L'esecuzione di casi di test in un framework automatizzato è facile rispetto a uno scenario di test manuale, a condizione che gli strumenti automatici siano configurati correttamente e concessi in licenza per più utenti. In particolare, quando il piano di test prevede test di prestazioni e carico oltre alla normale esecuzione di casi di test e test di regressione, i tester dovrebbero coprire l'esecuzione di casi di test su più ambienti come più server, più browser, più utenti ecc.
13) Assicurati che le macchine fantasma siano configurate per il test prima di iniziare l'esecuzione del test. Le macchine fantasma sono macchine con diversi ambienti di test. Ad esempio, un software applicativo web può essere pianificato per testare in più ambienti come Windows 7 e Access DB o Windows 2008 e SQL Server o Windows 8 e Oracle o Mainframe e DB2 ecc., Con tutti i browser come Chrome, Firefox, Internet Explorer , Safari ecc., Alcuni 'test di sistema' richiede anche di formattare completamente il disco rigido e installare un nuovo software o aggiornare il software esistente con patch e aggiornamenti, ecc.
14) Evitare di implementare le nuove funzionalità / richiesta di modifica interrompendo l'esecuzione del test e rilasciando il software per riavviare la fase di test. Questa è una pessima pratica in molte organizzazioni di software in base ai requisiti aziendali per soddisfare i clienti esterni o almeno per soddisfare le richieste del comitato direttivo di gestione o talvolta dei team di vendita / marketing. Anche se le richieste di modifica dei clienti sono sempre incoraggiate in un ambiente di progetto 'Agile', dovrebbero essere adeguatamente pianificate e implementate prima del rilascio del software al team di test.
Gestione e controllo del contenuto della versione di prova
La gestione e il controllo del contenuto della versione di prova è molto importante per qualsiasi software IT o anche per qualsiasi ambiente software non IT che verrà illustrato nella figura seguente.
- Il project manager e / o il comitato direttivo del progetto dipende dall'autorità della matrice organizzativa, è responsabile della selezione del contenuto per ogni rilascio.
- Una volta identificati e approvati i bug e / o le nuove funzionalità e la richiesta di modifica da parte dei clienti, verrà implementato dal team di sviluppo che dovrebbe essere comunicato agli stakeholder del progetto prima che lo sviluppo / implementazione venga avviato.
- Sulla base della versione finale implementata, il team di test aggiornerà i documenti correlati e si preparerà per il test di conseguenza.
- Il team di test inizierà i test di fumo / sanità in base ai requisiti definiti nel rapporto di rilascio.
- Una volta superata la sanità mentale, il team di test inizierà l'esecuzione del test secondo la pianificazione e le attività assegnate, vale a dire test funzionali, test non funzionali, test di sicurezza, test di sistema, test delle prestazioni, test di carico, test di accettazione dell'utente ecc.
- Una volta completato il primo round del ciclo di test, i rapporti di test verranno inviati a tutti gli stakeholder e al team manager di sviluppo per pianificare la successiva iterazione dell'esecuzione del test.
- A seconda dello stato dei rapporti di prova e della gravità e complessità dei bug, verrà pianificato un ciclo completo di un secondo ciclo di esecuzione del test o test di regressione insieme al test di accettazione dell'utente.
- Dopo aver completato i cicli di esecuzione dei test pianificati, i rapporti di prova verranno inviati a tutti gli stakeholder del progetto per il superamento / mancato / mancato delle caratteristiche, funzionalità e correzioni di bug.
Modello di rapporto di rilascio di esempio:
Nota : Di seguito è inoltre disponibile per il download un modello MS Word di esempio per il rapporto di rilascio.
Trova sotto un ' Rapporto di rilascio di esempio 'Che copre gli aspetti principali del processo di rilascio che rende la vita professionale dell'intero team di progetto molto più felice che mai.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
# 1) Campo di applicazione
La navigazione GPS per XYZ Company Limited è stata rilasciata per test interni. La versione rilasciata è 1.0.7, il numero di rilascio è 14.0 e il numero di build 105.25.03. Questa versione software include le nuove funzionalità e le principali correzioni di bug della versione precedente. Il test del fumo è passato dalla fase di sviluppo, ma è necessario un Smoke & Sanity prima di passare al test di regressione.
# 2) Riferimenti
GPSNavigation_URD_1.0.12, GPSNavigation_FFD_2.17, GPSNavigation_BusinessUseCases_1.23.10, GPSNavigation_TestPlan_1.44, GPSNavigation_TestSuites_2.10, GPSNavigation_UnitTesting_23.3
# 3) Descrizione della versione
Questa versione è una versione controllata della navigazione GPS e contiene le seguenti caratteristiche e funzionalità.
Le funzioni contrassegnate da * sono nuove in questa versione.
Le seguenti funzionalità non sono state implementate in questa versione.
1. Modulo 1
1.1 Caratteristica 1
1.1.1 Funzionalità 1
# 4) Gestione della configurazione
Stiamo utilizzando Visual Source Safe come strumento di gestione della configurazione. La build è disponibile nel seguente percorso.
Link interno: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Link esterno: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Istruzioni e passaggi per l'installazione
Fornire le informazioni dettagliate per l'installazione della build al team QA / Testing.
# 6) Problemi / bug risolti
Lo stato dei bug viene aggiornato nel sistema di tracciamento dei difetti.
# 7) Problemi / bug da correggere
# 8) Prodotti finali
# 9) Bug / problemi noti
# 10) Elenco di controllo del rilascio
| Si No / | Descrizione | S / N |
|---|---|---|
| uno | Tutti i file sono stati controllati in Visual Source Safe? | |
| Due | L'etichetta è stata inserita nella cartella corretta in VSS secondo gli standard interni? | |
| 3 | La versione è identificabile come versione 'esterna' / 'interna' in VSS? | |
| 4 | Nei commenti, la versione è stata menzionata in VSS? | |
| 5 | Nei commenti, è stata menzionata una breve descrizione in VSS? | |
| 6 | Il codice è stato esaminato e i problemi di revisione del codice sono stati registrati in Clear Quest? | |
| 8 | Il documento di unit test è stato preparato e rivisto? | |
| 9 | Casi di test unitari eseguiti e risultati aggiornati per lo stato? | |
| 10 | Il documento aggiornato dello unit test case è disponibile in VSS? | |
| undici | Tutti i problemi di Clear Quest per questa versione sono stati risolti / chiusi? | |
| 12 | Tutte le attività del pacchetto di lavoro completate e aggiornate in VSS? | |
| 13 | Il test del fumo è stato eseguito e superato? |
=> Scarica: Fare clic qui per scaricare il modello di report di rilascio di esempio in formato MS Word.
Conclusione:
Come migliorare continuamente il processo di rilascio dei test
Suggerimento n. 1) Istituire un team di ingegneri di rilascio che si occuperà dei fattori critici della manutenzione delle versioni e delle build del software e sarà responsabile dei sistemi di gestione della configurazione software centralizzata.
Suggerimento n. 2) Motivare e apprezzare i team di progetto per aver seguito il processo coinvolto nel ciclo di vita dello sviluppo del software, nel ciclo di vita dello sviluppo del prodotto e nel ciclo di vita del test del software. Possiamo definire il processo, ma fino a quando ea meno che non sia stato seguito dalle persone coinvolte, non serve definire il processo.
Suggerimento n. 3) Stimare lo sforzo di test in base alle esperienze e alla storia precedente. Scrivere casi di test è totalmente diverso dall'esecuzione dello stesso. I tester dovrebbero capire cosa testare, come testare e quando testare, altrimenti, gli sforzi dati al ciclo di test vengono sprecati, anche se si sono verificati più cicli di test.
Suggerimento n. 4) Infine, se possibile e fattibile, automatizza la fase di test utilizzando alcuni strumenti di test universalmente accettati. L'uso di strumenti di build automatizzati e strumenti di test automatizzati riduce gli sforzi di test di oltre il 50% migliorando la qualità del software e garantisce il 100% di qualità se il framework di automazione è progettato correttamente.
Suggerimento n. 5) Ultimo ma non meno importante, il rilascio di prova non è solo un lavoro, è un'arte di rendere la vita di tutti gli stakeholder in un progetto facile e più confortevole.
Circa l'autore: Balu A. è un professionista IT tecnico-funzionale esperto con oltre due decenni di esperienza nel software IT e un decennio di esperienza nella gestione di progetti e test nella fornitura di applicazioni aziendali e soluzioni di mobilità attraverso domini utilizzando tecnologie Microsoft, Oracle, Java e Mobile. È fondamentalmente un leader con la passione di promuovere le persone a diventare i leader con l'atteggiamento giusto e ama lavorare in un ambiente orientato al processo e crede che il processo migliori l'efficienza, la qualità e la produttività dei dipendenti.
Nelprossimo tutorial, impareremo - Come Migliora l'efficienza del test case.
Fateci sapere i vostri pensieri / domande nei commenti qui sotto.
Avere una versione del software secondo il processo!
Completare i test nei tempi previsti con grande produttività e sforzi !!
Prova a ottenere una consegna del software senza bug e di qualità garantita !!!
Se ti piace questo articolo considera di condividerlo con i tuoi amici!
Lettura consigliata
- Corso di test del software: quale istituto di test del software dovrei iscrivermi?
- Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
- Lavoro assistente QA test software
- Che cos'è il Monkey Testing nel Software Testing?
- Scegliere il test del software come carriera
- Lavoro di freelance di scrittore di contenuti tecnici di test del software
- Esempio di segnalazione di bug
- Flusso del processo di QA per il test pratico del software (requisiti per il rilascio)