A volte il mio team addetto al controllo qualità segnala errori, ma né io né loro abbiamo idea di come riprodurli. Questo porta a sessioni di debug molto lunghe e frustranti che a volte non danno nemmeno risultati.

Il mio software è fortemente legato all'hardware proprietario, quindi i bug possono provenire da molte direzioni contemporaneamente.

Devo aspettarmi qualcosa in più rispetto a "il tuo software si è arrestato in modo anomalo quando ho premuto un pulsante" o dovrei immaginare cosa è successo?

MODIFICARE:

Uno dei miei colleghi ha sottolineato che probabilmente siamo tutti sviluppatori qui, quindi i risultati potrebbero subire un leggero pregiudizio

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

Tuttavia, se non riescono a riprodurre facilmente i bug, dovrebbero comunque essere inseriti nel database dei bug con titoli / titoli adeguati e una descrizione completa di ciò che hanno fatto per causare il bug. La descrizione del bug dovrebbe indicare chiaramente che non possono riprodurre il bug (forse 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 le proprie scoperte e anche ottenere quante più informazioni possibili che potrebbero essere fondamentali per risparmiare tempo nel rintracciare il problema.

Inoltre, puoi filtrare le informazioni - potrebbero esserci molti bug in diversi sistemi che sai sono tutti collegati a (ad esempio) un'area del codice - se il QA non segnala nulla (poiché non possono riprodurli ) quindi queste informazioni non ti arrivano.

Sembra che il tuo dipartimento di controllo qualità stia facendo troppi test esplorativi (cioè non hanno un buon piano di test).

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

Esistono diversi motivi per cui è necessaria una riproduzione corretta (non solo buona, ma necessaria):

1. Devi riprogrammare 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 fare regressioni su bug precedenti.
4. I bug noti possono essere eliminati se l'esposizione è troppo piccola o la riproduzione è troppo improbabile.

Quindi, come osserva SteveCzetty: chiudilo come nessuna ripetizione e torna al lavoro.

Se il bug non può essere riprodotto in modo coerente, come farà mai il QA a sapere se è stato corretto?

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

1. Avviata nuova istanza del programma
2. Ho premuto il pulsante A
3. Immettere "testo di prova" nel campo NOME PROVA sul modulo n. 1
4. Premere il pulsante B
5. Osservato che il programma si è bloccato con questo messaggio (vedi screenshot allegato).

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

Il mio consiglio è di leggere quei bug e dare loro una buona vecchia idea. Se non riesci a capire una potenziale causa, dimenticala per ora.

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

Con questi bug "1 su 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 inserire il bug 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 hanno parzialmente implementato e poi dimenticato. Potrebbero non averne idea, ma nel tester non ha senso sprecare qualche ora cercando di riprodurre un problema ovvio per la persona che lo ha codificato. Il tester può sempre aggiungere ulteriori dettagli al bug in un secondo momento.

Il bug dovrebbe includere quante più informazioni possibili. Qualunque cosa il tester riesca a ricordare in merito alla causa del problema, dovrebbe essere scritto in modo doloroso nei dettagli. Dovrebbero essere collegati anche eventuali registri degli arresti anomali, istantanee del database o schermate pertinenti.

Se il bug non viene mai riprodotto, fantastico! Non fa male averlo nel database. Se il programma viene rilasciato e un utente segnala un bug simile in un secondo momento, è possibile confrontare la propria esperienza con ciò che è nel report e cercare eventuali somiglianze.

Nella mia esperienza, i bug più succosi non si trovano dai seguenti piani di test. A volte devi lasciare che le cose stufino per alcune settimane per far sì che la luna e le stelle si allineino causando un brutto insetto. Se il QA può svolgere qualche lavoro investigativo e trovare alcune possibili cause, dai loro una pacca sulla spalla. Ma a volte, chi sa cosa è successo?

Molti bug non sono riproducibili fino a quando non sai come risolverli. Ciò non significa che non debbano essere riparati. Ho sistemato un bug dello scorso anno che ancora non so come riprodurre. Richiede una bizzarra combinazione di un errore di trasmissione programmato con precisione insieme a dati spazzatura molto specifici in una determinata posizione di memoria nello stack. Sfortunatamente, uno dei nostri clienti è abbastanza "fortunato" da entrare sempre in quella condizione.

Pertanto, incoraggia sicuramente il QA a includere passaggi di riproducibilità ove possibile, ma non criticare se non possono. A volte ti aiuterà a sapere dove aggiungere la registrazione. A volte tutto ciò che fa è dirti cosa non causa il bug, ma una segnalazione di bug è sempre utile.

Se vuoi dire che il QA dovrebbe includere i passaggi per riprodurre il bug, se possibile, allora la risposta è sì. Se vuoi dire che dovrebbero solo registrare bug che sono in grado di riprodurre, allora assolutamente no. I bug sono bug, sia che si verifichino 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 raccolto è semi-casuale), ciò non significa che non dovrebbero essere registrati, investigati e, se possibile, corretti.

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

