È ragionevole insistere sulla riproduzione di ogni difetto prima di diagnosticare e correggere?

Lavoro per un'azienda produttrice di software. Abbiamo grandi clienti aziendali che implementano il nostro prodotto e forniamo loro supporto. Ad esempio, se c'è un difetto, forniamo patch, ecc. In altre parole, è una configurazione abbastanza tipica.

Di recente, un biglietto è stato emesso e assegnato a me per quanto riguarda un'eccezione rilevata da un cliente in un file di registro che ha a che fare con l'accesso simultaneo al database in un'implementazione cluster del nostro prodotto. Pertanto, la configurazione specifica di questo cliente potrebbe essere fondamentale per il verificarsi di questo errore. Tutto ciò che abbiamo ricevuto dal cliente era il loro file di registro.

L'approccio che ho proposto al mio team è stato quello di tentare di riprodurre il bug in un'impostazione di configurazione simile a quella del cliente e ottenere un registro comparabile. Tuttavia, non sono d'accordo con il mio approccio affermando che non ho bisogno di riprodurre il bug in quanto richiede troppo tempo e richiederà la simulazione di un cluster di server su VM. Il mio team mi suggerisce di semplicemente "seguire il codice" per vedere dove si trova il codice thread e / o non sicuro della transazione e inserire la modifica lavorando fuori da un semplice sviluppo locale, che non è un'implementazione del cluster come l'ambiente da cui si verifica l'occorrenza del bug ha origine.

Per me, elaborare un progetto astratto (codice programma) piuttosto che una manifestazione tangibile e visibile (riproduzione runtime) sembra difficile, quindi volevo porre una domanda generale:

È ragionevole insistere sulla riproduzione di ogni difetto ed eseguirne il debug prima di diagnosticare e correggere?

O:

Se sono uno sviluppatore senior, dovrei essere in grado di leggere il codice multithread e creare un'immagine mentale di ciò che fa in tutti gli scenari di casi d'uso piuttosto che richiedere l'esecuzione dell'applicazione, testare diversi scenari di casi d'uso in modo pratico e passare attraverso codice riga per riga? O sono uno sviluppatore povero per esigere quel tipo di ambiente di lavoro?

Il debug per femminucce?

A mio avviso, qualsiasi correzione presentata in risposta a un ticket di incidente dovrebbe essere testata in un ambiente simulato per essere il più vicino possibile all'ambiente originale. In quale altro modo puoi sapere che risolverà davvero il problema? È come rilasciare un nuovo modello di un veicolo senza crash test con un manichino per dimostrare che gli air bag funzionano davvero.

Ultimo ma non meno importante, se sei d'accordo con me:

Come dovrei parlare con il mio team per convincerli che il mio approccio è ragionevole, conservatore e più a prova di proiettile?

È ragionevole insistere sulla riproduzione di ogni difetto ed eseguirne il debug prima di diagnosticare e correggere?

Dovresti fare del tuo meglio. So che a volte ci sono condizioni e ambienti così complessi che non possono essere riprodotti esattamente , ma dovresti certamente provare se puoi.

Se non hai mai riprodotto il bug e non l'hai visto da solo, come puoi essere sicuro al 100% di averlo corretto? Forse la correzione proposta introduce qualche altro bug sottile che non si manifesterà a meno che non si provi effettivamente a riprodurre il difetto originale.

Se sono uno sviluppatore senior, dovrei essere in grado di leggere il codice (multithread) e creare un quadro mentale di ciò che fa in tutti gli scenari di casi d'uso piuttosto che richiedere di eseguire l'applicazione, testare diversi scenari di casi d'uso e procedere il codice riga per riga? O sono uno sviluppatore povero per esigere quel tipo di ambiente di lavoro? Il debug per femminucce?

Non mi fiderei di qualcuno che esegue il codice "nella loro testa", se questo è il loro unico approccio. È un buon punto di partenza . Riprodurre il bug e risolverlo, quindi dimostrare che la soluzione impedisce il ripetersi del bug, ecco dove dovrebbe finire .

Come dovrei parlare con il mio team per convincerli che il mio approccio è ragionevole, conservatore e più a prova di proiettile?

