QA/BugTriage

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/BugTriage and the translation is 37% 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

    Je kunt op meerdere manieren met leden van het QA-team in contact komen, de meesten kunnen je 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 je vrij om jezelf toe te voegen als je een bijdrage aan kwaliteitszorg hebt geleverd). Als de gebruiker toestaat dat je 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!
    

    Some bugs don't belong in Bugzilla at all. For a list of topics that belong elsewhere, see the BugReport page.

    • If one of these bugs is filed in Bugzilla, please change the Status to RESOLVED NOTOURBUG and add the following in a comment:

    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

    Duplicates are reports which are very similar or identical, but reported by different users. You typically want to keep the NEW status for the report with the most valuable information and close others as RESOLVED DUPLICATE. So even though an older report exists, there is no need to keep it open, if it contains confusing or incomplete information.

    Closed duplicates are automatically counted by Bugzilla and available at Most Frequently Reported Bugs page. When triaging please, check that list and do a quick search through reports in Bugzilla to see if there are any duplicates of the report you are examining. You don't need to spend a lifetime on this. As you see more reports you may start spotting duplicates without having to use the search.

    If you find a duplicate bug skip to step #5

    Stap 4: Informatie controleren

    Checking information is critical for development. What you should look for is the following:

    1. Clear and meaningful summary
    2. Clear problem description
    1. Steps to reproduce the problem -- if not clear from summary and/or description
    2. Attachments -- in many cases attachments are needed to reproduce the problem, if attachment(s) are not provided this can hinder proper fixes
    3. If the report refers to external data (screenshots, documents, screencasts, etc.), copy and attach them to the bug, so they don't vanish later and eventually render it unreproducible.

    If all information is not properly there, skip to step #5

    Stap 5: De fout proberen te reproduceren

    If the bug "passed" the Preparation steps it's time to try to reproduce the bug.

    Do just that: Go through the steps necessary and try to reproduce the bug, that simple! When you reproduce it, keep these things in mind:

    1. Did the bug reporter leave enough information in Bugzilla itself to reproduce the bug, or did you have to take extra steps? If extra steps were needed, add a comment to describe the extra step(s).
    2. Did your reproduction lead to the same result, something similar but not identical, or did everything work flawlessly?

    Stap 6: Status zetten

    This section is the last "mandatory" step of a successful triage and can only be done once steps #1–#4 are done (or #3 if #4 isn't applicable).

    The STATUS of the bug is dependent on your results from the above steps. Below is a short description of the usage of each status.

    1. NEW: Confirmed bug, all information necessary is there
    2. NEEDINFO: All information needed to attempt replication is not included in the bug report. Please ask a particular person for a particular information in a comment.
    3. RESOLVED: This category comes with several options, if you can't replicate the bug, RESOLVED WORKSFORME is the appropriate STATUS, see HERE for more information.
    4. VERIFIED: This option is only available when the current bug status is RESOLVED. You can mark a RESOLVED FIXED bug as VERIFIED, when you can confirm it is fixed with the version mentioned in the bug report. It is also pleasant for the developer who fixed the issue, and is a confirmation the problem is solved now. Otherwise a bug reporter can mark their own bug that is in RESOLVED WORKSFORME state as VERIFIED WORKSFORME to verify it is somehow fixed.
    5. INVALID: There are many reasons why a bug can be determined to be invalid, but this usually requires input from other QA members. If you come across a bug that you believe to be invalid, best bet is to get a second opinion from the QA IRC channel or send an email out to the mailing list explaining why you believe the bug to be invalid.
    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.

    ANY time you make changes you should put a comment that politely explains why you made the change

    Flowcharts below are examples of how to visually think of setting STATUS. Feel free to edit and upload your own version if you'd like.
    PDF file
    LibreOffice Draw file

    Stap 7: Regressie testen

    Use older versions of LibreOffice to find out whether the bug has been introduced since LibreOffice began.

    Download and install a number of old versions, the oldest being LibreOffice 3.3. At a minimum you should have one version from all the main release lines (3.x, 4.x, 5.x, 6.x...).

    You have to have some awareness of when various features were introduced into the software to avoid getting irrelevant test results. Please consult other team members, if you are unsure of something.

    • If the bug is present in version 3.3.0, set version to "inherited from OOo" and add the following comment:

    This bug is already present in Libreoffice 3.3.0

    Changing version to "inherited from OOo"
    
    • If the bug is not present in 3.3.0 add "regression" to the keywords field and add the following comment:

    This bug is not present in Libreoffice 3.3.0, thus it's a regression

    For regressions that are older than version 3.5.0, also add the keyword preBibisect. For newer regressions add the keyword bibisectRequest and update the version field to match the earliest known problematic version.

    Stap 8: Prioriteit bug bepalen

    We currently highlight only critical bugs by CC-ing developers and adding keywords. See below for more information.

    Prioritizing a bug is relatively subjective, but the triager should always try to be consistent with how they determine a bug's prioritization. The QA team member triaging should have a clear idea of what constitutes each priority state and then try to stick with that methodology. Also, commenting on the bug after prioritizing is helpful in that it lets the bug reporter (as well as developers and other users) know what thought process you used to come up with the priority status.

    To prioritize bugs above medium-normal, you need to be added to the contributors group in Bugzilla. In order to get this done, please contact one of the Bugzilla admins.

    The flowchart below shows rough guidelines on how to deal with prioritization.

    It is usually easier to determine the severity of an issue than try to think of a suitable priority.

    Small aesthetic tweaks to the UI can be considered low priority and trivial severity.

    Problems that make you angry, but you can tolerate or work around somehow can be set to minor severity.

    Bugs that break some functionality and do not have a workaround are normal severity.

    Crashes, hangs and freezes resulting from a specific file or command are major severity.

    Aanvullende bruikbare (optionele) stappen

    Keywords

    The Keywords field holds Keywords pertaining to the categorization of this bug.

    Some categories of Keywords include:

    One interesting Keyword is needsDevEval. An easyHack is a bug that will most likely not take long to fix and can be done by a new developer and/or a developer without a lot of programming skills. As QA we should NOT mark a bug as easyHack as it requires several additional steps (including finding a developer to mentor for the bug). If you think a bug qualifies as an easyhack, mark as needsDevEval.

    Foutrapporten

    Having a crash report (aka backtrace) for a bug makes it easy for a developer to identify what is causing the crash. If a crash report is added to a bug report, the havebacktrace keyword should be added to the Keywords field.

    Meta rapporten

    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.

    Commentaar 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.

    Aanvullende informatie controleren

    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

    Ontwikkelaars toevoegen aan de CC

    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.

    QA toevoegen aan de CC

    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.

    Testen of het in samenhang met andere systemen werkt

    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.

    Het gebruiken van de '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
    

    Aantekeningen over triage voor het QA-team

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

    Bugrapporten die te lastig zijn voor triage of sluiten

    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.

    Extensies

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

    Invloeden van de taal

    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.

    Voorgestelde volgorde van triage

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

    Tabel per platform (besturingssysteem)

    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.

    Tabel per 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