Controllo di qualità - Bugzilla - Domande frequenti

From The Document Foundation Wiki
< QA‎ | Bugzilla
Jump to navigation Jump to search
This page is a translated version of the page QA/Bugzilla/FAQ and the translation is 100% complete.
Other languages:
English • ‎español • ‎italiano • ‎čeština • ‎русский

Qui potete trovare le risposte alle Domande frequenti relative a Bugzilla.

Per risposte a domande di carattere più generale sul controllo di qualità (QA), vedete le relative QA/FAQ.

Come inviare delle richieste di miglioramento di Bugzilla stesso

Inviate le richieste di miglioramento di Bugzilla e altre relative all'infrastruttura come ticket di Redmine nella categoria Bugzilla.

Citazione dei commenti di altri

Evitate cortesemente delle citazioni lunghe e superflue! È noioso dover leggere ripetizioni infinite. Se lo fate, non rispondete al commento prima che ciò sia utile usando la funzione [reply] di Bugzilla. Se ritenete necessario contestualizzare il vostro commento, potete citare 1 o 2 righe rilevanti per la discussione sul quel punto, ma evitate citazioni di righe multiple.

Inoltre: non usate MAI la vostra email come interfaccia per i commenti. Aggiungeteli al bug usando la pagina web di Bugzilla, nella quale ci sono molte informazioni che non sono visibili nell'ultimo commento visibile in un messaggio email

Citazione di altri bug di LibreOffice su Bugzilla

Per ottenere un link verso un altro bug all'interno del commento, digitate semplicemente qualcosa tipo Bug 12345, sostituendo a "12345" in numero del Bug. Non inserite dei "#" o altri fronzoli nel numero del bug. Generalmente è utile copiare e incollare la riga completa dell'oggetto del bug che state citando.

Interpretare le informazione relative al Target nella Whiteboard

Nella Whiteboard target:3.7.0 significa che una correzione (fix) è stata inviata tramite "push" nel codice per il master. La prima versione pubblica nella quale sarà disponibile è la 4.0.0.x. Se vi meravigliate perché un fix non è stato integrato nel codice di una specifica versione, siate pazienti! Prima che un fix possa essere integrato nelle branch del codice corrente deve essere revisionato da altri sviluppatori al fine di evitare dei bug di regressione. Ciò richiede tempo. Quando lo stato del bug sarà modificato in FIXED potrete sperare nell'integrazione del fix nella branch corrente del codice.

Gestire le segnalazioni di Bug clonate

Screenshot

Alle volte chi segnala un bug crea accidentalmente dei cloni della segnalazione del bug in questione. Cortesemente NON segnalate questi cloni inutili come DUPLICATES. Molti duplicati sono un indicatore che un determinato problema affligge molti utenti. Piuttosto, chiudete ogni segnalazione non necessaria come RESOLVED - INVALID con il commento "Clone of Bug xxxxx".

Allegare dei documenti di esempio per più segnalazioni di bug

Videata, siete pregati di eliminare "Details " dopo il copia incolla e "Attachment ..." dall'intestazione della finestra del commento.

Non è necessario, né utile allegare ripetutamente lo stesso documento a più segnalazioni di bug. Piuttosto, create un collegamento con il testo "attachment 12345 dal Bug 6789" nel commento o nel testo della nuova segnalazione di bug. Questo crea un collegamento che permette di scaricare facilmente l'allegato, inoltre evidenziate che l'altra segnalazione di bug potrebbe contenere informazioni di interesse riguardanti il documento.

Per trovare il numero dell'allegato, passate il mouse sopra il collegamento nella segnalazione originaria, come mostrato nella videata. Oppure potete copiare e incollare queste informazioni dalla pagina Bugzilla Attachment Details Info. È importante conoscere per quale segnalazione di bug è stato inserito l'allegato, in quanto i commenti spesso contengono importanti informazioni aggiuntive.

In questo modo tutti sanno che il documento di esempio nella nuova segnalazione di bug è identico al documento di una segnalazione precedente, così è molto più semplice confrontare i risultati.

