Menu

Scenár testu Vs Testovací prípad: Aký je rozdiel medzi nimi?

test scenario vs test case

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

Rozdiel medzi testovacím scenárom vs skúšobným prípadom.

Pred 6 rokmi Keď som pri práci so stredne veľkým MNC navrhol dokumentovať testovacie scenáre a nestrácal čas prípravou úplného dokumentu s názvom testovacie prípady, všetky hlavy sa na mňa mrzuto otočili.

Pohľad na tvárach jasne naznačoval, že som urobil veľkú chybu tým, že som to naznačil. Hoci túto myšlienku nikto nepoprel, nikto ju ani neprijal. Každý mal pocit, že nasledovanie tradície, teda písanie dokumentov o testovacích prípadoch, by bolo bezpečnejšie. Nemohol som argumentovať.

Testovací scenár Vs Testovací prípad

Po 4 rokoch , spoločnosť získala testovací projekt, kde jediným obmedzením bol čas a jediným očakávaním bol úplný dôkaz testovanie.

Znovu sme boli na stretnutí a diskutovali sme o nápadoch, ako dodržať kritický termín. Aplikácia bola hlavne o hľadaní a generovaní rôznych reportov cez rôzne položky menu. Dokumentácia testovacích prípadov mala väčšinu času vytrhnúť a neboli sme si istí, koľko bude dokument na klienta spotrebovať.

Navrhol som dokumentáciu testovacích scenárov a akosi s určitým zaváhaním všetci súhlasili. Nie je potrebné spomínať, že by sme mohli ušetriť drahocenný čas na dokumentáciu a mohli by sme ju využiť na testovanie.

Čo sa dozviete:

Nahrádzajú sa testovacie prípady rýchlo testovacími scenármi?

Postupom času, keď sa všetko mení, sa veľmi zmenil aj softvérový priemysel a procesy.

php rozhovor otázky a odpovede pdf

Tradičné Vodopád a V-modely sú nahradené agilnými a iteračnými modelmi. Dokumentácia je nevyhnutná ale kvôli dodržaniu termínov a uľahčeniu a sprehľadneniu procesu je možné zmeniť spôsob dokumentácie.

Kedy je dokumentácia testovacích prípadov dôležitá?

  1. Klient požiadal o to isté ako súčasť projektu.
  2. Nie je tam žiadne časové obmedzenie (nemyslím si, že je to možné).
  3. Testery sú sviežejšie alebo pre produkt nie sú známe.
  4. Politika spoločnosti (pevne verím, že sa dá zmeniť).

Dovoľte mi, aby som sa s vami podelil o jednu skúsenosť:

Ja a môj tím sme boli zapojení do testovania projektu od spoločnosti Fortune 500 s flexibilnými časovými harmonogramami. Dokumentovali sme testovacie prípady s najlepšou dostupnou šablónou a dostali sme ju od klienta.

Akonáhle sa zostava začala uvoľňovať tímu QA, po väčšinu dňa bolo našou povinnosťou, mechanicky sledovať 100 testovacích prípadov za deň, aktualizovať dokument s výsledkom pass / fail a na konci dňa ho poslať klientovi. Väčšina z členovia tímu sa začali sťažovať monotónna práca ale spoločnosť generovala príjmy.

Potom bola prestávka na jeden deň medzi tým a nebolo treba testovať nové zostavenie. Začiatkom dňa sme sedeli spolu a diskutovali o tom, čo urobíme pre tento deň. Keď som navrhol vygenerovať viac nápadov na vylepšenie dokumentu o testovacom prípade, všetci členovia tímu popreli vynaloženie úsilia.

Podľa nich už nebolo o čom premýšľať, pretože sme prebrali všetky scenáre. A presvedčiť ich, aby premýšľajte po vybalení z krabice a vygenerujte viac nápadov bolo naozaj ťažké.

Väčšinou, keď dokumentujeme testovacie prípady a tie sú príliš raz schválené klientom, ľudská myseľ si myslí, že sme vykonali svoju prácu a naša myseľ automaticky prestane uvažovať o akejkoľvek snahe premýšľať o ďalších spôsoboch testovania produktu.

A verte mi, že keď sa pripraví dokument o testovacích prípadoch, chceme sa ním riadiť iba mechanicky. Povedzte mi, koľkokrát ste sa vo svojej kariére stretli s tým, že ste vy alebo tímový kolega ponúkli k schválenému dokumentu o testovacích prípadoch ďalšie testovacie prípady?

Ešte jedna skúsenosť:

Počas týždennej aktivity v oblasti tímových výziev sme oznámili aplikáciu a požiadali sme členov tímu, aby vyplnili testovacie scenáre.

