QA/BugTriage/da Fejlproritering

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/BugTriage and the translation is 52% complete.
    Outdated translations are marked like this.

    TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

    Other languages:


    Introduktion

    Dette dokument giver information om, hvordan fejl prioriteres i LibreOffice. Triage er navnet på bekræftelse, prioritering og organisering af fejlrapporter og er et godt sted for nye bidragsydere og/eller bidragsydere med begrænsede programmeringsevner at hjælpe LibreOffice med at blive et bedre produkt for alle. Triage er en utrolig vigtig del af udviklingen, som gavner både brugere og udviklere.

    Hvor finder jeg andre QA-medlemmer

    Der er nogle få steder, hvor du kan finde/kontakte medlemmer fra QA-holdet. Mange af dem kan hjælpe med spørgsmål om triage og deltager selv aktivt i triage.

    1. Maillister
      • libreoffice-qa@lists.freedesktop.org
      • libreoffice@lists.freedesktop.org
    2. IRC-kanaler på Libera Chat
    3. QA-medlemmer
      Her findes en liste over QA-medlemmer (tilføj gerne dit navn, hvis du ønsker at deltage i QA-arbejdet). Hvis brugeren har givet tilladelse til direkte kontakt, gør du det bare. Du kan også finde dem, når de halv-tit hænge ud i chatrummene.

    Trin i Fejl-triage

    Denne del oplister de trin, der er nødvendige i en korrekt triage. Denne tilsigter at være koncis; links i nogle afsnit giver flere oplysninger, der er relevante for det behandlede trin. Triage-processen kan efter sit væsen deles op i tre dele: den første "forberedelse", den anden "reproducering" og den tredje: "prioritering".

    Oversigt over trinene

    1. Find fejl til triage-behandling
    2. Forfiltrering af fejlrapporter
    3. Søgning efter fejl-dubletter
    4. Tjek af den information, der gives i fejlrapporter
    1. Forsøg at gentage fejlen
    2. Sæt status for fejlen
    3. Prioritér fejlen
    4. Giv besked til udviklerne -- Kun nødvendig i ganske særlige tilfælde, hvis fejl blokerer/er kritisk.

    Trinene detaljer

    Forberedelse

    Generelt vil du altid tage disse trin i forberedelsen af fejl-triage. Husk at du kun kan arbejde med fejl, når du er logget in ( opret venligst en konto, hvis du ikke allerede har en). Når du først har en konto, er det godt at gå til dine indstillinger og sæt 'Tilføj mig automatisk på CC:-listen på fejl, jeg retter' til 'Kun hvis jeg ikke har en rolle i dem', hvis du vil have besked, når som helst nogen svarer på en vilkårlig fejlrapport, du har kommenteret på.

    Trin 1: Find fejl til triage

    a) Bugzilla Search

    Navigér til LibreOffices fejlsporingssystem, der findes på bugs.documentfoundation.org. Når du har logget ind, browse åbner du problemerne efter komponent eller foretager en brugerdefineret søgning efter fejl, der er:

    a) indgivet om et LibreOffice-produkt

    b) har status som UNCONFIRMED (ubekræftet) eller REOPENED (genåbnet)

    c) tilføje hvilke som helst kriterier, du vil forespørge om

    Når du har nået det, leder du efter en fejl, du vil lave triage på. Brugerdefineret søgning efter fejl, kan konstrueres med Avanceret søgeformular eller ved at indtaste søgeterner i feltet Hurtigsøgning (Hjælp til Bugzillas Hurtigsøgning). Du kan også bruge følgende direkte links til at søge. Klik på linket vil bringe Bugzillas resultatside frem:

    Trin 2: Præfiltrer fejlrapporter

    Nogle fejl behøver særlig opmærksomhed fra bestemte teams:

    UX Forbedringer

    Alle fejl, som dækker forbedringer af LibreOffices UI/UX bør gives til UX-teamet

    1. Tilføj nøgleordet 'needsUXEval'
    2. Tilføj dette til CC-listen: libreoffice-ux-advise@lists.freedesktop.org
    3. Opdater Status
      • Hvis forespørgslen ser ud til at være komplet og troværdig, Status -> NEW (ny)
      • Hvis forespørgslen ser ud til at være ukomplet eller mangler forklaring, Status -> NEEDINFO (mangler oplysninger)
    2. Skriv en kommentar i retning af:
    UX Team -- please take a look at this enhancement. Thanks! (kig venligst på denne forbedring. Tak!)

    Nogle fejl hører slet ikke hjemme i Bugzilla. Find en liste over emner, der hører hjemme andre steder på siden Fejlrapportering.

    • Hvis en af disse fejl er indgivet i Bugzilla, vær venlig at rette Status til RESOLVED NOTOURBUG (Løst Ikke vores fejl) og tilføj følgende i kommentaren:
    Tak for at sætte dig i forbindelse med os!

    Selv om Bugzilla sommetider føles som universets centrum, er der stadig nogle få emner, der skal rapporteres andre steder. For at finde det rigtige at rapportere dit problem se venligst vores fejlrapporterings wiki-side: https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

    Trin 3: Led efter dubletter

    Dubletter er rapporter, som ligner hinanden meget eller er identiske, men indsendt af forskellige brugere. Du vil typisk beholde status NEW (ny) på rapporten og lukke andre som RESOLVED DUPLICATE (løst dublet). Så selv om der findes en ældre rapport, er der ikke brug for at holde den åben, hvis den indeholder forvirrende eller ufuldstændig information, Lukkede dubletter tælles automatisk af Bugzilla og findes på siden Mest hyppigt rapporterede fejl. Vi beder dig under triagen tjekke denne liste og lave en hurtig søgning gennem rapporterne i Bugzilla for at se, om der er nogle andre dubletter af den rapport, du undersøger. Du behøver ikke at bruge dit liv på det. Efterhånden som du ser flere rapporter, begynder du måske at finde dubletter uden at skulle bruge søgningen.

    Hvis du finder en fejldublet, hopper du til trin #5

    Trin 4: Tjek oplysningerne

    Tjek af oplysninger er kritisk for udviklingen. Du bør se efter dette:

    1. Klart og meningsfuldt resume
    2. Klar problembeskrivelse
    1. Trin til gentagelse af problemet -- hvis det ikke er klart ud fra resumeet og/beskrivelsen
    2. Vedhæftninger -- i mange tilfælde er vedhæftninger nødvendige for at genskabe problemet, hvis der ikke er en vedhæftning, kan dette forhindre passende løsninger

    Hvis al information ikke rigtig er der, hop til trin #5

    Trin 5: Prøv at genskabe fejlen

    Hvis fejlen "bestod" forberedelsestrinene, er det tid at prøve at genskabe fejlen.

    Gør bare dette: Gentag de nødvendige trin og prøv at genskabe fejlen, helt enkelt! Når du genskaber den, skal du huske:

    1. Gav rapportøren af fejlen nok oplysninger i selve Bugzilla til at genskabe fejlen, eller skulle du tage ekstra trin? Hvis ekstra trin var nødvendige, tilføjer du en kommentar for at beskrive de ekstra trin.
    2. Førte din genskabelse til samme resultat, noget lignende, men ikke identisk, er fungerede alt upåklageligt?

    Trin 6: Sæt Status

    Dette afsnit er det sidste "obligatoriske" trin i en successfuld triage og kan kun udføres, hvis trin #1-#4 er klaret (eller #3, hvis #4 ikke er relevant).

    Fejlens STATUS afhænger af dine resultater i trinnene ovenfor. Herunder er der en kort beskrivelse af brugen af hver enkel status.

    1. NEW: Bekræftet fejl, alle nødvendige oplysninger findes
    2. NEEDINFO: Alle oplysninger, der er nødvendige til genskabelse, er ikke medtaget i fejlrapporten. Bed venligst i en kommentar en bestemt person om en bestemt oplysning.
    3. RESOLVED: Denne kategori har mange muligheder: hvis du ikke kan genskabe fejlen, er den relevante STATUS RESOLVED WORKSFORME (Løst - virker for mig) is the appropriate STATUS, find flere oplysninger HER.
    4. VERIFIED: Denne indstilling er kun tilgængelig, når den aktuelle fejl er

    RESOLVED (løst). Du kan markere en RESOLVED FIXED (læst ordnet) fejl som VERIFIED (verificeret), når du kan bekræfte, at den er ordnet i den version, der er nævnt i fejlrapporten. Det er også rart for udvikleren, der ordnede problemet, og det er bekræftelse af, at problemet nu er løst. Ellers kan en fejlrapportør mærke sin egen fejl, hvis status er RESOLVED WORKSFORME som VERIFIED WORKSFORME, for at bekræfte, at den på en eller måde er ordnet.

    1. INVALID: Der er mange grunde til, at en fejl kan bestemmes som ugyldig, men sædvanligvis kræver dette input fra andre QA-medlemmer. Hvis du støder på en fejl, der efter din mening er ugyldig, er det bedste træk at sende få en 'second opinion' fra andre QAs IRC-kanal eller sende en email til maillisten og forklare, hvorfor du tror, at fejlen er ugyldig.
    2. UNCONFIRMED: Dette er den status, der gives alle nye fejl, der ikke har gennemgået triage-processen. Bemærk, at en sådan fejl også kan være i NEEDINFO-tilstand.

    NÅR som helst du foretager ændringer, bør du skrive en kommentar, der høfligt forklarer, hvor du lavede ændringen

    Rutediagrammerne herunder er eksempler på, hvordan man visuelt tænker på at sætte STATUS. Du er velkommen til at redigere og uploade din egen version, hvis du synes.
    PDF-fil
    LibreOffice Draw-fil

    Step 7: Regressionstests

    Brug ældre versioner af LibreOffice til at finde ud af, om fejlen har været der, fra før LibreOffice begyndte.

    Download og installer et antal ældre versioner, med LibreOffice 3.3 som den ældste. Du bør mindst have en version fra hver af hovedudgivelserne (3.x, 4.x, 5.x, 6.x...).

    Du skal have nogen viden om, hvornår forskellige funktionaliteter blev introduceret i softwaren for at undgå irrelevante testresultater. Konsulter venligst andre teammedlemmer, hvis du er usikker på noget.

    • Hvis fejlen findes i version 3.3.0, sætter du versionen til "nedarvet fra OOo" og tilføj følgende kommentar:
    Denne fejl findes allerede i Libreoffice 3.3.0

    og ændrer versionen til "nedarvet fra OOo"

    • Hvis fejlen ikke findes i 3.3.0 tilføjer du "regression" i feltet Nøgleord og tilføjer følgende kommentar:
    Denne fejl findes ikke i Libreoffice 3.3.0, derfor er det en regression

    Ved regressioner, der er ældre end version 3.5.0, tilføjer du også nøgleordet preBibisect. Ved nyere regressioner tilføjer du nøgleordet bibisectRequest og opdaterer versionsfeltet, så det matcher den tidligst kendte, problematiske version.

    Trin 8: Prioriter fejlen

    Fortiden fremhæver vi udelukkende kritiske fejl ved at sende CC til udviklere og tilføje nøgleord. Find flere oplysninger herunder.

    Prioritering af en fejl er forholdsvis subjektivt, men den, der laver triage, bør altid prøve at være konsistent i sin vurdering af en fejls prioritering. Det teammedlem, der laver triage, bør have en klar ide, om hvad der udgør hver prioritets-tilstand og så prøve at holde sig til metoden. Det er også nyttigt at kommentere på fejlen efter prioriteringen, derved at det lader fejlrapportøren (såvel som udviklere og andre brugere) vide, hvilke tankeprocesser, der førte dig til denne prioriteringsstatus.

    For at prioritere fejl over medium-normal skal du tilføjes til gruppen af bidragsydere i Bugzilla. For at blive det kontakter du venligst en Bugzilla admin.

    Rutediagrammet herunder viser de grove retningslinjer for prioritering.

    Example 1 JPG

    Example 1 Draw

    Det er sædvanligvis lettere at tænke på et problems alvorlighed end at tænke på en passende prioritet.

    Små æstetiske tilpasninger af brugerfladen kan bedømmes som lav prioritet og triviel alvorlighed.

    Problemer, der gør dig vred, men som kan tolerere eller omgå, kan sættes til mindre alvorlighed.

    Fejl, der ødelægger noget funktionalitet og ikke kan omgås er af normal alvorlighed.

    Nedbrud, hængen og frysninger der kommer fra en bestemt fil eller kommando er af større alvorlighed.

    Flere nyttige (valgfire) Trin

    Nøgleord

    Feltet Nøgleord indeholder nøgleord vedrørende kategoriseringen af denne fejl.

    Nogle kategorier af nøgleord indeholder:

    Et interessant nøgleord er needsDevEval (behøver Udviklings-evaluering). Et easyHack er en fejl, der sandsynligvis ikke tager lang tid at ordne og kan laves af en ny udvikler og/eller en udvikler uden mange programmeringsevner. Som QA bør vi IKKE mærke en fejl som easyHack, da den kræver adskillige yderlige trin (herunder at finde en udvikler til at være mentor på fejlen). Hvis du tror, at en fejl kunne være et easyHack, mærk den needsDevEval.

    Nedbrudsrapporter

    Med en nedbrudsrapport (også kaldet backtrace) til en fejl gør det let for en udvikler at identificere, hvad der er årsag til sammenbruddet. Hvis der er tilføjet en nedbrudsrapport til fejlrapporten, bør nøgleordet havebacktrace tilføjes i feltet Keywords.

    Meta reports

    Look at our existing meta reports that collect reports of the same genre. If you find a good fit, add the meta report number to the Blocks field of the report you are triaging.

    Comment tags

    Comment tags act as notes that help everyone get a quick overview of the comment history and value/relevance of individual comments. Click the tag text in the header of a comment, input your tag and press enter. There is no need to save the report. You can invent new tags or use existing tags. The tag input field supports auto-completion.

    Entering one of these tags make the comment hidden by default:

    obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise.

    You can show a hidden comment by clicking on the "Toggle comment display" widget in the comment header. You can also hide regular comments and show tagged comments by clicking on the tag name of your choosing under the "Comment Tags" list next to the bug description (comment 0). Click Expand all comments to show everything.

    Checking Additional Info

    As a triager we should try to check the information that was originally reported by the bug reporter. Things to check include:

    • Product
    • Version
    • Platform

    Adding Developer to CC List

    This step should only be done if you're sure that it is important enough to CC a developer. If you think that a bug is serious enough that it deserves extra attention but maybe does not belong in the category of Most Annoying Bugs, then you should seek out an expert for additional input. Please try to use this with care as we don't want to inundate our expert developers with minor bug pings. To add the user simply add their name to the CC list and put a comment on the bug telling the developers why you've added them to the CC Anyway, the right names can be found in the list of experts.

    Adding QA to CC List

    This mostly is not used but if you feel like adding yourself or another QA member to the list might be useful, feel free to do so. Again, please make sure to add a comment if you're adding someone else to the list, otherwise they might get irritated at not knowing what's going on.

    Interoperability testing

    If the requirement for testing is opening or saving a file with Microsoft Office and you don't have access to the software, you might make use of Office Web Viewer. It works with Word, Excel, PowerPoint and ODF documents. You need to upload the document somewhere and then add the URL to the end of this link:

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

    You can then click the Print button in the top menu and finally Open PDF to get access to a PDF rendering of the document. This will both allow you to see how the document looks like in the latest version of Microsoft Office and share the PDF in Bugzilla.

    Bugzilla attachment links work with the viewer.

    To conveniently use the live viewer in Firefox
    • Add a new bookmark
    • Set some Name
    • Set the URL to:
    https://view.officeapps.live.com/op/view.aspx?src=%s
    • Set a Keyword, such as lv, press OK.
    • Now you can use the bookmarks keyword plus a bugdoc URL in the URL bar to open the bugdoc in the Office live viewer:
    lv https://bugs.documentfoundation.org/attachment.cgi?id=180059

    Special Triage Notes for the QA Team

    Here are some notes for Advanced Triagers on the QA/Team. If you're new, don't worry about any of this!

    Bug reports that are difficult to triage or close

    Sometimes we need special software or hardware to reproduce a bug or we face some other difficulty that prevents us from investigating. For these cases we have:

    The collection uses the MediaWiki Bugzilla extension, which pulls data from meta reports and various other queries.

    Extensions

    It is best to get the creator of the extension involved in triaging. The responsibility for contacting the creator is on the bug reporter.

    Also read:

    Locale-related controversy

    Sometimes we are faced with hot topics related to locales. There might be a situation where a national standard for something differs from the actual practice. In these cases, it can be useful to direct the issue reporter to the Unicode Common Locale Data Repository and their survey tool.

    Suggested Triage Order

    The tables below represent a suggested order to approach triaging. The goal of QA is to confirm the worst bugs first.

    Table By Platform (OS)

    Description All Bugs Windows Linux macOS Comments
    Bugs Reporting Crashes CrasherAll CrasherWindows CrasherLinux CrashermacOS These are bugs that have "crash" or some similar word in the title of the bug. For crashers the severity should be set to Major/Critical depending on how many users will be affected. Also, QA should look at if the crash is a regression or not and add "regression" to keywords if the bug is determined to be a regression.
    Potential Regressions possibleRegressionAll possibleRegresionWindows possibleRegressionLinux possibleRegressionmacOS If the bug is confirmed to be a regression, the Keyword "possibleRegression" should be removed and "regression" should be added to the keywords.
    Keyword Regression RegressionAll RegressionWindows RegressionLinux RegressionmacOS The reporter of the bug or someone else has put regression in the keyword. Equally important as the row above but Bugzilla does not allow an "or" search so had to split into two rows.
    Bugs Reported as Critical CriticalAll CriticalWindows CriticalLinux CriticalmacOS Only contributors with special privileges can set bugs to critical. Critical is reserved for very serious bugs (such as data loss which will affect many userse). For guidance see PriorityFlowChart
    Bugs Reported as Major MajorAll MajorWindows MajorLinux MajormacOS Only contributors with special privileges can set bugs to major. Major is reserved for very serious bugs (such as data loss) but which will likely not affect many users or are only happening in corner cases with individual documents. For guidance see PriorityFlowChart.
    All Bugs AllBugs AllWindows AllLinux AllmacOS List of all bug reports (no enhancements). If the above bugs are tackled first then the ones remaining will be of slightly lower priority to confirm. Suggestion is to do these in chronological order (oldest first so that users who reported the longest time ago get priority).
    Enhancement Requests EnhancementAll EnhancementWindows EnhancementLinux EnhancementmacOS Enhancement requests are the lowest priority to confirm as valid requests.

    Table By Component

    Description Writer Calc Impress Draw Base Other Comment
    Bugs Reported as Crashers WriterCrasher SpreadsheetCrasher PresentationCrasher DrawingCrasher DatabaseCrasher OtherCrashers 'Critical' severity is reserved for only the most serious bugs (such as inability to install LibreOffice). For guidance see PriorityFlowChart
    Potential Regressions WriterPosReg SpreadsheetPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg If the bug is confirmed to be a regression, the Keyword "possibleRegression" should be removed and "regression" should be added.
    Keyword Regression WriterRegression SpreadsheetRegression PresentationRegression DrawingRegression DatabaseRegression OtherRegressions The reporter of the bug or someone else has put regression in the keyword. Equally important as the row above but Bugzilla does not allow an "or" search so had to split into two rows.
    Bugs Reported as Critical WriterCritical SpreadsheetCritical PresentationCritical DrawingCritical DatabaseCritical OtherCritical Only contributors with special privileges can set bugs to critical. Critical is reserved for very serious bugs (such as data loss which will affect many userse). For guidance see PriorityFlowChart.
    Bugs Reported as Major WriterMajor SpreadsheetMajor PresentationMajor DrawingMajor DatabaseMajor OtherMajor Only contributors with special privileges can set bugs to major. Major is reserved for very serious bugs (such as data loss) but which will likely not affect many users or are only happening in corner cases with individual documents. For guidance see PriorityFlowChart.
    All Other Bugs WriterOther SpreadsheetOther PresentationOther DrawingOther DatabaseOther AllOther These are all bugs marked as anything below Major but not including Enhancements.
    Enhancement Requests WriterEnhance SpreadsheetEnhance PresentationEnhance DrawingEnhance DatabaseEnhance OtherEnhance Enhancement Requests
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=QA/BugTriage/da&oldid=774316"