Perché se non hanno mai riprodotto il bug, non possono sapere con certezza che è stato corretto. E se il cliente ritorna e si lamenta che il bug è ancora lì, questa non è una buona cosa. Dopotutto, ti stanno pagando un sacco di soldi (suppongo) per affrontare questo problema.

Se non riesci a risolvere correttamente il problema, hai rotto la fiducia con il cliente (in una certa misura) e se ci sono concorrenti nel tuo mercato, questi potrebbero non rimanere il tuo cliente.

Come intendono verificare che il bug in questione sia stato corretto? Vogliono spedire all'utente un codice non testato e lasciarlo capire? Non è possibile fare affidamento su alcuna configurazione di test che non è mai stata dimostrata in grado di riprodurre l'errore per mostrare l'assenza dell'errore. Certamente non è necessario riprodurre l'intero ambiente client, ma è sufficiente per riprodurre l'errore.

Non credo sia irragionevole tentare di riprodurre tutti i bug prima di risolvere. Tuttavia, se si tenta di riprodurlo e non è possibile, diventa più una decisione aziendale se le patch cieche siano o meno una buona idea.

Idealmente, vuoi essere in grado di riprodurre ogni bug in modo che, per lo meno, puoi verificare che sia stato corretto.

Ma ... Potrebbe non essere sempre fattibile o anche fisicamente possibile. Soprattutto con software di tipo "enterprise" in cui ogni installazione è unica. C'è anche la valutazione costi / benefici. Un paio d'ore per esaminare il codice e formulare alcune ipotesi plausibili su un problema non critico può costare molto meno che avere un team di supporto tecnico per settimane cercando di impostare e duplicare l'ambiente di un cliente esattamente nella speranza di poter duplicare il problema. Quando lavoravo nel mondo dell '"Enterprise", spesso volevamo semplicemente far uscire i programmatori e farli correggere i bug sul sito, perché non c'era modo di duplicare la configurazione del cliente.

Quindi, duplica quando puoi, ma se non puoi, sfrutta la tua conoscenza del sistema e prova a identificare il colpevole nel codice.

Non credo che dovresti rendere la riproduzione dell'errore un requisito per esaminare il bug. Esistono, come hai già detto, diversi modi per eseguire il debug del problema e dovresti usarli tutti. Dovresti considerarti fortunato di essere riuscito a darti un file di registro! Se tu o qualcuno della tua azienda è in grado di riprodurre il bug, fantastico! In caso contrario, dovresti comunque tentare di analizzare i log e trovare le circostanze in cui si è verificato l'errore. Potrebbe essere possibile, come suggerito dai colleghi, leggere il codice, capire quali condizioni potrebbe verificarsi il bug, quindi tentare di ricreare lo scenario da soli.

Tuttavia, non rilasciare la correzione effettiva non testata. Qualsiasi modifica apportata dovrebbe passare attraverso la routine di sviluppo standard, test QA e test di integrazione. Potrebbe essere difficile testarlo: hai menzionato il codice multithread, che è notoriamente difficile da eseguire il debug. È qui che sono d'accordo con il tuo approccio per creare una configurazione o un ambiente di prova. Se hai riscontrato un problema nel codice, dovresti trovare molto più semplice creare l'ambiente, riprodurre il problema e testare la correzione.

Per me, questo è meno un problema di debug e più di un problema del servizio clienti. Hai ricevuto una segnalazione di bug da un cliente; hai la responsabilità di fare la dovuta diligenza per trovare il loro problema e risolverlo.

Secondo me ... come decisore, devi essere in grado di giustificare la tua posizione. Se l'obiettivo del dipartimento di supporto di terza linea è quello di correggere i bug nel minor tempo possibile con lo sforzo accettabile da parte del cliente, qualsiasi approccio deve rispettare tale obiettivo. Inoltre, se si può dimostrare che l'approccio fornisce i risultati più rapidi previsti, non dovrebbero esserci problemi a convincere la squadra.

