Controllo di qualità - Triage dei Bug

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/BugTriage and the translation is 100% complete.

    TDF LibreOffice Document Liberation Project Blog comunitari Weblate Nextcloud Redmine Ask LibreOffice Donazione

    Other languages:


    Introduzione

    Questo documento fornisce informazioni su come effettuare il triage dei bug di LibreOffice. Il Triage è il nome dato alla procedura di conferma, assegnazione della priorità e organizzazione delle segnalazioni di bug ed è un buon punto per i nuovi contributori, o per quelli con limitate capacità di programmazione, per aiutare LibreOffice a diventare un prodotto miglio per tutti. Il Triage è un aspetto incredibilmente importante dello sviluppo di cui beneficiano sia gli utenti, sia gli sviluppatori.

    Dove trovare altri membri del Controllo di qualità

    Ci sono alcuni posti dove potete trovare/contattare membri del gruppo del Controllo di qualità, molti dei quali possono aiutarvi a rispondere alle vostre domande e che sono loro stessi attivamente coinvolti nel triage.

    1. Mailing List
      • libreoffice-qa@lists.freedesktop.org
      • libreoffice@lists.freedesktop.org
    2. Canali IRC Channel su Libera Chat
    3. Membri del Controllo di qualità
      Qui trovate un elenco dei membri del Controllo di qualità (sentitevi liberi di aggiungere il vostro nome se avete intenzione di contribuire al Controllo di qualità). Se un utente vi ha dato il permesso di contattarlo direttamente, sentitevi liberi di farlo. Inoltre li troverete nei ritrovi delle chat room abbastanza di frequente.

    Passaggi per il Triage di un bug

    Questa sezione elenca i passaggi necessari al fine di effettuare correttamente il triage. Questa guida si propone di essere concisa, i collegamenti presenti in alcune sezioni forniranno maggiori informazioni inerenti a un determinato passaggio. Il processo di triage può essere essenzialmente spezzato in tre parti, di cui la prima è la "preparazione", la seconda la "riproduzione" e la terza "l'assegnazione della priorità".

    Indice dei passaggi

    1. Ricerca dei bug di cui fare il Triage
    2. Prefiltraggio delle segnalazioni di bug
    3. Ricerca di duplicati del bug
    4. Controllo delle informazioni fornite nella segnalazione del bug
    5. Tentativo di riproduzione del bug
    6. Impostazione dello stato del bug
    7. Test di regressione
    8. Assegnazione della priorità al bug

    Passaggi in dettaglio

    Preparazione

    In generale nella preparazione del triage di un bug dovreste eseguire sempre questi passaggi. Ricordatevi che potete lavorare sui bug solo dopo aver eseguito l'accesso (siete pregati di creare un profilo se non ne avete già uno). Una volta che avrete un profilo, è opportuno che andiate nelle preferenze ed impostiate la voce 'Automatically add me to the CC list of bugs I change' su 'Only if I have no role on them', se desiderate ricevere una notifica quando qualcuno risponde ad una qualsiasi segnalazione di bug da voi commentata.

    Passaggio 1: Ricerca dei bug di cui fare il Triage

    a) Ricerca su Bugzilla

    Navigate fino al sistema di tracciamento dei bug di LibreOffice disponibile su bugs.documentfoundation.org. Dopo aver effettuato l'accesso, sfogliate gli elementi aperti per componente o eseguite una ricerca dei bug che sono:

    a) relativi al prodotto LibreOffice

    b) abbiano lo stato UNCONFIRMED o REOPENED

    c) aggiungete qualsiasi altro criterio di ricerca riteniate opportuno

    Una volta fatto ciò, cercate un bug per il quale volete fare il triage. Potere costruire delle ricerche personalizzate dei bug usando il modello Advanced Search o inserendo i termini nel campo Quick Search (Bugzilla Quick Search help). Potete anche usare i seguenti collegamenti diretti alle ricerche. Facendo clic sul collegamento sarete indirizzati alla pagina di Bugzilla con i risultati dei:

    Passaggio 2: Prefiltraggio delle segnalazioni di bug

    Alcuni bug necessitano di un'attenzione particolare da parte di un team specifico:

    Miglioramenti all'Esperienza utente (UX)

    Qualsiasi segnalazione inerente il miglioramento dell'Interfaccia utente/Esperienza utente (UI/UX) di LibreOffice dovrebbe essere assegnato al Team UX. Questo dovrebbe avvenire ad un punto in cui è chiaro cosa la segnalazione intende dire. È meglio lasciare lo stato su UNCONFIRMED. Usare NEW solo se risulta ovvio che la modifica proposta debba essere implementata e rimane solamente l'interrogativo su come farlo.

    1. Aggiungete la parola chiave 'needsUXEval'
    2. Aggiungete all'elenco in CC: libreoffice-ux-advise@lists.freedesktop.org
    3. Lasciate un commento del tipo:
    UX Team -- please take a look at this enhancement. Thanks!

    Alcuni bug non sono affatto di competenza di Bugzilla. Per un elenco degli argomenti da riportare altrove, constualte la pagina BugReport.

    • Se uno di questi bug è stato inserito in Bugzilla, modificate lo Status in RESOLVED NOTOURBUG e aggiungete quanto segue in un commento:
    Grazie per esservi messi in contatto con noi!
