Menu

3 najhoršie zvyky pri hlásení defektov a ako ich zlomiť

3 worst defect reporting habits

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

Závady sú vážne záležitosti a malé chyby môžu byť drahé.

Keď zistíte poruchu, viete, čo máte robiť. Ty to nahlásiš; buď v a Tracker chýb / Nástroj na správu defektov alebo v hárku programu Excel. Základné princípy sú pre obe metódy rovnaké.

Nástroje na správu chýb nezaručujú lepšie nahlasovanie. Sú to osvedčené postupy, ktoré šetria deň.

Aby sme ocenili dobro, musíme si uvedomiť, čo nie.

Čo sa dozviete:

3 najhoršie zvyky pri hlásení defektov a ako ich zlomiť

najhoršie zvyky pri hlásení porúch

Tu ide:

# 1) Lenivosť

Nemáte čas na to, aby ste robili to najlepšie, čo môžete.

To je proces sledovania defektov nasledoval vo väčšine tímov:

(Poznámka- kliknite na ľubovoľný obrázok pre zväčšenie)

sledovanie defektov

Ako vidíte, testovací vodič skontroluje chyby skôr, ako ich pošle tímom QA.

Táto kontrola zahŕňa potvrdenie:

  • Platnosť - je to chyba?
  • Úplnosť - názov, kroky, údaje, snímka obrazovky atď.
  • Duplikáty
  • Reprodukovateľné alebo nie ... atď.

Z prvej ruky viem, že je nemožné, aby bola kontrola kvality stopercentná.

Takže, tento prístup: „Nahlásim problém tak, ako chcem. Vedenie QA sa môže opätovne skontrolovať. Môže rozhodnúť, či je chyba platná / úplná alebo nie “, to je koniec vášho tímu QA a vašej dôveryhodnosti.

Vedeli ste, že niektorí klienti majú SLA pre počet prijateľných neplatných chýb? Akonáhle počet prekročí, začnú penalizovať dodávateľov za každú nahlásenú neplatnú chybu?

Náprava: Urobte náležitú starostlivosť a buďte zodpovední za svoje výsledky. Porucha sa vrátila pre nedostatok informácií alebo to, že nejde o chybu? Nemusí to byť vždy chyba vývojového tímu. Nie je to tak, že by nechceli vlastniť problémy v aplikácii. Môže to byť nefalšovaný tím QA. Nedovoľte, aby sa to stalo.

# 2) Rúti sa

Urobme to pomocoupríklad.

Nižšie je uvedený snímok obrazovky OpenEMR obrazovka vytvorenia pacienta. Je to otvorený systém riadenia nemocníc.

Táto obrazovka umožňuje používateľovi zadať dátum narodenia pacienta pomocou funkcie kalendára. Nerobí to iba obmedzenie záznamu na výber z kalendára. Mám na mysli to, že z kalendára si môžete zvoliť DOB, napríklad „31. marca 1983“. Neskôr to zmeňte na „31. februára 1983“.

funkcia open-emr-calendar

hádanie chyby open-emr

Prečo 31. február? Vykonávať chyba pri hádaní a skúste negatívne údaje v teréne; čo je podstatou testovania, nie?

Po dokončení kliknem na tlačidlo „Vytvoriť pacienta“. Pretože je dátum neplatný, myslím, že systém zobrazí chybu a nevytvorí pacienta. Ale to sa nedeje. Vytvára pacienta ako je uvedené nižšie.

Na nasledujúcej obrazovke si všimnite polia Vek a Dátum narodenia:

openemr-test-tester

Pri testovaní to môžete vyskúšať niekoľkokrát a rozhodnúť sa, že:

  • Je to chyba.
  • Je reprodukovateľný.
  • Nejde o duplikát (overte si to u svojho tímu)
  • Poznáte presný popis problému
  • Tiež poznáte presné kroky, ktoré to umožňujú.

Teraz, keď máte surovinu, môžete vyraziť.

Začnete to hlásiť. Priradenie závažnosti chyby je povinný krok a váš tím pravdepodobne používa niečo podobné nasledujúca tabuľka pre referenciu:

Závažnosť Dopad
1 (kritická) • Táto chyba je dosť dôležitá na to, aby zlyhala systém, spôsobila poškodenie súborov alebo potenciálnu stratu údajov
• Spôsobuje abnormálny návrat do operačného systému (zlyhanie alebo správa o zlyhaní systému).
• Spôsobuje zablokovanie aplikácie a vyžaduje reštartovanie systému.
2 (vysoká) • Spôsobuje to nedostatok životne dôležitých funkcií programu.
3 (stredná) • Táto chyba zníži kvalitu systému. Existuje však inteligentné riešenie na dosiahnutie požadovanej funkčnosti - napríklad prostredníctvom inej obrazovky.
• Táto chyba zabraňuje testovaniu iných oblastí produktu. Môžu sa však nezávisle testovať aj iné oblasti.
4 (nízka) • Vyskytuje sa nedostatočné alebo nejasné chybové hlásenie, ktoré má minimálny vplyv na použitie produktu.
5 (kozmetické) • Vyskytuje sa nedostatočné alebo nejasné chybové hlásenie, ktoré nemá žiadny vplyv na použitie produktu.

