QA/BugTriage

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


    Introductie

    Informatie over het uitvoeren van triage voor bugs in LibreOffice. Met triage bedoelen wij het het bevestigen van de fout, het bepalen van de prioriteit bij het oplossen, het werken met bugrapporten en het inwerken van nieuwe medewerkenden met beperkte mogelijkheden om te zorgen dat LibreOffice een goed product blijft en een beter product wordt. Het is een belangrijk onderdeel bij de ontwikkeling wat zowel voor de ontwikkelaars als de gebruikers voordelen biedt.

    Andere QA-leden vinden

    U kunt op meerdere manieren met leden van het QA-team in contact komen, de meesten kunnen u helpen met vragen over triage.

    1. Mailinglijsten
      • libreoffice-qa@lists.freedesktop.org
      • libreoffice@lists.freedesktop.org
    2. IRC op Libera Chat
    3. QA Leden
      Dit is een lijst van QA-leden (voel u vrij om uzelf toe te voegen als u een bijdrage aan kwaliteitszorg hebt geleverd). Als de gebruiker toestaat dat u direct contact opneemt met de gebruiker, doe dat dan. Kijk ook of die gebruiker de chat gebruikt.

    Stappen om bij een fout triage te doen

    Hier geven we stappen aan om de triage goed te doen. We proberen dat bondig te doen, met links verwijzen we naar uitgebreidere in die stap relevante informatie. Het proces bestaat uit drie gedeelten. Eerst een "voorbereiding", dan een "reproductie" en tot slot het "bepalen van de prioriteit".

    De stappen

    1. Fouten zoeken
    2. Filteren op foutrapporten
    3. Zoeken naar dubbele fouten
    4. Meegeleverde informatie in het foutrapport controleren
    5. De fout proberen te krijgen, het reproduceren van de bug
    6. De status zetten
    7. prioriteit bepalen
    8. Ontwikkelaars inlichten, alleen nodig als de fout echt kritiek lijkt te zijn

    Details van de stappen

    Voorbereiden

    In het het algemeen zult u de volgende stappen willen doen als voorbereiding voor de triage. U dient dient ingelogd te zijn om aan de bugs te werken (als u nog geen account heeft, maak een account aan als u dat nog niet heeft). Stel in uw account in bij uw voorkeuren bij 'Automatically add me to the CC list of bugs I change' de waarde 'Only if I have no role on them' te kiezen, dan wordt u ingelicht als iemand op een bugrapport reageert, waar u ook een post heeft gedaan.

    Stap 1: Fouten zoeken voor de triage

    a) Bugzilla Search

    Ga naar de LibreOffice bugtracker bugs.documentfoundation.org. Na het inloggen, bekijk de open issues per component of zoek naar een bug die:

    a) betrekking heeft op een LibreOffice product

    b) de status UNCONFIRMED of REOPENED heeft

    c) u kunt uw keuze uitbreiden met eigen criteria om het aantal resultaten te beperken tot uw aandachtsgebied

    Zoek daar naar een fout die u wilt beoordelen. Dat zoeken kan met de Geavanceerd zoeken of met het invoeren van zoektermen in het Snelle Zoekveld (Bugzilla Quick Search help). U kunt voor het zoeken ook de volgende links gebruiken. Na een klik op de link krijgt u in Bugzilla de pagina met de resultaten:

    Step 2: Bugrapporten vooraf filteren

    Bij enkele fouten is er aandacht nodig van een specifiek team:

    UX Uitbreidingen

    Alle fouten in de uitbreidingen van de UI/UX van LibreOffice moeten worden gegeven aan het UX Team

    1. Voeg het keyword 'needsUXEval' toe
    2. Zet bij de CC: libreoffice-ux-advise@lists.freedesktop.org
    3. Pas de status aan
      • Als het verzoek compleet en aannemelijk lijkt, wordt de Status NEW
      • Als het niet compleet lijkt of onduidelijk is, dan wordt de Status NEEDINFO
    4. Voeg commentaar toe als:
    UX Team -- please take a look at this enhancement. Thanks!
    

    Sommige bugs horen helemaal niet thuis in Bugzilla. Voor een lijst met onderwerpen die elders thuishoren, zie de BugReport pagina.

    • Als een van deze bugs is ingediend in Bugzilla, wijzig dan de Status in RESOLVED NOTOURBUG en voeg het volgende toe als een opmerking:
    Thank you for getting in touch with us!
    Although Bugzilla sometimes feels like the center of the
    Universe, there are a few topics that need to be
    reported elsewhere. To find the right place to report
    your issue, please look at the BugReport wiki page:
    https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla
    

    Stap 3: Zoeken naar dubbelen

    Duplicaten zijn rapporten die erg op elkaar lijken of identiek zijn, maar door verschillende gebruikers worden gerapporteerd. U wilt meestal de status NEW voor het rapport met de meest waardevolle informatie behouden en andere als RESOLVED DUPLICATE sluiten. Dus ook al bestaat er een ouder rapport, het is niet nodig om het open te houden, als het verwarrende of onvolledige informatie bevat. Gesloten duplicaten worden automatisch geteld door Bugzilla en zijn beschikbaar op de pagina meest gemelde bugs. Wanneer u triage doet, controleer dan die lijst en doorzoek snel de rapporten in Bugzilla om te zien of er duplicaten zijn van het rapport dat u onderzoekt. U hoeft hier niet veel tijd aan te besteden. Naarmate u meer rapporten ziet, kunt u duplicaten gaan herkennen zonder dat u de zoekopdracht hoeft te gebruiken.

    Als u een dubbele bug vindt, ga dan naar stap #5

    Stap 4: Informatie controleren

    Het controleren van informatie is van cruciaal belang voor ontwikkeling. Waar u op moet letten, is het volgende:

    1. Duidelijke en zinvolle samenvatting
    2. Duidelijke probleembeschrijving
    3. Stappen om het probleem te reproduceren - indien niet duidelijk uit samenvatting en / of beschrijving
    4. Bijlagen - in veel gevallen zijn bijlagen nodig om het probleem te reproduceren, als bijlage (en) niet worden verstrekt, kan dit de juiste oplossingen belemmeren
    5. Als het rapport verwijst naar externe gegevens (schermafdrukken, documenten, screencasts, enz.), Kopieer en voeg ze toe aan de bug, zodat ze later niet verdwijnen en uiteindelijk niet-reproduceerbaar worden.

    Als niet alle informatie goed is, ga dan verder met stap #5

    Stap 5: De fout proberen te reproduceren

    Als de bug de voorbereidingsstappen heeft "doorstaan", is het tijd om te proberen de bug te reproduceren.

    Doe precies dat: doorloop de stappen die nodig zijn en probeer de bug te reproduceren, zo eenvoudig! Wanneer u het reproduceert, moet u rekening houden met het volgende:

    1. Heeft de bug reporter genoeg informatie achtergelaten in Bugzilla zelf om de bug te reproduceren, of moest u extra stappen ondernemen? Als er extra stappen nodig waren, voeg dan een opmerking toe om de extra stap(pen) te beschrijven.
    2. Heeft de reproductie tot hetzelfde resultaat geleid, iets vergelijkbaars maar niet identiek, of werkte alles vlekkeloos?

    Stap 6: Status zetten

    Dit gedeelte is de laatste "verplichte" stap van een succesvolle triage en kan alleen worden uitgevoerd als de stappen #1 tot #4 zijn voltooid (of #3 als #4 niet van toepassing is).

    De STATUS van de bug is afhankelijk van uw resultaten van de bovenstaande stappen. Hieronder vindt u een korte beschrijving van elke status.

    1. NEW: Bevestigde bug, alle benodigde informatie is aanwezig
    2. NEEDINFO: Alle informatie die nodig is om replicatie te proberen, is niet opgenomen in het bugrapport. Vraag een bepaalde persoon om een bepaalde informatie te verstrekken.
    3. RESOLVED: Deze categorie wordt geleverd met verschillende opties. Als het probleem bijvoorbeeld al is gemeld, kunt u het markeren als RESOLVED DUPLICATE. Of als u de bug kunt repliceren zoals beschreven, maar het is al opgelost in een recentere versie, RESOLVED WORKSFORME is de juiste STATUS. Zie RESOLVED voor een gedetailleerde beschrijving van alle mogelijke waarden.
    4. VERIFIED: Deze optie is alleen beschikbaar als de huidige bugstatus is OPGELOST (RESOLVED). U kunt een opgeloste (RESOLVED FIXED) bug markeren als GEVERIFIEERD (VERIFIED), wanneer u kunt bevestigen dat deze is opgelost met de versie die in het bugrapport wordt vermeld. Het is ook prettig voor de ontwikkelaar die het probleem heeft opgelost en is een bevestiging dat het probleem nu is opgelost. Anders kan een bugreporter zijn eigen bug die zich in de status RESOLVED WORKSFORME bevindt, markeren als VERIFIED WORKSFORME om te controleren of deze op de een of andere manier is opgelost.
    5. INVALID: Er zijn veel redenen waarom kan worden vastgesteld dat een bug ongeldig is, maar dit vereist meestal inbreng van andere QA-leden. Als u een bug tegenkomt waarvan u denkt dat deze ongeldig is, kunt u het beste een second opinion krijgen van het QA IRC-kanaal of een e-mail sturen naar de mailinglijst waarin wordt uitgelegd waarom u denkt dat de bug ongeldig is.
    6. UNCONFIRMED: Dit is de status die alle nieuwe bugs krijgen die nog niet door triage beoordeeld zijn. Het kan ook zijn dat die bug dan de status NEEDINFO krijgt als er meer informatie nodig is om de bug te kunnen beoordelen.

    ELKE keer dat u wijzigingen aanbrengt, moet u een opmerking plaatsen die beleefd uitlegt waarom u de wijziging hebt aangebracht

    Stroomdiagrammen hieronder zijn voorbeelden van hoe u visueel kunt denken aan het instellen van STATUS. Voel ju vrij om uw eigen versie te bewerken en te uploaden als u dat wilt.
    PDF bestand
    LibreOffice Draw-bestand

    Stap 7: Regressie testen

    Gebruik oudere versies van LibreOffice om erachter te komen in welke versie de bug is geïntroduceerd.

    Download en installeer een aantal oude versies, waarvan de oudste LibreOffice 3.3 is. U moet minimaal één versie hebben van alle hoofdreleaselijnen (3.x, 4.x, 5.x, 6.x...).

    U moet zich bewust zijn van wanneer verschillende functies in de software zijn geïntroduceerd om te voorkomen dat u irrelevante testresultaten krijgt. Raadpleeg andere teamleden als u ergens niet zeker van bent.

    • Als de bug aanwezig is in versie 3.3.0, stel dan de versie in op "inherited from OOo" en voeg de volgende opmerking toe:
    This bug is already present in Libreoffice 3.3.0
    
    Changing version to "inherited from OOo"
    
    • Als de bug niet aanwezig is in 3.3.0, voeg dan "regression" toe aan het trefwoordenveld en voeg de volgende opmerking toe:
    This bug is not present in Libreoffice 3.3.0, thus it's a regression
    
    

    Voor regressies die ouder zijn dan versie 3.5.0, voegt u ook het trefwoord preBibisect toe. Voor nieuwere regressies voegt u het trefwoord bibisectRequest toe en werkt u het versieveld bij zodat deze overeenkomt met de vroegst bekende problematische versie.

    Stap 8: Prioriteit bug bepalen

    We highlighten nu alleen kritieke bugs door CC-ing ontwikkelaars en het toevoegen van trefwoorden. Meer informatie.

    Het prioriteren van een bug is relatief subjectief, maar de triager moet altijd proberen consistent te zijn met hoe ze de prioritering van een bug bepalen. Het QA-teamlid triage moet een duidelijk idee hebben van wat elke prioriteitsstatus vormt en vervolgens proberen vast te houden aan die methodologie. Ook is het nuttig om commentaar te geven op de bug na het prioriteren omdat het de bugverslaggever (evenals ontwikkelaars en andere gebruikers) laat weten welk denkproces u heeft gebruikt om de prioriteitsstatus te bedenken.

    Om bugs boven medium-normal te prioriteren, moet u worden toegevoegd aan de contributors-groep in Bugzilla. Om dit voor elkaar te krijgen, kunt u contact opnemen met een van de Bugzilla beheerders.

    Het onderstaande stroomdiagram toont ruwe richtlijnen over hoe om te gaan met prioritering.

    Voorbeeld1 JPG

    Vooebeeld1 Draw

    Het is meestal gemakkelijker om de ernst van een probleem te bepalen dan te proberen een geschikte prioriteit te bedenken.

    Kleine esthetische aanpassingen aan de gebruikersinterface kunnen worden beschouwd als lage prioriteit en trivial'.

    Problemen die u boos maken, maar die u op de een of andere manier kunt tolereren of omzeilen, kunnen worden ingesteld op minor'.

    Bugs die sommige functionaliteit breken en geen tijdelijke oplossing hebben, zijn normal.

    Crashes, vastlopen en vastlopen als gevolg van een specifiek bestand of commando zijn major.

    Aanvullende bruikbare (optionele) stappen

    Keywords

    De Trefwoorden veld bevat trefwoorden (keywords) met betrekking tot de categorisatie van deze bug.

    Enkele categorieën hiervan zijn:

    Een interessant trefwoord is needsDevEval. Een easyHack is een bug die hoogstwaarschijnlijk niet lang zal duren om te repareren en kan worden gedaan door een nieuwe ontwikkelaar en / of een ontwikkelaar zonder veel programmeervaardigheden. Als QA moeten we een bug NIET markeren als easyHack omdat het verschillende extra stappen vereist (inclusief het vinden van een ontwikkelaar om de bug te begeleiden). Als u denkt dat een bug kwalificeert als een easyhack, markeer dan als needsDevEval.

    Foutrapporten

    Het hebben van een crashrapport (ook bekend als backtrace) voor een bug maakt het voor een ontwikkelaar gemakkelijk om te identificeren wat de crash veroorzaakt. Als een crashrapport wordt toegevoegd aan een bugrapport, moet het trefwoord havebacktrace worden toegevoegd aan het veld 'Keywords.

    Meta rapporten

    Kijk naar onze bestaande meta-rapporten die rapporten van hetzelfde genre verzamelen. Als u een goede match vindt, voegt u het meta-rapportnummer toe aan het veld Blokken (Blocks) van het rapport dat u triageert.

    Commentaar tags

    Commentaar-tags fungeren als notities waarmee iedereen een snel overzicht krijgt van de reactiegeschiedenis en de waarde/relevantie van individuele opmerkingen. Klik op de tagtekst in de koptekst van een opmerking, voer uw tag in en druk op enter. Het is niet nodig om het rapport op te slaan. U kunt nieuwe tags bedenken of bestaande tags gebruiken. Het invoerveld voor tags ondersteunt automatisch aanvullen.

    Als u een van deze tags invoert, wordt de opmerking standaard verborgen: obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise. U kunt een verborgen opmerking weergeven door te klikken op de widget "Commentaarweergave in-/uitschakelen" in de commentaarkop. U kunt ook gewone opmerkingen verbergen en getagde opmerkingen weergeven door op de tagnaam van uw keuze te klikken onder de lijst "Commentaartags" naast de bugbeschrijving (opmerking 0). Klik op Alle opmerkingen uitvouwen om alles weer te geven.

    Aanvullende informatie controleren

    Als triager moeten we proberen de informatie te controleren die oorspronkelijk door de bugreporter werd gemeld. Dingen om te controleren zijn onder andere:

    • Product
    • Versie
    • Platform

    Ontwikkelaars toevoegen aan de CC

    Deze stap moet alleen worden uitgevoerd als u zeker weet dat deze belangrijk genoeg is om een ontwikkelaar te mailen met kopie. Als u denkt dat een bug ernstig genoeg is dat het extra aandacht verdient maar misschien niet thuishoort in de categorie Meest vervelende bugs, dan moet u een expert zoeken voor een aanvullende mening. Probeer dit met zorg te gebruiken, want we willen onze deskundige ontwikkelaars niet overspoelen met kleine bug-pings. Om de gebruiker toe te voegen, voegt u eenvoudig zijn naam toe aan de CC-lijst en plaatst een opmerking over de bug die de ontwikkelaars vertelt waarom u ze aan de CC hebt toegevoegd Hoe dan ook, de juiste namen zijn te vinden in de lijst met experts.

    QA toevoegen aan de CC

    Dit wordt meestal niet gebruikt, maar als u het gevoel hebt dat het toevoegen van uzelf of een ander QA-lid aan de lijst nuttig kan zijn, voel u dan vrij om dit te doen. Nogmaals, zorg ervoor dat u een opmerking toevoegt als u iemand anders aan de lijst toevoegt, anders kunnen ze geïrriteerd raken omdat ze niet weten wat er aan de hand is.

    Testen of het in samenhang met andere systemen werkt

    Als de testvereiste het openen of opslaan van een bestand met Microsoft Office is en u geen toegang hebt tot de software, kunt u gebruikmaken van Office Web Viewer. Het werkt met Word-, Excel-, PowerPoint- en ODF-documenten. U moet het document ergens uploaden en vervolgens de URL toevoegen aan het einde van deze link:

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

    U kunt vervolgens op de Print knop in het bovenste menu en ten slotte Open PDF om toegang te krijgen tot een PDF-weergave van het document. Hiermee kunt u zien hoe het document eruit ziet in de nieuwste versie van Microsoft Office en de PDF delen in Bugzilla.

    Bugzilla bijlage links werken met de viewer.

    Het gebruiken van de 'live viewer' in Firefox
    • Voeg een nieuwe bladwijzer toe
    • Stel een aantal Naam in
    • Stel de URL in op:
    https://view.officeapps.live.com/op/view.aspx?src=%s
    
    • Stel een Keyword in, zoals lv, druk op OK.
    • Nu kunt u het trefwoord bladwijzers plus een bugdoc-URL in de URL-balk gebruiken om de bugdoc in de Office Live Viewer te openen:
    lv https://bugs.documentfoundation.org/attachment.cgi?id=180059
    

    Aantekeningen over triage voor het QA-team

    Hier zijn enkele opmerkingen voor ervaren triagers in de QA/Team. Als u nieuw bent, maak u hier dan geen zorgen over!

    Bugrapporten die te lastig zijn voor triage of sluiten

    Soms hebben we speciale software of hardware nodig om een bug te reproduceren of we worden geconfronteerd met een andere moeilijkheid die ons ervan weerhoudt om te onderzoeken. Voor deze gevallen hebben wij:

    De collectie maakt gebruik van de MediaWiki Bugzilla-extensie, die gegevens uit metarapporten en verschillende andere query's haalt.

    Extensies

    Het is het beste om de maker van de extensie te betrekken bij de triage. De verantwoordelijkheid voor het contact opnemen met de maker ligt bij de bugreporter.

    Lees ook:

    Invloeden van de taal

    Soms worden we geconfronteerd met moeilijke onderwerpen met betrekking tot locaties. Er kan een situatie zijn waarin een landelijke norm voor iets afwijkt van de praktijk. In deze gevallen kan het nuttig zijn om de probleemmelder door te verwijzen naar de Unicode Common Locale Data Repository en hun enquêtehulpmiddel.

    Voorgestelde volgorde van triage

    De onderstaande tabellen geven een voorgestelde volgorde om de triage te benaderen. Het doel van QA is om eerst de ergste bugs te bevestigen.

    Tabel per platform (besturingssysteem)

    Beschrijving Alle bugs Windows Linux macOS Opmerkingen
    Bugs die crashes veroorzaken CrasherAll CrasherWindows CrasherLinux CrashermacOS Dit zijn bugs die "crash" of een vergelijkbaar woord in de titel van de bug hebben. Hiervan moet de ernst worden ingesteld op Major/Critical, afhankelijk van het aantal gebruikers dat wordt getroffen. QA moet ook kijken of de crash een regressie is of niet en "regressie" toevoegen aan trefwoorden als de bug wordt vastgesteld als een regressie.
    Potentiële regressies possibleRegressionAll possibleRegresionWindows possibleRegressionLinux possibleRegressionmacOS Als wordt bevestigd dat de bug een regressie is, moet het trefwoord "possibleRegression" worden verwijderd en moet "regression" aan de zoekwoorden worden toegevoegd.
    Keyword Regressie RegressionAll RegressionWindows RegressionLinux RegressionmacOS De melder van de bug of iemand anders heeft 'regression' in het zoekwoord gezet. Net zo belangrijk als de rij hierboven, maar Bugzilla staat geen "of" -zoekopdracht toe, dus moest het in twee rijen gesplitst worden.
    Bugs gerapporteerd als kritiek CriticalAll CriticalWindows CriticalLinux CriticalmacOS Alleen gebruikers met speciale bevoegdheden kunnen bugs op kritiek zetten. Kritiek is gereserveerd voor zeer ernstige bugs (zoals gegevensverlies dat veel gebruikers zal treffen). Meer informatie: PriorityFlowChart
    Bugs gerapporteerd als 'major' MajorAll MajorWindows MajorLinux MajormacOS Alleen gebruikers met speciale rechten kunnen bugs instellen op 'major'. Dat is gereserveerd voor zeer ernstige bugs (zoals gegevensverlies), maar die waarschijnlijk niet veel gebruikers zullen treffen of alleen in bijzondere gevallen met individuele documenten. Meer informatie: PriorityFlowChart.
    Alle bugs AllBugs AllWindows AllLinux AllmacOS Lijst van alle bugrapporten (geen verbeteringen). Als de bovenstaande bugs als eerste worden aangepakt, hebben de resterende bugs een iets lagere prioriteit om te bevestigen. Suggestie is om deze in chronologische volgorde te doen (oudste eerst, zodat gebruikers die het langst geleden een fout hebben gemeld voorrang krijgen).
    Verbeteringsverzoeken EnhancementAll EnhancementWindows EnhancementLinux EnhancementmacOS Verbeteringsverzoeken krijgen de laagste prioriteit als geldige verzoeken.

    Tabel per component

    Beschrijving Writer Calc Impress Draw Base Andere Opmerking
    Bugs gerapporteerd als vastlopers WriterCrasher SpreadsheetCrasher PresentationCrasher DrawingCrasher DatabaseCrasher OtherCrashers 'Kritiek' is alleen voorbehouden aan de ernstigste bugs (zoals het niet kunnen installeren van LibreOffice). Meer informatie: PriorityFlowChart
    Potentiële regressies WriterPosReg SpreadsheetPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg Als wordt bevestigd dat de bug een regressie is, moet het trefwoord "possibleRegression" worden verwijderd en moet "regression" aan de zoekwoorden worden toegevoegd.
    Keyword Regressie WriterRegression SpreadsheetRegression PresentationRegression DrawingRegression DatabaseRegression OtherRegressions De melder van de bug of iemand anders heeft 'regression' in het zoekwoord gezet. Net zo belangrijk als de rij hierboven, maar Bugzilla staat geen "of" -zoekopdracht toe, dus moest het in twee rijen gesplitst worden.
    Bugs gerapporteerd als kritiek WriterCritical SpreadsheetCritical PresentationCritical DrawingCritical DatabaseCritical OtherCritical Alleen gebruikers met speciale bevoegdheden kunnen bugs op kritiek zetten. Kritiek is gereserveerd voor zeer ernstige bugs (zoals gegevensverlies dat veel gebruikers zal treffen). Meer informatie: PriorityFlowChart
    Bugs gerapporteerd als 'major' WriterMajor SpreadsheetMajor PresentationMajor DrawingMajor DatabaseMajor OtherMajor Alleen gebruikers met speciale rechten kunnen bugs instellen op 'major'. Dat is gereserveerd voor zeer ernstige bugs (zoals gegevensverlies), maar die waarschijnlijk niet veel gebruikers zullen treffen of alleen in bijzondere gevallen met individuele documenten. Meer informatie: PriorityFlowChart.
    Overige bugs WriterOther SpreadsheetOther PresentationOther DrawingOther DatabaseOther AllOther Dit zijn alle bugs die zijn gemarkeerd als iets onder Major, maar exclusief verbeteringen.
    Verbeteringsverzoeken WriterEnhance SpreadsheetEnhance PresentationEnhance DrawingEnhance DatabaseEnhance OtherEnhance Verbeteringsverzoeken