Menu

Umění hlášení chyb: Jak uvádět na trh a opravit chyby?

art bug reporting

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Proč je potřeba Marketing a Bug?

První věci, které mi při psaní tohoto článku napadnou, jsou slova Cem Kaner - 'Nejlepší tester není ten, kdo najde nejvíce chyb nebo který zahanbí většinu programátorů.' Nejlepší tester je ten, kdo opraví většinu chyb. “

Nyní - jaký je rozdíl mezi nimi najít většinu chyb a oprava většiny chyb ?

Není zřejmé, že se přihlásila nějaká chyba? systém pro správu chyb by měl opravit vývojář? Odpověď zní ne. Faktory jako čas na uvedení produktu na trh, čas na dokončení projektu podle plánu a vývojáři, kteří pracují nepraktické napjaté plány atd. nutí společnosti vydat produkt s několika chybami, které nebudou mít na uživatele velký vliv.

Hlášení chyb čl

(obraz zdroj )

Kdo dává důvěru vedení s tím, že chyby přítomné v produktu nebudou mít vliv na důvěru zákazníka, spolehlivost a zájem zúčastněných stran? - Zkušební inženýr nebo zkušební tým - je povinností každého zkušebního technika opravit chyby, které by mohly mít negativní dopad na kvalitu produktu.

Priorita chyby podle mého názoru do značné míry závisí na tom, jak tester předloží problém vývojovým a řídícím týmům.

Přemýšlejte o tom jako o reklamě nebo marketingu problému - to zahrnuje 2 kroky:

  1. Napište nebo hlásit chyby správně
  2. Vědět vše o chybě, takže jakékoli další podrobnosti lze lépe vysvětlit

Co se naučíte:

Umění hlášení chyb

Ano, hlášení chyb je umění . Způsob, jakým je chyba zapsána, ukazuje technické dovednosti, odborné znalosti domény a komunikační schopnosti testovacího inženýra.

Chyba by obvykle měla obsahovat následující informace:

  • Souhrn chyb
  • Kroky k reprodukci
  • Přílohy (snímek, soubory protokolu atd.)
  • Reprodukovatelnost chyb
  • Závažnost chyby
  • Verze softwaru, informace o prostředí
  • Další informace na základě organizačních požadavků.

Důležitá poznámka: Vždy se podívejte hlouběji, abyste našli hlavní příčinu problému a nahlásili jej. Například jednoduché selhání přihlášení se správnou kombinací uživatelského jména a hesla může souviset s různými důvody, například:

  1. Přihlašovací údaje nejsou vůbec ověřeny
  2. Problémy s časovým limitem sítě v případě vzdáleného přihlášení
  3. Systém může považovat všechny CAPS za ne-CAPS.

Jako tester byste tedy měli být schopni rozluštit rozdíly při sledování souhrnných hlášení o chybě:

  • „Nelze se přihlásit pomocí správného uživatelského jména a hesla“
  • 'Nelze se přihlásit pomocí správného uživatelského jména a hesla, pokud uživatelské jméno nebo heslo obsahuje kombinaci CAPS a non-CAPS abeced.'

Ten je velmi jasným popisem problému a je jednoznačný. Tímto způsobem nejen zvýšíte svoji důvěryhodnost jako testera, ale místo příznaku hlásíte také skutečný problém.

Pojďme se nyní podívat na každé pole zapojené do hlášení o chybě a probrat důležité aspekty každého z nich:

# 1. Souhrn chyb

Souhrn chyb by měl poskytnout rychlý snímek toho, o co přesně jde. Musí to být přesné a dobře nasměrované.

Příklad :

Kromě teorie se pokusím vysvětlit na příkladech.

Předpokládejme jednoduchý přihlašovací modul. Předpokládejme problém, protože nový uživatel, který navštíví web, se nemůže přihlásit pomocí svého výchozího hesla. Když jsem představil stejný scénář mnoha studentům, které jsem trénoval během počáteční fáze školení, bylo několik odpovědí jako souhrn chyb. Níže uvádíme několik ukázek toho, jak souhrn vypadal:

software, který je nainstalován v počítači a slouží ke správě virtuálních strojů

' Nový uživatel se nemůže přihlásit “

„Přihlášení uživatele nefunguje podle očekávání“

„Uživatel se nemůže přihlásit pomocí správného hesla“

shrnutí chyby nesprávné a správné

Z výše uvedených vzorků můžete vybrat jedno prohlášení, které skutečně popisuje problém? Nemyslím si to. Souhrn by měl vždy poskytovat úplné informace o scénáři selhání.

Zvažte následující prohlášení:

