QA/Triage For Beginners/it

Il "Triaging" è il processo di conferma e prioritizzazione dei bug. È una grande opportunità per i non-sviluppatori per aiutare a migliorare l'applicazione. Dei bug report ben preparati aiutano gli sviluppatori a concentrarsi sulla risoluzione dei problemi in un ordine ragionevole. Questa pagina riassume i vari aspetti della "bug investigation" e riporta collegamenti ad ulteriori informazioni dettagliate su ogni attività.

Duplicazione di Bug
Ci sono molte probabilità che un "bug report" non confermato (unconfirmed) sia stato già segnalato precedentemente, quindi è sempre una buona idea cercare i duplicati di un bug prima di cercare di crearlo. Fare questo ridurrà gli sforzi per ulteriori investigazioni e concentrerà tutte le discussioni sul bug nel primo bug report in cui è stato identificato. Se hai riconosciuto un bug report come duplicato, clicca sul link ‘Mark as Duplicate’ sotto il menu a discesa Status e quindi inserisci il numero di bug report nel campo presentato.

Non è sempre facile trovare bug duplicati, poiché le note possono essere incomplete oppure i bug sono stati segnalati sotto un componente diverso.

Questa è la lista dei Bug Riportati Più di Frequente

Prioritizzazione dei Bug
Ai nuovi membri attivi del QA team possono essere assegnati diritti bugzilla aggiuntivi per modificare i campi Priority e Severity, mentre gli utenti normali non possono. Per richiedere questi privilegi, chiedi ai membri del QA team (ad es. buovjaga, jmadero) su IRC o per email al team sulla mailing list. Se vuoi cmentarti in questo compito, sarebbe bene per te seguire altri membri che lo stanno facendo e vedere se l'avresti fatto allo stesso modo.

[[media:Prioritizing Bugs Flowchart.jpg|Diagramma di prioritizzazione dei Bug]]

Di solito è più semplice determinare la "severità" di un problema che cercare di immaginare una corretta "priorità".

Piccoli ritocchi estetici alla UI (User Interface, ndt) possono essere considerati "low priority" e "trivial severity".

Problemi che ti fanno arrabbiare, ma che puoi tollerare o aggirare in qualche modo possono essere impostati come "minor severity".

Bug che interrompono qualche funzionalità e non c'è modo di aggirare sono "normal severity".

Se LibreOffice va in crash, si blocca o congela in conseguenza di un comando o file specifico l bug è da considerare "major severity".

Quando qualche componente di LibreOffice è completamente inusabile per via di crash o problemi all'interfaccia, il bug è "severity critical".

Test delle Regressioni
Verificare nelle vecchie versioni di LibreOffice per capire se un bug si trova in versioni precedenti, rende più facile identificare se un bug è stato introdotto nell'evoluzione di LibreOffice.

Scarica ed installa LibreOffice 3.3.


 * Se il bug è presente nella 3.3, imposta la versione a "inherited from OOo" ed inserisci il seguente commento:

This bug is already present in Libreoffice 3.3 Changing version to "inherited from OOo"


 * Se invece NON è presente nella 3.3 aggiungi "regression" nel campo keywords field ed inserisci il seguente commento:

This bug is not present in Libreoffice 3.3, thus it's a regression Adding "regression" to the keywords

Ulteriori informazioni:
 * SI-GUI - Simple GUI app to parallel install on Windows
 * Installing in parallel - Instructions on how to manually parallel install on Windows, Linux and Mac.
 * http://downloadarchive.documentfoundation.org/libreoffice/old/ - Download old releases, betas, and alphas

Crash Reports
Avere un crash report (detto backtrace) per un bug rende semplice per uno sviluppatore identificare cosa sta causando il crash. Se aggiungi crash report in un bug report, la keyword havebacktrace dovrebbe essere aggiunta nel campo Keywords.


 * QA/BugReport/Debug Information
 * How to get a backtrace with WinDbg

Bibisecting
I Bug introdotti in LibreOffice dopo la versione 3.5 possono essere facilmente tracciate attraverso il bibisecting.


 * Effective Bisection and Bibisection (video) - Matthew Francis
 * QA/Bibisect
 * QA/Bibisect/Implementation