Responsabilità di riprodurre bug

Ha ragione è probabilmente una domanda a cui non si può davvero rispondere senza conoscere la propria azienda. Tuttavia, certamente non è di grande aiuto.

Solleverei il bug con lui (cosa che hai fatto), se sta causando un problema con il tuo progetto, lo innalzerei come blocker con il tuo project manager e renderò molto chiaro che hai sollevato il problema bug con una persona appropriata, ma ha un impatto sul progetto se non viene risolto tempestivamente.

Vorrei anche andare a parlare con lo sviluppatore e spiegare perché è impossibile creare test unitari, ma saresti felice di mostrarlo sulla tua macchina (supponendo che sia fattibile?).

Ha ragione al 100% che è necessario fornire informazioni sufficienti per rendere riproducibile il bug, altrimenti non c'è alcuna possibilità di scoprire se una correzione fornita funzionerà davvero.

Ma - è IMHO 100% sbagliato che questo deve essere in forma di test unitario. Se è possibile descrivere uno scenario di test in modo da poter riprodurre l'errore (almeno con un'alta probabilità in un lasso di tempo ragionevole, o con un test manuale), si ha una prova che il problema esiste - che dovrebbe impostare il collega nella responsabilità di risolverlo. Naturalmente, se sei in grado di creare uno scenario che riproduca il bug più veloce, sarebbe utile per lui. Idealmente, si farebbe un test automatico da questo, e dipende dalla vostra organizzazione che ne ha la responsabilità.

Entrambe le parti dovrebbero sforzarsi.

Lo sviluppatore della biblioteca dovrebbe fare uno sforzo supplementare anche senza test unitari, perché alcuni problemi non possono essere riprodotti con test unitari. A volte è hardware, a volte è una sequenza specifica di azioni corrette dal resto del programma che fa sì che la libreria produca risultati sbagliati.

Dovresti fare uno sforzo in più, perché dopotutto il mio non essere un bug nella libreria, ma il risultato di azioni errate dal resto del programma (ad es. heap corrotto potrebbe rendere strana la libreria che si comporta ). Quindi è logico ridurre il più possibile il codice non-libreria coinvolto nella riproduzione dei bug. E probabilmente lo farai più veloce e più pulito di una persona che non ha familiarità con il codice della tua applicazione.

Se l'autore della libreria non è in grado di riprodurre il bug in base al rapporto, è irragionevole aspettarsi che trascorra molto tempo su di esso, per non parlare di correggerlo.

Ma hai anche una quantità limitata di tempo speso a lavorare su un prodotto che è periferico al tuo interesse. Sfortunatamente, ciò potrebbe significare che il bug continua a esistere e che non è stato fatto alcun lavoro per risolverlo.

Fortunatamente questo non è necessariamente un disastro - mentre in un mondo ideale, tutto il software sarebbe privo di bug, non è così, e quindi dobbiamo stabilire le priorità in base ai problemi che causano negli Stati Uniti.

Ciò significa che è davvero tua responsabilità sviluppare un caso di test riproducibile SE VUOI FISSARE. Non ti importa se viene riparato, e in tal caso, hai fatto tutto ciò che può e dovrebbe aspettarti da te. Potresti volerlo risolto, ma non abbastanza da dedicare del tempo per renderlo riproducibile in questo momento. Questo è perfettamente accettabile.

Segnalare un bug al meglio delle tue abilità nel tempo in cui devi affrontarlo è semplicemente una buona cittadinanza, non è necessario andare oltre, a meno che non sia necessario per il tuo programma. E potresti non volerlo fare anche in quel momento, ci potrebbe essere un'altra libreria che potresti usare, o potrebbe essere possibile eseguire il tuo proprio in un ragionevole periodo di tempo. Fondamentalmente spetta a te decidere quale e quale tipo di sforzo vale la pena per te.

Sarei propenso a lasciar mentire i cani che dormono per ora - hai sollevato il problema e gli è stato assegnato. Presumibilmente ci sono processi in atto per tracciare bug in sospeso e inseguirli?

Se desideri progredire ulteriormente, ti suggerisco di parlare con il tuo responsabile per verificare se sono disponibili strumenti di test in grado di riprodurre il problema in modo affidabile.

