live project bug tracking
Questa è la parte conclusiva del nostro ' Formazione sul test del software su un progetto live 'Serie.
Si tratterà di difetti e anche di alcuni argomenti rimanenti che segneranno il completamento della fase di esecuzione del test dell'STLC.
Nel articolo precedente , mentre era in corso l'esecuzione del test, abbiamo riscontrato una situazione in cui il risultato atteso del test case non è stato soddisfatto. Inoltre, abbiamo identificato alcuni comportamenti imprevisti durante i test esplorativi.
Cosa succede quando incontriamo queste deviazioni?
Ovviamente dobbiamo registrarli e monitorarli per assicurarci che queste deviazioni vengano gestite e alla fine riparate sull'AUT.
# 1) Queste deviazioni sono indicate come Difetti / bug / problemi / incidenti / errori / guasti.
#Due) Tutti i seguenti casi possono essere registrati come difetti
- Requisiti mancanti
- Requisiti di funzionamento errati
- Requisiti aggiuntivi
- Documento di riferimento incoerenze
- Problemi legati all'ambiente
- Suggerimenti per il miglioramento
# 3) La registrazione dei difetti viene eseguita principalmente in fogli Excel o tramite l'uso di un software / strumento di gestione dei difetti. Per informazioni su come gestire i difetti tramite strumenti, provare a utilizzare i seguenti collegamenti:
- HP ALM
- Atlassian JIRA
- Inoltre, fare riferimento a questo post per un elenco dei file strumenti di tracciamento dei bug più popolari nel mercato.
Cosa imparerai:
- Come registrare i difetti in modo efficace
- Alcuni puntatori durante il rilevamento dei bug
- Il ciclo di vita completo dei difetti
- Criteri di uscita per il test del progetto OrangeHRM Live
- Metriche di test
- Rapporto di firma / completamento del test
- Lettura consigliata
Come registrare i difetti in modo efficace
Proveremo ora a vedere come registrare in un foglio excel i difetti riscontrati nel precedente articolo. Come sempre, la scelta di un formato o modello standard è importante.
domande e risposte intervista tecnico help desk pdf
In genere, le seguenti colonne fanno parte del rapporto sui difetti:
- ID difetto: Per l'identificazione univoca.
- Descrizione del difetto: Questo è come un titolo per descrivere brevemente il problema.
- Modulo / sezione dell'AUT: Questo è facoltativo, solo per aggiungere maggiore chiarezza in quanto indica l'area dell'AUT dove si è verificato il problema.
- Passaggi per riprodurre: Qual è l'esatta sequenza di operazioni da eseguire sull'AUT per ricreare il bug sono da elencare qui. Inoltre, se i dati di input sono specifici per il problema, devono essere inserite anche le informazioni.
- Gravità: Per indicare l'intensità del problema e, eventualmente, l'impatto che questo potrebbe avere sul funzionamento dell'AUT. Le linee guida su come assegnare e quali valori assegnare in questo campo possono essere trovate nel documento del piano di test. Quindi, fare riferimento al Documento Piano di prova dall'articolo 3 .
- Stato: Sarà discusso ulteriormente nell'articolo.
- Immagine dello schermo: Un'istantanea dell'applicazione per mostrare l'errore quando si è verificato.
Questi sono alcuni dei campi 'indispensabili'. Questo modello può essere espanso (ad esempio per includere il nome del tester che ha segnalato il problema) o contrattato ( Per esempio, il nome del modulo rimosso) secondo necessità.
Seguendo le linee guida di cui sopra e utilizzando il modello sopra, un registro / rapporto di difetto di esempio potrebbe essere simile a questo:
Report di esempio sui difetti per il progetto OrangeHRM Live:
=> Fare clic qui per scaricare il rapporto sui difetti del progetto live
Di seguito è riportato il rapporto sui difetti di esempio creato nello strumento qTest Test Management: (Clicca sull'immagine per ingrandirla)
I difetti non vanno bene quando li registriamo e li teniamo per noi. Dovremo assegnarli nel giusto ordine affinché le squadre interessate agiscano su di loro. Il processo - chi assegnare o quale ordine seguire può essere trovato anche nel documento del piano di test. È per lo più simile a (Clicca sull'immagine per ingrandirla)
Ciclo di difetti:
Dal processo di cui sopra, si può notare che i bug passano attraverso persone diverse e decisioni diverse nel processo di identificazione e correzione. Per monitorare e stabilire la trasparenza in merito allo stato esatto in cui si trova un determinato bug, viene utilizzato un campo 'Stato' nella segnalazione del bug. L'intero processo viene definito 'ciclo di vita dei bug'. Per ulteriori informazioni su tutti gli stati e il loro significato, fare riferimento a questo Tutorial sul ciclo di vita dei bug .
Alcuni puntatori durante il rilevamento dei bug
- Quando siamo nuovi in un team / progetto / AUT creativo, è sempre meglio discutere il problema che abbiamo riscontrato con un collega per assicurarci che la nostra comprensione di ciò che realmente rende un difetto sia corretta o meno.
- Per fornire tutte le informazioni necessario per riprodurre il problema. Un difetto che ritorna a un team di test con lo stato impostato come 'Informazioni insufficienti' non si riflette molto positivamente su di noi. Dai un'occhiata a questo post - Come ottenere la risoluzione di tutti i bug senza alcuna etichetta 'Bug non valido' .
- Controlla se è stato sollevato un problema simile prima di crearne uno nuovo. Problemi 'duplicati' sono anche cattive notizie per il team QA.
- Se c'è un problema, si verifica in modo casuale e non conosciamo i passaggi / le situazioni esatti in cui possiamo ricreare il problema, sollevalo lo stesso. A rischio che il problema venga impostato 'Informazioni non riproducibili / insufficienti' - dobbiamo ancora assicurarci di aver gestito tutti i possibili malfunzionamenti nel miglior modo possibile.
- La pratica generale è che il team QA crea i difetti di ciascuno in un foglio Excel durante una giornata e li consolida alla fine della giornata.
Il ciclo di vita completo dei difetti
Per il nostro progetto live, se dovessimo seguire il ciclo di vita del difetto per il difetto 1,
VPN per Reddit
- Quando io (il tester) lo creo, il suo stato è 'Nuovo'. Quando lo assegno al lead del team QA, lo stato è ancora 'Nuovo' ma il proprietario è ora il lead QA.
- Il responsabile del QA esaminerà il problema e, una volta stabilito che si tratta di un problema valido, il problema viene assegnato al responsabile dello sviluppo. In questa fase, lo stato è 'Assegnato' e il proprietario è Dev lead.
- Il responsabile dello sviluppo assegnerà quindi questo problema a uno sviluppatore che lavorerà per risolverlo. Lo stato sarà ora 'Lavori in corso' (o qualcosa di simile a quell'effetto), il proprietario è lo sviluppatore.
- Per il difetto 1, lo sviluppatore non è in grado di riprodurre l'errore, quindi lo riassegna al team QA e imposta lo stato come 'Non in grado di riprodursi'.
- In alternativa, se lo sviluppatore fosse in grado di lavorarci e risolvere un problema, lo stato sarebbe impostato su 'risolto' e il problema sarebbe stato assegnato nuovamente al team QA.
- Il team di controllo qualità lo raccoglierà, verificherà nuovamente il problema e, se risolto, imposterà lo stato su 'Chiuso' . Se il problema persiste, lo stato viene impostato su 'Riaprire' e il processo continua.
- A seconda delle altre situazioni, lo stato può essere impostato come 'Differito' , 'Informazioni insufficienti', 'Duplicare' , 'funziona come previsto' , ecc dallo sviluppatore.
- Questo metodo di registrare i difetti, segnalarli e assegnarli, gestirli è una delle principali attività svolte dai membri del team QA durante la fase di esecuzione del test. Questo viene fatto su base giornaliera fino al completamento di un particolare ciclo di test.
- Una volta completato il ciclo 1, il team di sviluppo impiegherà un giorno o due per consolidare tutte le correzioni e ricostruire il codice nella versione successiva che verrà utilizzata per il ciclo successivo.
- Lo stesso processo continua anche per il ciclo 2. Alla fine del ciclo, è possibile che ci siano ancora dei problemi 'aperti' o non risolti nell'applicazione.
- In questa fase, continuiamo ancora con il ciclo 3? Se sì, quando smetteremo di testare?
Criteri di uscita per il test del progetto OrangeHRM Live
È qui che utilizziamo quelli che chiameremmo i 'criteri di uscita'. Questo è predefinito nel documento Piano di prova. È semplicemente sotto forma di elenco di controllo che determinerà se concludere il test dopo il ciclo 2 o eseguire un altro ciclo. Risulta come il seguente quando compilato prendendo in considerazione alcune risposte ipotetiche alle seguenti domande riguardanti il progetto OrangeHRM:
Quando esaminiamo attentamente la lista di controllo sopra, ci sono metriche e firme menzionate lì che non abbiamo discusso in precedenza. Parliamone adesso.
Metriche di test
Abbiamo stabilito che durante la fase di esecuzione del test, i rapporti vengano inviati a tutti gli altri membri del team di progetto per dare un'idea chiara cosa sta succedendo nella fase di esecuzione del QA . Questa informazione è importante per tutti al fine di ottenere la convalida sulla qualità complessiva del prodotto finale.
Immagina di segnalare che 10 casi di test sono stati superati o sono stati eseguiti 100 casi di test: questi numeri sono semplicemente dati grezzi e non danno una prospettiva molto buona su come stanno andando le cose.
Le metriche svolgono un ruolo fondamentale nel colmare questa lacuna. Le metriche sono in parole semplici, numeri intelligenti che il team di test raccoglie e mantiene . Per esempio, se dicessi che il 90% dei casi di test è stato superato, ha più senso che dire che 150 casi di test sono stati superati. Non è vero?
Esistono diversi tipi di metriche raccolte durante la fase di esecuzione del test. Quali metriche devono essere raccolte e mantenute esattamente per quali periodi di tempo - queste informazioni possono essere trovate nel documento del piano di test.
Le seguenti sono le metriche di test raccolte più comunemente per la maggior parte dei progetti:
- Percentuale superata dei casi di test
- Densità dei difetti
- Percentuale di difetti critici
- Difetti, numero saggio di gravità
Controlla il Rapporto sullo stato allegato a questo articolo per vedere come vengono utilizzate queste metriche.
Rapporto di firma / completamento del test
Poiché dobbiamo informare tutte le parti interessate che i test sono iniziati, è anche dovere del team QA far sapere a tutti che i test sono stati completati e condividere i risultati. Quindi, in genere viene inviata un'e-mail dal team QA (solitamente il Team Lead / QA Manager) che fornisce un'indicazione che il team QA ha firmato il contratto sul prodotto allegando i risultati del test e l'elenco dei problemi aperti / noti.
Email di conferma del test di esempio:
Per: Cliente, PM, team di sviluppo, team DB, BA, team QA, team ambiente (e chiunque altro debba essere incluso)
E-mail: Ciao Team,
Il team di QA firma il software OrangeHRM versione 3.0 dopo il completamento con successo dei 2 cicli di test funzionale del sito web.
I casi di test e i risultati della loro esecuzione sono allegati all'e-mail. (Oppure menzionare la posizione in cui sono presenti. Oppure, se si utilizza un software di gestione dei test, fornire i dettagli relativi allo stesso.)
Anche l'elenco dei problemi noti è allegato all'e-mail. (Di nuovo, è possibile aggiungere qualsiasi altro riferimento che abbia senso.)
Grazie,
Responsabile del team QA.
Allegati: Rapporto di esecuzione finale, Rapporto finale di problemi / difetti, Elenco dei problemi noti
Una volta che l'e-mail di conferma del test viene inviata dal team QA, abbiamo ufficialmente finito con il processo STLC. Questo non segna necessariamente il completamento della fase di 'test' dell'SDLC. Abbiamo ancora il test UAT da finire perché ciò avvenga. Trova maggiori dettagli sui test UAT qui .
Dopo che l'UAT è terminato, l'SDLC passa alla fase di distribuzione in cui diventa attivo ed è disponibile per i suoi clienti / utenti finali per essere utilizzato.
Questo è tutto!
Questo è stato il nostro sforzo per offrire ai nostri lettori l'esperienza più live come QA Project. Fateci sapere i vostri commenti e le vostre domande su questa serie di formazione online gratuita sul controllo del controllo del software.
Lettura consigliata
- Formazione sul test del software: formazione end-to-end su un progetto in tempo reale - Formazione QA online gratuita, parte 1
- Scrittura di casi di test dal documento SRS (SCARICA casi di test di esempio del progetto Live)
- Domande frequenti sul corso di formazione QA sul test del software
- 11 miglior software di formazione online per una formazione senza problemi nel 2021
- Lavorare con la visualizzazione delle parole chiave - Tutorial di formazione QTP 2
- Che cos'è il ciclo di vita di difetti / bug nei test del software? Tutorial sul ciclo di vita dei difetti
- Tutorial JIRA Bug Tracking Tool: come utilizzare JIRA come strumento di ticketing
- Come rivedere il documento SRS e creare scenari di test - Formazione sul test del software su un progetto live - Giorno 2