3 worst defect reporting habits
Vady jsou vážná věc a malé chyby mohou být drahé.
Víte, co dělat, když zjistíte závadu. Ty to nahlásíš; buď v Sledování defektů / Nástroj pro správu defektů nebo v listu aplikace Excel. Základní principy jsou pro obě metody stejné.
Nástroje pro správu vad nezaručují lepší hlášení. Osvědčené postupy šetří den.
Abychom ocenili dobro, musíme si uvědomit, co není.
Co se naučíte:
- 3 nejhorší návyky při hlášení vad a jak je rozbít
- # 1) Lenost
- # 2) Spěchá
- # 3) Nedostatek kreativity
- Doporučené čtení
3 nejhorší návyky při hlášení vad a jak je rozbít
Tady je:
# 1) Lenost
Nebudete si dělat čas, abyste udělali to nejlepší, co můžete.
To je proces sledování závad následoval ve většině týmů:
(Poznámka- pro zvětšení klikněte na libovolný obrázek)
Jak vidíte, testovací olovo zkontroluje vady, než je odešle z týmů QA.
Tato recenze zahrnuje potvrzení:
- Platnost - Je to chyba?
- Úplnost - název, kroky, data, snímek obrazovky atd.
- Duplikáty
- Reprodukovatelné nebo ne… atd.
Z první ruky vím, že je nemožné, aby vedení QA bylo 100% důkladné.
Postoj tedy: „Ohlásím problém tak, jak chci. Vedení QA může znovu zkontrolovat. Může se rozhodnout, zda je vada platná / úplná či nikoli “, to je konec vašeho týmu QA a vaší důvěryhodnosti.
Věděli jste, že někteří klienti mají SLA pro počet přijatelných neplatných vad? Jakmile počet překročí, začnou penalizovat dodavatele za každou nahlášenou neplatnou vadu?
Lék: Proveďte svou náležitou péči a buďte zodpovědní za své plnění. Porucha se vrátila pro nedostatek informací nebo to, že nejde o chybu? Možná to nemusí být vždy chyba vývojového týmu. Není to tak, že by nechtěli vlastnit problémy v aplikaci. Může to být nefalšovaný tým QA. Nedovolte, aby se to stalo.
# 2) Spěchá
Udělejme to spříklad.
Níže je snímek obrazovky OpenEMR vytvořit obrazovku pacienta. Jedná se o otevřený systém správy nemocnic.
Tato obrazovka umožňuje uživateli zadat datum narození pacienta pomocí funkce kalendáře. Nedělá to, že omezuje záznam na výběr z kalendáře. Chci tím říct, že si můžete z kalendáře vybrat DOB, řekněme „31. března 1983“. Později jej změňte na „31. února 1983“.
Proč 31. února? Provádět chyba hádání a zkuste negativní data v terénu; což je celý bod testování, že?
Po dokončení kliknu na „Vytvořit pacienta“. Jelikož je datum neplatné, očekávám, že systém zobrazí chybu a nevytvoří pacienta. Ale to se neděje. Vytváří pacienta, jak je uvedeno níže.
Na níže uvedené obrazovce si všimněte polí Věk a Datum narození:
Při testování to můžete několikrát vyzkoušet a rozhodnout se, že:
- Je to chyba.
- Je reprodukovatelný.
- Nejedná se o duplikát (ověřte u svého týmu)
- Znáte přesný popis problému
- Také znáte přesné kroky, díky nimž se to stane.
Nyní, když máte surovinu, můžete vyrazit.
Začnete to hlásit. Přiřazení závažnosti defektu je povinný krok a váš tým možná používá něco podobného následující tabulka pro referenci:
Vážnost | Dopad |
---|---|
1 (kritický) | • Tato chyba je dostatečně kritická na to, aby zhroutila systém, způsobila poškození souborů nebo potenciální ztrátu dat • Způsobuje abnormální návrat do operačního systému (dojde k chybě nebo se zobrazí zpráva o selhání systému). • Způsobí zablokování aplikace a vyžaduje restartování systému. |
2 (vysoká) | • Způsobuje to nedostatek životně důležitých funkcí programu. |
3 (střední) | • Tato chyba sníží kvalitu systému. Existuje však inteligentní řešení pro dosažení požadované funkce - například prostřednictvím jiné obrazovky. • Tato chyba brání testování dalších oblastí produktu. Jiné oblasti však mohou být nezávisle testovány. |
4 (nízká) | • Není k dispozici dostatečné nebo nejasné chybové hlášení, které má minimální dopad na použití produktu. |
5 (kosmetické) | • K dispozici je nedostatečná nebo nejasná chybová zpráva, která nemá žádný vliv na použití produktu. |
Jelikož tato vada nenarušuje systém nebo neblokuje zásadní funkčnost nebo nebrání testování dalších oblastí aplikace, můžeme použít „Nízký“.
Vypadá dobře, že?
ŠPATNĚ. Z údajů o pacientovi jsou všechna očkování a další upomínky opožděné. To může, ale nemusí být správné. U pacienta také záleží na jeho věku, zda navštíví pediatra nebo praktického lékaře atd.
Ovlivňuje dávky léků a mnoho dalších oblastí léčby, o kterých bychom možná ani nevěděli.
Takže půjdu s „High“. Souhlasím, že je nepravděpodobné, že by personál nemocnice vstoupil do DOB pacienta špatně. Ale ať je to faktor, který ovlivňuje prioritu, kdy problém vyřešit.
Mým úkolem jako testera je zajistit, abych co nejlépe informoval o závažnosti problému.
Lék: Nespěchejte s hlášením. Buďte si 100% jisti, že chápete dopad problémů z mnoha úhlů. Je to nejlepší přidaná hodnota, kterou testeři mohou poskytnout. Neříkáme jen: „Něco nefunguje“. Říkáme také: „Tady je to, co se stane, pokud to nebude fungovat.“ Tuny rozdílu, že?
# 3) Nedostatek kreativity
Testeři mají skvělou příležitost předložit návrhy na vylepšení softwaru.
Ve vašem Nástroj pro správu defektů také můžete odeslat vadu typu „Návrh vylepšení“. Zde můžete být kreativní.
Lék: Myslet mimo krabici. Pokud si myslíte, že určité vlastnosti chybí faktor „Páni“ a víte, jak ji do ní vnést, předveďte tuto myšlenku. V nejhorším případě by to mohlo být odmítnuto a to je v pořádku. Důležitou součástí je snaha.
Tuto super sílu také používejte opatrně. Snažte se nepřidávat komentáře typu „Nesnáším barvu banneru, změňte ji prosím.“
Tady je dobrápříkladnávrhu vylepšení, na který jsem narazil: Nahrazení možnosti „E-mail prodejci“ možností „Chat s prodejcem“ na webu prodejců automobilů. Předpokládá se, že převede větší provoz na prodej.
Přál bych si, abych byl tak kreativní! Ale možná se k tomu všichni můžeme dopracovat.
Zde je bonus. Kontrolní seznam k osvobození od těchto špatných návyků:
1. Vysvětluje můj název problém jasně a stručně?
Například:„Vytvořit pacienta nefunguje“ není dobrý název. „Vytvořit pacienta selže, i když všechna vstupní pole obsahují správné hodnoty“ je.
dva. Jaká je míra reprodukovatelnosti?
Jinými slovy, děje se to vždy? Znám přesnou posloupnost kroků, které problém zopakují?
3. Je tato problémová platforma, prohlížeč nebo uživatel specifický?
Čtyři. Jsou kroky dokončeny a dostanou vás k problému?
5 . Mám zahrnutý snímek obrazovky?
6. Musím anotovat svůj snímek obrazovky, abych zvýraznil nějaké konkrétní oblasti?
7. Je název připojeného obrazového souboru popisný?
Nepoužívejte něco jako „Untitled.jpg“. Dejte mu popisný název.
8. Zahrnul jsem údaje z testu?
Například:U defektu v modulu správce, který vyžaduje autorizační pověření, zahrňte je. Vývojový tým může, ale nemusí mít přístup do prostředí QA. Nechcete zpoždění a sledování něčeho tak zásadního.
9. Mohu uvést další podrobnosti k posílení mé vady?
(Příklad:odkaz na FRD nebo rozhovor s klientem atd.)
10. Chápu, jak závažný je problém z různých úhlů pohledu?
jedenáct. Znám příčinu problému? Pokud ano, mám důkazy (možná soubory protokolu) a mohu je zahrnout? Upozorňujeme, že to možná ne vždy víte nebo potřebujete vědět. Pokud to však uděláte, nezaškodí to zahrnout.
12. Není hlášení o závadě bez problémů s gramatikou, formátem, pravopisem a interpunkcí?
nejlepší bezplatný optimalizátor pro Windows 10
13. Znám způsob, jak vylepšit produkt?
Myslíte si, že je to časově náročné? Jakmile se to stane zvykem, už to nebude.
Zakořenění k lepšímu hlášení závad rutiny!
O autorovi: Tento článek je napsán členem týmu STH Swati.
Neváhejte a pošlete své dotazy / komentáře níže.
Doporučené čtení
- Proč je hlášení chyb umění, které by se měl naučit každý tester?
- Co je životní cyklus vady / chyby při testování softwaru? Výukový program pro defekt životního cyklu
- Ukázky hlášení chyb pro webové a produktové aplikace
- Co je technika testování na základě vad?
- Proces správy defektů: Jak efektivně spravovat defekty
- Proces defektního třídění a způsoby řešení schůzky defektního třídění
- Jak napsat dobrou zprávu o chybě? Tipy a triky
- 3 strategie řešení vady blokátoru