QA/BugTriage/cs

Úvod
Tento dokument poskytuje informace o tom, jak třídit chyby v LibreOffice. Třídění (Triage) je název pro potvrzení, stanovení priority a organizaci hlášení o chybách a je dobrým místem pro nové přispěvatele nebo přispěvatele s omezenými programovacími schopnostmi, aby pomohli LibreOffice stát se lepším produktem pro každého. Třídění je neuvěřitelně důležitý aspekt vývoje, ze kterého mají prospěch uživatelé i vývojáři.

Kde najít další členy QA týmu
Existuje několik míst, kde můžete najít/kontaktovat členy QA týmu, z nichž mnozí mohou pomoci s dotazy ohledně třídní a sami aktivně třídí.


 * 1) E-mailové konference
 * 2) *libreoffice-qa@lists.freedesktop.org
 * 3) *libreoffice@lists.freedesktop.org
 * 4) IRC kanály na Libera Chat
 * 5) Členové QA Zde je seznam členů QA (pokud chcete přispět k QA, můžete přidat své vlastní jméno). Pokud vám uživatel dal svolení kontaktovat je přímo, můžete tak učinit. Také je najdete dost často v chatovacích místnostech, kde něco diskutují.
 * 6) * Seznam členů QA
 * 1) Členové QA Zde je seznam členů QA (pokud chcete přispět k QA, můžete přidat své vlastní jméno). Pokud vám uživatel dal svolení kontaktovat je přímo, můžete tak učinit. Také je najdete dost často v chatovacích místnostech, kde něco diskutují.
 * 2) * Seznam členů QA

Kroky ke třídění chyby
Tato část obsahuje seznam kroků nezbytných pro správné třídění. Tento návod má být stručný, odkazy v některých částech poskytnou více informací relevantních pro konkrétní krok. Proces třídění lze v zásadě rozdělit na tři části, z nichž první je „příprava“, druhá je „reprodukce“, třetí je „prioritizace“.

'Přehled kroků'

 * 1) Najděte chyby k třídění
 * 2) Předfiltrujte hlášení o chybách
 * 3) Vyhledejte duplikáty chyb
 * 4) Zkontrolujte informace uvedené v hlášení o chybě
 * 5) Pokuste se o reprodukci chyby
 * 6) Nastavte stav chyby
 * 7) Stanovte prioritu chyby
 * 8) Upozorněte vývojáře - je potřeba pouze ve velmi specifických případech, pokud se chyba jeví jako blokátor/kritická.

Příprava
Obecně jsou při přípravě třídění chyb žádoucí tyto kroky. Nezapomeňte, že na chybách můžete pracovat pouze po přihlášení (prosím vytvořte účet, pokud jej ještě nemáte). A jakmile máte účet, je dobré jít do předvoleb a nastavit 'Automaticky přidat mě do seznamu CC chyb, které změním' na 'Pouze pokud nemají na ně žádnou roli “, pokud chcete být upozorněni pokaždé, když někdo odpoví na některou z hlášení chyb, ke které jste se vyjádřili.

Krok 1: Najděte chyby k třídění
a) Hledání v Bugzille

Přejděte do systému sledování chyb LibreOffice, který se nachází na adrese bugs.documentfoundation.org. Po přihlášení, procházení otevřete problémy podle komponenty nebo proveďte vlastní hledání chyb, které jsou:

a) zařazené v produktu LibreOffice

b) mají status UNCONFIRMED nebo REOPENED

c) přidejte jakákoli další kritéria, podle kterých byste chtěli hledat

Jakmile jste tam, hledejte chybu, kterou chcete třídit. Vlastní hledání chyb lze vytvořit pomocí formuláře pro pokročilé vyhledávání nebo zadáním vyhledávacích dotazů do pole Rychlé hledání (Nápověda pro rychlé vyhledávání Bugzilly). Můžete také použít následující přímé odkazy na vyhledávání. Kliknutím na odkaz se zobrazí stránka s výsledky Bugzilly:


 * Chyby hlášené v předchozích 2 týdnech
 * Chyby hlášené v předchozím 1 měsíci
 * Všechny chyby, které potřebují třídění. (Omezeno na 500 chyb, načtení celého seznamu bude nějakou dobu trvat, protože je to poměrně dlouhý seznam - můžete to změnit!)
 * Všechny macOS chyby, které vyžadují potvrzení

Krok 2: Předběžné filtrování hlášení o chybách
Některé chyby vyžadují zvláštní pozornost specifických týmů:

UX vylepšení
Veškeré chyby, které pokrývají vylepšení UI / UX LibreOffice, by měly být dány týmu UX