Aggiungere segnalazioni di bug al tracciamento di quelli più fastidiosi (MAB)

Vedete la pagina speciale dedicata i Bug più fastidiosi (MAB - Most Annoying Bugs).

Convalidare la soluzione (fix) di un bug

Se avete provato a riprodurre un bug con una versione che dovrebbe includere il fix (vedete le informazioni sul target nella Whiteboard) e potete confermare che il bug non esiste più, potete modificare lo stato nella segnalazione del bug in VERIFIED. Questo indica che la soluzione (fix) è stata confermata. Se invece potete ancora riprodurre il bug ricordatevi come riaprire un bug.

Allegare Backtrace

Se volte fornire ulteriori informazioni agli sviluppatori come Backtrace e materiale simile, dovete decidere se inserire le informazioni

  • nel testo di un commento
    • Vantaggi:
      • è possibile effettuare ricerche in base al contenuto dei Backtrace
    • Svantaggi:
      • le stringhe dei Backtrace possono generare includere risultati non voluti nelle ricerche
      • scarsa leggibilità delle segnalazioni di bug su Bugzilla a causa degli infiniti testi di commento ai Backtrace
  • in un documento di testo allegato
    • Vantaggi:
      • la leggibilità del bug su Bugzilla non è ridotta
      • Se si trovate nuovi elementi potete segnare l'allegato come obsoleto
    • Svantaggi:
      • non è possibili effettuare ricerche relative al contenuto dei Backtrace
      • nessuna ricorrenza indesiderata delle ricerche per stringa nei Backtrace corrisponderà alle "normali" ricerche di stringhe

Sta a voi decidere cosa preferite.

Menzione di allegati o altre segnalazioni di bug relative a LibO

Il modo più semplice e affidabile è scrivere Bug 47712 (per esempio) anziché <https://bugs.documentfoundation.org/show_bug.cgi?id=47712>. Bugzilla aggiungerà un collegamento al testo che compare in una segnalazione o in un commento. Per gli allegati, dovreste scrivere attachment 61814 invece di <https://bugs.documentfoundation.org/attachment.cgi?id=61814>.

Cos'è libreoffice.org/bugzilla?