Anche se Bugzilla può sembrare il centro dell'Universo,
ci sono degli argomenti che dovete segnalare altrove. 
Per trovare il posto adatto dove segnalare il vostro problema, 
siete pregati di consultare la pagina BugReport del wiki:
https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

    Passaggio 3: Ricerca di duplicati del bug

    I duplicati sono segnalazioni molto simili o identiche, segnalate da utenti diversi. Solitamente vorrete tenere lo stato NEW per la segnalazione con le informazioni di maggior valore e chiudere le altre come RESOLVED DUPLICATE. Perciò anche se esiste una segnalazione più vecchia, non è necessario tenerla aperta se contiene informazioni confuse o incomplete. I duplicati chiusi sono automaticamente conteggiati da Bugzilla e disponibili nella pagina Most Frequently Reported Bugs. Quando eseguite il triage siete pregati di controllare questo elenco ed effettuare una rapida ricerca tra le segnalazioni su Bugzilla per verificare se esistono duplicati di quella che state esaminando. Non dovete passare una vita a farlo. Esaminando più segnalazioni inizierete a vedere dei duplicati a colpo d'occhio senza necessità di usare la ricerca.

    Se trovate un duplicato di un bug, saltate al passaggio numero 5

    Passaggio 4: Controllo delle informazioni

    Il controllo delle informazioni è fondamentale per lo sviluppo. Dovrete verificare quanto segue:

    1. Un oggetto chiaro e significativo
    2. Una chiara descrizione del problema
    3. I passaggio per riprodurre il problema -- se non sono già chiariti nell'oggetto o nella descrizione
    4. Allegati -- in molti casi gli allegati sono necessari alla riproduzione del problema, se non sono stati forniti può essere ostacolata l'appropriata correzione del bug
    5. Se la segnalazione fa riferimento a dati esterni (schermate, documenti, video, ecc.), copiateli e allegateli al bug, in modo che in seguito non svaniscano e diventino quindi irriproducibili.

    Se tutte le informazioni non sono appropriate, saltate al passaggio numero 5

    Passaggio 5: Tentativo di riproduzione

    Se il bug ha "superato" i passaggi propedeutici, è giunto il momento di provare a riprodurlo.

    Fate solo questo: eseguite i passaggi necessari e provare a riprodurlo, semplice! Quando lo riproducete, tenete a mente queste cose:

    1. colui che ha segnalato il bug ha lasciato su Bugzilla informazioni sufficienti a riprodurre il bug, o avete dovuto effettuare dei passaggi in più? Se sono stati necessari dei passaggi extra, aggiungete un commento per descriverli.
    2. La vostra riproduzione ha portato allo stesso risultato, a qualcosa di simile ma non identico, o ha funzionato tutto senza problemi?

    Passaggio 6: Impostazione dello stato

    Questa sezione è l'ultimo passaggio "obbligatorio" di un triage positivo e può essere posto in essere solo dopo aver eseguito i passaggi dall'1 al 4 (o al 3 se il 4 non è applicabile).

    Lo STATUS di un bug dipende dai risultati dei passaggi precedenti. Di seguito trovate una breve descrizione dell'uso di ogni stato.

    1. NEW: Bug confermato, ci sono tutte le informazioni necessarie
    2. NEEDINFO: Tutte le informazioni necessarie per tentare la sua riproduzione non sono comprese nella segnalazione del bug. Chiedete in un commento l'informazione specifica a una determinata persona.
    3. RESOLVED: Questa categoria può prevedere diverse opzioni. Per esempio, se il problema è già stato segnalato, potete segnarlo come RESOLVED DUPLICATE. Oppure, se non riuscite a riprodurre il bug, come descritto, ma questo è già stato risolto in una versione più recente, RESOLVED WORKSFORME potrebbe essere lo STATUS appropriato. Vedete RESOLVED per una descrizione dettagliata di tutti i possibili valori.
    4. VERIFIED: Questa opzione è disponibile solo se lo stato del bug in esame è RESOLVED. Potete indicare un RESOLVED FIXED bug come VERIFIED, quando siete in grado di confermare che è stato corretto con la versione indicata nella pagina di segnalazione del bug. È anche una soddisfazione per lo sviluppatore che ha corretto il problema e una conferma che il problema è risolto. Altrimenti colui che ha segnalato un bug può modificare lo stato del proprio bug da RESOLVED WORKSFORME a VERIFIED WORKSFORME per indicare che in qualche modo è risolto.
    5. INVALID: Ci sono molte ragioni per cui un bug può essere considerato non valido, ma per questo di solito è necessario l'intervento di altri membri del Controllo di qualità. Se vi imbattete in un bug che considerate non valido, l'opzione migliore è quella di chiedere un'altra opinione sul canale IRC del gruppo QA o inviare un messaggio alla mailing list spiegando i motivi per cui ritenete che il bug non sia valido.
    6. UNCONFIRMED: Questo è lo stato assegnato a tutti i nuovi bug che non hanno superato il processo di triage. Fate attenzione che un bug di questo tipo potrebbe trovarsi anche nello stato NEEDINFO.

    OGNI volta che effettuate delle modifiche dovreste inserire un commento che spiega cortesemente il perché della modifica

    I diagrammi di flusso qui di seguito sono degli esempi di come potete immaginare visivamente l'impostazione dello STATUS. Sentitevi liberi di modificarli e caricare la vostra versione, se lo lo ritenete.
    File PDF
    File di LibreOffice Draw

    Passaggio 7: Controllo di Regressione

    Usate delle vecchie versioni di LibreOffice per verificare che il bug non sia stato presente sin dalle origini di LibreOffice.

    Scaricate e installate un serie di vecchie versioni, la più vecchia è LibreOffice 3.3. Come minimo dovreste avere una versione di ogni linea di rilascio principale (3.x, 4.x, 5.x, 6.x...).

    Dovete avere una certa conoscenza di quando sono state introdotte le varie funzionalità del software, al fine di evitare risultati di test non pertinenti. Se non siete sicuri di qualcosa, siete pregati di consultare altri membri del gruppo.

    • Se il bug è presente nella versione 3.3.0, impostate la versione a "inherited from OOo" e aggiungete il seguente commento:
    Questo bug era già presente in Libreoffice 3.3.0