Tým UX - podívejte se prosím na toto vylepšení. Dík!
 * 1) Přidejte klíčové slovo 'needsUXEval'
 * 2) Přidejte toto do seznamu CC:
 * 3) Aktualizujte stav
 * 4) * Pokud požadavek vypadá kompletní a hodnověrný, nastavte  'Status'  ->  NEW 
 * 5) * Pokud se požadavek zdá neúplný nebo potřebuje vysvětlení,  'Status'  ->  NEEDINFO 
 * 6) Zanechte komentář v řádcích:

 Některé chyby Bugzille vůbec nepatří . Seznam témat, která patří jinam, viz stránka BugReport.
 * Pokud je některá z těchto chyb uložena v Bugzille, změňte prosím status  'Status'  na RESOLVED NOTOURBUG a do komentáře přidejte následující:

Děkujeme, že jste nás kontaktovali! Přestože se Bugzilla někdy cítí jako střed vesmíru, existuje několik témat, která musí být hlášena jinde. Správné místo k nahlášení vašeho problému, najdete na wiki stránce BugReport: https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

Krok 3: Vyhledejte duplikáty
Duplikáty jsou zprávy, které jsou velmi podobné nebo identické, ale jsou hlášeny různými uživateli. Obvykle chcete zachovat stav NEW pro zprávy s nejcennějšími informacemi a ostatní uzavřít jako RESOLVED DUPLICATE (VYŘEŠENÝ DUPLIKÁT). Takže přestože existuje starší zpráva, není třeba ji udržovat otevřenou, pokud obsahuje matoucí nebo neúplné informace. Uzavřené duplikáty automaticky zaznamenává Bugzilla a jsou k dispozici na stránce Nejčastěji hlášené chyby. Při třídění prosím zkontrolujte tento seznam a proveďte rychlé search through reports in Bugzilla, abyste zjistili, zda existují nějaké duplikáty zprávy, kterou zkoumáte. Nemusíte nad tím strávit moc času. Až uvidíte více zpráv, poznáte pravděpodobně duplikáty, aniž byste museli používat vyhledávání.

'''Pokud najdete duplicitní chybu, přeskočte na krok č. 5'''

Krok 4: Kontrola informací
Kontrola informací je pro vývoj rozhodující. Měli byste hledat zejména:


 * 1) Jasné a smysluplné shrnutí
 * 2) Jasný popis problému
 * 1) Kroky pro reprodukování problému - pokud to není zřejmé ze shrnutí a / nebo popisu
 * 2) Přílohy - v mnoha případech jsou k reprodukování problému nutné přílohy, pokud nejsou přílohy k dispozice, může to vlastní opravy ztížit

'''Pokud nejsou všechny informace správně poskytnuty, přejděte ke kroku č. 5'''

Krok 5: Pokus o reprodukci
Pokud chyba „prošla“ přípravnými kroky, je čas zkusit tuto chybu reprodukovat.

Udělejte jen toto: Projděte nezbytné kroky a pokuste se reprodukovat chybu, tak jednoduché! Při reprodukci mějte na paměti tyto věci:
 * 1) Zanechal reportér chyb v Bugzille dostatek informací, aby chybu reprodukoval, nebo jste museli podniknout další kroky? Pokud byly potřeba další kroky, přidejte komentář k popisu těchto dalších kroků.
 * 2) Vedla vaše reprodukce ke stejnému výsledku, něčemu podobnému, ale ne identickému, nebo všechno fungovalo bezchybně?

Krok 6: Nastavení stavu
Tato část je posledním „povinným“ krokem úspěšného třídění a může být provedena pouze poté, co jsou provedeny kroky # 1– # 4 (nebo # 3, pokud # 4 nelze použít).

STATUS chyby závisí na vašich výsledcích z výše uvedených kroků. Níže je uveden stručný popis použití jednotlivých stavů.
 * 1) NEW: Potvrzená chyba, všechny potřebné informace jsou zde
 * 2) NEEDINFO: Ve zprávě o chybách nejsou zahrnuty všechny informace potřebné k pokusu o replikaci. Požádejte konkrétní osobu o konkrétní informaci v komentáři.
 * 3) RESOLVED: Tato kategorie přichází s několika možnostmi, pokud nemůžete replikovat chybu, je vhodný STATUS RESOLVED WORKSFORME, další informace viz  zde.
 * 4) VERIFIED: Tato možnost je k dispozici, pouze pokud je aktuální stav chyby RESOLVED (VYŘEŠENO). VYŘEŠENOU OPRAVENOU chybu můžete označit jako VERIFIED (VERIFIKOVÁNO), pokud můžete potvrdit, že je chyba opravena verzí uvedenou v hlášení o chybě. Pro vývojáře, který problém vyřešil, je to užitečné a je to i potvrzení, že problém je nyní vyřešen. V opačném případě může reportér chyb označit svou vlastní chybu, která je ve stavu  RESOLVED WORKSFORME jako VERIFIED WORKSFORME, aby bylo ověřeno, že je to nějak opraveno.
 * 5) INVALID: Existuje mnoho důvodů, proč lze chybu určit jako neplatnou, ale obvykle to vyžaduje vstup od ostatních členů QA. Pokud narazíte na chybu, o které se domníváte, že není platná, je nejlepší získat druhý názor od QA IRC nebo poslat e-mail do mailing listu s vysvětlením, proč se domníváte, že chyba není platná.
 * 6) UNCONFIRMED: Toto je stav daný všem novým chybám, které neproběhly procesem třídění. Tato chyba může být také ve stavu NEEDINFO.