Všetci členovia tímu, vrátane tých, ktorí neskoro reagovali alebo nereagovali, vložili nápady. Prečo? Neexistovala žiadna formálna dokumentácia, kde by museli vyplniť očakávaný výsledok pre každú postupnosť funkčnosti a predbežné podmienky pre každý testovací prípad. Zozbierali sme 40 testovacích scenárov za deň a to bola skvelá skúsenosť.

V prospech mojich skúseností, Rád by som uviedol príklad.

Vezmite si ukážkovú aplikáciu, povedzme prihlasovaciu stránku pomocou tlačidiel používateľského mena, hesla, prihlásenia a zrušenia. Ak sa od nás bude vyžadovať, aby sme písali rovnaké testovacie prípady, nakoniec napíšeme viac ako 50 testovacích prípadov kombináciou rôznych možností a podrobností.

Ak sa však majú písať testovacie scenáre, bude to otázka 10 riadkov, ako je uvedené nižšie:

Scenár na vysokej úrovni: Funkcia prihlásenia
Scenáre nízkej úrovne :

1. Skontrolujte, či sa aplikácia spúšťa
2. Skontrolujte textový obsah na prihlasovacej stránke
3. Skontrolujte pole Meno používateľa
4. Skontrolujte pole Heslo
5. Skontrolujte funkčnosť tlačidla Prihlásenie a zrušenie funkcie

Pozri tiež=> 180+ príkladov testovacích scenárov na testovanie webových a desktopových aplikácií.

aký je najlepší bezplatný sťahovač hudby

Pretože nám všetkým chýba čas, testovacie scenáre fungujú skôr ako sprej proti bolesti ako ako starý IODEX. Efekt je stále rovnaký.

Rozdiely medzi testovacím scenárom Vs a testovacím prípadom v tabuľkovom formáte

Na záver by som chcel zhrnúť rozdiel medzi Testovacím scenárom a Testovacím prípadom:

Testovacie prípadyTestovacie scenáre
Čo to je => Koncept, ktorý poskytuje podrobné informácie o tom, čo treba testovať, aké kroky je potrebné podniknúť a aký je očakávaný výsledokKoncept, ktorý poskytuje jednoriadkové informácie o tom, čo treba testovať.
Je to o => Ide skôr o dokumentovanie podrobností.Ide skôr o premýšľanie a diskusiu o detailoch.
Dôležitosť => Je dôležité, aby testovanie nebolo podporované a vývoj bol na mieste. Písanie testovacích prípadov s podrobnosťami pomôže synchronizovať tím vývojárov aj QA.Je dôležité, keď je menej času a väčšina členov tímu môže súhlasiť / porozumieť podrobnostiam scenára jedného typu.
Výhoda => Jednorazová dokumentácia všetkých testovacích prípadov je prospešná pre budúce sledovanie regresných testov s trvaním 1000 s.
Väčšinou je to užitočné pri hlásení chýb. Tester musí uviesť iba ID testovacieho prípadu a nevyžaduje zmienku o každej jednej minúte.
Činnosť šetriaca čas a vytváranie nápadov, ktorú uprednostňuje komunita testovania softvéru novej generácie.
Úpravy a pridanie sú jednoduché a nie sú špecifické pre človeka.
Pre obrovský projekt, kde skupina ľudí pozná iba konkrétne moduly, dáva táto aktivita každému príležitosť nahliadnuť do ďalších modulov a prekonať mozgovú búrku a diskutovať o nich.
Prospešné pre => Úplný dokument o testovacom prípade je pre nového testera životnou líniou.Dobré pokrytie testu je možné dosiahnuť rozdelením aplikácie do testovacích scenárov, čo znižuje opakovateľnosť a zložitosť produktu
Nevýhoda => Časovo a finančne náročné, pretože to vyžaduje viac zdrojov na podrobné vysvetlenie všetkého, čo treba testovať a ako testovaťAk ich vytvorí konkrétna osoba, nemusí recenzent alebo iný používateľ synchronizovať presný nápad. Potrebujete viac diskusií a tímového úsilia.

Záver

Testovacie prípady sú najdôležitejšou súčasťou životného cyklu vývoja softvéru a bez tohto je ťažké niečo sledovať, rozumieť im, sledovať ich a zdôvodňovať. Ale v ére Agile sa testovacie prípady rýchlo nahrádzajú testovacími scenármi.

Bežný testovací kontrolný zoznam pre každý typ testovania (testovanie databázy, testovanie grafického používateľského rozhrania, testovanie funkčnosti atď.) v spojení s testovacími scenármi je moderné delostrelectvo pre softvérových testerov. Diskusie, školenie, otázky a prax môžu definitívne zmeniť výsledný graf vaša produktivita rovnako ako matica správy o chybe.

Ako obvykle uvítame vaše myšlienky a dotazy. Nalaďte sa prosím.

Výukový program PREV | NEXT Tutorial

Odporúčané čítanie

^