Pretože táto chyba nespôsobuje zlyhanie systému alebo neblokuje dôležitú funkčnosť alebo nebráni v testovaní ďalších oblastí aplikácie, môžeme použiť hodnotu „Nízka“.

Vyzerá dobre?

NESPRÁVNE. Z údajov o pacientovi sú všetky očkovania a ďalšie pripomienky oneskorené. To môže, ale nemusí byť správne. U pacienta tiež závisí od ich veku, či navštívi pediatra alebo všeobecného lekára atď.

Ovplyvňuje dávky liekov a mnohých ďalších oblastí liečby, o ktorých by sme možno ani nevedeli.

otvoriť-emr-klinicky-pripomenutie

Takže idem s „Vysokým“. Súhlasím, že je nepravdepodobné, že by personál nemocnice vstúpil do DOB ​​chyby pacienta. Nech je to však faktor, ktorý ovplyvňuje prioritu, kedy problém vyriešiť.

Mojou úlohou ako testera je zabezpečiť, aby som čo najlepšie informoval o závažnosti problému.

Náprava: Neponáhľajte sa s hlásením. Buďte si stopercentne istí, že chápete dopad problémov z mnohých uhlov pohľadu. Je to najlepšia pridaná hodnota, akú môžu testéri poskytnúť. Nehovoríme iba: „Niečo nefunguje“. Hovoríme tiež: „Tu sa stane, čo sa stane, ak to naďalej nebude fungovať.“ Tuny rozdielu, nie?

# 3) Nedostatok tvorivosti

Testéri majú skvelú príležitosť navrhnúť vylepšenia softvéru.

Vo vašom Nástroj na správu defektov tiež môžete odoslať chybu typu „Návrh vylepšenia“. Tu môžete byť kreatívni.

Náprava: Mysli mimo krabicu. Ak si myslíte, že niektorej funkcii chýba faktor „Páni“ a viete, ako ju do nej začleniť, predložte nápad. Prinajhoršom by to mohlo byť odmietnuté a to je v poriadku. Dôležitá časť sa snaží.

Túto super výkon používajte tiež opatrne. Snažte sa nepridávať komentáre typu „Neznášam farbu bannera, zmeňte ju.“

Tu je dobrápríkladnávrhu vylepšenia, na ktorý som narazil: Nahradenie možnosti „Poslať e-mailom predajcovi“ na možnosť „Chatovať s predajcom“ na stránke s predajcami automobilov. Očakáva sa, že prevedie väčšiu prevádzku na tržby.

Bodaj by som bol taký kreatívny! Ale možno sa k tomu všetci môžeme dopracovať.

Tu je bonus. Kontrolný zoznam na oslobodenie od týchto zlých návykov:

1. Vysvetľuje môj názov problém jasne a výstižne?
Napríklad:„Vytvorenie pacienta nefunguje“ nie je dobrý názov. „Vytvoriť pacienta zlyhá, aj keď všetky vstupné polia obsahujú správne hodnoty“ je.

dva. Aká je miera reprodukovateľnosti?
Inými slovami, stáva sa to vždy? Viem presnú postupnosť krokov, pri ktorých sa problém zopakuje?

3. Je táto problémová platforma, prehliadač alebo používateľ špecifický?

Štyri. Sú kroky dokončené a dostanete sa k svojmu problému?

5 . Mám zahrnutý aj screenshot?

6. Musím anotovať svoju snímku obrazovky, aby som zvýraznil niektoré konkrétne oblasti?

7. Je názov priloženého obrázkového súboru popisný?
Nepoužívajte niečo ako „Untitled.jpg“. Dajte jej popisný názov.

8. Zahrnul som údaje z testu?
Napríklad:V prípade poruchy modulu správcu, ktorá vyžaduje autorizačné poverenia, zahrňte ich. Vývojový tím môže, ale nemusí mať prístup do prostredia QA. Nechcete meškanie a nadviazanie na niečo také základné.

9. Môžem uviesť ďalšie podrobnosti, ktoré by posilnili môj nedostatok?
(Príklad:odkaz na FRD alebo rozhovor s klientom atď.)

10. Rozumiem, aký závažný je problém z rôznych uhlov pohľadu?

jedenásť. Viem hlavnú príčinu problému? Ak áno, mám dôkazy (možno protokolové súbory) a môžem ich zahrnúť? Upozorňujeme, že to nemusíte vždy vedieť alebo potrebujete vedieť. Ak to však urobíte, nezaškodí to zahrnúť.

12. Je správa o chybe bez problémov s gramatikou, formátom, pravopisom a interpunkciou?

ako používať thread.sleep v jave

13. Viem o spôsobe vylepšenia produktu?

Myslíte si, že je to časovo náročné? Akonáhle sa to stane zvykom, už to nebude.

Zakorenenie k lepšiemu hlásenie závady rutiny!

O autorovi: Tento článok je napísaný členom STH tímu Swati.

Neváhajte a pošlite svoje dotazy alebo komentáre nižšie.

Odporúčané čítanie

^