Kdykoli provedete změny, měli byste vložit komentář, který přehledně vysvětluje, proč jste změnu provedli

Vývojové diagramy níže jsou příklady toho, jak vizuálně přemýšlet o nastavení stavu chyby. Pokud chcete, můžete upravit a nahrát svou vlastní verzi.

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

[[Media:Unconfirmed Bugs Status Flowchart.odg|LibreOffice Draw file]]

Krok 7: Regresní testování
Použijte starší verze LibreOffice a zjistěte, zda chyba existovala již od začátku LibreOffice.

Stáhněte si a nainstalujte několik starých verzí, z nichž nejstarší je LibreOffice 3.3. Minimálně byste měli mít jednu verzi ze všech hlavních řad vydání (3.x, 4.x, 5.x, 6.x ...).

Musíte si být vědomi toho, kdy byly do softwaru zavedeny různé funkce, abyste se vyhnuli irelevantnímu výsledku testu. Pokud si nejste jisti, obraťte se na další členy týmu.


 * Pokud je chyba přítomna ve verzi 3.3.0, nastavte verzi na "inherited from OOo (zděděnou z OOo)" a přidejte tento komentář:

This bug is already present in Libreoffice 3.3.0 (český překlad: Tato chyba je již v Libreoffice 3.3.0) Změna verze na „inherited from OOo“


 * Pokud se chyba nevyskytuje v 3.3.0, přidejte do pole klíčových slov "regression" (regrese) a přidejte tento komentář:

This bug is not present in Libreoffice 3.3.0, thus it's a regression (český překlad: Tato chyba se v Libreoffice 3.3.0 nevyskytuje, jedná se tedy o regresi) U regresí starších než verze 3.5.0 přidejte klíčové slovo preBibisect. Pro novější regrese přidejte klíčové slovo bibisectRequest a aktualizujte pole verze tak, aby odpovídalo nejstarší známé problematické verzi.


 * SI-GUI - Jednoduchá aplikace GUI pro paralelní instalaci na Windows a Android
 * Installing in parallel - Pokyny k ruční paralelní instalaci na Windows, Linux a Mac.
 * https://downloadarchive.documentfoundation.org/libreoffice/old/ - Stáhněte si stará vydání, beta a alfa

Krok 8: Prioritizace chyby
V současné době upozorňují na kritické chyby a přidávají klíčová slova pouze CC vývojáři. Viz více informace níže.

Stanovení priority chyby je relativně subjektivní, ale triager by se měl vždy snažit být konzistentní v tom, jak určí prioritu chyby. Členové týmu QA triaging by měli mít jasnou představu o tom, co představuje každý prioritní stav, a poté se pokusit držet se této metodiky. Také je užitečné po stanovení priority chyby přidat komentář, což umožňuje reportérovi chyb (stejně jako vývojářům a dalším uživatelům) poznat, jaký myšlenkový proces jste použili pro stanovení stavu priority.

Chcete-li upřednostnit chyby nad středně normální, je třeba, abyste byl přidán do skupiny přispěvatelů v Bugzille. Chcete-li to provést, kontaktujte prosím někoho z administrátorů Bugzilly.

Níže uvedený vývojový diagram ukazuje hrubé pokyny, jak zacházet s prioritami.

Příklad 1 JPG

Příklad 1 Draw

Obvykle je snazší určit závažnost problému, než se pokusit vymyslet vhodnou prioritu.

Malé estetické vylepšení uživatelského rozhraní lze považovat za nízkou prioritu a triviální závažnost.

Problémy, které vás rozčilují, ale můžete je nějak tolerovat nebo nějak obejít, lze nastavit na minor (menší) závažnost.

Chyby, které narušují některé funkce a nemají řešení, mají normal (normální) závažnost.

Havárie, zablokování a zamrznutí způsobené konkrétním souborem nebo příkazem mají major (velkou) závažnost.

Klíčová slova
Pole Keywords (klíčová slova) obsahuje klíčová slova týkající se kategorizace této chyby.

Některé kategorie klíčových slov zahrnují:
 * Porušená funkcionalita v konkrétních oblastech: např. filter:xxx (filter:ooxml, filter:doc, filter:rtf, ...), perf
 * Požadované nebo poskytované informace o ladění: např.  bibisectRequest, bibisected
 * Easy Hacks: easyHack, difficultyBeginner, skillCPP

