QA/BugTriage/da

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
 * 2) *libreoffice-qa@lists.freedesktop.org
 * 3) *libreoffice@lists.freedesktop.org
 * 4) IRC-kanaler på Libera Chat
 * 5) 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.
 * 6) * QA-medlemslisten
 * 1) 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.
 * 2) * QA-medlemslisten

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
 * 5) Forsøg at gentage fejlen
 * 6) Sæt status for fejlen
 * 7) Prioritér fejlen
 * 8) Giv besked til udviklerne -- Kun nødvendig i ganske særlige tilfælde, hvis fejl blokerer/er kritisk.

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:


 * Fejl rapporteret i de foregående 2 uger
 * Fejl rapporteret i den foregående 1 måned
 * Alle fejl, der behøver triage-arbejde. (Begrænset til 500 fejl, det vil tage nogen tid at indlæse den komplette liste, da det er en ret lang liste - du kan hjælpe med at ændre det!)
 * Alle macOS-fejl, der behøver bekræftelse

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

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

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. 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) 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
 * 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.

[[Media:Unconfirmed Bugs Status Flowchart Version 0.1.pdf|PDF-fil]]

[[Media:Unconfirmed Bugs Status Flowchart.odg|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.


 * SI-GUI - Enkel GUI-app til parallel installation under Windows og Android
 * Parallelinstallation - Instruktioner til manuel parallelinstallation om Windows, Linux og Mac.
 * https://downloadarchive.documentfoundation.org/libreoffice/old/ - Download gamle udgivelser, betaer and alphaer

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.

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

Nogle kategorier af nøgleord indeholder:
 * Ødelagte funktionalitet i bestemte områder: fx filter:xxx (filter:ooxml, filter:doc, filter:rtf, ...), perf
 * Anmodet eller leveret fejlsøgningsinformation: fx bibisectRequest, bibisected
 * Easy Hacks: easyHack, difficultyBeginner, skillCPP

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.


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

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 button in the top menu and finally  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
https://view.officeapps.live.com/op/view.aspx?src=%s
 * Add a new bookmark
 * Set some Name
 * Set the URL to:
 * 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.
 * A collection of UNCONFIRMED bugs that QA team members are having a hard time with.

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:
 * QA/BugReport/Extensions

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.