IMO, dovresti. Il QA non sta svolgendo il proprio lavoro se non è in grado di fornire passaggi di riproduzione. Non perdere tempo cercando di riprodurre qualcosa che non puoi, basta chiuderlo come "Impossibile riprodurre" e andare avanti.

Il tuo tempo è molto più prezioso di così.

Una segnalazione di bug dovrebbe contenere:

• I passaggi per riprodurre
• Comportamento reale
• 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.
• La lista conteneva il seguente messaggio: GUPOS ERROR #0000000: SOMETHING WENT WRONG!. Quando ho fatto clic sul messaggio, l'app è scomparsa dallo schermo e Task Manager.
• Mi aspettavo di vedere un elenco vuoto o (preferibilmente) un messaggio come "Nessun fornitore trovato". Fare clic sull'elenco vuoto o sul messaggio non dovrebbe avere alcun effetto. L'app ovviamente non dovrebbe scomparire senza preavviso in nessun caso.

Quindi sì: dovrebbe contenere i passaggi per la riproduzione. Il fatto che non sentano il bisogno di includerlo sembrerebbe indicare che pensano che il loro lavoro sia "rompere il software", piuttosto che identificare i guasti.

Il QA dovrebbe essere in grado di riprodurre i bug in base ai passaggi inseriti. Se si sono sforzati, ma non sono stati in grado di 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.

Qui è in gioco il denaro. Perché un membro del team dovrebbe essere in grado di creare un'attività scarsamente definita e con poche possibilità di successo che grava su uno sviluppatore (si spera) ben pagato?

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

Quando si può dimostrare che un problema ha un impatto negativo e misurabile sul valore del prodotto, è necessario esaminarlo, riprodurlo e risolverlo. Correggi la pipeline dei difetti del prodotto per filtrare il rumore.

la tua squadra di controllo qualità fa schifo

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

In particolare, indicali nella sezione "Mostrami come mostrarmi" :

Questa è l'era di Internet. Questa è l'era della comunicazione mondiale. Questa è l'era in cui posso inviare il mio software a qualcuno in Russia con il semplice tocco di un pulsante e può inviarmi commenti altrettanto facilmente. Ma se ha un problema con il mio programma, non può farmi stare davanti mentre fallisce. "Mostrami" va bene quando puoi, ma spesso non puoi.

Se devi segnalare un bug a un programmatore che non può essere presente di persona, lo scopo dell'esercizio è consentire loro di riprodurre il problema. Volete che il programmatore esegua la propria copia del programma, vi faccia le stesse cose e lo faccia fallire allo stesso modo. Quando riescono a vedere il problema accadere davanti ai loro occhi, allora possono affrontarlo ...

Se iniziano a urlare contro di te lamentandoti che "i bug possono venire da molte direzioni contemporaneamente" , digli che fanno schifo anche più di quanto pensassi prima. Spiega loro che la Testabilità è una funzionalità che dovrebbero valutare tra le altre funzionalità del progetto e che dovrebbero investire gli sforzi per ottenere questa funzionalità nel modo giusto.

• I miglioramenti della testabilità che si potrebbero ottenere quando esiste un tester professionale focalizzato su di essa potrebbero essere molto simili alla magia. L'ho imparato da solo alcuni mesi fa. L'ingegnere addetto al controllo qualità che ha collaborato con il nostro team mi ha dato una manciata di richieste di testabilità da sviluppare per alcuni componenti della nostra applicazione. Le cose che mi ha chiesto avevano molto poco senso per me, ma gliel'ho dato solo supponendo che conoscesse meglio come professionista. Poco dopo aver finito, ha messo a punto uno strumento che ha ridotto gli sforzi di test per ordine di grandezza . Ha detto che la maggior parte era basata su queste richieste criptiche che ho implementato, vai a capire.