„Nový uživatel se nemůže přihlásit pomocí výchozího hesla zadaného prostřednictvím e-mailu nebo SMS.“

Jak vidíte, z výše uvedeného prohlášení může vývojář jasně pochopit, o jaký problém jde a kde je problém.

Pokuste se tedy najít správná slova k popisu souhrnu, který by poskytoval informace přímo. Je třeba se vyhnout obecným tvrzením jako „nefunguje správně“, „nefunguje podle očekávání“ atd.

# 2. Kroky pro reprodukci a přílohy

Neprodukovatelné chyby se vždy dostanou na zadní sedadlo, i když mohou být významné. Proto buďte opatrní, abyste postupovali správně a popisně.

Kroky by měly být přesné a přesně stejné jako kroky, které vedly k problému. Pro chyby související s funkčností je nejlepším příkladem následující ukázka.

Příklad :

Zvažte stejný problém uvedený v předchozí části.

  1. Vytvořte nového uživatele pomocí možnosti Přihlásit se na domovské stránce. (Ukázkové uživatelské jméno: HelloUser)
  2. E-mail a SMS budou přijaty s výchozím heslem. E-mailové ID a číslo mobilního telefonu pro SMS jsou poskytovány při vytváření uživatele v kroku č. 1. (Ukázkový e-mail: HelloUser@hello.com , Ukázkové číslo mobilního telefonu: 444-222-1123)
  3. Na domovské stránce vyberte možnost Přihlášení.
  4. Do textového pole uživatelské jméno zadejte Sample Username poskytnuté v kroku č. 1.
  5. Do pole pro heslo zadejte výchozí heslo přijaté prostřednictvím e-mailu nebo SMS.
  6. Klikněte na tlačítko Přihlásit se
  7. Očekávaný výsledek: Uživatel by měl být schopen se přihlásit pomocí zadaného uživatelského jména a hesla a přejít na stránku uživatelského účtu.
  8. Skutečný výsledek: Zobrazí se zpráva „Neplatné uživatelské jméno / heslo“.

kroky hlášení závad

Pokud některá z informací není poskytnuta ve výše uvedeném vzorku, pak bude mít za následek mezery v komunikaci a vývojář nebude schopen problém reprodukovat. Kroky musí být konkrétní a podrobné s ukázkovými daty, která používáte během testování.

Pokud je to možné nebo kdekoli je to možné, uveďte a momentka toho, co přesně vidíte na obrazovce. Tímto způsobem vývojářům poskytne nejen dobrý přehled o problému, ale také důkaz o výsledku vašeho testu.

The nefunkční testovací případy, jako jsou testovací případy stresu, stability nebo výkonu, kromě výše uvedených podrobností, lze ohlásit informace o scénáři, který způsobí stres systému, tak jak je. Kromě toho existuje několik systémů, které hlásí protokoly o každé provedené operaci. Protokoly jsou obvykle tiskové příkazy poskytované vývojáři v jejich kódu. Kdykoli je modul spuštěn, budou vytištěny nebo zobrazeny odpovídající protokoly. Pokud jsou k dispozici protokoly, pomohlo by to vývojářům do značné míry při reprodukci problému.

# 3. Reprodukovatelnost chyb

Problém, který je velký nebo malý, bude mít prioritu na základě reprodukovatelnosti. Je vidět vždy, někdy, zřídka nebo dokonce jen jednou. Problém, který je reprodukován jako „vždy“, bude mít vyšší prioritu než ostatní.

nelze reprodukovat vadu

Je tedy povinností testovacího inženýra přesně sledovat scénář problému, který je vždy reprodukován. Někdy může být několik problémů mimo kontrolu zkušebního technika, které by vedly k tomu, že by se problém reprodukoval jen několikrát, ale v několika pokusech. V takových případech vždy uveďte počet pokusů, konkrétní scénář se provede spolu s počtem případů, kdy je problém během těchto pokusů viděn.

To by zase dodalo důvěryhodnost vámi zmíněné zprávě o chybě. To by opět zlepšilo vaši reputaci testera. Později vám řeknu důvody pro dobrou pověst.

# 4. Závažnost chyby

Závažnost je bezpochyby jedním z největších ovlivňovatelů upřednostňování Bugů.

Následují různé kategorie závažnosti. Vezměte prosím na vědomí, že se jedná pouze o obecné vzorky, které se u jednotlivých společností liší.

  1. Závažnost 1 - Zobrazit zarážku - pro chyby, které jsou katastrofické, bez opravení nebude uživatel moci pokračovat v používání softwaru a neexistuje žádné možné řešení
  2. Závažnost 2 - vysoká - pro chyby podobné závažnosti 1, ale existuje řešení
  3. Závažnost 3 - střední
  4. Závažnost 4 - nízká
  5. Závažnost 5 - triviální.

