Ciclo di vita dei difetti - Come ormai saprai, l'esecuzione del test è la fase in cui il tester eseguirà effettivamente gli script di test. Il processo di esecuzione degli script di test varia da una società all'altra e potrebbe essere diverso nei diversi progetti all'interno della stessa società.
Ora un giorno ci sono strumenti disponibili per l'esecuzione dei test, strumenti come - Quality Center, Microsoft Visual Studio e così via. L'effettivo processo di esecuzione di ogni passaggio per confrontare i risultati effettivi e previsti rimane lo stesso per il tester funzionale indipendentemente dagli strumenti utilizzati.
- Cosa succede se il comportamento effettivo non è uguale al comportamento previsto?
Quando un tester rileva che il risultato del test effettivo non è uguale al risultato previsto, viene registrato un difetto.
- Come registrare un difetto?
Al giorno d'oggi ci sono molti strumenti disponibili, alcuni degli strumenti per la registrazione dei difetti sono ClearQuest di IBM, il Quality Center di HP, strumenti open source come il ciclo di vita dei difetti in JIRA e così via.
Esistono alcuni dei campi obbligatori comuni tra i vari strumenti di registrazione dei difetti, questi campi sono:
- Descrizione del ciclo di vita del difetto
- Riepilogo del ciclo di vita dei difetti
- Difetto registrato da
- Difetto assegnato a
- Gravità del difetto
- Priorità ai difetti
- Istantanee aggiuntive
- Numero di rilascio / Nome
Difetto Ciclo di vita
Difetto Il ciclo di vita inizia dalla registrazione di un nuovo difetto. Ogni volta che un difetto viene registrato, passa allo stato "Nuovo".
Tester - Nuovo difetto
A chi assegnare un nuovo difetto?
Un tester può assegnare un difetto a uno sviluppatore o a un responsabile dello sviluppo. Questa decisione di assegnazione del difetto varia da progetto a progetto. In alcuni luoghi di lavoro esiste un processo del ciclo di vita dei difetti per assegnarlo direttamente a un rispettivo sviluppatore e in alcuni punti il difetto viene inizialmente assegnato a un lead di sviluppo e il lead di sviluppo a sua volta lo assegna a uno sviluppatore.
Defect Assignment (Novità) - Defect Cycle Developer
Defect Assignment (Novità) - Dev Leadà Developer
Analisi dei difetti
Lo sviluppatore analizzerà il difetto per verificare se è riproducibile. Qui il contributo più importante del tester è di includere tutti i dettagli necessari nel difetto. Riepilogo difetti, Descrizione dettagliata dei difetti sono i campi che aiutano le parti interessate a comprendere il difetto in una volta sola. Il riepilogo dei difetti deve sempre contenere solo informazioni di alto livello sul difetto. Allo stesso tempo, dovrebbe disporre di informazioni sufficienti per descrivere la panoramica del difetto in una riga.
La descrizione del difetto è il luogo in cui è previsto che il tester includa tutte le informazioni necessarie come Ambiente, Scenario, Dati di test utilizzati, Risultato atteso, Risultato effettivo, Riferimento a file / dati e riferimento all'istantanea.
Ecco la breve panoramica di vari elementi della descrizione dettagliata del difetto -
Ambiente
Testare l'ambiente in cui è stato rilevato il difetto. Spesso i progetti hanno più ambienti di test in cui il team di test esegue i test. Ad esempio: AT (ambiente di test di assemblaggio), PT (ambiente di test di prodotto), UAT (ambiente di test di accettazione dell'utente) e così via. Lo scopo di avere vari ambienti è che fornisce flessibilità all'interno del team di sviluppo e test per avere il codice distribuito su uno qualsiasi degli ambienti disponibili per iniziare i test in tempo.
Ci sono momenti in cui il test del prodotto (chiamato anche test del sistema) e il test UAT si sovrappongono, quindi avere più ambienti è un must per continuare il test in parallelo.
Ci sono casi in cui il team di sviluppo ha bisogno di un ambiente aggiuntivo per eseguire il debug dei problemi segnalati dal team di test. Inoltre, il team di sviluppo ha un ambiente dedicato per l'attività di test unitario.
Pertanto, con più ambienti, è necessario menzionare nel difetto un ambiente particolare in cui è stato riscontrato il problema.
Scenario
Lo scenario è l'insieme di passaggi eseguiti dal tester che ha portato a un difetto. Qui un tester dovrebbe menzionare tutti i passaggi che lo sviluppatore può eseguire per riprodurre il difetto. Spesso ci sono momenti in cui il difetto viene segnalato dal tester ma lo sviluppatore non è in grado di replicare lo stesso e quindi il difetto viene respinto. Ciò potrebbe accadere a causa di passaggi errati / passaggi mancanti menzionati nella descrizione. I passaggi chiari aiutano tutti a comprendere il difetto e replicarlo senza avere la dipendenza di contattare un tester per ottenere input. Uno scenario ben documentato prevede passaggi facili da leggere, da comprendere e precisi da seguire per replicare il difetto.
Dati di test
Un tester dovrebbe menzionare i dati utilizzati durante il flusso di test che ha portato a un problema. Queste informazioni offrono allo sviluppatore la possibilità di utilizzare dati simili per riprodurre il difetto e trovare la causa principale per lo stesso.
Esistono alcuni scenari in cui un tester rileva un difetto utilizzando dati specifici ma lo stesso problema non è riproducibile utilizzando un tipo di dati simile. Ciò potrebbe accadere a causa della corruzione dei dati, quindi l'immissione dei dati offre la possibilità di scoprire la causa principale del difetto. Uno sviluppatore potrebbe non scavare a livello di codice in caso di danneggiamento dei dati. Questo tipo di difetto può essere convertito in difetto dei dati.
Risultato atteso e reale
Questo è il momento saliente del campo della descrizione dettagliata in cui un tester dimostra che l'errore riscontrato è effettivamente un difetto. L'evidente menzione del risultato atteso rende le cose chiare per ogni stakeholder che considera l'errore come un difetto. Immagina che un difetto sia registrato con tutti i dettagli ma non specifica il risultato atteso dello scenario!
Di solito un tester inserisce solo il risultato atteso può essere in una riga o due, tuttavia è molto importante menzionare la fonte del risultato atteso. Fonte qui riferimento al documento in cui è menzionato il risultato atteso. Questo potrebbe essere un documento obbligatorio o un riferimento allo storyboard.
Riferimento a file / dati
A volte il difetto comporta la generazione di file o l'input come file. In questo tipo di scenari, tester dovrebbe fornire informazioni sul file che è stato utilizzato e che ha causato il problema nell'applicazione. Questi file possono essere allegati utilizzando lo strumento di gestione dei difetti oppure è possibile fornire il riferimento per lo stesso. Tali posizioni di riferimento dovrebbero essere accessibili a tutte le parti interessate.
Riferimento all'istantanea
Le istantanee svolgono un ruolo molto importante quando si desidera mostrare loro l'esatto messaggio di errore di interruzione di pagina come visualizzato sullo schermo o quando si desidera mostrare i dettagli di navigazione dello schermo. Lo snapshot fornisce una rapida idea del difetto riscontrato, della schermata in cui è stato rilevato il difetto, dei dati utilizzati sullo schermo e così via. Tutti gli strumenti di gestione dei difetti prevedono di allegare le istantanee. A volte il tester potrebbe allegare anche fogli di calcolo Excel o documenti Word.
Questi erano i vari componenti della registrazione dei difetti e delle migliori pratiche per ciascuno di essi. Tornando al ciclo di vita del difetto, una volta assegnato il difetto a uno sviluppatore, lo analizzerà utilizzando i dati forniti nella voce del difetto. Se, secondo l'analisi, il problema registrato è effettivamente un difetto, lo sviluppatore "aprirà" il difetto per risolverlo.
Corsi consigliati
- Servizi Web nel pacchetto di formazione Java
- Formazione sullo sviluppo di giochi in C ++
- Formazione completa sull'hacking etico
- Vegas Pro 13 Corsi di formazione
Nuovo - Apri
Un difetto nello stato Aperto mostra che è nella piastra di sviluppo e che gli sviluppatori stanno lavorando alla sua correzione. Nel caso in cui l'analisi rilevi che il problema registrato non è un difetto, ciò può accadere quando c'è una lacuna nel comportamento previsto del sistema. Se l'analisi indica che il difetto non è valido, lo sviluppatore rifiuterà il difetto. La terminologia è "Rifiutato" o "Ritorna al test".
Nuovo: torna al test.
In che modo il tester dovrebbe validare se il difetto era davvero un difetto non valido?
Questo è lo scenario in cui un documento di requisiti precisi aiuta tutti nel team a giungere alla conclusione se il difetto registrato era non valido o valido. Il riferimento ai documenti dei requisiti aiuta il tester e lo sviluppatore a giungere alla stessa conclusione e facilita davvero il processo di discussione.
Esistono scenari in cui viene messa in dubbio la correttezza dei documenti di progettazione e dei requisiti mentre si fa riferimento a questi documenti in tempi di discussioni sui difetti, in tali periodi il ritorno a Business Analyst è considerato l'opzione migliore per chiarire le domande.
Come best practice, i documenti relativi ai requisiti e alla progettazione dovrebbero essere sempre aggiornati per poterli fare riferimento senza alcuna ambiguità.
In stato "Aperto", il team di sviluppo lavora per correggere il difetto, una volta risolto il problema lo stato cambia in "Pronto per la distribuzione".
Apri - Pronto per la distribuzione
La distribuzione è il processo in cui le modifiche vengono caricate sul server in modo che il team di test possa lavorare sulla versione fissa del codice. Di solito ogni progetto ha un team di distribuzione separato per questa attività.
Quindi, ad alto livello, un team di software è composto principalmente da questi 3 gruppi:
- Sviluppo
- Ciclo di vita dei difetti nei test
- Deployment (o talvolta chiamato come team Build)
Una volta che la build è stata distribuita e il difetto è nuovamente disponibile per il test, viene assegnato a un tester appropriato per l'attività di test.
Difetto assegnato a - Test lead.
Cavo di prova - Tester individuale.
Difetto assegnato - Tester individuale.
In alcuni luoghi di lavoro, il difetto viene prima assegnato al conduttore del test e lui / lei a sua volta lo assegna al singolo tester, tuttavia in alcuni punti, il difetto viene assegnato direttamente al tester che lo testerà o colui che ha sollevato il difetto.
Lo stato qui cambia da Pronto per la distribuzione - Test SIT pronto.
Ora il difetto è nella piastra del tester. Il team di test convaliderà il difetto e ci sono 2 possibilità, o la correzione funzionerebbe correttamente o lo stesso problema si verifica nuovamente. A seconda del risultato, il difetto può passare ai seguenti stati:
Test SIT pronto - Chiuso
Test SIT pronto - Riaprire
In entrambi i casi precedenti, è necessario il tester per aggiungere i commenti dei test eseguiti. Ciò include la menzione degli scenari testati e dei dati utilizzati. Se il difetto viene riaperto, il tester deve fornire i passi esatti eseguiti che hanno portato nuovamente all'errore.
Lo stato di riapertura è uguale allo stato del difetto "Nuovo".
Una volta riaperto, il difetto seguirà di nuovo lo stesso ciclo.
Difetti del ciclo di vita
- Decidere sulla gravità del difetto: questo è uno dei temi comuni di discussione (spesso combattimenti) tra gli sviluppatori di tester / v.
- Il difetto non è riproducibile sul sistema dello sviluppatore.
- Difetto sollevato nello scenario che non è menzionato nei requisiti e nei documenti di progettazione.
- È stato rilevato un difetto, ma non è possibile sollevare lo stesso, in quanto non è possibile il verificarsi dello scenario nell'ambiente di produzione.
Come un tester dovrebbe superare le sfide?
- La gravità è direttamente proporzionale all'impatto che il difetto sta causando all'applicazione, se il tester non può procedere a causa del difetto, è sicuramente contrassegnato con la massima gravità.
- Se esiste una soluzione alternativa per continuare il test, è necessario contrassegnarlo come di gravità media. Inoltre, oltre a considerare l'impatto di ulteriori test del ciclo di vita dei difetti, la gravità può anche essere decisa considerando la situazione in cui un intero modulo sta fallendo, in questo caso anche se è possibile eseguire i test di un altro modulo ma la gravità del modulo corrente è elevata quindi il difetto deve essere contrassegnato con la massima severità.
- Se un difetto non è riproducibile sul sistema dello sviluppatore, è possibile che l'ambiente di sviluppo e test non sia sincronizzato. Un difetto riproducibile sul sistema di prova è sempre considerato un difetto valido.
- Ci sono situazioni in cui un difetto viene registrato considerando lo scenario aziendale complessivo ma lo scenario diretto non è menzionato nei requisiti o nel documento di progettazione. È sempre considerata una buona pratica considerare gli scenari di business reali anziché semplicemente seguire i passaggi del test. La comunicazione con analisti aziendali e altre parti interessate del prodotto svolge un ruolo importante per la registrazione di tali difetti.
- Ci sono scenari in cui un tester rileva una lacuna nella logica aziendale durante la fase di test. Trovare tali lacune è di nuovo considerato un grande vantaggio per un tester. Le lacune di progettazione vengono generalmente gestite tramite miglioramenti.
- Miglioramento: se è necessario modificare un comportamento durante la fase di test del ciclo di vita del software, viene creato un miglioramento che può essere preso nella versione corrente o successiva considerando le tempistiche e la larghezza di banda dei team di sviluppo e test.
- Ci sono alcuni scenari che un tester potrebbe testare durante i test ad hoc che potrebbero effettivamente essere scenari non validi, considerando la possibilità che si verifichino nella produzione.
Chi è il migliore amico del tester?
Dove dovrebbe andare un tester in caso di ambiguità? La risposta dipende dal tipo di query, se una query riguarda i requisiti, è consigliabile prima discutere all'interno del team per verificare la corretta comprensione del sistema consultando i membri senior. Il prossimo punto di contatto dovrebbe essere analisti aziendali.
Se la query riguarda il processo di test, è consigliabile contattare il responsabile del test o il responsabile del test.
Se la query riguarda la comprensione degli aspetti tecnici dell'applicazione, il membro del team di sviluppo potrebbe essere la persona giusta a cui rivolgersi.
Poiché il test è un processo che richiede una comprensione generale del sistema, la comunicazione aiuta un tester a ottenere una risposta rapida alle domande, dipende solo dal porre domande giuste alle persone giuste. Evitare di fare domande al momento giusto potrebbe portare a un difetto che fuoriesce nell'ambiente di produzione.
Quanto è importante il ruolo di tester nell'azienda oggi?
Esistono progetti in cui il team di test è altrettanto importante del team di sviluppo e in alcuni scenari c'è più dipendenza dal team di test che dal team di sviluppo. Lo scenario successivo è raro ma esiste in alcuni luoghi di lavoro. Ciò è accaduto nel tempo e potrebbe essere per un periodo di tempo specifico in cui il team di sviluppo non ha molta esperienza rispetto al team di test. Ci sono persone che comprendono meglio il flusso e le funzionalità complessive rispetto alla maggior parte degli altri membri del team. Tale individuo potrebbe far parte del team di test / sviluppo. Questo è uno dei fattori che decide la dipendenza da un team / individuo per il progetto specifico.
Qual è il percorso professionale per un tester?
Un individuo potrebbe impiegare un po 'di tempo per comprendere il processo generale di test, il dominio e altre attività su cui dovrebbe lavorare nella vita di tutti i giorni. Sulla base di questa comprensione, è consigliabile prendere la decisione di esplorare ulteriori aree che un tester potrebbe occupare. Ci sono sempre opportunità nel processo di automatizzare vari flussi. La creazione di piccole utility può anche aiutare il team in grande stile. Se un tester è bravo a programmare, è considerato un grande vantaggio. Questo apre opportunità per ruoli di automazione. Il test delle prestazioni è anche una delle tracce di carriera per i tester. L'analista aziendale è un'altra opzione. Una buona conoscenza del dominio con buone capacità comunicative sono le competenze richieste per essere analisti aziendali. I test offrono molte opportunità ai tester di lavorare su vari domini, strumenti, processi e così via. Dipende solo da un individuo da raccogliere e iniziare ad andare in profondità all'interno di una delle aree chiave del test. Esistono molte certificazioni specifiche per vari strumenti per specializzarsi in una delle aree di test. Avere la certificazione del fornitore standard è un vantaggio per aumentare la carriera, ma il certificato da solo non può aiutarti a lungo termine se non combinato con la corretta esperienza di lavoro.
Articoli consigliati
Ecco alcuni articoli che ti aiuteranno a ottenere maggiori dettagli sui test del software, quindi basta passare attraverso il link.
- 6 domande di intervista di test del software più sorprendenti
- Carriere nel test del software
- Come ottenere una migliore crescita professionale nel lavoro del tester software