Riproduzione di un problema¶
Non si può risolvere un problema se non si ha il problema stesso. Pertanto, riprodurre il problema è un prerequisito per risolverlo. Nel software, i problemi sono comunemente chiamati "bug", mentre i problemi sono spesso chiamati "segnalazioni di bug".
Qualcuno ha fornito una segnalazione di bug. È necessario verificare che i passaggi descritti dal segnalatore producano il bug segnalato. È possibile riprodurre lo stesso risultato facendo esattamente ciò che è stato descritto nella segnalazione? Se non ci riuscite, dovete capire perché.
Per iniziare a riprodurre un problema, è necessario configurare un ambiente di sviluppo.
Bug nel codice¶
In una situazione ideale, si avrà la stessa configurazione della persona che ha segnalato il bug, si seguiranno i passaggi e si riuscirà a riprodurre il bug come descritto. In molti casi, però, non sarà così semplice. Molte segnalazioni di bug includono solo spiegazioni vaghe e una serie di condizioni vaghe. Il problema è che molti bug variano in base all'insieme di condizioni coinvolte, tra cui le modalità di interazione, le varie precondizioni, il sistema operativo, la versione del sistema operativo, l'architettura della CPU o il fatto che la macchina dell'utente sia vecchia e lenta o nuova e veloce. Più informazioni abbiamo sulla situazione che circonda il bug, meglio è. Cercate di riprodurre l'insieme di condizioni fornite dal segnalatore. Se non si riesce a farlo, il passo successivo potrebbe essere quello di richiedere ulteriori informazioni alla persona che ha segnalato il bug.
Il modo migliore per riprodurre un bug è con l'esempio più piccolo possibile che presenti comunque il problema. La maggior parte delle volte i segnalatori non forniranno un esempio minimo fattibile; se forniscono un qualsiasi esempio, sarà copiato direttamente dalla loro applicazione del "mondo reale". Il vostro obiettivo sarà quello di ridurre il rapporto alla forma più semplice possibile che mostri il problema. Il miglior caso di riproduzione è il programma più piccolo possibile. Questa riduzione è di per sé utile perché determina quale sia il problema effettivo. Chiunque può prendere l'esempio minimo, eseguirlo e osservare il bug descritto.
Bug nella documentazione¶
I bug nella documentazione possono manifestarsi in modi diversi. Ci sono problemi di formattazione che causano problemi di rendering. A volte non si tratta nemmeno di un bug; la persona potrebbe aver letto male la documentazione o aver commesso un vero e proprio errore. Questo non significa necessariamente che non ci sia un problema nella documentazione. Il contenuto può essere poco chiaro o impreciso, lasciando spazio a confusione o interpretazioni errate. È possibile che un concetto che dovrebbe essere discusso non lo sia, perché è completamente privo di documentazione.
Quando viene segnalato un bug per un problema di documentazione, è necessario verificare che il problema segnalato esista effettivamente. Nel caso di problemi di rendering, è necessario costruire la documentazione per vedere se è possibile riprodurre il problema. Per i problemi relativi ai contenuti è necessario verificare che nessuno abbia inviato un aggiornamento.
Aggiornare il problema¶
La fase finale del processo di triage consiste nel documentare le proprie scoperte lasciando un commento sul problema.
Se siete in grado di riprodurre il problema esattamente come descritto, è tutto ciò che dovete dire. Lasciate un commento dicendo che avete confermato di riscontrare lo stesso problema, nel modo esatto descritto dal segnalatore originale.
Se siete in grado di fornire un contesto aggiuntivo, includete i dettagli di tale contesto. Ad esempio, è possibile riprodurre il problema su un sistema operativo diverso o con una versione diversa di alcuni dei software coinvolti, o qualsiasi altra cosa che differisca dalla segnalazione originale.
Se il rapporto originale mancava di dettagli necessari per riprodurre il rapporto, includere questi dettagli. Ad esempio, si possono fornire dettagli sul sistema operativo o sulla versione che il report originale non ha fornito, registri o tracce di stack più completi o istruzioni più chiare sull'esatta sequenza di operazioni necessarie per riprodurre il problema. Se avete sviluppato un modo più semplice per riprodurre il problema (o il segnalatore originale non ha fornito un caso di riproduzione), potete includere i dettagli di tale metodologia di riproduzione.
Se non riesci a riprodurre il problema, lascia comunque un commento descrivendo in dettaglio ciò che hai provato a fare. Sapere dove un problema non esiste è importante quasi quanto sapere dove esiste, perché aiuta a restringere il campo delle possibili cause. Se hai qualche teoria sul perché non riesci a riprodurre il problema, ad esempio se pensi che si tratti di un errore di utilizzo o che il problema sia stato risolto da un recente aggiornamento del sistema operativo, includi questa ipotesi nel tuo commento.
Infine, si possono fornire eventuali raccomandazioni al team centrale. Se ritenete che la segnalazione originale sia errata, suggerite di chiudere il problema; se avete una teoria sulla causa del problema, potete suggerire anche quella. I vostri commenti aiuteranno il team centrale a capire come far passare il problema alla fase successiva.
A questo punto, potresti scegliere di provare a risolvere il problema che hai appena riprodotto; in alternativa, puoi scrivere le tue conclusioni e provare a riprodurre un altro problema.