Cosa fare con i bug che non vengono riprodotti?

Ho un tester che durante il test si verificherà un errore (ok finora), ma poi lo riporta frequentemente subito. Successivamente (gli sviluppatori) scopriamo che il tester non ha provato a riprodurre il problema e (quando richiesto) non riesce a trovare un modo per farlo accadere di nuovo.

Ora questi sono ancora bug, non voglio ignorarli. Ma senza passaggi repro sono un po 'bloccato. A volte c'è una traccia dello stack (anche se spesso non è utile perché si tratta di un framework compatto e non ci sono numeri di riga). Ma quando ce n'è uno posso prendere la traccia dello stack e aprire il codice e iniziare a indovinare, ma ciò non porta a "correzioni" verificabili.

Cosa fai in scenari come questo?

Un bug senza contesto non è un bug, è un colpo di fortuna. Il problema potrebbe essere il tuo codice, potrebbe essere una libreria di terze parti, potrebbe essere l'hardware o potrebbe essere la radiazione solare a causare il capovolgimento di un singolo bit. Se non riesci a riprodurlo con almeno un po 'di regolarità (anche se solo "succede una volta ogni 10 o 20 volte faccio X"), non è molto meglio del tuo tester che ti dice "Qualcosa da qualche parte è andato storto in qualche modo - risolvilo" .

Potrebbe essere necessario spiegare al tester che il suo compito non è solo quello di generare input fino a quando qualcosa non si interrompe. Se lo fosse, potresti sostituirlo con un generatore di numeri casuali. Parte del suo lavoro è identificare i bug, il che implica identificare come produrli.

Alla fine, se né lo sviluppatore né il tester sono in grado di riprodurre il bug, questo dovrebbe essere chiuso ma contrassegnato come tale.

Tuttavia, è discutibile quanto tempo impieghi per arrivare a quel punto.

Alcune persone sostengono che se non è immediatamente riproducibile, dovrebbe essere immediatamente chiuso.

Di solito mi sforzo di cercare di ottenere maggiori informazioni dall'autore del problema. Potrebbe esserci qualcosa che hanno dimenticato nel rapporto originale. Avere una conversazione sui passaggi richiesti può spesso rivelare le informazioni mancanti.

Un ultimo pensiero - chiuso come "no-repro" non significa fisso. Se c'è un problema reale, si rivelerà prima o poi e avere tutte le informazioni che ti aiuteranno quando potrai finalmente riprodurre il problema.

Alcuni altri suggerimenti:

1. Aggiungi la registrazione (e non solo un keylogger:}) al tuo codice prodotto. I bug "No repro" possono essere un colpo di fortuna, ma possono essere un danneggiamento della memoria o dello stato che si verifica solo su un sistema sporco usato in modo imprevisto (cioè come un computer dei clienti). La registrazione o la traccia delle informazioni possono aiutarti a capire cosa potrebbe esserci stato di sbagliato quando il tester ha rilevato il colpo di fortuna.

2. Analizza il resto dei bug "no repro" nel database (o qualunque cosa tu usi per il tracciamento dei bug). Spesso, i flukes si raggruppano in un'area del prodotto. Se sembra che un componente sia in errore, controlla il componente per possibili difetti, aggiungi una registrazione aggiuntiva a quel componente - o entrambi.

3. Prendi mezz'ora o giù di lì e guarda il tuo test tester. Il loro approccio potrebbe darti un'idea di ciò che è andato storto (ad es. "Interessante - non sapevo che si potesse arrivare a quel dialogo in quel modo"). È inoltre possibile che saltino involontariamente una finestra di dialogo o un passaggio di configurazione. Vale la pena investire un po 'di tempo in testa.

Faccio QA su un grande codice commerciale, questo scenario irritante si presenta troppo spesso. Di solito è indicativo di non avere procedimenti corazzati per la costruzione del binario su tutte le piattaforme che supportiamo. Quindi, se lo sviluppatore crea il proprio codice (che deve fare per eseguire il debug e correggere) e non segue la stessa procedura di creazione della lettera, c'è la possibilità che i bug dipendenti dal sistema sembrino svanire magicamente (o apparire) . Naturalmente queste cose di solito si chiudono con "funziona per me" nel database dei bug e se falliscono la prossima volta che si verifica il problema, il bug può essere riaperto. Ogni volta che sospetto che un bug possa dipendere dal sistema, provo a testarlo su una varietà di piattaforme e segnalare in quali condizioni si verifica. Spesso un problema di corruzione della memoria viene visualizzato solo se i dati danneggiati sono sufficientemente grandi da causare un arresto anomalo. Alcune piattaforme (combinazioni HW e OS) potrebbero bloccarsi più vicino alla vera fonte della corruzione, e questo può essere molto prezioso per il povero che deve eseguirne il debug.