Modificata la versione in "inherited from OOo"
    • Se il bug non è presente nella versione 3.3.0 aggiungete "regression" nel campo delle parole chiave e aggiungete il seguente commento:
    Questo bug non è presente in Libreoffice 3.3.0, perciò è una regressione

    Per le regressioni precedenti alla versione 3.5.0, aggiungete anche la parola chiave preBibisect. Per le nuove regressioni aggiungete la parola chiave bibisectRequest e aggiornate il campo della versione in modo che corrisponda alla prima versione problematica conosciuta.

    Passaggio 8: Assegnazione della priorità al bug

    Attualmente sono evidenziati solo i bug critici inserenti in CC gli sviluppatori e aggiungendo le parole chiave. Vedete qui di seguito per maggiori informazioni.

    L'assegnazione della priorità a un bug è relativamente soggettiva, ma chi esegue il triage dovrebbe cercare di essere sempre coerente nel modo in cui determina la priorità di un bug. I membri del gruppo del Controllo di qualità che eseguono il triage dovrebbero avere le idee chiare su cosa costituisce ogni stato di priorità e quindi tentare di attenersi a questa metodologia. Inoltre, commentare il bug dopo avergli assegnato la priorità è utile in quanto permette a colui che ha segnalato il bug (e anche agli sviluppatori e agli altri utenti) di sapere quale processo mentale vi ha portato ad assegnare quello stato di priorità.

    Per assegnare ai bug una priorità maggiore alla medium-normal, dovete essere aggiunti al gruppo dei contributori su Bugzilla. Al fine di farlo, contattate uno degli amministratori di Bugzilla.

    Il diagramma di flusso sottostante illustra grossomodo le linee guida su come gestire l'assegnazione della priorità.

    Esempio 1 JPG

    Esempio 1 Draw

    Di solito è più semplice determinare la gravità di un problema che pensare alla sua priorità adeguata.

    Piccoli aggiustamenti estetici all'interfaccia utente posso essere considerati a passa priorità e di gravità trivial.

    I problemi che vi fanno arrabbiare, ma che potete tollerare o superare in qualche modo possono essere impostati a una gravità minor.

    I bug che compromettono qualche funzionalità e non sono aggirabili hanno una gravità normal.

    I crash, blocchi e congelamenti derivanti da un file o comando specifico hanno una gravità major.

    Passaggi utili aggiuntivi (opzionali)

    Parole chiave

    Il campo Keywords contiene le parole chiave inerenti alla categorizzazione del bug in esame.

    Alcune categorie di parole chiave comprendono:

    Una parola chiave interessante è needsDevEval. Un easyHack è un bug che in linea di massima non richiede molto per essere corretto e può essere risolto da un nuovo sviluppatore e/o da uno sviluppatore senza grandi capacità di programmazione. Come Controllo di qualità NON dobbiamo segnalare un bug come easyHack, ciò richiede diversi passaggio aggiuntivi (tra i quali trovare uno sviluppatore che faccia da mentore per il bug). Se pensate che un bug possa considerarsi un easyhack, segnatelo come needsDevEval.

    Segnalazione di crash

    Avere una segnalazione di crash (detta anche backtrace) causati da un bug, rende più semplice per uno sviluppatore identificare qual è la causa del crash. Se una segnalazione di crash è aggiunta a quella di bug, anche la parola chiave havebacktrace dovrebbe essere aggiunta nel campo Keywords.

    Segnalazioni Meta

    Date un'occhiata alle segnalazioni meta esistenti che raggruppano le segnalazioni dello stesso genere. Se ne trovate una che si adatti, aggiungete il numero della segnalazione meta al campo Blocks della segnalazione di cui state effettuando il triage.

    Tag nei commenti

    I tag ai Commenti agiscono come note che aiutano chiunque a farsi una rapida panoramica della cronologia dei commenti e del valore/importanza di ciascun commento. Fate clic sul testo del tag nell'intestazione di un commento, inserite il vostro tag e premete invio. Non è necessario salvare la segnalazione. Potete inventare nuovi tag o usarne di esistenti. Il campo di inserimento dei tag supporta l'autocompletamento.

    L'inserimento di uno di questi tag nasconde il commento, per impostazione predefinita: obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise. Potete visualizzare un commento nascosto facendo clic sul widget "Toggle comment display" nell'intestazione del commento. Potete anche nascondere dei commenti normali e visualizzare quelli con dei tag facendo clic sul nome del tag a vostra scelta nell'elenco "Comment Tags" vicino alla descrizione del bug (comment 0). Fate clic su Expand all comments per visualizzare tutto.

    Controllo delle Informazioni aggiuntive

    Come esecutori del triage è necessario tentare di controllare le informazioni originariamente indicate dall'autore della segnalazione del bug. Le cose da controllare comprendono:

    • Prodotto
    • Versione
    • Piattaforma

    Aggiunta di sviluppatori all'elenco CC

    Questo passaggio dovrebbe essere eseguito solamente se siete sicuri che il bug sia importante abbastanza per includere in CC (copia per conoscenza) uno sviluppatore. Se ritenete che un bug sia abbastanza serio da richiedere una maggior attenzione, ma forse non rientra nella categora dei Principali bug fastidiosi, dovreste cercare un esperto che vi fornisca un parere aggiuntivo. Siete pregati di usare questa funzione con cautela, in quando non vorremmo inondare gli sviluppatori esperti con richiami a bug di minore importanza. Per aggiungere un utente digitate semplicemente il suo nome nell'elenco CC e inserite un commento al bug indicando agli sviluppatore il motivo per cui li avete aggiunti al campo CC In ogni caso, potete trovare i nomi corretti nell'elenco degli esperti.

    Aggiunta del Controllo di qualità all'elenco CC

    Di solito questo non viene fatto, ma se ritenete che aggiungere all'elenco voi stessi, o un altro membro del Controllo di qualità, potrebbe essere utile, sentitevi liberi di farlo. Nuovamente, assicuratevi di aggiungere un commento nel caso in cui aggiungiate qualcun altro all'elenco, altrimenti potrebbero irritarsi non conoscendo cosa sta succedendo.

    Verifica di interoperabilità

    Se la richiesta di verifica riguarda l'apertura o il salvataggio di un file con Microsoft Office e non avete accesso al software, potete usare Office Web Viewer. Funziona con i documenti di Word, Excel, PowerPoint e con gli ODF. Dovete caricare il documento e poi aggiungere l'URL al termine di questo collegamento:

    https://view.officeapps.live.com/op/view.aspx?src=

    Potrete quindi fare clic sul pulsante Print nel menu in alto e infine su Open PDF per accedere a una riproduzione in PDF del documento. Questo vi permetterà sia di vedere l'aspetto del documento nell'ultima versione di Microsoft Office, sia di condividere il PDF su Bugzilla.

    I collegamenti agli allegati su Bugzilla funzionano con il visualizzatore.

    Uso pratico del visualizzatore in Firefox
    • Aggiungete un nuovo segnalibro
    • Impostate un Nome
    • Inserite l'URL:
    https://view.officeapps.live.com/op/view.aspx?src=%s
    • Impostate una Keyword (parola chiave), come lv, premete OK.
    • Ora potrete usare la parola chiave del segnalibro seguita dall'URL del documento, inserendola nella barra dell'indirizzo in modo da aprire il documento relativo al bug nell'Office live viewer:
    lv https://bugs.documentfoundation.org/attachment.cgi?id=180059

    Note particolari sul Triage per il gruppo del Controllo di qualità

    Qui trovate alcune note per gli esperti di triage del QA/gruppo del Controllo di qualità. Se siete dei nuovi arrivati, non preoccupatevi di questo!

    Segnalazioni di bug difficili per il triage o da chiudere

    Alle volte sono necessari dei software o hardware particolari per riprodurre un bug o si incontrano altre difficoltà che ne impediscono l'investigazione. Pe questi casi esiste:

    La raccolta usa l'estensione Bugzilla di MediaWiki, che raccoglie i dati dalle segnalazioni meta e attraverso varie altre ricerche.

    Estensioni

    È preferibile coinvolgere nel triage anche il creatore dell'estensione. La responsibilità di contattare il creatore è di colui che ha segnalato il bug.

    Leggete anche:

    Controversie relative alle impostazioni locali

    Alle volte si incontrano argomenti relativi alle impostazioni locali. Può presentarsi una situazione in cui uno standard nazionale di qualche elemento differisce dalla pratica abituale. In questi casi, può essere utile indirizzare colui che ha effettuato la segnalazione all'Unicode Common Locale Data Repository e al loro questionario.

    Ordine suggerito per il Triage

    La tabella sottostante raffigura l'ordine suggerito con cui approcciare il triage. Lo scopo del Controllo di qualità è quello di confermare per primi i bug peggiori.

    Tabella per piattaforma (SO)

    Descrizione Tutti i bug Windows Linux macOS Commenti
    Bug con segnalazioni di crash CrasherAll CrasherWindows CrasherLinux CrashermacOS Questi sono bug che riportano "crash" o parole simili nel loro titolo. Per quelli che comportano un crash la gravità dovrebbe essere impostata a Major/Critical a seconda di quanti utenti ne saranno afflitti. Inoltre, il Controllo di qualità dovrebbe verificare se il crash è una regressione o meno e, nel caso constati che lo è, aggiungere la parola chiave "regression".
    Potenziali regressioni possibleRegressionAll possibleRegresionWindows possibleRegressionLinux possibleRegressionmacOS Se il bug si conferma essere una regressione, tra le parole chiave deve essere rimossa "possibleRegression" e deve essere aggiunta "regression".
    Parola chiave Regression RegressionAll RegressionWindows RegressionLinux RegressionmacOS Colui che ha segnalato il bug o qualcun altro ha inserito regression come parola chiave. È ugualmente importante a quello della riga precedente, ma Bugzilla non consente una ricerca di tipo "or" perciò è stato suddiviso su due righe.
    Bug segnalati come Critical CriticalAll CriticalWindows CriticalLinux CriticalmacOS Solo i contributori con determinati privilegi possono impostare i bug come critical. La gravità Critical è riservata a bug molto seri (come perdite di dati che possono affliggere molti utenti). Per indicazioni vedete PriorityFlowChart
    Bug segnalati come Major MajorAll MajorWindows MajorLinux MajormacOS Solo i contributori con determinati privilegi possono impostare i bug come major. La gravità Major è riservata a bug molto seri (come perdite di dati), ma che probabilmente non affliggeranno molti utenti o che si verificano in casi marginali con singoli documenti. Per indicazioni vedete PriorityFlowChart
    Tutti i bug AllBugs AllWindows AllLinux AllmacOS Elenco di tutte le segnalazioni di bug (escluse richieste di miglioramenti). Se i bug in cima sono affrontati per primi, quelli rimanenti hanno una priorità leggermente inferiore per essere confermati. Il suggerimento è di esaminarli in ordine cronologico (prima i più vecchi in modo che gli utenti che hanno effettuato la segnalazione da più tempo abbiano la priorità).
    Richieste di miglioramento EnhancementAll EnhancementWindows EnhancementLinux EnhancementmacOS Le richieste di miglioramento hanno la priorità più bassa per essere confermate come richieste valide.

    Tabella per componente

    Descrizione Writer Calc Impress Draw Base Altro Commento
    Bug con segnalazioni di crash WriterCrasher SpreadsheetCrasher PresentationCrasher DrawingCrasher DatabaseCrasher OtherCrashers La gravità 'Critical' è riservata solo ai bug più seri (come all'impossibilità di installare LibreOffice). Per indicazioni vedete PriorityFlowChart
    Potenziali regressioni WriterPosReg SpreadsheetPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg Se il bug si conferma essere una regressione, tra le parole chiave deve essere rimossa "possibleRegression" e deve essere aggiunta "regression".
    Parola chiave Regression WriterRegression SpreadsheetRegression PresentationRegression DrawingRegression DatabaseRegression OtherRegressions Colui che ha segnalato il bug o qualcun altro ha inserito regression come parola chiave. È ugualmente importante a quello della riga precedente, ma Bugzilla non consente una ricerca di tipo "or" perciò è stato suddiviso su due righe.
    Bug segnalati come Critical WriterCritical SpreadsheetCritical PresentationCritical DrawingCritical DatabaseCritical OtherCritical Solo i contributori con determinati privilegi possono impostare i bug come critical. La gravità Critical è riservata a bug molto seri (come perdite di dati che possono affliggere molti utenti). Per indicazioni vedete PriorityFlowChart
    Bug segnalati come Major WriterMajor SpreadsheetMajor PresentationMajor DrawingMajor DatabaseMajor OtherMajor Solo i contributori con determinati privilegi possono impostare i bug come major. La gravità Major è riservata a bug molto seri (come perdite di dati), ma che probabilmente non affliggeranno molti utenti o che si verificano in casi marginali con singoli documenti. Per indicazioni vedete PriorityFlowChart
    Tutti gli altri bug WriterOther SpreadsheetOther PresentationOther DrawingOther DatabaseOther AllOther Questi sono tutti i bug indicati con gravità inferiore a Major, escluse le richieste di miglioramento.
    Richieste di miglioramento WriterEnhance SpreadsheetEnhance PresentationEnhance DrawingEnhance DatabaseEnhance OtherEnhance Richieste di miglioramento
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=QA/BugTriage/it&oldid=774732"