Avendo lavorato a supporto, mi sono sempre ragionevolmente aspettato che il cliente fosse in grado di fornire alcuni "script" di azioni eseguite per riprodurre in modo coerente il bug e, se non in modo coerente, esempi candidati che hanno prodotto il bug.

Se fossi nuovo nel sistema e non avessi alcuna conoscenza del codice, i miei primi passi sarebbero tentare di identificare le possibili fonti dell'errore. È possibile che la registrazione non sia sufficiente per identificare un codice candidato. A seconda del client, potrei essere propenso a fornire loro una versione di debug in modo che possano essere in grado di restituire i file di registro che forniscono ulteriori indizi sulla posizione del codice offensivo.

Se sono in grado di identificare rapidamente il blocco di codice, la mappatura visiva del flusso potrebbe essere sufficiente per individuare il codice. In caso contrario, la simulazione basata su unit test potrebbe essere sufficiente. È possibile che la configurazione di un ambiente di replica client richieda meno tempo, soprattutto se esiste una notevole replicabilità del problema.

Penso che potresti scoprire che il tuo approccio dovrebbe essere una combinazione delle soluzioni proposte e che sapere quando abbandonare una e passare alla successiva è la chiave per svolgere il lavoro in modo efficiente.

Sono abbastanza sicuro che il team supporterà l'idea che se esiste una possibilità la loro soluzione troverà il bug più veloce, quindi dando loro un arco di tempo adatto per dimostrare che non avrà un impatto eccessivo sul tempo necessario per correggere il bug qualunque percorso che prendi.

È ragionevole insistere sulla riproduzione di ogni difetto ed eseguirne il debug prima di diagnosticare e correggere?

Dico di sì, con alcuni avvertimenti.

• Penso che sia corretto leggere il codice e provare a trovare luoghi che sembrano essere problematici. Crea una patch e inviala al client per vedere se questo risolve il problema. Se questo approccio continua a fallire, potrebbe essere necessario esaminare altre opzioni. Ricorda solo che mentre stai risolvendo un bug potrebbe non essere il bug che è stato segnalato.
• Se non riesci a riprodurlo entro limiti ragionevoli e non trovi alcuna bandiera rossa nel codice, potrebbe essere necessario un coordinamento più stretto con il cliente. Ho volato sui siti dei clienti prima di eseguire il debug sul sito. Non è il miglior ambiente di sviluppo, ma a volte se il problema è ambientale, trovare la causa esatta sarà più semplice quando è possibile riprodurlo in modo coerente.

