3 strategies dealing with blocker defect
Vady blokátoru dodávají do běžných testovacích dnů spoustu dramat.
V tomto článku chci popsat některé kroky, které může tester podniknout, když s nimi jedná.
Budu předpokládat, že naši milí čtenáři již závažnosti a prioritě defektů hluboce rozumí. Potřebujete rychlou rekapitulaci? Koukni na tohle.
Znamená to, že vždy musíme úplně zastavit testování, pokud narazíme na problém s blokátory?
V některých případech „ano“, ale možná ne vždy. Mohly by nastat případy, kdy je možná nějaká testovací aktivita.
obraz zdroj
Níže uvádíme několik situací, které jsem zažil ve své kariéře testera. Pevně věřím, že níže uvedené kroky (později sloučené do vývojového diagramu) je třeba dodržet, aby byl tento proces jednodušší.
Pojďme skočit přímo dovnitř.
Kroky, které byste měli podniknout, když narazíte na závadu blokátoru
Krok 1: Když narazíte na problém, investujte čas do nalezení příčiny.
Pevně věřím, že jako tester naše práce nekončí hlášení vad . Pokud to čas dovolí, měli bychom prozkoumat, co mohlo problém způsobit. Možná nebudeme vždy schopni poukázat na přesnou problémovou oblast, ale pokuste se problém vyřešit co nejvíce. Stejné podrobnosti lze v defektu aktualizovat jako další komentáře.
Ve svých projektech jsem toho udělal hodně a výsledkem byla rychlá oprava. Výhody analýzy hlavních příčin jsou:
- Jelikož jde o přidanou hodnotu, může to určitě poskytnout vývojáři lepší směr pro opravu chyb.
- Tester QA také dokáže rozpoznat, zda je tento problém vytvořen sám (problémy se zadáváním dat nebo používáním lidí), a pokud ano, může být opraven samotným testerem. Když se takové chyby nahlásí vývojářům, aniž bychom to zkontrolovali z konce QA, jsou považováno za nevydání a mohlo by to pro testera vytvořit negativní pověst.
Navrhuji tedy, abychom vždy před přihlášením defektu dvakrát zkontrolovali náš konec.
Zde je několik příkladů z mých projektů v reálném čase, které posílí výše uvedené body:
Pracoval jsem na projektu, kde by naše testování vyžadovalo, abychom umístili soubor na určené místo. Přejmenujte jej tak, aby odpovídal názvu v konfiguraci. Naplánovaná úloha by vyzvedla datový soubor a načetla data do systému. Poté bychom ověřili data v databázi a rozhraní frontend.
10 nejlepších společností pro vývoj webových aplikací v Indii
Dříve jsme narazili na problémy, kdy by se úloha spustila, ale data by se nenačetla, a po prošetření to bylo proto, že tester nezměnil název při přetažení souboru na dané místo.
To pro nás byl blokátor, ale ne něco, co by vyžadovalo pozornost vývojáře. Museli jsme věnovat pozornost detailům a vyhnout se tak malým chybám.
Následuje několik běžných kategorií, hlavních příčin a nápravných opatření:
# 1) Soubor hostitelů Problém - Řekněme, že váš soubor hostitelů má parametry, které jsou nesprávné a způsobují problém. V tomto případě můžete buď aktualizovat hostitelský soubor sami, nebo vyhledat pomoc od někoho, kdo má přístup k aktualizaci a pokračovat v provádění testu.
Vadu pro stejné by měl být vznesen, aby vývojáři prozkoumat, ale s řešením funkční testování může stále pokračovat.
Poznámka: Než provedete tyto změny, poraďte se se svými projektovými týmy, zda je pro tým QA v pořádku.
# 2) Konfigurace - Často jsme zaznamenali problémy s konfigurací, jako například neukazování na správné prostředí nebo jiné problémy s nastavením, které blokují problémy. I v takových případech mohou testeři provádět změny a pokračovat v testování.
Poznámka: Ještě jednou si vyžádejte povolení.
# 3) Vydání kódu - Pokud máte pocit, že problém je způsoben kódem, testeři nemohou nic moc udělat. Přihlaste se k závadě blokátoru a počkejte, až bude oprava pokračovat v testování.
# 4) Problém s nasazením - Špatné nasazení je další častou příčinou problémů s blokováním a tyto mohou být zachyceny během testu rozumnosti. I zde by mělo být testování okamžitě zastaveno, dokud nebude přijato nové sestavení.
# 5) Prostředí dolů - Pokud je prostředí nefunkční, řekněme, že se databáze nepřipojuje k serveru nebo URL nefunguje v případě webových stránek; testeři v těchto případech nemohou udělat nic jiného, než nahlásit závadu a počkat, až bude systém funkční.
Pokud tedy řešení existuje, použijte jej k pokračování v testování. Jediným způsobem, jak zjistit, zda uvedené řešení existuje, je prozkoumat hlavní příčinu. Více často než ne, může existovat alternativa.
Krok 2: Při zkoumání hlavní příčiny je velmi snadné spadnout do nekonečné smyčky. Ujistěte se tedy, že to nespotřebovává celý den a veškeré úsilí.
Zde jsou některé ukazatele:
- Najděte rovnováhu a rozpoznejte bod zastavení, když se tam dostanete.
- Zkušenosti a odborné znalosti testeru jsou zásadní pro úspěšný RCA. Je však vhodné zapojit v případě potřeby tým a vedení týmu.
- Pokud máte pocit, že je RCA časově náročná, nejprve neprodleně nahláste problém a poskytněte co nejvíce informací. Screenshot je vždy užitečný.
- V případě potřeby pokračujte. Zašlete e-mail správci nebo vývojáři, abyste upozornili na kritický problém.
- Po upozornění na nezbytné strany pokračujte v odstraňování problémů.
Důvod, proč by měly být vady blokátorů hlášeny okamžitě:
- Vedení by mělo být informováno o všech prostojích, pokud se jedná o závadu showstopper. Tyto informace musí být předány klientovi a mohou také vyžadovat aktualizace plánu projektu (časové osy QA), změnu dodávek atd.
- Jakékoli zpoždění dodávek QA musí být doloženo důkazy. Vždy je tedy lepší komunikovat co nejdříve, místo čekání do konce dne.
Krok # 3: Nyní přejdeme k poslednímu kroku, protože jsme dokončili analýzu problému a jeho komunikaci, co bude dál?
- Pokud problém blokuje přístup do jedné funkční oblasti, zkontrolujte, zda to má dopad na jiné oblasti
- Pokud je aplikace front-end nefunkční, zkontrolujte, zda může pokračovat testování backendu / middlewaru / databáze.
- Pokud nemůže proběhnout žádná aktivita provádění testu, zkuste to pracovat na nějaké dokumentaci související s vaším projektem.
- Můžete také zkusit určit oblasti pro automatizaci pokud ručně opakujete hodně práce. Automatizace nemusí vždy používat nástroj. Řekněme, generování zpráv je pro vás monotónní úkol, to je jedna oblast, kterou lze automatizovat pomocí jednoduchých maker aplikace Excel a podobně.
- Věnujte čas znalostem nástrojů open source, které lze implementovat do vašeho projektu
- V neposlední řadě , pracovat na inovaci, mantře, která v současné době vládne světu!
Konečně , vývojový diagram, který shrnuje celou diskusi!
Vývojový diagram: Kroky k řešení vady blokátoru
jaké jsou komponenty platformy Java?
Autor : Tento úžasný článek napsal člen týmu STH Priya R.
Jaké kroky podniknete, když narazíte na vadu blokátoru?
Doporučené čtení
- Co je technika testování na základě vad?
- Co je životní cyklus vady / chyby při testování softwaru? Výukový program pro defekt životního cyklu
- Proces správy defektů: Jak efektivně spravovat defekty
- Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
- Ukázky hlášení chyb pro webové a produktové aplikace
- Jak reprodukovat nereprodukovatelný defekt a zajistit, aby vaše úsilí při testování stálo za to
- Testování softwaru je vše o nápadech (a jak je generovat)
- 7 Principy testování softwaru: Shlukování vad a Paretův princip