Jedním ze zajímavých klíčových slov je needsDevEval. EasyHack je chyba, jejíž oprava pravděpodobně nezabere moc času a může být provedena novým vývojářem nebo vývojářem s méně programovacími dovednostmi. Jako QA bychom NEMĚLI označit chybu jako easyHack, protože vyžaduje několik dalších kroků (včetně nalezení vývojáře jako mentora pro chybu). Pokud si myslíte, že lze chybu označit jako "easyhack", označte ji jako needsDevEval.

Hlášení o pádech
Díky chybové zprávě o pádu (aka backtrace) vývojáři snadno zjistí, co způsobuje pád aplikace. Pokud je zpráva o pádu přidána do zprávy o chybě, mělo by se do pole Keywords přidat klíčové slovo havebacktrace.


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

Meta zprávy
Podívejte se na naše existující meta zprávy, které shromažďují zprávy stejného žánru. Pokud najdete vhodnou meta zprávu, přidejte číslo této meta zprávy do pole Bloky ve zprávě, kterou právě upravujete.

Comment tags (Štítky komentářů)
Štítky komentářů fungují jako poznámky, které pomáhají každému získat rychlý přehled o historii komentářů a hodnotě / relevanci jednotlivých komentářů. Klikněte na text štítku v záhlaví komentáře, zadejte štítek a stiskněte klávesu Enter. Není třeba zprávu ukládat. Můžete vymýšlet nové štítky nebo používat existující štítky. Pole pro zadání štítku podporuje automatické doplňování.

Zadáním jednoho z těchto štítků bude komentář ve výchozím nastavení skrytý: obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise. Skrytý komentář můžete zobrazit kliknutím na widget "Přepnout zobrazení komentáře" v záhlaví komentáře. Můžete také skrýt pravidelné komentáře a zobrazovat označené komentáře kliknutím na název štítku podle svého výběru v seznamu "Štítky komentářů" vedle popisu chyby (komentář 0). Všechny komentáře zobrazíte kliknutím na Rozbalit všechny komentáře.

Kontrola dodatečných informací
Jako triager bychom se měli pokusit zkontrolovat informace, které původně hlásil reportér chyb. Kontrola zahrnuje:
 * Produkt
 * Verze
 * Platforma

Přidání vývojáře do seznamu CC
Tento krok by měl být proveden pouze v případě, že jste si jisti, že je to důležité pro CC vývojáře. Pokud si myslíte, že chyba je natolik vážná, že si zaslouží zvláštní pozornost, ale možná ne status MAB, měli byste vyhledat odborníka pro dodatečný input (zápis). Prosím, používejte toto s rozmyslem, protože nechceme zaplavit naše odborné vývojáře drobnými chybovými pingy. Chcete-li přidat uživatele, přidejte jeho jméno do seznamu CC a 'přidejte komentář k chybě a řekněte vývojářům, proč jste jej přidali do CC'. Každopádně správná jména však najdete v seznamu odborníků.

Přidání QA do seznamu CC
Většinou se nepoužívá, ale pokud si myslíte, že může být užitečné, přidat sebe nebo jiného člena QA do seznamu, neváhejte to udělat. Pokud do seznamu přidáváte někoho jiného, nezapomeňte přidat komentář, jinak by mohli být podrážděni tím, že nevědí, co se děje.

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

Zvláštní poznámky ke třídění pro tým QA
Zde jsou některé poznámky pro pokročilé Triagers v QA/Team. Pokud jste nový, nedělejte si s tím starosti!

Hlášení chyb, které je obtížné třídit nebo uzavřít
Někdy pro reprodukci chyby potřebujeme speciální software nebo hardware, nebo čelíme jiným problémům, které nám brání ve vyšetřování. Pro tyto případy máme: Tento soubor používá rozšíření MediaWiki Bugzilla, které stahuje data z meta zpráv a různých dalších dotazů.
 * soubor UNCONFIRMED chyb, se kterými mají členové týmu QA potíže.

Rozšíření
Nejlepší je zapojit tvůrce rozšíření do třídění. Odpovědnost za kontaktování tvůrce má reportér chyb.

Čtěte také:
 * QA/BugReport/Extensions

Kontroverze týkající se národního prostředí
Někdy se potýkáme s horkými tématy souvisejícími s místním nastavením. Může nastat situace, kdy se národní standard pro něco liší od skutečné praxe. V těchto případech může být užitečné nasměrovat reportéra problému do Unicode Common Locale Data Repository a jejich průzkumový nástroj.

Navrhovaný způsob třídění
Níže uvedené tabulky představují navržený způsob třídění. Cílem QA je nejprve potvrdit nejhorší chyby.