this scenario explains how important it is document frequently encountered errors
Credi che gli errori software si verifichino una sola volta e che una volta risolti non si ripresentino mai? Penso che circa il 30% degli errori si ripresenti.
In questo articolo, voglio spiegare quanto sia importante documentare alcuni degli errori riscontrati di frequente.
Di seguito ne troverai alcuni aree comuni in cui si riscontrano problemi e un modello per documentarli.
Spero che lo troverai utile!
Immagine fonte
Scenario 1
Il codice è distribuito e pronto per il controllo qualità. John, il tester è pronto con i suoi casi di prova. A metà del test, incontra un problema. Sente che è stato notato diverse volte prima, ma John non sapeva come risolverlo.
Sia John che Sheryl sono andati a cercare Smith che aveva visto lo stesso errore in precedenza e lo aveva risolto in precedenza. Purtroppo, quel giorno Smith era in licenza.
Cosa dovrebbe fare John adesso? John dovrebbe provare a contattare Smith per trovare una soluzione anche quando Smith non è disponibile?
Pertanto, se un problema ambientale viene osservato ripetutamente in più versioni, è una buona idea documentare i dettagli e posizionalo in una posizione condivisa. Ciò eliminerà la dipendenza da qualsiasi individuo e aiuterà tutti i membri del team a trovare una soluzione da soli quando ciò accade.
Scenario n. 2
John sta testando una nuova versione e si imbatte di nuovo in un errore noto. Questa volta sa che è stato creato un difetto in una delle versioni precedenti. Ma la domanda è: 'come faccio a trovare il numero del difetto e altri dettagli associati?'
Anche in questo caso cosa pensi aiuterebbe John?
- Cerca il difetto in Strumento di tracciamento dei difetti con la descrizione?
- Cerca in tutto il passato rapporti sui difetti ?
- Rivolgersi al suo capo squadra per assistenza?
Queste sono possibilità.
Ma a mio parere, se tali questioni sono ben documentate in un'area separata e condivise con il team, aggiunge valore e fa risparmiare tempo.
Cosa imparerai:
- Alcune delle aree con errori frequenti:
- Scarica i modelli per tenere traccia degli errori riscontrati di frequente
- Vantaggi della documentazione degli errori riscontrati di frequente
- Conclusione
- Lettura consigliata
Alcune delle aree con errori frequenti:
1) File dei parametri - Sulla base della mia esperienza con lo strumento Informatica, in molti casi ho notato che il file param punta a una connessione DB errata. Ha provocato gli stessi problemi più volte. Il motivo principale era che la connessione era condivisa tra dev e QA. Quindi, il file param doveva sempre essere aggiornato secondo le necessità per evitare l'errore.
2) URL che punta a DB errato
3) Problemi di accesso - Gli utenti incontrano problemi quando hanno autorizzazioni di accesso al DB insufficienti o errate o In questo caso, un documento che delinei i passaggi da compiere o la persona / le persone da contattare sarebbe di grande aiuto.
4) Emissione dei dati di prova - L'utilizzo di un formato o di valori di dati errati il più delle volte causerà problemi.
5) Problemi DB - Il timeout della connessione DB è uno di questi problemi comuni. Alcuni dei tempi di inattività sono temporanei, pianificati e, a volte, potremmo aver bisogno dell'assistenza di DBA. Gli utenti vengono avvisati in anticipo per la manutenzione programmata, ma per errori temporanei e risoluzione, i tester hanno sicuramente bisogno
La maggior parte degli errori ripetuti sono generalmente problemi ambientali .
Tuttavia, problemi di codice non può essere ignorato. La discussione sopra è generica e non include problemi di codice perché i problemi di codice sono più specifici per l'applicazione, il framework, il linguaggio di programmazione, ecc.
input e output di file c ++
Potrebbe esserci anche una piccola area di difetti inserimento dati o errore di utilizzo umano S .
ScaricaModelli per tenere traccia degli errori riscontrati di frequente
Formato Word
=> Scarica il modello di monitoraggio degli errori (Mondo)
Formato Excel
=> Scarica il modello di monitoraggio degli errori (Excel)
Vantaggi della documentazione degli errori riscontrati di frequente
1) Elimina la dipendenza - Nello scenario 1, John dipendeva da Smith per la risoluzione. Se ci fosse stato un documento per il riferimento di Giovanni, non sarebbe stato così.
2) Turnaround più veloce - Prendiamo lo scenario 2. Un tester non dovrebbe passare attraverso l'intero elenco dei difetti già registrati se ci fosse un documento dedicato per i problemi ad alta frequenza.
3) Aiuta i nuovi membri del team a essere autosufficienti
4) Aiuta a risolvere gli errori umani
Conclusione
Direi che è decisamente vantaggioso documentare i problemi più frequenti in quanto costituirebbe un ottimo riferimento e un valore aggiunto.
Può diventare noioso documentare mentre è in corso l'esecuzione del test, ma come best practice, durante l'esecuzione è possibile prendere appunti approssimativi che possono essere successivamente riassunti e aggiornati in documenti condivisi.
Lettura consigliata
- 10 migliori sistemi di gestione dei documenti per un flusso di lavoro migliore
- MongoDB Aggiorna ed elimina documento con esempi
- Documento di query MongoDB utilizzando il metodo Find () (esempi)
- Esercitazione sul sistema di gestione dei documenti di SharePoint
- 7 tipi di errori software che ogni tester dovrebbe conoscere
- Come testare in modo più intelligente: esplora di più, documenta di meno
- Scenario di test vs scenario di test: qual è la differenza tra questi?
- Come scrivere un documento di strategia di test (con modello di strategia di test di esempio)