Il tester deve fare un po 'di valore aggiunto, oltre a riferire che il suo sistema mostra un guasto. Trascorro molto tempo a cercare falsi positivi, forse la piattaforma in questione era sovraccarica o la rete aveva un problema tecnico. E sì, a volte puoi ottenere qualcosa che è veramente influenzato da eventi di temporizzazione casuali, i bug hardware possono spesso essere come un esempio di proto: se due richieste di dati ritornano esattamente nello stesso periodo di clock e la logica hardware per gestire il potenziale conflitto è difettosa, quindi il bug verrà visualizzato solo in modo intermittente. Allo stesso modo con l'elaborazione parallela, a meno che con un'attenta progettazione non sia stata vincolata la soluzione indipendente da quale processore fosse più veloce, è possibile ottenere bug che si verificano solo una volta in una luna blu e la loro imporbibilità statistica rende il debug un incubo.

Inoltre, il nostro codice viene aggiornato, di solito molte volte al giorno, rintracciare un numero esatto di revisione del codice sorgente per quando è andato a sud può essere un'informazione molto utile per lo sforzo di debug. Il tester non dovrebbe avere una relazione contraddittoria con i debugger e gli sviluppatori, è lì come parte di un team per migliorare la qualità del prodotto.

Esistono due tipi di bug che non sono riproducibili:

1) Quelli che un tester (o utente) ha visto una volta ma non è stato in grado o non ha tentato di riprodurre.

In queste situazioni dovresti:

• Controllare molto brevemente il corso base delle azioni che hanno mostrato il difetto per assicurarsi che non sia riproducibile.

• Parla con il tester / utente per vedere se ci sono altre informazioni che potrebbero aiutare.

• Incrociali con altri difetti che potrebbero essere correlati per vedere se hai abbastanza informazioni per esaminarli in base a più istanze. Potresti scoprire che questo problema non ti fornisce informazioni sufficienti per continuare, tuttavia, se associato a una serie di altri problemi, potrebbe suggerirti qualcosa di non giusto che vale la pena indagare.

• Se non hai ancora abbastanza per continuare, devi spiegare all'utente / tester che non hai abbastanza informazioni. Descrivi educatamente a loro che aspetto sarebbero sufficienti e perché sono necessarie.

2) Quelli in cui non possono essere riprodotti in modo affidabile, tuttavia ci sono prove sufficienti (in termini di ricorrenze ripetute) per suggerire l'esistenza del difetto, quindi tendo a vedere che si tratta di problemi dello sviluppatore e che lo sviluppatore - supportato dal tester / utente: deve indagare.

Questo sarà probabilmente lento e doloroso, probabilmente dovrai camminare sul codice, aggiungere più log, guardare i dati e parlare in profondità con i tester / utenti, ma se ci sono prove sufficienti per suggerire che è probabile che ci sia è un problema che è necessario assumerne la proprietà e fare tutto il necessario per risolverlo.

Sembra che questo accada relativamente frequentemente - il che mi fa meravigliare, è perché la maggior parte dei bug è davvero difficile da riproporre, o è per qualche altra ragione che non ci sta provando? Sai perché non sta cercando di riprodurre il problema? È perché non si rende conto di quanto sia importante per te? O forse ha altre pressioni - un responsabile del test che vuole solo che superi rapidamente i test assegnati e getti gli insetti sul muro, per esempio? O forse non è sicuro di come procedere?

Concordo con gli altri sul fatto che lavorare su una migliore registrazione è una priorità. Nel frattempo, se sospetti che la mancanza di abilità / fiducia dei tester possa essere un problema, allora mi piace molto questo articolo di Danny Faught sull'isolamento dei bug - potresti indicarlo per cominciare.

Se il problema si manifesta a causa della pressione del management, hai le mie simpatie, dato che è difficile da risolvere, specialmente se tester e programmatori riferiscono a manager diversi e i manager non sono propensi a "aiutare" un altro team.

In genere noto che non è riproducibile, ma lo lascio aperto fino al completamento del batch di test o iterazioni.

Se non è stato riprodotto da quel punto, viene chiuso, ma può essere riaperto se si incontra di nuovo.

attaccare un keylogger sulla workstation di questo tester!

Bene, il primo compito è avere un sistema di test riproducibile. Il tester deve avere un processo ben definito, se possibile automatico.

Hanno queste tre condizioni:

• Lo stesso binario
• Stessi passi
• Stessa macchina

Se il bug appare sporadicamente con le 3 condizioni precedenti, inizia a isolare ulteriormente. Considera ogni livello dello stack di sistema e la sua configurazione.

Un modo per rilevare gli errori di gestione della memoria è eseguire il programma su più sistemi operativi con più compilatori. Valgrind può anche aiutare.

Tuttavia, i sistemi in genere paralleli possono indurre bug non repro. Cose come dimensioni del buffer e velocità di elaborazione, asincrono, blocchi di database, intrecci di scrittura a memoria variabile; tutti questi possono generare problemi. E così via.

Prima di tutto, dovresti avere una rigorosa procedura di test (ma ti capisco, nella mia azienda ciò che hai descritto accade di frequente).

A seconda della gravità del bug, è possibile investire un po 'di tempo su di esso o (meglio) ignorarlo fino a quando non vengono fornite le fasi di riproduzione.