3 worst defect reporting habits
I difetti sono una cosa seria e piccoli errori possono essere costosi.
Sai cosa fare quando trovi un difetto. Segnalalo; o in un file Tracker dei difetti / Strumento di gestione dei difetti o in un foglio Excel. I principi di base sono gli stessi per entrambi i metodi.
Gli strumenti di gestione dei difetti non garantiscono rapporti migliori. Sono buone pratiche che salvano la giornata.
Per apprezzare il bene, dobbiamo riconoscere ciò che non lo è.
Cosa imparerai:
- 3 peggiori abitudini di segnalazione dei difetti e come romperli
- # 1) Pigrizia
- # 2) Correre
- # 3) Mancanza di creatività
- Lettura consigliata
3 peggiori abitudini di segnalazione dei difetti e come romperli
Ecco qui:
# 1) Pigrizia
Non prenderti il tempo per fare il meglio che puoi.
Questo è il processo di tracciamento dei difetti seguito nella maggior parte delle squadre:
(Nota- clicca su qualsiasi immagine per ingrandirla)
Come puoi vedere, il responsabile del test esamina i difetti prima di inviarli ai team QA.
Questa revisione include la conferma:
- Validità: è un bug?
- Completezza: titolo, passaggi, dati, screenshot ecc.
- Duplicati
- Riproducibile o no ... ecc.
So in prima persona che è impossibile che un lead QA sia completo al 100%.
Quindi, l'atteggiamento: “Riporterò il problema nel modo desiderato. Il responsabile del QA può ricontrollare. Può decidere se il difetto è valido / completo o meno 'è la fine del tuo team di QA e della tua credibilità.
Sapevi che alcuni clienti hanno uno SLA per il numero di difetti non validi accettabili? Una volta superato il numero, iniziano a penalizzare gli appaltatori per ogni difetto non valido segnalato?
Rimedio: Esegui la dovuta diligenza e sii responsabile del risultato finale. Si è ripresentato un difetto per informazioni insufficienti o che non è un bug? Potrebbe non essere sempre colpa del team di sviluppo. Non è che non vogliano possedere i problemi nell'applicazione. Potrebbe essere un vero pasticcio del team di controllo qualità. Non lasciare che accada.
# 2) Correre
Facciamolo con un fileesempio.
Di seguito è riportata una schermata di OpenEMR's schermata di creazione del paziente. È un sistema di gestione ospedaliera open source.
Questa schermata consente all'utente di inserire la data di nascita del paziente tramite una funzione di calendario. Quello che non fa è limitare l'ingresso alla scelta dal calendario. Quello che voglio dire è che puoi scegliere il DOB come dire, '31-Mar-1983' dal calendario. Successivamente cambiarlo in '31-Feb-1983'.
Perché il 31 febbraio? Implementare errore di indovinare e prova un dato negativo sul campo; qual è il punto centrale del test, non è vero?
Una volta terminato, faccio clic su 'Crea paziente'. Poiché la data non è valida, mi aspetto che il sistema visualizzi un errore e non crei il paziente. Ma questo non accade. Crea il paziente come di seguito.
Nota i campi Età e Data di nascita nella schermata seguente:
Durante il test, potresti provare alcune volte e decidere che:
- È un bug.
- È riproducibile.
- Non è un duplicato (verifica con il tuo team per confermare)
- Conosci la descrizione esatta del problema
- Inoltre, conosci i passaggi esatti che lo rendono possibile.
Ora che hai la materia prima, sei a posto.
Inizi a segnalarlo. Assegnare la gravità del difetto è un passaggio obbligatorio e il tuo team potrebbe utilizzare qualcosa di simile a tabella seguente per riferimento:
Gravità | Impatto |
---|---|
1 (critico) | • Questo bug è sufficientemente critico da causare un arresto anomalo del sistema, causare il danneggiamento dei file o una potenziale perdita di dati • Provoca un ritorno anomalo al sistema operativo (viene visualizzato un messaggio di arresto anomalo o di errore del sistema). • Causa il blocco dell'applicazione e richiede il riavvio del sistema. |
2 (alto) | • Provoca una mancanza di funzionalità di programma vitale con una soluzione alternativa. |
3 (medio) | • Questo bug ridurrà la qualità del sistema. Tuttavia esiste una soluzione alternativa intelligente per ottenere la funzionalità desiderata, ad esempio tramite un'altra schermata. • Questo bug impedisce che altre aree del prodotto vengano testate. Tuttavia altre aree possono essere testate indipendentemente. |
4 (Basso) | • È presente un messaggio di errore insufficiente o poco chiaro, che ha un impatto minimo sull'uso del prodotto. |
5 (cosmetico) | • È presente un messaggio di errore insufficiente o poco chiaro che non ha alcun impatto sull'uso del prodotto. |
Dal momento che questo difetto non sta bloccando il sistema o bloccando una funzionalità vitale o impedendo il test delle altre aree dell'applicazione, potremmo scegliere 'Basso'.
Sembra giusto?
SBAGLIATO. Dai dati del paziente, tutte le vaccinazioni e altri promemoria sono in ritardo. Questo può o non può essere giusto. Inoltre, per un paziente la loro età determina se vede un pediatra o un medico generico, ecc.
Colpisce i dosaggi dei farmaci e molte altre aree di trattamento di cui potremmo anche non essere a conoscenza.
Quindi, vado con 'High'. Sono d'accordo che sia improbabile che il personale ospedaliero inserisca il DOB di un paziente sbagliato. Ma lascia che sia un fattore che influisce sulla priorità di quando risolvere il problema.
Il mio lavoro di tester è assicurarmi di comunicare al meglio la gravità del problema.
Rimedio: Non abbiate fretta di fare rapporto. Assicurati al 100% di comprendere l'impatto dei problemi da molti punti di vista. È il miglior valore aggiunto che possiamo offrire ai tester. Non stiamo solo dicendo: 'Qualcosa non funziona'. Stiamo anche dicendo: 'Ecco cosa succederà se continua a non funzionare'. Tanta differenza, non è vero?
# 3) Mancanza di creatività
I tester hanno una meravigliosa opportunità di dare suggerimenti per migliorare il software.
Nel tuo Strumento di gestione dei difetti anche tu puoi inviare un difetto di tipo 'Suggerimento di miglioramento'. È qui che puoi essere creativo.
Rimedio: Pensa fuori dagli schemi. Se pensi che a una certa funzionalità manchi un fattore 'Wow' e sai come inserirla, proponi l'idea. Nel peggiore dei casi, potrebbe essere rifiutato e va bene. La parte importante è provare.
Inoltre, usa questo super potere con cautela. Cerca di non fare commenti come 'Odio il colore del banner, per favore cambialo'.
Ecco una buonaesempiodi un suggerimento di miglioramento che ho riscontrato: Sostituendo 'Email al rivenditore' con l'opzione 'Chat con il rivenditore' sul sito di un concessionario di automobili. Si prevede di convertire più traffico in vendite.
Vorrei essere così creativo! Ma forse possiamo lavorarci tutti.
Ecco un bonus. Una lista di controllo per liberarsi da queste cattive abitudini:
1. Il mio titolo esprime il problema in modo chiaro e conciso?
Per esempio:'Creare paziente non funziona' non è un buon titolo. 'La creazione del paziente non riesce anche quando tutti i campi di input contengono valori corretti' è.
2. Qual è il tasso di riproducibilità?
In altre parole, succede sempre? Conosco l'esatta sequenza di passaggi che ripeteranno il problema?
3. Questa piattaforma problematica, browser o utente è specifico?
Quattro. I passaggi sono stati completati e ti portano al problema?
5 . Ho uno screenshot incluso?
6. Devo annotare il mio screenshot per evidenziare aree particolari?
7. Il nome del file immagine allegato è descrittivo?
Non utilizzare qualcosa come 'Untitled.jpg'. Dagli un nome descrittivo.
8. Ho incluso i dati del test?
Per esempio:Per un difetto in un modulo di amministrazione che richiede credenziali di autorizzazione, includerle. Il team di sviluppo può o meno avere accesso all'ambiente QA. Non vuoi un ritardo e un follow-up su qualcosa di così semplice.
9. Posso fornire altri dettagli per rafforzare il mio difetto?
(Esempio:un riferimento all'FRD o una conversazione con il cliente, ecc.)
10. Capisco quanto sia grave il problema da diverse prospettive?
undici. Conosco la causa principale del problema? Se sì, ho prove (forse file di registro) e posso includerle? Tieni presente che potresti non saperlo sempre o aver bisogno di saperlo. Ma se lo fai, non fa male includerlo.
12. Il rapporto sui difetti è privo di problemi di grammatica, formato, ortografia e punteggiatura?
domande e risposte del colloquio di test delle applicazioni mobili
13. Conosco un modo per migliorare il prodotto?
Pensi che questo richieda tempo? Ebbene, una volta che diventa un'abitudine, non lo sarà più.
Fare il tifo per il meglio segnalazione dei difetti routine!
Circa l'autore: Questo articolo è stato scritto dal membro del team STH Swati.
Sentiti libero di pubblicare le tue domande / commenti qui sotto.
Lettura consigliata
- Perché la segnalazione dei bug è un'arte che dovrebbe essere appresa da ogni tester?
- Che cos'è il ciclo di vita di difetti / bug nei test del software? Tutorial sul ciclo di vita dei difetti
- Esempi di report di bug per applicazioni Web e di prodotto
- Che cos'è la tecnica di test basata sui difetti?
- Processo di gestione dei difetti: come gestire un difetto in modo efficace
- Processo di valutazione dei difetti e modi per gestire la riunione di valutazione dei difetti
- Come scrivere una buona segnalazione di bug? Suggerimenti e trucchi
- 3 strategie per affrontare un difetto bloccante