Sono stato dalla parte dei clienti del tavolo in questo scenario. Lavoravo in un ufficio del governo degli Stati Uniti che utilizzava un cluster di database Oracle incredibilmente grande (diversi terabyte di dati e l'elaborazione di milioni di record al giorno).

Abbiamo riscontrato uno strano problema che è stato molto facile per noi riprodurre. Abbiamo segnalato il bug a Oracle e siamo andati avanti e indietro con loro per settimane, inviando loro i registri. Hanno detto che non erano in grado di riprodurre il problema, ma ci hanno inviato alcune patch che speravano potessero risolvere il problema. Nessuno di loro ha fatto.

Alla fine hanno volato fuori un paio di sviluppatori nella nostra posizione per eseguire il debug del problema sul sito. E fu allora che fu trovata la causa principale del bug e una patch successiva risolse correttamente il problema.

Se non sei positivo sul problema, non puoi essere positivo sulla soluzione. Sapere come riprodurre il problema in modo affidabile in almeno una situazione del caso di test consente di dimostrare di sapere come causare l'errore, e quindi anche di dimostrare che il problema è stato risolto, a causa della conseguente mancanza di errore nello stesso caso di test dopo aver applicato la correzione.

Detto questo, le condizioni di gara, i problemi di concorrenza e altri bug "non deterministici" sono tra i più difficili da individuare per uno sviluppatore in questo modo, perché si verificano raramente, su un sistema con carico più elevato e più complessità di qualsiasi copia di uno sviluppatore di il programma e scompaiono quando l'attività viene rieseguita sullo stesso sistema in un secondo momento.

Più spesso, ciò che originariamente sembra un bug casuale finisce per avere una causa deterministica che si traduce nella riproducibilità deterministica del bug una volta che sai come. Quelli che sfidano questo, i veri Heisenbugs (bug apparentemente casuali che scompaiono quando si tenta di testarli in un ambiente sterile e monitorato), sono correlati al tempismo del 99,9% e, una volta capito, la strada da percorrere diventa più chiara; cerca cose che potrebbero fallire se qualcos'altro dovesse ottenere una parola in modo marginale durante l'esecuzione del codice e quando trovi una tale vulnerabilità, prova a sfruttarla in un test per vedere se mostra il comportamento che stai cercando di riprodurre.

In questi casi è generalmente richiesta una quantità significativa di ispezione approfondita del codice; devi guardare il codice, abbandonando le nozioni preconcette su come dovrebbe comportarsi il codice e immaginare scenari in cui potrebbe fallire nel modo in cui il tuo cliente ha osservato. Per ogni scenario, prova a sviluppare un test che potrebbe essere eseguito in modo efficiente all'interno del tuo attuale ambiente di test automatizzato (ovvero, senza la necessità di un nuovo stack VM solo per questo test), che proverebbe o confuterebbe che il codice si comporta come previsto ( che, a seconda di ciò che ti aspettavi, proverebbe o confuterebbe che questo codice è una possibile causa dei problemi dei clienti). Questo è il metodo scientifico per gli ingegneri del software; osservare, ipotizzare, testare, riflettere, ripetere.

È ragionevole insistere sulla riproduzione di ogni difetto ed eseguirne il debug prima di diagnosticare e correggere?

No, decisamente no. Sarebbe una politica stupida.

Il problema che vedo con la tua domanda e la tua proposta è che non riescono a distinguere tra

• segnalazioni di bug
• guasti ( errori )
• bug (a volte chiamati anche errori )

Una segnalazione di bug è la comunicazione di un bug. Ti dice che qualcuno pensa che qualcosa non vada. Potrebbe o meno essere specifico su ciò che dovrebbe essere sbagliato.

Una segnalazione di bug è la prova di un fallimento.

Un fallimento è un incidente di qualcosa che non va. Un malfunzionamento specifico, ma non necessariamente con alcun indizio su cosa potrebbe averlo causato.

Un errore può essere causato da un bug.

Un bug è una causa di guasti; qualcosa che può (in linea di principio) essere modificato al fine di evitare che in futuro si verifichino i guasti che esso provoca.

A volte, quando viene segnalato un bug, la causa è immediatamente chiara. In tal caso, la riproduzione del bug sarebbe priva di senso. Altre volte, la causa non è affatto chiara: la segnalazione di bug non descrive alcun errore particolare, oppure lo fa ma l'errore è tale da non fornire un indizio su quale potrebbe essere la causa. In questi casi, ritengo che il tuo consiglio sia giustificato, ma non sempre: non si insiste nel lanciare un secondo razzo spaziale da $ 370 milioni prima di accettare di indagare su ciò che ha causato il crash del primo (un bug particolare nel software di controllo).

E ci sono anche tutti i tipi di casi in mezzo; ad esempio, se una segnalazione di bug non dimostra, ma suggerisce solo, che un potenziale problema di cui già si era a conoscenza potrebbe svolgere un ruolo, questo potrebbe essere un incentivo sufficiente per dargli un'occhiata più da vicino.

Quindi, mentre insistere sulla riproducibilità è saggio per i casi più difficili, non è saggio applicarlo come una politica rigorosa.

Come per qualsiasi altra cosa nello sviluppo del software, la risposta corretta è un compromesso.

In teoria, non dovresti mai provare a correggere un bug se non puoi provare che esiste. Ciò potrebbe farti apportare modifiche inutili al codice che alla fine non risolveranno nulla. E provarlo significa prima riprodurlo, quindi creare e applicare una correzione, quindi dimostrare che non succede più. Il tuo istinto qui ti sta guidando nella giusta direzione: se vuoi essere sicuro di aver risolto il problema del tuo cliente, devi prima sapere cosa lo ha causato.

In pratica, ciò non è sempre possibile. Forse il bug si verifica solo su cluster di grandi dimensioni con dozzine di utenti che accedono contemporaneamente al tuo codice. Forse esiste una combinazione specifica di operazioni sui dati su set specifici di dati che attiva il bug e non hai idea di cosa si tratti. Forse il tuo cliente ha eseguito il programma interattivamente ininterrottamente per 100 ore prima che si manifestasse il bug.

In uno di questi casi, c'è una forte probabilità che il tuo dipartimento non abbia il tempo o i soldi per riprodurre il bug prima di iniziare a lavorare. In molti casi, è molto più ovvio per te, lo sviluppatore, che c'è un bug nel codice che ti indica la situazione corretta. Dopo aver diagnosticato il problema, potresti essere in grado di tornare indietro e riprodurlo. Non è l'ideale, ma allo stesso tempo, parte del tuo lavoro come sviluppatore senior è sapere come leggere e interpretare il codice, in parte per individuare questo tipo di bug sepolti.

Secondo me, ti stai concentrando sulla parte sbagliata della domanda. E se alla fine non riesci a riprodurre il bug in questione? Niente è più frustrante per un cliente che sentire "sì, sappiamo che hai bloccato il programma ma non possiamo riprodurlo, quindi non è un bug." Quando il tuo cliente lo sente, lo interpretano come "sappiamo che il nostro software è difettoso ma non possiamo preoccuparci di correggere e correggere i bug, quindi incrocia le dita". Se è meglio chiudere un bug segnalato come "non riproducibile" o chiuderlo come "non riproducibile, ma abbiamo apportato alcune modifiche ragionevoli per cercare di migliorare la stabilità"?

A meno che l'errore non sia evidente, ovvio e banale, con un messaggio di errore molto specifico, ecc., È spesso molto difficile correggere un bug se l'utente o il manutentore non sono in grado di replicarlo.

Inoltre, come dimostreresti loro che il bug è stato corretto se non fosse possibile replicare i passaggi?

Il problema con il tuo caso è che l'utente non sa né come si è verificato l'errore, cioè in quale schermata di quale operazione. Hanno semplicemente il registro.

Penso che il tuo punto sia ragionevole. Se avessi poteri psichici , probabilmente non lavoreresti per uno stipendio.

Penso che dovresti dire ai tuoi capi che senza essere in grado di replicare l'errore ci vorrebbe molto tempo prima di scoprirlo, e non c'è alcuna garanzia che lo farai.

Il problema sarà quando un tuo collega trova il bug per pura fortuna e lo risolve.

Portiamolo all'estremo e supponiamo che tu abbia trovato il bug molto prima: nel tuo codice, mentre lo stavi scrivendo. Quindi non avresti alcun scrupolo nel risolverlo proprio lì - vedi un difetto logico nel codice che hai appena scritto, non fa quello che volevi che facesse. Non sentiresti la necessità di impostare un intero ambiente per dimostrare che in realtà è un bug.

Ora arriva una segnalazione di bug. Ci sono diverse cose che puoi fare. Uno di questi è tornare al codice e rileggerlo. Supponiamo ora che in questa seconda lettura trovi immediatamente il bug nel codice: semplicemente non fa quello che intendevi fare e non sei riuscito a notare quando lo hai scritto. E , spiega perfettamente il bug appena arrivato! Fai la correzione. Ti ci sono voluti venti minuti.

Ciò ha risolto il bug che ha causato la segnalazione del bug? Non puoi esserne sicuro al 100% (potrebbero esserci stati due bug che causavano la stessa cosa), ma probabilmente lo ha fatto.

Un'altra cosa che potresti fare è riprodurre al meglio la configurazione del cliente (qualche giorno di lavoro) e infine riprodurre il bug. In molti casi, ci sono problemi di tempistica e concorrenza che significano che non puoi riprodurre il bug, ma puoi provare molto tempo e a volte vedere accadere la stessa cosa. Ora si avvia il debug, si trova l'errore nel codice, lo si inserisce nell'ambiente e si riprova molte volte. Non vedi più l'insorgere del bug.

Ciò ha risolto il bug che ha causato la segnalazione del bug? Non puoi ancora essere sicuro al 100%: uno, potresti aver visto un bug completamente diverso rispetto al cliente, due, forse non hai provato abbastanza spesso e tre, forse la configurazione è ancora leggermente diversa ed è risolto su questo sistema, ma non su quello del cliente.

Quindi la certezza è impossibile da ottenere in ogni caso. Ma il primo metodo è molto più veloce (puoi dare al cliente una patch anche più veloce), è molto più economico e, se trovi un chiaro bug di codifica che spiega il sintomo, è effettivamente più probabile trovare anche il problema.

Quindi dipende. Se è economico impostare un ambiente di test (o meglio: un test automatizzato che mostra il problema), allora fallo. Ma se è costoso e / o le circostanze in cui il bug mostra sono imprevedibili, allora è sempre meglio provare a trovare il bug leggendo prima il codice.

Leggendo la domanda, non vedo alcuna opposizione fondamentale tra la tua posizione e quella della tua squadra.

• Sì, dovresti fare del tuo meglio per riprodurre il problema che si verifica nelle impostazioni del client. Ma lo sforzo migliore significa che è necessario definire un intervallo di tempo per questo, e potrebbero non esserci dati sufficienti nel registro per riprodurre effettivamente il problema.

  In tal caso, tutto dipende dal rapporto con questo cliente. Può darsi che tu non abbia nient'altro da lui, a cui potresti inviare uno sviluppatore in loco con strumenti di diagnosi e capacità di eseguirli sul sistema difettoso. Di solito, siamo nel mezzo e se i dati iniziali non sono sufficienti ci sono modi per ottenerne di più.

• Sì, uno sviluppatore senior dovrebbe essere in grado di leggere il codice ed è probabile che trovi il motivo del problema dopo il contenuto del registro. Davvero, è spesso possibile scrivere alcuni unit test che presentano il problema dopo aver letto attentamente il codice.

  Superare la scrittura di tali test unitari è quasi altrettanto buono quanto riprodurre l'ambiente funzionale di rottura. Ovviamente, questo metodo non è nemmeno una garanzia che troverai qualcosa. Comprendere l'esatta sequenza di eventi che portano al fallimento in alcuni software multi-thread può essere davvero difficile da trovare semplicemente leggendo il codice e la possibilità di eseguire il debug in tempo reale diventerà critica.

Riassumendo, proverei simultaneamente entrambi gli approcci e chiederei un sistema live che mostri il problema (e che mostri che è stato risolto in seguito) o che rompa un test di unità interrompendo il problema (e anche mostrandolo risolto dopo la correzione).

Cercare di correggere semplicemente il codice e inviarlo in natura, sembra davvero molto rischioso. In alcuni casi simili che mi sono occorsi (dove non siamo riusciti a riprodurre il difetto internamente), ho chiarito che se una correzione andava in natura e non riusciva a risolvere il problema del cliente, o aveva altre conseguenze negative inaspettate, l'uomo che ha proposto dovrebbe aiutare il team di supporto a trovare il problema reale. Compreso trattare con il cliente, se necessario.

Mi sembra che tu abbia bisogno di una registrazione più dettagliata.

Mentre l'aggiunta di più registrazioni non può garantire che non sarà necessario eseguire il debug (o, in questo caso, riprodurre la situazione), ti fornirà una visione molto migliore di ciò che è effettivamente andato storto.

Soprattutto in situazioni complicate / di threading o qualsiasi cosa in cui non è possibile utilizzare un debugger, ricorrere a "debug by printf ()" potrebbe essere l'unica soluzione. In tal caso, accedi il più possibile (più di quanto ti aspetti di aver bisogno) e disponi di alcuni buoni strumenti per filtrare il grano dalla paglia.

È ragionevole insistere sulla riproduzione di ogni difetto ed eseguirne il debug prima di diagnosticare e correggere?

Dal momento che nessuno lo ha ancora detto in termini chiari: assolutamente no!

Come ogni altra cosa nello sviluppo del software, la correzione di bug significa tenere presente tempo, rischi e costi. Trovare un equilibrio tra questi è la metà della descrizione del lavoro di uno sviluppatore.

Alcuni bug non sono abbastanza importanti da spendere 2 giorni, ma abbastanza importanti da spendere 10 minuti per risolverli. Altri bug non sono deterministici e sai già che un ambiente di test non può dimostrare che sono stati corretti. Se la configurazione dell'ambiente di test richiede 2 giorni, non lo fai per questi bug. Invece dedichi tempo a cose più intelligenti, come trovare modi per impostare un ambiente di test in 5 minuti anziché 2 giorni.

E naturalmente ci sono bug in cui se li sbagli un cliente perderà $ 100'000 +. E i bug in cui il client perderà $ 100'000 + per ogni ora in cui il bug non è stato corretto. Devi guardare il bug e prendere una decisione. Le dichiarazioni generali per trattare allo stesso modo tutti i bug non funzionano.

Ottima domanda! La mia opinione è che se non riesci a riprodurre il problema, non puoi dire al 100% che la correzione che hai apportato non:

a) risolvere effettivamente il problema. b) creare un altro bug

