Menu

Umenie hlásenia chýb: Ako uvádzať na trh a opraviť chyby?

art bug reporting

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Prečo je potreba Marketing a Bug?

Prvé, čo mi napadnú, keď začnem písať tento článok, sú slová Cem Kaner - „Najlepším testerom nie je ten, kto nájde najviac chýb alebo ktorý trápi väčšinu programátorov. Najlepší tester je ten, kto opraví väčšinu chýb. “

Teraz - Aký je rozdiel medzi nájdenie väčšiny chýb a opravuje sa väčšina chýb ?

Nie je zrejmé, že bola prihlásená nejaká chyba a systém správy chýb by mal opraviť vývojár? Odpoveď je č. Faktory ako čas na uvedenie produktu na trh, čas na dokončenie projektu podľa plánu a vývojári, ktorí pracujú nepraktické tesné harmonogramy atď. nútia spoločnosti vydávať produkt s niekoľkými chybami, ktoré nebudú mať na používateľov veľký vplyv.

Hlásenie chýb čl

(obrázok zdroj )

Kto dáva dôveru manažmentu a tvrdí, že chyby prítomné v produkte nebudú mať vplyv na dôveru, spoľahlivosť a záujem zainteresovaných strán? - Testovací inžinier alebo testovací tím - je povinnosťou každého testovacieho inžiniera opravovať chyby, ktoré by mohli mať negatívny vplyv na kvalitu produktu.

Priorita chyby , podľa môjho názoru do veľkej miery závisí od toho, ako tester predloží problém vývojovým a riadiacim tímom.

Myslite na to ako na reklamu alebo marketing problému - to zahŕňa 2 kroky:

  1. Napíš príp nahlásiť chyby správne
  2. Vedzte všetko o chybe, aby bolo možné lepšie vysvetliť všetky ďalšie podrobnosti

Čo sa dozviete:

Umenie hlásenia chýb

Áno, hlásenie chýb je umenie . Spôsob, akým je chyba napísaná, ukazuje technické zručnosti, odborné znalosti domény a komunikačné schopnosti testovacieho inžiniera.

Chyba by zvyčajne mala obsahovať nasledujúce informácie:

  • Zhrnutie chyby
  • Kroky na reprodukciu
  • Prílohy (snímka, súbory denníka atď.)
  • Reprodukovateľnosť chýb
  • Závažnosť chyby
  • Verzia softvéru, informácie o prostredí
  • Ďalšie informácie na základe organizačných požiadaviek.

Dôležitá poznámka: Siahajte vždy hlbšie, nájdite hlavnú príčinu problému a nahláste to. Napríklad jednoduché zlyhanie prihlásenia so správnou kombináciou používateľského mena a hesla môže súvisieť s rôznymi dôvodmi, ako napríklad:

  1. Prihlasovacie údaje nie sú vôbec overené
  2. Problémy s časovým limitom siete v prípade vzdialeného prihlásenia
  3. Systém môže považovať všetky CAPS za iné ako CAPS.

Ako tester by ste teda mali byť schopní dešifrovať rozdiely a zároveň postupovať podľa súhrnných vyhlásení o chybe:

  • „Nemôžem sa prihlásiť pomocou správneho používateľského mena a hesla“
  • 'Nemožno sa prihlásiť so správnym používateľským menom a heslom, ak používateľské meno alebo heslo obsahuje kombináciu písmen CAPS a non-CAPS.'

Posledný uvedený je veľmi jasným popisom problému a je jednoznačný. Týmto nielen zvýšite svoju dôveryhodnosť testera, ale namiesto príznaku nahlásite aj skutočný problém.

Poďme sa teraz pozrieť na každé pole zapojené do hlásenia o chybe a prediskutovať dôležité aspekty každého z nich:

# 1. Zhrnutie chyby

Zhrnutie chyby by malo poskytnúť rýchly prehľad toho, o čo konkrétne ide. Musí to byť presné a dobre nasmerované.

Príklad :

Okrem teórie sa to pokúsim vysvetliť na príkladoch.

Predpokladajme jednoduchý prihlasovací modul. Predpokladajme problém, pretože nový používateľ, ktorý navštívi web, sa nemôže prihlásiť pomocou svojho predvoleného hesla. Keď som predstavil rovnaký scenár mnohým študentom, ktorých som trénoval počas úvodnej fázy tréningu, bolo tu niekoľko odpovedí ako súhrn chýb. Ďalej uvádzame niekoľko príkladov toho, ako vyzeralo zhrnutie:

testovacie prípady v príkladoch testovania softvéru

„ Nový používateľ sa nemôže prihlásiť ”

„Prihlásenie používateľa nefunguje podľa očakávaní“

„Používateľ sa nemôže prihlásiť so správnym heslom“

súhrn chýb nesprávny a správny

Z vyššie uvedených vzoriek môžete vybrať jedno vyhlásenie, ktoré skutočne popisuje problém? Ja si nemyslím. Súhrn by mal vždy obsahovať úplné informácie o zlyhávajúcom scenári.

Zvážte nasledujúce vyhlásenie:

