Il QA dovrebbe sempre cercare di rendere i bug facili da riprodurre il più possibile e la descrizione del bug dovrebbe contenere i passaggi.

Tuttavia, se non riescono a riprodurre facilmente i bug, dovrebbero comunque essere inseriti nel database dei bug con titoli / intestazioni adatti e una descrizione completa di ciò che hanno fatto per causare il bug. La descrizione del bug dovrebbe indicare chiaramente che non è possibile riprodurre il bug (magari con qualche commento sulla falsariga di "provato cinque volte, è successo una volta"). In questo modo, se qualcun altro vede lo stesso bug, può aggiungere al database dei bug i risultati e anche ottenere il maggior numero di informazioni che in futuro potrebbero essere fondamentali per farti risparmiare tempo nel rintracciare il problema.

Inoltre, puoi filtrare le informazioni - potrebbero esserci molti bug in diversi sistemi che tu sai sono tutti collegati (ad esempio) a un'area del codice - se il QA non riporta nulla (come possono fare) t riprodurli) quindi questa informazione non ti arriva.

Sembra che il tuo dipartimento di QA stia facendo troppi test di esplorazione (cioè non hanno un buon piano di test).

I test esplorativi sono buoni e identificano le aree problematiche, ma da lì dovrebbero essere definiti dei casi di test riproducibili (ad esempio un piano di test) da eseguire che rivelano bug specifici.

Ci sono una serie di motivi per cui è necessaria una riproduzione corretta (non solo buona, ma necessaria):

1. Devi fare una riproduzione in modo da poter eseguire il debug / rintracciare la causa.
2. Il QA dovrà essere in grado di verificare la correzione una volta terminato.
3. Ulteriori passaggi di test dovranno effettuare regressioni sui precedenti bug.
4. I bug noti possono essere eliminati se l'esposizione è troppo piccola o la riproduzione è troppo improbabile.

Quindi, come fa notare SteveCzetty: chiudilo come nessuna replica e torna al lavoro.

Se il bug non può essere riprodotto in modo coerente, in che modo QA saprà mai se è stato riparato?

Sì, dovresti aspettarti di più da loro. Dovrebbero essere in grado di dire:

1. Started new instance of program
2. I pressed button A
3. Entered "test text" into the TEST NAME field on Form #1
4. Pressed button B
5. Observed that the program crashed with this message (see attached screenshot).

Se tutto ciò che dicono è "si è schiantato", non sono molto buoni. Anche se i passaggi precedenti non sono riproducibili al 100%, un campione sufficientemente ampio di questi arresti anomali potrebbe aiutare a restringere la causa, una volta rilevato un modello.

Il mio consiglio è di leggere quegli errori e dare loro un buon vecchio pensiero. Se non riesci a capire una potenziale causa, dimenticateli per ora.

Il QA dovrebbe documentare ogni problema che trova, anche se non ha idea di come sia successo. È compito di QA cercare di riprodurre i problemi, ma realisticamente questo non sarà sempre possibile. A volte non ha nulla a che fare con quello che hanno fatto negli ultimi 10 minuti. Qualcosa è entrato in uno stato non valido un giorno fa, ed è diventato evidente solo a causa di uno degli ultimi 10 passaggi.

Con questi bug "1 in 1000", il QA dovrebbe provare a riprodurli per un po '. Se non hanno successo, dovrebbero documentare il bug, quindi provare un po 'di più.

Il motivo per cui dovrebbero ricevere il bug inserito abbastanza presto è che il programmatore conosce il codice molto meglio del QA e potrebbe immediatamente conoscere il problema. Potrebbe essere il codice che hanno refactored. Potrebbe essere quella funzione che a metà implementarono poi dimenticata. Forse non ne hanno idea, ma non ha senso sprecare qualche ora nel tentativo di riprodurre un problema ovvio per chi lo ha codificato. Il tester può sempre aggiungere ulteriori dettagli al bug più tardi.

Il bug dovrebbe includere quante più informazioni possibili. Qualunque cosa il tester possa ricordare sull'avanzamento del problema dovrebbe essere annotato con dettagli dolorosi. Devono essere allegati anche eventuali registri di crash, snapshot del database o schermate pertinenti.

Se il bug non viene mai riprodotto, ottimo! Non fa male averlo nel database. Se il programma viene rilasciato e un utente segnala un bug simile in seguito, puoi confrontare la loro esperienza con le informazioni contenute nel rapporto e cercare eventuali somiglianze.

Nella mia esperienza, i bug più succosi non vengono trovati dai seguenti piani di test. A volte devi lasciar stufare le cose per alcune settimane per far allineare la luna e le stelle che causano un brutto insetto. Se il QA può fare qualche lavoro investigativo e trovare alcune possibili cause, dagli una pacca sulla spalla. Ma a volte, chissà cosa è successo?

Molti bug non sono riproducibili finché non sai come risolverli. Ciò non significa che non debbano essere corretti. L'anno scorso ho corretto un bug che io ancora non so come riprodurre. Richiede una combinazione bizzarra di un errore di trasmissione con precisione temporale insieme a dati spazzatura molto specifici in una determinata posizione di memoria nello stack. Sfortunatamente, uno dei nostri clienti è "abbastanza fortunato" da entrare in quella condizione tutto il tempo.