Porovnejme například dva podobné problémy.

V našich set-top boxech poskytuje několik poskytovatelů služeb informace o frekvenci služby tak, jak jsou aktuálně naladěny. Předpokládejme, že frekvence je zobrazena jako 100 MHz místo 100,20 MHz. To nemusí mít vliv na prohlížení služeb uživatelem, ale může to mít dopad na monitorování diagnostiky set-topů. Proto to může být prezentováno jako problém závažnosti 3.

Za předpokladu podobného problému v bankovní doméně: Pokud je zůstatek vašeho účtu zobrazen na 100 $, místo 100,20 $, představte si dopad problému. To musí být závada Závažnosti -1. Jak vidíte v obou případech je problém velmi podobný tomu, že uživatelské rozhraní nezobrazuje číslice za desetinnou čárkou. Dopad se však liší podle příslušné domény.

Efektivní účast na schůzkách o kontrole verze softwaru

Každá organizace má obvykle svůj vlastní proces, který má chyby zkoumat a určovat jejich priority. Obecně by ke schůzce došlo v konkrétních intervalech během projektu, aby se diskutovalo o chybách a stanovila jejich priorita.

Proces během těchto schůzek je následující:

  1. Dotaz na seznam chyb ze systému správy chyb podle závažnosti.
  2. Podívejte se na shrnutí a diskutujte o dopadu chyby na uživatelskou zkušenost s používáním softwarového produktu.
  3. Na základě posouzení rizik a dopadů stanovte prioritu a přiřaďte chybu příslušnému vývojáři pro jejich opravu.

Během kroku 2 je bezpodmínečně nutné, aby každý zkušební technik prosazoval dopad chyby na uživatelskou zkušenost, pokud chyba nezíská prioritu, kterou si zaslouží. Koneckonců jsme to my testovací inženýři, kteří berou v úvahu pohled uživatele na psaní testovacích případů a testování produktu.

Zvažte výše uvedený příklad problému nezobrazování číslic za desetinnou čárkou v bankovní doméně. Pro vývojáře se to může zdát jako méně závažný problém. Mohl by namítnout, že místo deklarace proměnné jako celého čísla by to deklaroval jako pohyblivou řádovou čárku k vyřešení problému, a tedy méně závažnou.

Ale jako tester vaše role vysvětluje situaci zákazníka. Vaše myšlenka by měla být v tom, jak by si uživatel v tomto scénáři stěžoval. Tester by měl říci, že to způsobí mezi uživateli paniku, protože zákazník přijde o své peníze v centech.

Dopad nesprávného uvedení chyby na trh

Pokud chyba není správně uvedena na trh, vytvoří problémy jako:

  • Nesprávná priorita defektu
  • Zpoždění při řešení důležitých otázek
  • Uvolnění produktu se závažnými vadami
  • Negativní zpětná vazba od zákazníků
  • Devalvace hodnoty značky

Dopad nesprávného uvedení chyby na trh

Kromě všech výše zmíněných důvodů je velmi důležité vybudovat si svůj pověst testovacího inženýra . Je to spíš jako rozvíjení hodnoty značky pro své vlastní já.

Pokud si v počáteční fázi své kariéry můžete ponechat svůj počet „Cannot Reproduce“ nebo „Need More Info“ nebo „Not a Valid Bug“ nebo změny v závažnosti na co nejnižší úrovni, v jedné fázi nebudou vaše chyby podrobně zkoumány vůbec a byly by přímo přiřazeny k příslušnému vývojáři, který má být opraven.

Chcete-li rozvíjet takovou hodnotu značky a získat důvěru svého týmu a vývojových nebo manažerských týmů, musíte si osvojit některé technické dovednosti, pokud jde o testování znalostí, domén a komunikačních dovedností.

Závěr

Jakýkoli produkt nebo služba, ať už velká nebo malá, musí vždy selhat bez řádné reklamy. Jakmile je značka zavedena, jakýkoli malý produkt může být u publika super hitem.

To znamená, že nadměrná reklama na produkt může také poškodit pověst.

Takže chyba by měla být vždy napsána jasným, stručným a přesným způsobem, aby poskytovala přesné umístění chyby v rozsáhlé / vyčerpávající softwarové mapě. Opakuji, že to nejen zlepšuje kvalitu softwaru, ale také do značné míry snižuje náklady na testování a vývoj softwaru.

Teď není pozdě! Pojďme a hned opravme chyby!

jak otevřít binární soubor

Doporučené čtení

^