„Nový používateľ sa nemôže prihlásiť pomocou predvoleného hesla poskytnutého prostredníctvom e-mailu alebo SMS.“

Ako vidíte, z vyššie uvedeného vyhlásenia môže vývojár jasne pochopiť, o aký problém ide a kde sa nachádza.

Skúste teda nájsť správne slová na opísanie súhrnu, ktorý by poskytol informácie priamo. Musíte sa vyhnúť všeobecným vyhláseniam ako „nefunguje správne“, „nefunguje podľa očakávania“ atď.

# 2. Kroky na reprodukciu a prílohy

Neopakovateľné chyby sa vždy dostanú na zadné sedadlo, aj keď môžu byť významné. Preto buďte opatrní, aby ste kroky napísali správne a popisne.

Kroky by mali byť presné a úplne rovnaké ako kroky, ktoré viedli k problému. Pokiaľ ide o chyby súvisiace s funkčnosťou, najlepším príkladom je nasledujúca ukážka.

Príklad :

Zvážte to isté, čo je uvedené v predchádzajúcej časti.

  1. Vytvorte nového používateľa pomocou možnosti Prihlásiť sa na domovskej stránke. (Vzorové používateľské meno: HelloUser)
  2. E-mail a SMS budú prijaté s predvoleným heslom. E-mailová adresa a číslo mobilného telefónu pre SMS sa poskytujú pri vytváraní používateľa v kroku č. 1. (Vzorový e-mail: HelloUser@hello.com , Vzorové číslo mobilného telefónu: 444-222-1123)
  3. Na domovskej stránke vyberte možnosť Prihlásiť sa.
  4. Do textového poľa používateľské meno zadajte vzorové používateľské meno uvedené v kroku č. 1.
  5. Do poľa pre heslo zadajte predvolené heslo prijaté prostredníctvom e-mailu alebo SMS.
  6. Kliknite na tlačidlo Prihlásiť sa
  7. Ocakavane vysledky: Používateľ by mal byť schopný prihlásiť sa pomocou poskytnutého používateľského mena a hesla a prejsť na stránku používateľského účtu.
  8. Skutočný výsledok: Zobrazí sa správa „Neplatné užívateľské meno / heslo“.

kroky hlásenia poruchy

Ak niektorá z informácií nie je uvedená vo vyššie uvedenej vzorke, potom bude mať za následok komunikačné medzery a vývojár nebude môcť problém reprodukovať. Kroky musia byť konkrétne a podrobné so vzorovými údajmi, ktoré používate počas testovania.

Ak je to možné alebo kdekoľvek je to vhodné, poskytnite a momentka toho, čo presne vidíte na obrazovke. Týmto spôsobom vývojárom poskytne nielen dobrý prehľad o probléme, ale aj dôkaz o výsledku vašej skúšky.

The nefunkčné okrem vyššie uvedených podrobností možno uviesť aj testovacie prípady, ako sú napríklad testy stresu, stability alebo výkonu, možno hlásiť informácie o scenári, ktorý spôsobuje stres v systéme, tak ako sú. Ďalej existuje len málo systémov, ktoré hlásia protokoly o každej vykonanej operácii. Denníky sú zvyčajne tlačené vyhlásenia poskytované vývojármi v ich kóde. Kedykoľvek je modul vykonaný, príslušné protokoly sa vytlačia alebo zobrazia. Keď budú k dispozícii protokoly, pomohlo by to vývojárom do veľkej miery pri reprodukcii problému.

# 3. Reprodukovateľnosť chýb

Veľký alebo malý problém bude mať prioritu na základe reprodukovateľnosti. Vidno to vždy, niekedy, zriedka alebo dokonca iba raz. Číslo, ktoré sa zobrazí ako „vždy“, bude mať vyššiu prioritu ako ostatné.

nedokáže reprodukovať chybu

Je teda povinnosťou testovacieho inžiniera presne sledovať scenár problému, ktorý sa vždy reprodukuje. Niekedy môže byť niekoľko problémov mimo kontroly skúšobného inžiniera, ktoré by viedli k tomu, že by sa problém reprodukoval iba niekoľkokrát, ale vo viacerých pokusoch. V takýchto prípadoch vždy uveďte počet pokusov, vykoná sa konkrétny scenár spolu s počtom prípadov, počas ktorých sa počas týchto pokusov problém vyskytol.

To by zase dodávalo dôveryhodnosť vami uvedenému hláseniu o chybe. To by opäť zlepšilo vašu reputáciu testera. Neskôr vám poviem dôvody dobrej reputácie.

# 4. Závažnosť chyby

Závažnosť je nepochybne jedným z najväčších ovplyvňujúcich faktorov pri určovaní priorít Bugu.

Nasledujú rôzne kategórie závažnosti. Upozorňujeme, že ide iba o všeobecné vzorky, ktoré sa u jednotlivých spoločností líšia.

  1. Závažnosť 1 - Zobraziť zarážku - pre chyby, ktoré sú katastrofické, bez opravenia nebude používateľ môcť pokračovať v používaní softvéru a neexistuje možné riešenie.
  2. Závažnosť 2 - vysoká - pre chyby podobné závažnosti 1, ale existuje riešenie
  3. Závažnosť 3 - stredná
  4. Závažnosť 4 - nízka
  5. Závažnosť 5 - triviálna.