Quindi, incoraggiando in ogni modo il QA a includere passaggi di riproducibilità laddove possibile, ma non criticarli se non possono farlo. A volte ti aiuterà a sapere dove aggiungere la registrazione. A volte tutto ciò che fa è dirti che non causa il bug, ma una segnalazione di bug è sempre utile.

Se vuoi che il QA includa i passaggi per riprodurre il bug, se possibile, allora la risposta è sì. Se intendi dovrebbero registrare solo bug che sono in grado di riprodurre, quindi assolutamente no. I bug sono bug, che avvengano solo a mezzanotte di luna piena o ogni volta che lo guardi. Alcuni bug non sono deterministici (l'esempio classico è una variabile non inizializzata, in cui il valore rilevato è semi-casuale), ciò non significa che non dovrebbero essere registrati, investigati e, se possibile, riparati.

I bug non riproducibili dovrebbero generalmente avere una priorità bassa, ma dovrebbero essere sicuramente registrati.

IMO, dovresti. Il QA non sta facendo il suo lavoro se non può darti alcuna procedura di riproduzione. Non perdere tempo a cercare di riprodurre qualcosa che non puoi, basta chiuderlo come "Impossibile riprodurre" e andare avanti.

Il tuo tempo è molto più prezioso di quello.

Una segnalazione di bug dovrebbe contenere:

• Passaggi per la riproduzione
• Comportamento effettivo
• Comportamento previsto

per esempio:.

• Ho eliminato tutti i fornitori dal database (utilizzando DELETE * FROM tSuppliers ), ho aperto la finestra di dialogo del fornitore e ho fatto clic sull'elenco a discesa Fornitore.
• L'elenco conteneva il seguente messaggio: GUPOS ERROR #0000000: SOMETHING WENT WRONG! . Quando ho fatto clic sul messaggio, l'app è scomparsa dallo schermo e il Task Manager.
• Mi aspettavo di vedere una lista vuota o (preferibilmente) un messaggio come "Nessun fornitore trovato". Fare clic sulla lista vuota o sul messaggio non dovrebbe avere alcun effetto. Ovviamente l'app non dovrebbe scomparire senza preavviso in nessuna circostanza.

Quindi, sì - dovrebbe contenere i passaggi da riprodurre. Il fatto che non sentano il bisogno di includerlo sembrerebbe indicare che pensano che il loro compito sia "rompere il software", piuttosto che identificare i difetti.

Il QA dovrebbe essere in grado di riprodurre i bug in base ai passaggi inseriti. Se ci hanno provato, non possono ancora riprodursi, dovrebbero comunque inserire i bug con tutti i dettagli che hanno con il timestamp in modo che gli sviluppatori possano dare un'occhiata ai registri dell'applicazione e di debug per maggiori dettagli.

Il denaro è in gioco qui. Perché un membro del team dovrebbe essere in grado di creare un compito poco definito e con poche probabilità di successo che grava su uno sviluppatore (si spera) altamente pagato?

Non si tratta di beccarsi ordine, gerarchia, arroganza, noi contro di loro, o qualcosa del genere. Si tratta solo di investire in attività che aggiungono valore al prodotto.

Quando è possibile dimostrare che un problema ha un impatto negativo e misurabile sul valore del prodotto, è necessario studiarlo, riprodurlo e correggerlo. Correggi la pipeline del tuo prodotto per filtrare il rumore.

il tuo team addetto al QA fa schifo

Vai da loro e di 'loro di leggere un documento che ogni tester professionista deve aver stampato direttamente nel cervello (ero un tester una volta e ce l'ho ancora proprio lì, nel mio cervello): Come segnalare efficacemente i bug .

In particolare, indirizzali alla sezione "Mostrami come mostrarmi" :

This is the era of the Internet. This is the era of worldwide communication. This is the era in which I can send my software to somebody in Russia at the touch of a button, and he can send me comments about it just as easily. But if he has a problem with my program, he can't have me standing in front of it while it fails. "Show me" is good when you can, but often you can't.

If you have to report a bug to a programmer who can't be present in person, the aim of the exercise is to enable them to reproduce the problem. You want the programmer to run their own copy of the program, do the same things to it, and make it fail in the same way. When they can see the problem happening in front of their eyes, then they can deal with it...

Se iniziano a urlare contro di te lamentando che "i bug possono provenire da più direzioni contemporaneamente" , digli che succhiano ancora più di quanto pensassi prima. Di 'loro che Testability è una funzione che dovrebbero valutare tra le altre funzionalità del progetto e che dovrebbero investire gli sforzi per ottenere questa funzionalità giusta.

• I miglioramenti di testabilità che si possono ottenere quando c'è un tester professionale focalizzato su di esso potrebbero essere molto simili alla magia. L'ho imparato da me pochi mesi fa. L'ingegnere di QA che lavora con il nostro team mi ha dato una manciata di richieste di testabilità per lo sviluppo di alcuni componenti nella nostra applicazione. Le cose che mi chiedevano non avevano molto senso per me, ma gliel'ho dato solo supponendo che lui lo sapesse come professionista. Subito dopo aver terminato, è venuto fuori con uno strumento che ha ridotto gli sforzi di test di ordine di grandezza . Ha detto che la maggior parte si basava su queste richieste criptiche che ho implementato, vai a capire.