test scenario vs test case
Rozdíl mezi testovacím scénářem vs testovacím případem.
před 6 lety Když jsem při práci se středně velkým MNC navrhoval dokumentování testovacích scénářů, místo aby jsem plýtval časem přípravou úplného dokumentu s názvem testovací případy, všechny hlavy se ke mně otočily.
Pohled na tvářích jasně naznačoval, že jsem udělal velkou chybu tím, že jsem to naznačil. Ačkoli tuto myšlenku nikdo nepopřel, nikdo ji ani nepřijal. Každý měl pocit, že následovat tradici, tj. Psát dokumenty týkající se testovacích případů, bude bezpečnější. Nemohl jsem se hádat.
Po 4 letech , společnost obdržela testovací projekt, kde jediným omezením byl čas a jediným očekáváním byl úplný důkaz testování.
Byli jsme znovu na schůzce a diskutovali jsme o nápadech ke splnění kritického termínu. V aplikaci šlo hlavně o vyhledávání a generování různých zpráv pomocí různých položek nabídky. Dokumentační testovací případy měly většinu času vytrhnout a nebyli jsme si jisti, kolik bude dokument klientovi využívat.
Navrhl jsem zdokumentovat testovací scénáře a všichni s určitým váháním všichni souhlasili. Není třeba zmínit, že bychom mohli ušetřit drahocenný čas dokumentace a mohli bychom jej využít k testování.
Co se naučíte:
- Nahrazují se testovací případy rychle testovacími scénáři?
- Kdy je dokumentace zkušebních případů důležitá?
- Rozdíly mezi testovacím scénářem vs testovacím případem v tabulkovém formátu
- Závěr
- Doporučené čtení
Nahrazují se testovací případy rychle testovacími scénáři?
Postupem času, jak se vše mění, se také hodně změnil softwarový průmysl a procesy.
spusťte java projekt v zatmění
Tradiční Vodopád a V-modely jsou nahrazovány agilními a iterativními modely. Dokumentace je nutná ale kvůli dodržení termínů a zjednodušení a transparentnosti procesu lze změnit způsob dokumentace.
Kdy je dokumentace zkušebních případů důležitá?
- Klient požádal o totéž jako součást projektu.
- Neexistuje žádné časové omezení (nemyslím si, že je to možné).
- Testeři jsou pro produkt svěžejší nebo neznámí.
- Politika společnosti (pevně věřím, že ji lze změnit).
Dovolte mi s vámi sdílet jednu zkušenost:
Já a můj tým jsme se zapojili do testování projektu od společnosti Fortune 500 s flexibilními časovými osami. Dokumentovali jsme testovací případy s nejlepší dostupnou šablonou a nechali jsme ji schválit klientem.
Jakmile se sestavení začalo vydávat týmu QA, po většinu dne bylo naší povinností mechanicky sledovat 100 testovacích případů denně, aktualizovat dokument s výsledkem vyhovění / neúspěchu a na konci dne jej odeslat klientovi. Většina členové týmu si začali stěžovat monotónní práce ale společnost generovala příjmy.
Pak byla mezi nimi přestávka na jeden den bez testování nového sestavení. Seděli jsme spolu na začátku dne a diskutovali o tom, co pro tento den uděláme. Když jsem navrhl vygenerovat více nápadů na vylepšení dokumentu testovacího případu, všichni členové týmu popřeli, že by se měli snažit.
Podle nich nebylo o čem přemýšlet, protože jsme pokryli všechny scénáře. A přesvědčit je myslet po vybalení z krabice a vytvářet další nápady bylo opravdu těžké.
Většinu času, když dokumentujeme testovací případy a to příliš jednou schválí klient, si lidská mysl myslí, že jsme odvedli svou práci a naše mysl automaticky přestane uvažovat o jakékoli snaze přemýšlet o dalších způsobech testování produktu.
A věřte mi, že až bude připraven dokument o testovacích případech, chceme ho sledovat pouze mechanicky. Řekněte mi, kolikrát jste ve své kariéře zažili, že jste vy nebo váš týmový kolega nabídli další schválené zkušební případy?
Ještě jedna zkušenost:
Během týdenní aktivity s výzvou týmu jsme oznámili aplikaci a požádali jsme členy týmu, aby nalili testovací scénáře.
Všichni členové týmu, včetně těch, kteří reagovali nebo neodpovídali, vložili nápady. Proč? Neexistovala žádná formální dokumentace, kde by museli vyplnit očekávaný výsledek pro každou posloupnost funkčnosti a předběžné podmínky pro každý testovací případ. Shromáždili jsme 40 testovacích scénářů za den a to byla skvělá zkušenost.
Upřednostňovat mé zkušenosti, Chtěl bych uvést příklad.
Vezměte si ukázkovou aplikaci, řekněme přihlašovací stránku s tlačítky uživatelského jména, hesla, přihlášení a zrušení. Pokud budeme požádáni, abychom pro stejný případ napsali testovací případy, skončíme psaním více než 50 testovacích případů kombinací různých možností a podrobností.
Pokud se ale mají psát testovací scénáře, bude to otázka 10 řádků, jak je uvedeno níže:
Scénář na vysoké úrovni: Funkce přihlášení
Scénáře nízké úrovně :
jak spustit soubor jnlp v systému Windows 10
1. Zkontrolujte spuštění aplikace
2. Chcete-li zkontrolovat textový obsah na přihlašovací stránce
3. Chcete-li zkontrolovat pole Uživatelské jméno
4. Chcete-li zkontrolovat pole Heslo
5. Chcete-li zkontrolovat přihlašovací tlačítko a zrušit funkčnost tlačítka
Viz také=> 180+ ukázkových testovacích scénářů pro testování webových a desktopových aplikací.
Protože nám všem chybí čas, testovací scénáře fungují spíše jako sprej proti bolesti než jako starodávný IODEX. A přesto je účinek stejný.
Rozdíly mezi testovacím scénářem vs testovacím případem v tabulkovém formátu
Na závěr bych chtěl shrnout rozdíl mezi Testovacím scénářem a Testovacím případem:
| Testovací případy | Testovací scénáře | |
|---|---|---|
| Co to je => | Koncept, který poskytuje podrobné informace o tom, co je třeba otestovat, kroky, které je třeba podniknout, a očekávaný výsledek | Koncept, který poskytuje jednorázové informace o tom, co testovat. |
| Je to o => | Jde spíše o dokumentování podrobností. | Jde spíše o přemýšlení a diskusi o detailech. |
| Důležitost => | Je důležité, když testování není podporováno a vývoj probíhá na místě. Psaní testovacích případů s podrobnostmi pomůže týmu dev i QA synchronizovat. | Je důležité, když je méně času a většina členů týmu může souhlasit / porozumět podrobnostem ze scénáře jedné linky. |
| Výhoda => | Jednorázová dokumentace všech testovacích případů je v budoucnu prospěšná pro sledování kol regresního testování po 1000 s. Většinou je to užitečné při hlášení chyb. Tester stačí uvést odkaz na ID testovacího případu a nevyžaduje zmínku o každém detailu každé minuty. | Činnost šetřící čas a generování nápadů upřednostňovaná komunitou testování softwaru nové generace. Úpravy a přidání jsou jednoduché a nejsou specifické pro osobu. U obrovského projektu, kde skupina lidí zná pouze konkrétní moduly, dává tato aktivita každému příležitost nahlédnout do dalších modulů a mozkové bouře a diskutovat |
| Přínosné pro => | Úplný dokument o testovacím případu je pro nového testera životní linií. | Dobrého pokrytí testu lze dosáhnout rozdělením aplikace v testovacích scénářích a snižuje opakovatelnost a složitost produktu |
| Nevýhoda => | Časově a finančně náročné, protože vyžaduje více zdrojů k podrobnému popisu všeho, co je třeba testovat a jak testovat | Pokud je vytvořil konkrétní osoba, nemusí recenzent nebo jiný uživatel synchronizovat přesný nápad. Potřebujete další diskuse a týmové úsilí. |
Závěr
Testovací případy jsou nejdůležitější součástí životního cyklu vývoje softwaru a bez tohoto je těžké něco sledovat, rozumět, sledovat a zdůvodňovat. Ale v éře Agile se testovací případy rychle nahrazují testovacími scénáři.
Běžný kontrolní kontrolní seznam pro každý typ testování (testování databáze, testování grafického uživatelského rozhraní, testování funkčnosti atd.) ve spojení se scénáři testování je moderní dělostřelectvo pro softwarové testery. Diskuse, školení, otázky a praxe mohou konečný graf konečně změnit vaše produktivita stejně jako matice hlášení o chybě.
Jako obvykle uvítáme vaše myšlenky a dotazy. Prosím naladit
Výukový program PREV | DALŠÍ výuka
Doporučené čtení
- Rozdíl mezi testovacím plánem, strategií testu, testovacím případem, testovacím skriptem, testovacím scénářem a testovací podmínkou
- Typy testování softwaru: Různé typy testování s podrobnostmi
- Jak psát testovací případy: Ultimate Guide s příklady
- Jak zkontrolovat dokument SRS a vytvořit testovací scénáře - školení testování softwaru na živém projektu - 2. den
- Jak klasifikovat scénáře pozitivních a negativních testů - podváděcí tester
- Testování výkonu vs. zátěžové testování vs. zátěžové testování (rozdíl)
- Statické testování a dynamické testování - rozdíl mezi těmito dvěma důležitými testovacími technikami
- 101 Rozdíly mezi základy testování softwaru