Napríklad si porovnajme dva podobné problémy.

V našich set-top boxoch niekoľko poskytovateľov služieb poskytuje informácie o frekvencii služby tak, ako sú práve naladené. Predpokladajme, že frekvencia sa zobrazuje ako 100 MHz namiesto 100,20 MHz. To nemusí mať vplyv na prezeranie služieb používateľom, ale môže to mať vplyv na monitorovanie diagnostiky udalostí. Preto to možno považovať za problém závažnosti 3.

Za predpokladu podobného problému v bankovej oblasti: Ak sa zostatok na vašom účte zobrazuje ako 100 USD, namiesto 100,20 USD si predstavte dopad problému. Toto musí byť chyba Závažnosti -1. Ako môžete vidieť v obidvoch prípadoch, problém je veľmi podobný tomu, že používateľské rozhranie nezobrazuje číslice za desatinnou čiarkou. Dopad sa však líši podľa príslušnej domény.

Efektívna účasť na stretnutiach týkajúcich sa kontroly verzie softvéru

Každá organizácia má zvyčajne svoj vlastný proces na zisťovanie a určovanie priorít chýb. Spravidla by sa stretnutie malo konať v konkrétnych intervaloch počas projektu, aby sa prediskutovali chyby a stanovili sa rovnaké priority.

Proces týchto stretnutí je nasledovný:

  1. Dotazujte sa na zoznam chýb v systéme správy chýb podľa závažnosti.
  2. Prezrite si zhrnutie a prediskutujte dopad chyby na dojem používateľa z používania softvérového produktu.
  3. Na základe posúdenia rizika a vplyvu stanovte prioritu a priraďte chybu príslušnému vývojárovi, ktorý ju opraví.

V priebehu kroku 2 je nevyhnutné, aby každý testovací technik obhajoval vplyv chyby na dojem používateľa, ak chyba nezíska prioritu, ktorú si zaslúži. Nakoniec sme to my testovací inžinieri, ktorí uvažujú o hľadisku používateľa, aby napísal testovacie prípady a produkt otestoval.

Zvážte vyššie uvedený príklad problému so nezobrazením číslic za desatinnou čiarkou v bankovej doméne. Pre vývojárov sa to môže javiť ako menej závažný problém. Môže namietať, že namiesto toho, aby premennú deklaroval ako celé číslo, vyhlásil by ju ako plávajúcu desatinnú čiarku na vyriešenie problému, a teda menej závažnú.

Ale ako tester vaša úloha vysvetľuje situáciu zákazníka. Malo by ísť o to, ako by sa používateľ sťažoval v tomto scenári. Tester by mal povedať, že to spôsobí medzi používateľmi paniku, pretože zákazník príde o peniaze v centoch.

Dopad nesprávneho marketingu chyby

Ak chyba nie je správne uvedená na trh, spôsobí problémy ako:

  • Nesprávna priorita defektu
  • Oneskorenie pri riešení dôležitých otázok
  • Uvoľnenie produktu so závažnými chybami
  • Negatívna spätná väzba od zákazníkov
  • Devalvácia hodnoty značky

Dopad nesprávneho marketingu chyby

Okrem všetkých vyššie spomenutých dôvodov je veľmi dôležité zostaviť si svoj reputácia testovacieho inžiniera . Je to skôr ako rozvíjať hodnotu značky pre svoje vlastné ja.

Ak si v počiatočnej fáze svojej kariéry dokážete udržať počet „Cannot Reproduce“ alebo „Need More Info“ alebo „Not a Valid Bug“ alebo zmeny závažnosti na čo najnižšej úrovni, v jednej fáze nebudú vaše chyby podrobne preskúmané. vôbec a boli by priamo priradení k príslušnému vývojárovi, ktorý sa má opraviť.

Ak chcete rozvíjať takúto hodnotu značky a získať dôveru svojho tímu a vývojových alebo manažérskych tímov, musíte si osvojiť určité technické zručnosti, pokiaľ ide o testovanie vedomostí, oblasti a komunikačných schopností.

Záver

Akýkoľvek produkt alebo služba, či už veľká alebo malá, musí vždy zlyhať bez náležitej reklamy. Po založení značky môže byť akýkoľvek malý produkt u publika super hitom.

To znamená, že nadmerná reklama na výrobok môže tiež spôsobiť poškodenie dobrého mena.

Takže chyba by mala byť vždy napísaná jasným, výstižným a presným spôsobom, aby poskytovala presné umiestnenie chyby v rozsiahlej / vyčerpávajúcej softvérovej mape. Opakujem, že sa tým nielen zlepší kvalita softvéru, ale tiež sa to do veľkej miery zníži náklady na testovanie a vývoj softvéru.

Teraz nie je neskoro! Poďme do toho a okamžite opravme chyby!

nový svet súkromných serverov warcraft

Odporúčané čítanie

^