No, non è un nuovo bugzilla a se stante, ma è l'ambiente Bugzilla del nostro Bugzilla. Sostanzialmente se trovate un collegamento di questo tipo (in un campo URL) relativo a segnalazioni di bug dovreste sostituirlo con l'URL bugs.documentfoundation.org/ in modo da evitare problemi di login e simili (controllate i collegamenti ai Bug in #Menzione di allegati o altre segnalazioni di bug relative a LibO.

Reperire le informazioni necessarie

Qui trovate i risultati di diverse ricerche utili:

Per gli utenti di sistemi operativi a 64 bit

È possibile eseguire applicazioni a 32 bit su sistemi operativi a 64 bit. Questo può conforndere nella scelta del campo Platform su Bugzilla. In generale, inserite il sistema per il quale è stata compilata la vostra versione di LibreOffice. Purtroppo questa informazione non è visibile nell'applicazione, comunque:

  • utenti Windows: sono disponibili sia di versioni a 32 bit che a 64 bit. Nel caso di versione a 32 bit, usate "x86 (IA32)". Precisate il vostro sistema operativo nel campo Description.
  • utenti Linux: nella maggior parte dei casi, se il vostro sistema è a 64 bit, state usando una versione a 64 bit di LibreOffice. Il vostro Sistema di gestione dei pacchettiWikipedia logo v3.svg può fornirvi ulteriori indizi. Usate "x86-64 (AMD64)" per le versioni a 64 bit.
  • utenti MacOS: MacOS supporto solamente versioni a 64 bit.

Riaprire una segnalazione di bug

Vedete i dettagli riporati qui.

Segnalazione di un bug come duplicato

MarkAsDuplicate.png

Se riscontrate che una segnalazione di bug (per esempio tdf#40691) è il duplicato (DUPLICATE) di una già esistente (tdf#37195), decidete quale delle due mantenere. Solitamente conserverete la segnalazione più vecchia, ma alle volte delle segnalazioni più recenti contengono informazioni aggiuntive di valore, oppure sono in uno stato più avanzato (Assigned).

Quando avrete deciso quale segnalazione tenere, segnate l'altra come Duplicate, (tdf#40691) inserendo il numero di quella conservata (37195) nel pannello che si apre quando fate clic su Mark as Duplicate. Non è necessario trasferire il nome del segnalatore e l'elenco degli indirizzi in CC nella segnalazione mantenuta tdf#37195, in quanto Bugzilla invierà le informazioni relative a tutte le modifiche della segnalazione rimasta anche al segnalatore ed agli indirizzi in CC delle segnalazioni chiuse come duplicate.

Chiusura della segnalazione di un bug che non è più riproducibile

Se la segnalazione di un bug è stata confermata, ma il problema è scomparso in una versione successiva di LibreOffice, non usate Resolved Fixed per chiudere la segnalazione. Quella voce è riservata ai bug risolti con un effettivo Fix revisionato. Lo Stato appropriato per un Bug il cui problema è semplicemente scomparso è Resolved WORKSFORME.

Un Fix revisionato è una soluzione molto più affidabile di una causa sconosciuta che ha fatto scomparire il problema. La differenza deve essere evidente nelle informazioni dello Stato. La versione in cui il bug non può più essere riprodotto deve essere menzionata nella Whiteboard come Target. Specialmente se è il vostro primo contatto con un determinato bug (quindi non avete mai riprodotto il problema), descrivete, passo per passo, come avete eseguito il test. Questo può fornire informazioni importanti:

  • Possibile ragione del perchè ora "funziona"
    • Le istruzioni passo passo per riprodurre il bug sono poco chiare, perciò avete eseguito un test differente da chi lo ha segnalato.
    • Il problema è effettivo, ma è legato ad un condizione particolare, al momento sconosciuta. Il vostro test non comprende tale condizione.

Assegnare una segnalazione di bug (solo per il gruppo del Controllo di qualità)

  • Il profilo di un Friendly Expert (o di uno sviluppatore che conosce il problema) sarà inserito in CC da un utente esperto. Lo stato rimane (o diventa) New
  • Lo sviluppatore accetta la segnalazione di bug
    • aggiungendo se stesso nel campo Assigned to e
    • modificando lo stato in ASSIGNED

oppure non accetta l'assegnazione del bug.

Un bug è ancora visibile anche se il suo stato è FIXED

La correzione potrebbe non essere integrata nella prossima versione. Verificate l'informazione Target nella Whiteboard o su GITWikipedia logo v3.svg.

La versione RC è scomparsa

Se avete inviato una segnalazione di bug, ma non riuscite a trovarla cercando con "Search by Version" (ad esempio usando un collegamento che avete salvato), la ragione potrebbe essere che avete scoperto un bug nell'ultima versione Release Candidate prima del rilascio. Se la versione di LibreOffice rilasciata è identica bit per bit all'ultima RC, la versione RC del selettore di versione viene cambiata dall'amministratore nella versione rilasciata (per esempio: da 3.4.2 RC a 3.4.2 release).

Votazioni su Bugzilla

Bugzilla è dotato di una funzionalità che permette ai membri del progetto di votare le segnalazioni di bug che ritengono necessitino di un'attenzione tempestiva. LibreOffice non usa questa funzionalità, in quanto l'Engineering Steering Committee non ritiene che la semplice votazione fornisca sufficienti nuove informazioni.

Ciò non significa comunque che ci sia una resistenza di base verso qualunque tipo di "sondaggio tra gli utenti". Se qualcuno ha dei motivi ben fondati e convincenti da proporre, si può ridiscutere la questione e se il riscontro dovesse essere positivo, troveremo l'infrastruttura per il procedimento.

Statistiche di Bugzilla

Vedete le Statistiche di Bugzilla.