Menu

Jak se vypořádat se špatnými požadavky jako tester

how deal with bad requirements

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

Tichá konferenční místnost se dusila a všichni uvnitř byli zmatení. Jak nám to mohlo uniknout , odrážela se otázka tváře každého.

Koneckonců, neobjevení se žádné relevantní chyby, když se uživatel pokusí duplikovat stávající záznam a umožnit mu to, nebyla malá chyba - to také pro pojišťovnu.

Poté, co se rozhodli vyřešit problém, se všichni rozešli. A při výkopu bylo zjištěno, že klient nikdy nezmínil nic o duplicitě záznamů v dokumentu požadavků, a proto nikdo nekládal relevantní otázky ani o tom nepřemýšlel.

špatné požadavky

To byl jen příklad.

V kariéře více než 10 let „Pozoroval jsem mnoho případů, kdy projekty utrpěly kvůli špatným nebo špatným požadavkům.

Ale jak se říká, na tomto světě není nic dokonalého a budete se s tím muset vypořádat a vypořádat se s projekty, které nemají žádné nebo špatné požadavky, jsou svým způsobem noční můrou.

Nech mě to vysvětlit -

Co se naučíte:

Jak špatné, špatné a protichůdné požadavky vytvářejí potíže:

# 1) Žádné požadavky - Žádné požadavky neimplikují předpoklady a odhady, a proto neexistuje důvěra. Je velmi obtížné otestovat produkt / aplikaci bez jakékoli základní linie. Výsledkem je více práce, více chyb od klienta a více utrpení pro projekt.

  • Jak bys nahlásit problém o zhroucení systému, když neexistuje definice toho, jak by se mělo chování chovat, byla k dispozici?
  • Jak byste vyjádřili, že doba načítání domovské stránky 100 sekund je nepřijatelná, když na výkon neexistuje žádný relevantní požadavek?

Další informace o Žádných požadavcích a způsobu řešení situace při testování naleznete v dřívějším publikovaném článku - Jak otestovat aplikaci bez požadavků?

# 2) Špatné požadavky - Citát, Vědět něco neúplného je nebezpečné, než to nevědět vůbec , je velmi pravda, pokud jde o řešení špatného požadavku.

Interpretace špatného požadavku a jeho implementace je velkým rizikem.

  • Jak byste potvrdili, že vyskakovací okno zobrazující výsledky vyhledávání je platné nebo ne, když jediným zmíněným požadavkem bylo - výsledky vyhledávání by měly být správné a nejste si jisti, která kritéria by měla být při hledání zohledněna.
  • Jak byste to interpretovali - Zapomenuté heslo by mělo být implementováno, aby uživateli usnadnilo regeneraci / resetování zapomenutého hesla. Neznámo o tom, jaký pracovní tok chce zákazník pro zapomenuté heslo, implementuje vývojář to, co považuje za nejlepší, a začnou konflikty.

# 3) Konfliktní požadavky - Výzva, aby někdo udělal dvě různé věci současně, je pouze zmatená a systém není výjimkou.

  • Jak byste otestovali aplikaci s uvedenými požadavky, jak je uvedeno níže:
    • Aplikace by měla být vždy otevřena na domovské stránce.
    • Od uživatelů se očekává, že se přihlásí, aby měli přístup k aplikaci.
  • Jaký je váš názor na prioritu, když je dokument s požadavky uveden níže:
    • Pokud má uživatel skóre 1000, měla by herní aplikace povýšit uživatele na další úroveň.
    • Jakmile dosáhne skóre 1000, měl by být uživatel přesměrován na bezplatnou stránku předplatného.

A tak špatné, špatné a protichůdné požadavky vytvářejí potíže.

V softwarovém průmyslu by to mělo být součástí projektu, protože někdy si ani zákazník není jistý, co přesně chce a jak to vyslovit.

Z hlediska testování, i když je obtížné zvládnout tyto nejednoznačné nebo vágní požadavky, není to úplně nemožné.

Podívejme se na možná řešení:

Špatné požadavky a způsob, jak s nimi zacházet jako s testerem:

Metoda č. 1)Prozkoumat a učit se:

Jedním ze způsobů řešení situace je zkoumání dalších aplikací, učení se o obecném očekávaném chování, porozumění průběhu práce, přemýšlení o pohodlí uživatele a uplatňování logiky. Taky, spoléhat se na průzkumné testování by bylo užitečné v takových situacích, kdy požadavky nejsou jasné.

Většinu času je dobré dát přednost uživatelskému zážitku a pohodlí, když požadavky nejsou jasné.

Metoda č. 2)Využijte zkušenosti:

Využijte zkušenosti

Zkušenosti s doménou , celková zkušenost s testováním, problémy, s nimiž se setkáváme v minulosti, a osobní pohledy mohou pomoci vyřešit matoucí situace a požadavky.

Metoda č. 3)Doporučte drátové modely:

Drátové modely jsou jakýmsi vizuálním požadavkem, kde najdete malé podrobnosti a tyto podrobnosti mohou být velmi užitečné při vytváření očekávaného obrazu produktu nebo aplikace a pomáhají lépe pokrývat aspekty testování.

Přečtěte si více => Drátové modely - měly by být skutečně testovány? A pokud ano, jak?

Metoda č. 4)Peer diskuse:

rozdíl mezi testováním sit a uat

Peer diskuse

Bez ohledu na to, o jaký zmatek jde, pokud se jedná o správnou skupinu lidí, věci se vyjasní. Každý má různé zkušenosti, očekávání, pohled uživatele a pohled na analýzu a diskuse o těchto špatných požadavcích s kolegy bude přínosem krystalizace porozumění a zvýšení sebevědomí.

Metoda č. 5)Vyjasnění od zákazníka:

Zákazník je vlastníkem produktu / aplikace a pokud jde o jasnost požadavků, je vždy moudré k němu přistoupit. Nezapomeňte však, že není vhodné zaútočit na zákazníka stovkami otázek. Než tak učiníte, je třeba udělat nějaké domácí úkoly.

Pokuste se zjistit dostupné osvědčené postupy, porozumět výhodám implementace a poté kontaktovat zákazníka s dotazem a možným řešením.

Závěr

A konečně, volně definované nebo nedefinované požadavky jsou součástí života testerů a musíme je přijmout, ale zkusme být optimističtí a určit jejich řešení. Koneckonců, jsme testeři, pomáháme udržovat aplikace na správné cestě a chránit je před pádem. YAY nám :)

O autorovi: Tento inspirativní příspěvek napsal člen týmu STH Bhumika M. Je vedoucím projektu a má více než 10 let zkušeností s testováním softwaru.

Šťastné testování, jako obvykle ... .. čeká na vaše názory, komentáře a názory.

Doporučené čtení

^