QA/BugTriage

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


    Ú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
      • libreoffice-qa@lists.freedesktop.org
      • libreoffice@lists.freedesktop.org
    2. IRC kanály na Libera Chat
    3. Č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í.
    4. * 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. Nastavte status chyby
    6. Nastavte prioritu chyby
    7. Pokuste se o reprodukci chyby
    8. Nastavte stav chyby
    9. Stanovte prioritu chyby
    10. Upozorněte vývojáře - je potřeba pouze ve velmi specifických případech, pokud se chyba jeví jako blokátor/kritická.

    'Podrobnosti kroků'

    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:

    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

    1. Přidejte klíčové slovo 'needsUXEval'
    2. Přidejte toto do seznamu CC: libreoffice-ux-advise@lists.freedesktop.org
    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:

      Tým UX - podívejte se prosím na toto vylepšení. Dík!

    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
    3. Kroky pro reprodukování problému - pokud to není zřejmé ze shrnutí a / nebo popisu
    4. 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
    5. Pokud hlášení odkazuje na externí data (snímky obrazovky, dokumenty, screencasty atd.), zkopírujte je a připojte k chybě, aby později nezmizely a nezpůsobily její neopravitelnost.

    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.
    soubor PDF
    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.

    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.

    Další užitečné (volitelné) kroky

    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í:

    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.

    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á nepatří do kategorie Most Annoying Bugs (nejotravnější chyby), měli byste vyhledat odborníka pro dodatečné posouzení. Prosím, používejte toto s rozmyslem, protože nechceme zaplavit naše odborné vývojáře drobnými chybami. 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.

    Testování interoperability

    Pokud je podmínkou testování otevření nebo uložení souboru pomocí Microsoft Office a nemáte přístup k tomuto softwaru, můžete použít Office Web Viewer. Pracuje s dokumenty Word, Excel, PowerPoint a ODF. Dokument je třeba někam nahrát a pak přidat adresu URL na konec tohoto odkazu:

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

    Poté můžete kliknout na tlačítko Tisk v horní nabídce a nakonec na Otevřít PDF, čímž získáte přístup k zobrazení dokumentu ve formátu PDF. To vám umožní jednak vidět, jak dokument vypadá v nejnovější verzi Microsoft Office, a také sdílet PDF v Bugzille.

    Odkazy na přílohy Bugzilla fungují s prohlížečem.

    Chcete-li pohodlně používat živý prohlížeč ve Firefoxu
    • Přidejte novou záložku
    • Nastavte nějaký Název
    • Nastavte URL na:
    https://view.officeapps.live.com/op/view.aspx?src=%s
    
    • Nastavte Klíčové slovo, například lv, stiskněte OK.
    • Nyní můžete použít klíčové slovo záložky a URL adresu přílohy v bugu v panelu URL a otevřít přílohu v prohlížeči Office Live:
    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ů.

    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é:

    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.

    Tabulka podle platformy (OS)

    Popis Všechny chyby Windows Linux macOS Komentář
    Hlášení o pádech aplikace CrasherAll CrasherWindows CrasherLinux CrashermacOS Jedná se o chyby, které mají v názvu chyby „havárie“ nebo podobné slovo. V případě havárií by závažnost měla být nastavena na Major/Critical v závislosti na tom, kolik uživatelů bude ovlivněno. Také QA by se měl podívat na to, zda je selhání regresí nebo ne, a přidat klíčové slovo „regrese“, pokud je chyba určena jako regrese.
    Potenciální regrese possibleRegressionAll possibleRegresionWindows possibleRegressionLinux possibleRegressionmacOS Pokud je chyba regrese, mělo by být klíčové slovo "possibleRegression" (možná regrese) odstraněno a do klíčových slov by mělo být přidáno slovo "regression" (regrese).
    Klíčové slovo Regression (regrese) RegressionAll RegressionWindows RegressionLinux RegressionmacOS Reportér chyby nebo někdo jiný uvedl regresi jako klíčové slovo. Stejně důležité jako výše uvedený řádek, ale Bugzilla neumožňuje vyhledávání "or" (nebo), takže se to muselo rozdělit do dvou řádků.
    Chyby hlášené jako Critical (kritické) CriticalAll CriticalWindows CriticalLinux CriticalmacOS Pouze uživatelé se speciálním oprávněním mohou nastavit status chyby na Critical. Critical (kritický) je vyhrazeno pro velmi závažné chyby (jako je ztráta dat, která ovlivní mnoho uživatelů). Pokyny viz PriorityFlowChart
    Chyby hlášené jako Major (velké) MajorAll MajorWindows MajorLinux MajormacOS Pouze uživatelé se speciálním oprávněním mohou nastavit status chyby na Major (velká). Stav Major je vyhrazen pro velmi závažné chyby (jako je ztráta dat), které však pravděpodobně neovlivní mnoho uživatelů nebo se děje pouze v některých případech s jednotlivými dokumenty. Pokyny viz PriorityFlowChart.
    Všechny chyby AllBugs AllWindows AllLinux AllmacOS Seznam všech hlášení o chybách (bez vylepšení). Pokud jsou výše uvedené chyby vyřešeny jako první, pak zbývající budou mít pro potvrzení o něco nižší prioritu. Navrhuje se potvrzovat je v chronologickém pořadí (nejstarší jako první, takže uživatelé, kteří ohlásili chybu nejdříve, dostanou prioritu).
    Žádosti o vylepšení EnhancementAll EnhancementWindows EnhancementLinux EnhancementmacOS Žádosti o vylepšení mají při potvrzení platnosti požadavku nejnižší prioritu.

    Tabulka podle komponenty

    Popis Writer Calc Impress Draw Base Ostatní Komentář
    Chyby hlášené jako pád systému WriterCrasher SpreadsheetCrasher PresentationCrasher DrawingCrasher DatabaseCrasher OtherCrashers 'Critical (Kritická)' závažnost je vyhrazena pouze pro nejzávažnější chyby (jako je nemožnost nainstalovat LibreOffice). Pokyny viz PriorityFlowChart
    Potenciální regrese WriterPosReg SpreadsheetPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg Pokud je chyba regrese, mělo by být klíčové slovo "possibleRegression" (možná regrese) odstraněno a do klíčových slov by mělo být přidáno slovo "regression" (regrese).
    Klíčové slovo Regression (regrese) WriterRegression SpreadsheetRegression PresentationRegression DrawingRegression DatabaseRegression OtherRegressions Reportér chyby nebo někdo jiný uvedl regresi jako klíčové slovo. Stejně důležité jako výše uvedený řádek, ale Bugzilla neumožňuje vyhledávání "or" (nebo), takže se to muselo rozdělit do dvou řádků.
    Chyby hlášené jako Critical (kritické) WriterCritical SpreadsheetCritical PresentationCritical DrawingCritical DatabaseCritical OtherCritical Pouze uživatelé se speciálním oprávněním mohou nastavit status chyby na Kritický. Critical (kritický) je vyhrazeno pro velmi závažné chyby (jako je ztráta dat, která ovlivní mnoho uživatelů). Pokyny viz PriorityFlowChart
    Chyby hlášené jako Major (velké) WriterMajor SpreadsheetMajor PresentationMajor DrawingMajor DatabaseMajor OtherMajor Pouze uživatelé se speciálním oprávněním mohou nastavit status chyby na Major (velká). Stav Major je vyhrazen pro velmi závažné chyby (jako je ztráta dat), které však pravděpodobně neovlivní mnoho uživatelů nebo se děje pouze v některých případech s jednotlivými dokumenty. Pokyny viz PriorityFlowChart.
    Všechny ostatní chyby WriterOther SpreadsheetOther PresentationOther DrawingOther DatabaseOther AllOther Toto jsou všechny chyby, které jsou označeny jakkoliv mimo Major (velké), ale nezahrnují Enhancements (vylepšení)
    Žádosti o vylepšení WriterEnhance SpreadsheetEnhance PresentationEnhance DrawingEnhance DatabaseEnhance OtherEnhance Žádosti o vylepšení