Ci sono momenti in cui si verifica un bug e lo risolvo e non mi preoccupo di testarlo. So con certezza che funziona al 100%. Ma fino a quando il nostro dipartimento di QA non dice che funziona, lo considero ancora una possibilità che sia ancora presente un bug ... o un nuovo bug creato dalla correzione.

Se non riesci a riprodurre il bug, quindi installa la nuova versione e conferma che è stato corretto, non puoi, con certezza al 100%, dire che il bug è scomparso.

Ho provato per qualche minuto a pensare a un'analogia per aiutarti a spiegare agli altri, ma non mi è mai venuto in mente nulla. Una vasectomia è un esempio divertente ma non è la stessa situazione :-)

[bug relativo a] accesso simultaneo al database, implementazione in cluster, multithread

È ragionevole insistere sulla riproduzione di ogni difetto ed eseguirne il debug prima di diagnosticare e correggere?

Non passerei troppo tempo a provare a riprodurlo. Sembra un problema di sincronizzazione e questi si trovano più spesso ragionando (a partire da registri come quello che devi individuare il sottosistema in cui si verifica il problema) piuttosto che essere in grado di trovare un modo per riprodurlo e attaccarlo con un debugger . Nella mia esperienza, ridurre il livello di ottimizzazione del codice o talvolta attivare anche la strumentazione aggiuntiva può essere sufficiente per aggiungere un ritardo sufficiente o la mancanza della primitiva di sincronizzazione per impedire al bug di manifestarsi.

