QA/BugTriage

From The Document Foundation Wiki
< QA
Jump to: navigation, search
This page is a translated version of the page QA/BugTriage and the translation is 100% complete.

Other languages:
čeština • ‎Deutsch • ‎English • ‎français • ‎Nederlands • ‎português do Brasil • ‎русский • ‎Türkçe • ‎中文(简体)‎


Ú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 Freenode
  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. 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á.

'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

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

Nejnepříjemnější chyby

Opravdu kritické chyby by měly být označeny jako [[QA/Most Annoying Bugs |MostAnnoyingBugs ( MAB s)] ]. Prosím, zvažte zde nutnost, protože seznam je nutno udržovat na rozumné úrovni.

Hard Hacks

Pokud se chyba jeví jako zvlášť těžká, ovlivňuje značné množství uživatelů a byla by považována za MAB, je tato chyba kandidátem na hard hack. Jejich seznam najdete zde:

HardHacks wiki

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 Tyto chyby jsou označeny jako possibleRegression (možnáRegrese), což je automatický stav daný v BSA, pokud uživatel, který chybu hlásil, řekl, že v konkrétní verzi nebyla chyba přítomna. 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 Uživatelé mohou v současné době nastavit závažnost svých vlastních chyb, pokud je chyba nesprávně označena jako kritická, změňte závažnost a vysvětlete uživateli, proč chyba není kritická. 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 Uživatelé mohou v současné době nastavit závažnost svých vlastních chyb, pokud je chyba nesprávně označena jako Major (velká), změňte závažnost a vysvětlete uživateli, proč chyba není chybou Major (velkou). 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 Pokud je chyba nesprávně označena jako critical (kritická), změňte závažnost a vysvětlete, proč chyba není kritická. 'Critical' (kritická) závažnost je vyhrazena pouze pro nejzávažnější chyby (například nemožnost nainstalovat LibreOffice). Pokyny viz PriorityFlowChart
Potenciální regrese WriterPosReg SpreadsheetPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg Tyto chyby jsou označeny jako possibleRegression (možnáRegrese), což je automatický stav daný v BSA, pokud uživatel, který chybu hlásil, řekl, že v konkrétní verzi nebyla chyba přítomna. 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 Uživatelé mohou v současné době nastavit závažnost svých vlastních chyb, pokud je chyba nesprávně označena jako kritická, změňte závažnost a vysvětlete uživateli, proč chyba není 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 Uživatelé mohou v současné době nastavit závažnost svých vlastních chyb, pokud je chyba nesprávně označena jako Major (velká), změňte závažnost a vysvětlete uživateli, proč chyba není chybou Major (velkou). 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í