Come convincere i membri del team dell'esistenza di un "mandelbug"

Stiamo sviluppando un'applicazione; include una libreria sviluppata da un altro programmatore, questa libreria comunica con il server tramite più connessioni di rete e ciò comporta la collaborazione di più thread. Il codice lato server è piuttosto complicato e non abbiamo accesso al codice sorgente.

Recentemente ho scoperto un mandelbug che a volte fa crash dell'applicazione. Potrei riprodurlo una volta e ottenere una traccia dello stack, quindi ho aperto una segnalazione di bug. Il bug stesso è facile da correggere (eccezione web non rilevata in uno dei thread in background, che fa chiudere CLR al programma).

Il problema è che lo sviluppatore si rifiuta di correggere l'errore, perché "non è convinto che esista". Sfortunatamente per me il capo si schiera con lui e dice che questo errore non può essere risolto se non faccio un "solido test case" per dimostrare l'esistenza del bug e per fare unit test verificando che sia sparito. Ciò che è sostanzialmente impossibile a causa della natura del bug.

Qualche consiglio?

Se possibile, potrebbe essere necessario del tempo per verificare se questo difetto può essere riprodotto inserendo un po 'di sospensione o blocco nel codice dell'applicazione. Ma non passare troppo tempo. Poiché questo problema è dovuto al multi-theading (e anche come hai osservato), il suo verificarsi sarà raro.

Il mio consiglio è di non sudare troppo. Continua il tuo lavoro. Ogni volta che ti imbatti in questo crash, aggiorna la tua segnalazione bug con la traccia dello stack, dicendo che si tratta di ripetizione e cambia il proprietario in sviluppatore della libreria. Lascia che il management / lead decida se risolvere o meno in base alla sua frequenza.

Cerca anche di capire la mentalità dello sviluppatore. Hai detto "eccezione Web non rilevata". Lo sviluppatore in questa fase potrebbe non essere del tutto sicuro di quali saranno gli altri effetti della cattura di questo . Quindi potrebbe essere riluttante a toccare il codice.

Quindi, dai tuoi commenti più o meno chiari, ho capito in questo modo:

Sei sicuro che manchi solo una semplice eccezione aggiuntiva e sai già quale riga di codice nella libreria è problematica e come la libreria potrebbe essere riparata.

Perché allora non aggiungi semplicemente le poche righe mancanti di codice alla lib da solo, chiedi gentilmente al team di testare la lib con quelle modifiche? Assicurati che si tratti di una modifica a basso rischio, di facile comprensione da parte dello sviluppatore responsabile della lib. La cosa peggiore che potrebbe accadere è che qualcuno debba annullare quel cambiamento nel tuo VCS se la tua correzione provoca qualche nuovo comportamento imprevisto.

Molte persone sono più facili da convincere quando il lavoro è già finito. Inoltre, reagiscono meglio su "ecco una soluzione migliorata", al contrario di "questo codice è sbagliato, correggilo in qualche modo".

EDIT: quando lo sviluppatore rifiuta ancora di aggiungere quella modifica, l'opzione migliore sta cercando di far funzionare il codice problematico all'interno di un cablaggio di test isolato in cui simuli l'errore di rete. Lavorare in modo efficace con il codice legacy descrive molte tecniche su come affrontare questo tipo di problemi. Ad esempio, è possibile creare una versione di prova della libreria, includendo solo i moduli e le funzioni problematiche, e creare un "ambiente simulato" attorno ad esso in cui è possibile simulare l '"eccezione di rete" in condizioni controllate. A prima vista potrebbe sembrare uno sforzo eccessivo, ma una volta che hai un ambiente simile, puoi aggiungere molti altri test (e immagino che abbia senso, da quando l'autore della lib si rifiuta di aggiungere i dispersi gestione delle eccezioni in un unico posto,

Per un bug come questo, il test fuzz automatizzato (chiamato anche test casuale) potrebbe essere utile nel tentativo di riprodurlo. Ciò automatizza il processo di ricerca del bug randomizzando un set fisso di parametri (o input) nella cosa che stai testando. Ad ogni esecuzione del test, i parametri vengono registrati in un file di registro, inclusi i timestamp, ecc. In modo che quando si verifica l'arresto anomalo, è possibile (teoricamente) riprodurre nuovamente il test, utilizzando gli stessi parametri, per riprodurlo.

Dal momento che è automatizzato, il processo di test può eseguire molti test in un breve periodo di tempo. Spesso può essere lasciato in esecuzione durante la notte e al mattino è possibile controllare un file di registro per vedere se ha riprodotto l'arresto anomalo.

The Devil's Advocate suggerisce un altro percorso.

L'altro sviluppatore ha affermato chiaramente che non esiste alcun bug.

Riesci a trovare un modo per stressare l'inferno del suo presunto bug inesistente e causarne un arresto molto più frequente?

La traccia dello stack è una chiara prova dell'esistenza del bug, o almeno esisteva in una certa build. Quello che non hai è la prova che il bug è stato corretto. Sono sciocchi a ignorarlo. Ho avuto bug "impossibili da riprodurre" dopo centinaia di migliaia di tentativi automatici su più sistemi che si sono attivati ogni volta sul sistema di un cliente.

Ricevo un paio di bug come quello all'anno, la maggior parte senza nemmeno il beneficio di una traccia dello stack. In quasi tutti i casi, anche se non sono riuscito a riprodurlo in anticipo, potrei facilmente fare un test automatico per esso una volta che è stato risolto.

Ad esempio, alcuni mesi fa ho corretto un bug che si verificava solo quando l'utente digitava più velocemente di 96 parole al minuto. Prima di ripararlo, sapevo solo che l'errore si verificava "a volte". Non mi verrebbe mai in mente di scrivere un test unitario per una digitazione veloce. Tuttavia, dopo aver conosciuto la causa principale, fare un test per questo è stato banale.

Anche in quei rari casi in cui un bug non può essere riprodotto anche dopo essere stato corretto, è possibile chiuderlo mediante l'ispezione del codice.