Dal punto di vista dello sviluppatore, sarebbe seriamente inerte da parte loro non fare nulla, dato che hai fornito le informazioni richieste. Tuttavia, potrebbe essere possibile che abbiano un carico di lavoro enorme, quindi non è possibile dedicare il tempo necessario per tracciare il problema.

Hai trovato un bug, lo hai segnalato e lui è un idiota.

Se voi due siete stati amici intimi, avrebbe fatto qualcosa per aiutare, ma avrebbe preferito semplicemente rimandare il problema.

Puoi fare di più, segnalando ulteriori dettagli e cercando di supportare le tue affermazioni che sta perdendo memoria. Tuttavia, hai le tue responsabilità e devi finire il tuo lavoro.

Accedi quante più informazioni possibile al bug tracker e prosegui.

Se vedi questa persona di nuovo in futuro. Sii amichevole, cerca di parlare di interessi comuni e capisci che le buone relazioni sono un modo molto più efficace di sistemare le cose, quindi qualsiasi quantità di fatti che puoi fornire per sostenere un reclamo.

Spesso, quello che ho trovato in situazioni simili è una supposizione che tutti i bug dovrebbero essere corretti e mentre è ammirevole, è sicuramente un grande obiettivo avere (lascia che faccia non ci mettiamo mai a scrivere bug!) in definitiva irrealistico in qualsiasi progetto di una dimensione decente per correggere un bug solo perché è un bug (se riesci a trovarlo!) Ecco perché abbiamo metodologie, schemi e modelli di gestione del progetto e di codifica pratiche ecc.

Quindi, una cosa che direi nella difesa del proprietario della libreria (ed è stato il caso in cui ho lavorato su alcuni grandi progetti) è che il tempo di sviluppo costa denaro ed è una risorsa finita quindi la decisione su come la relazione viene gestita, chi indaga, quali test sono prodotti / necessari e in definitiva se (e in tal caso, quando) viene implementata una soluzione basata esclusivamente sull'impatto sul business. Qual è l'impatto del riavvio del tuo lungo processo una volta ogni tanto se fallisce e puoi facilmente automatizzarlo (e forse non dovresti essere già una misura di programmazione difensiva?) È solo ora o c'è altro da fare ?

Guarda anche dal loro punto di vista, un bug report da un utente di un problema imprevedibile in un po 'di codice che accade molto raramente, solo in combinazione con il loro codice, possibilmente solo su una macchina e solo sotto un set di insolite condizioni di cronometraggio non avranno una strong giustificazione per una grande quantità di tempo di sviluppo da trovare e risolvere, se è possibile. Ma se si tratta di un business case abbastanza strong da permettere all'utente / bisogno di dedicare del tempo per investigare più a fondo e fornire un caso / applicazione affidabile o una descrizione del problema radicalmente più dettagliata rispetto a quella iniziale, allora potrebbe essere un altro .

Questa è forse una questione di comunicazione che il proprietario della biblioteca non ha preso in considerazione in questo modo e se hai un caso aziendale strong (come il tuo codice è costoso per il business, ha un obbligo di conformità legale, buco di sicurezza o ha qualche altro grande effetto a catena), quindi è il momento di prenderlo in carico e lasciarlo combattere.

Hai menzionato che "ho presentato un errore con la descrizione delle condizioni per far accadere questa perdita".

Se sei sicuro che la descrizione sia veramente sufficiente per riprodurre l'errore, allora conosci già le condizioni esatte. Ora, se non è possibile scrivere un test unitario dopo aver conosciuto le condizioni, significa chiaramente che non è possibile prendere in giro alcuni dei componenti coinvolti o che alcune parti del codice sono troppo strettamente accoppiate per consentire di creare test unitari pratici.

Dovresti chiedere al proprietario della biblioteca il codice refactoring per permetterti di creare un test unitario. Dovrai spiegare chiaramente cosa c'è nella libreria che ti impedisce di creare un test unitario. Dovrà rifattarsi il codice altrimenti concedere che il test unitario non è possibile con il codice corrente. In entrambi i modi, hai vinto.

Se questo non funziona, le seguenti sono le opzioni disponibili:

• Puoi riprodurre bug con più prove.
• Prova a coinvolgere un'autorità superiore e chiedigli di valutare le tue prove.
• Prova ad usare la libreria in un'applicazione prototipo con ambiente finto da codificare solo per riprodurre bug. In questo modo, sarai in grado di provare almeno che il bug esiste.