Sì, se non hai modo di riprodurre il bug, non sarai sicuro di risolverlo. Ma se il tuo cliente non ti dà il modo di riprodurlo, potresti anche cercare qualcosa di simile con la stessa conseguenza ma con una causa diversa.

Entrambe le attività (revisione e test del codice) sono necessarie, né sufficienti.

Potresti passare mesi a costruire esperimenti cercando di riproporre il bug e non arrivare mai da nessuna parte se non guardassi il codice e formassi un'ipotesi per restringere lo spazio di ricerca. Potresti soffiare mesi guardando l'ombelico nel tentativo di visualizzare un bug nel codice, potresti persino pensare di averlo trovato una, due, tre volte, solo per far dire al cliente sempre più impaziente: "No, il bug è ancora lì. "

Alcuni sviluppatori sono relativamente migliori in una attività (revisione del codice rispetto ai test di costruzione) rispetto all'altra. Un manager perfetto sopporta questi punti di forza quando assegna bug. Un approccio di squadra può essere ancora più fruttuoso.

In definitiva, potrebbero non esserci informazioni sufficienti per riproporre il bug e devi lasciarlo marinare per un po 'sperando che un altro cliente trovi un problema simile, dandoti maggiori informazioni sul problema di configurazione. Se il cliente che ha visto il bug vuole davvero che venga risolto, lavorerà con te per raccogliere ulteriori informazioni. Se questo problema si è presentato solo una volta, probabilmente non è un bug con priorità alta anche se il cliente è importante. A volte non funziona un insetto è più intelligente che passare ore umane a cercare un difetto davvero oscuro con informazioni insufficienti.