Triage Per Principianti

    From The Document Foundation Wiki
    < QA

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

    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.

    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:

    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.

    Bibisecting

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

    Retrieved from "https://wiki.documentfoundation.org/index.php?title=QA/Triage_For_Beginners/it&oldid=422230"