Cosa fare con bug che non vengono riprodotti?

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 un solo bit da capovolgere. Se non riesci a riprodurlo con almeno alcuni 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 - aggiustalo ".

Potresti dover spiegare al tuo tester che il suo compito non è solo generare input finché qualcosa non si rompe. Se lo fosse, potresti sostituirlo con un generatore di numeri casuali. Parte del suo lavoro consiste nell'identificare i bug, che comportano l'identificazione di come produrli.

In definitiva se né lo sviluppatore né il tester possono riprodurre il bug, questo dovrebbe essere chiuso ma contrassegnato come tale.

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

Alcuni sostengono che se non è immediatamente riproducibile, allora dovrebbe essere chiuso immediatamente.

Di solito mi sforzo di provare a ottenere più informazioni dall'originatore 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 saranno utili quando potrai finalmente riprodurre il problema.

Alcuni altri suggerimenti:

1. Aggiungi il log (e non solo un keylogger:}) al tuo codice prodotto. "I bug senza repro" possono essere i colpevoli, ma possono essere la memoria o la corruzione dello stato che si verifica solo su un sistema sporco usato in modi imprevisti (cioè come un computer dei clienti). Le informazioni di registrazione o tracciamento possono aiutarti a capire che potrebbe essere stato errato quando il tester ha trovato il colpo di fortuna.

2. Analizza il resto dei bug "no repro" nel database (o qualsiasi altra cosa tu usi per il bug tracking). Spesso i felci si raggruppano in un'unica area del prodotto. Se sembra che un componente sia in errore, il codice controlla il componente per verificare eventuali difetti, aggiunge ulteriore registrazione a quel componente o entrambi.

3. Dedica mezz'ora e guarda il tuo test. Il loro approccio potrebbe darti un'idea di cosa è andato storto (ad esempio "interessante - non sapevo che avresti potuto arrivare a quella finestra di dialogo in quel modo"). È inoltre possibile che saltino una finestra di dialogo o un passaggio di configurazione involontariamente. 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 costruire il binario su tutte le piattaforme che supportiamo. Quindi se lo sviluppatore crea il proprio codice (che deve fare il debug e il fix), e non segue la stessa procedura per la lettera, c'è la possibilità che i bug dipendenti dal sistema sembrino scomparire magicamente (o apparire) . Naturalmente queste cose si chiudono solitamente con "lavora per me" nel database dei bug e se falliscono la volta successiva che il problema viene eseguito, 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 riferisco in quali condizioni accade. Spesso si verifica un problema di corruzione della memoria se i dati danneggiati sono di grandezza sufficiente a 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 ragazzo che deve eseguirne il debug.

Il tester deve fare un po 'di valore aggiunto, oltre a segnalare che il suo sistema mostra un errore. Trascorro molto tempo a escludere i falsi positivi - forse la piattaforma in questione era sovraccaricata, o la rete ha avuto un problema tecnico. E sì, a volte si può ottenere qualcosa che è veramente influenzato da eventi di temporizzazione casuale, i bug hardware possono spesso essere come un esempio di proto: Se due richieste di dati restituiscono esattamente lo 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 si sia costretti a rendere la soluzione indipendente dal processore più veloce, è possibile ottenere bug che si verificano solo una volta in una luna blu e la loro imponderabilità statistica rende il debug un incubo.

Anche il nostro codice viene aggiornato, solitamente molte volte al giorno, rintracciando 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 essere in 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 sono stati in grado o non hanno tentato di riprodurre.

In queste situazioni dovresti:

• Controlla brevemente il corso di base delle azioni che hanno mostrato il difetto per assicurarti che non sia riproducibile.

• Parla con il tester / utente per vedere se ci sono altre informazioni che potrebbero essere d'aiuto.

• Confrontali 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 dà abbastanza informazioni per andare avanti, tuttavia quando accoppiato con una serie di altri problemi può suggerirti qualcosa di non giusto che vale la pena investigare.

• Se ancora non ne hai abbastanza, devi spiegare all'utente / tester che non hai abbastanza informazioni. Descrivi cortesemente quali informazioni sarebbero sufficienti e perché è necessario.

2) Quelle in cui non possono essere riprodotte in modo affidabile, tuttavia ci sono prove sufficienti (in termini di ricorrenze ripetute) per suggerire che il difetto esiste, quindi tendo a vedere che si tratta di problemi di sviluppo e che lo sviluppatore supporta dal tester / utente - deve indagare.

È probabile che sia lento e doloroso, è probabile che tu debba percorrere il codice, aggiungere più logging, esaminare i dati e parlare in profondità ai tester / utenti, ma se ci sono prove sufficienti per suggerire che è probabile che ci sia un problema che devi prenderne possesso e fare tutto il necessario per risolverlo.

Sembra che ciò avvenga relativamente frequentemente - il che mi fa meravigliare, è perché la maggior parte degli errori sono veramente difficili da riprodurre, 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 dei test che vuole solo che superi i test assegnati rapidamente e metta i bug oltre il muro, per esempio? O forse non è sicuro di come farlo?

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

Se il problema si rivela dovuto alla pressione del management, hai le mie simpatie, perché è difficile da decifrare, specialmente se i tester e gli ampli; i programmatori riferiscono a diversi manager e i manager non sono inclini a "aiutare" un altro team.

In genere noto che non è riproducibile, ma lo lascia aperto fino a quando quel batch di test o iterazione è completo.

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

inserisci un keylogger sulla workstation di questo tester!

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

Hai queste tre condizioni:

• Same binary
• Stessi passaggi
• Stessa macchina

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

Un modo per rilevare errori di gestione della memoria è eseguire il programma su più SO con più compilatori. Valgrind può anche aiutarti.

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

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

A seconda della gravità del bug, puoi investire un po 'di tempo su di esso o (meglio) ignorarlo fino a quando vengono forniti i passaggi di ripro.