Testování kouře vs. Test příčetnosti: Rozdíl s příklady

smoke testing vs sanity testing

Prozkoumejte rozdíly mezi kouřovým testem a testem zdravého rozumu podrobně na příkladech:

V tomto kurzu se naučíme, co je Test příčetnosti a Test kouře v Testování softwaru. Na jednoduchých příkladech se také naučíme klíčové rozdíly mezi zkouškami Sanity a Smoke.

Většinou jsme zmateni mezi významem Testování příčetnosti a Testování kouře. Nejprve jsou tato dvě testování způsobem “ odlišný „A jsou prováděny v různých fázích testovacího cyklu.

Co se naučíte:

• Test příčetnosti
• Moje zkušenost
• Zdraví Testování vs. Regresní Testování
• Strategie pro testování mobilních aplikací
• Preventivní opatření
• Testování kouře
• Příklady zkoušek kouře
  • # 1) Přijímací testování
  • # 2) Testování integrace
  • # 3) Testování systému
• Důležitost v metodice SCRUM
• Kouřový test vs Testování přejímky
• Cyklus zkoušky kouře
• Kdo by měl provést kouřový test?
• Proč bychom měli automatizovat kouřové testy?
• Výhody a nevýhody
• Rozdíl mezi testováním kouře a zdravého rozumu
  • TESTOVÁNÍ KOUŘE
  • TESTOVÁNÍ SANITY
• Doporučené čtení

Test příčetnosti

Test příčetnosti se provádí, když jako QA nemáme dostatek času na spuštění všech testovacích případů Funkční testování , UI, OS nebo testování prohlížeče.

Proto bych definoval,

'Testování příčetnosti jako provedení testu, které se provádí s cílem dotknout se každé implementace a jejího dopadu, ale ne důkladně nebo do hloubky, může zahrnovat funkční testování, uživatelské rozhraní, verzi atd. V závislosti na implementaci a jejím dopadu.'

Nespadáme všichni do situace, kdy se musíme za den nebo dva odhlásit, ale verze pro testování stále není vydána?

web, který vám umožňuje stahovat videa z YouTube

Ach ano, vsadím se, že jste se také museli alespoň jednou setkat s touto situací ve svém testování softwaru. No, čelil jsem tomu hodně, protože moje projekty byly většinou agilní a občas jsme byli požádáni, abychom je doručili ve stejný den. Jejda, jak mohu testovat a uvolnit sestavení během několika hodin?

Občas jsem se zbláznil, protože i když se jednalo o malou funkčnost, mohla by být implikace obrovská. A jako třešničku na dortu klienti někdy jednoduše odmítnou dát čas navíc. Jak bych mohl dokončit celé testování za pár hodin, ověřit všechny funkce, Hmyz a uvolnit to?

Odpověď na všechny tyto problémy byla velmi jednoduchá, tj. Nic jiného než použití Strategie testování zdravého rozumu.

Když provádíme toto testování pro modul nebo funkčnost nebo kompletní systém, Testovací případy pro provedení jsou vybrány tak, aby se dotýkaly všech důležitých částí stejného, ​​tj. širokého, ale mělkého testování.

Někdy se testování provádí náhodně bez testovacích případů. Ale pamatuj, Test zdravého rozumu by měl být proveden pouze v případě, že vám dochází čas, nikdy jej nepoužívejte pro své běžné verze. Teoreticky je toto testování podmnožinou Regresní testování .

Moje zkušenost

Z mé 8+ let kariéry v Testování softwaru jsem pracoval 3 roky Agilní metodik y a to byla doba, kdy jsem většinou používal test zdravého rozumu.

Všechna velká vydání byla plánována a prováděna systematicky, ale občas bylo nutné vydat malá vydání co nejdříve. Neměli jsme moc času dokumentovat testovací případy, provádět, dělat dokumentaci chyb, dělat regresi a sledovat celý proces.

Proto jsou některé z klíčových ukazatelů, které jsem v takových situacích sledoval:

# 1) Sedněte si s manažerem a týmem vývojářů, když diskutují o implementaci, protože musí pracovat rychle, a proto nemůžeme očekávat, že nám to vysvětlí samostatně.

To by vám také pomohlo získat představu o tom, co se chystají implementovat, na kterou oblast to bude mít vliv atd., To je velmi důležitá věc, protože si občas jednoduše neuvědomujeme důsledky a pokud existuje nějaká stávající funkce bude brzděno (v nejhorším případě).

#dva) Jelikož vám chybí čas, v době, kdy vývojový tým pracuje na implementaci, si můžete testovací případy zaznamenat zhruba v nástrojích, jako je Evernote atd. Nezapomeňte je ale někam napsat, abyste je mohli později přidat do nástroj testovacího případu.

# 3) Udržujte své testovací lůžko připravené podle implementace a pokud máte pocit, že existují nějaké červené příznaky, jako je vytvoření některých konkrétních dat, pokud testovací postel bude nějakou dobu trvat (a je to důležitý test pro vydání), okamžitě tyto příznaky zvedněte a informujte svého manažera nebo PO o zátarasu.

Jen proto, že klient chce co nejdříve, neznamená to, že se QA uvolní, i když je napůl testováno.

# 4) Dohodněte se se svým týmem a manažerem, že kvůli časové tísni budete chyby komunikovat pouze vývojovému týmu a formální proces přidávání, označování chyb pro různé fáze nástroje pro sledování chyb bude provedeno později, aby se ušetřil čas .

# 5) Když vývojový tým testuje na svém konci, zkuste se s nimi spárovat (tzv. Párování dev-QA) a udělat základní kolo na jejich samotném nastavení, což pomůže vyhnout se sem a tam sestavení, pokud selže základní implementace .

# 6) Nyní, když máte sestavení, nejprve otestujte obchodní pravidla a všechny případy použití. Testy, jako je ověření pole, navigace atd., Si můžete ponechat na později.

# 7) Ať už najdete jakékoli chyby, poznamenejte si je všechny a zkuste je hlásit společně vývojářům, nikoli hlásit jednotlivě, protože pro ně bude snadné pracovat na hromadě.

# 8) Pokud máte požadavek na celkový Testování výkonu nebo Zátěžové nebo zátěžové testování, pak se ujistěte, že máte stejný automatizační rámec. Protože je téměř nemožné je ručně otestovat testem zdravého rozumu.

# 9) Toto je nejdůležitější část a skutečně poslední krok vaší strategie testování zdravého rozumu - „Když vypracujete e-mail s vydáním nebo dokument, uveďte všechny testovací případy, které jste provedli, chyby nalezené se značkou stavu a pokud něco zbylo netestováno zmínit to s důvody ' Zkuste napsat ostrý příběh o svém testování, který každému sdělí, co bylo testováno, ověřeno a co ještě nebylo.

Sledoval jsem to nábožensky, když jsem používal toto testování.

Dovolte mi podělit se o své vlastní zkušenosti:

# 1) Pracovali jsme na webu, který používal vyskakovací reklamy na základě klíčových slov. Inzerenti zadávali nabídky pro konkrétní klíčová slova, která měla stejnou obrazovku. Výchozí hodnota nabídky se dříve zobrazovala jako 0,25 USD, kterou mohl uchazeč dokonce změnit.

Bylo ještě jedno místo, kde se tato výchozí nabídka dříve zobrazovala, a také ji bylo možné změnit na jinou hodnotu. Klient přišel s požadavkem na změnu výchozí hodnoty z 0,25 $ na 0,5 $, ale zmínil pouze zřejmou obrazovku.

Během naší brainstormingové diskuse jsme zapomněli (?) Na tuto druhou obrazovku, protože pro tento účel nebyla příliš používána. Ale při testování, když jsem spustil základní případ, kdy nabídka byla $ 0,5 a zkontroloval jsem konec do konce, zjistil jsem, že cronjob pro totéž selhal, protože na jednom místě nacházel 0,25 $.

Ohlásil jsem to svému týmu a provedli jsme změnu a úspěšně jsme ji doručili ve stejný den.

#dva) V rámci stejného projektu (uvedeného výše) jsme byli požádáni, abychom přidali malé textové pole pro poznámky / komentáře k podávání nabídek. Byla to velmi jednoduchá implementace a zavázali jsme se ji doručit ve stejný den.

Proto, jak bylo uvedeno výše, jsem otestoval všechna obchodní pravidla a případy použití kolem něj a když jsem provedl nějaké ověřovací testování, zjistil jsem, že když jsem zadal kombinaci speciálních znaků, jako je stránka, došlo k chybě.

Přemýšleli jsme o tom a zjistili jsme, že skuteční uchazeči takové kombinace v žádném případě nepoužijí. Proto jsme jej vydali s dobře vypracovanou poznámkou o problému. Klient to přijal jako chybu, ale souhlasil s námi, abychom ji implementovali později, protože to byla závažná chyba, ale ne předchozí.

# 3) Nedávno jsem pracoval na projektu mobilní aplikace a měli jsme požadavek na aktualizaci doby doručení zobrazené v aplikaci podle časového pásma. Mělo to být testováno nejen v aplikaci, ale také ve webové službě.

Zatímco vývojový tým pracoval na implementaci, vytvořil jsem automatizační skripty pro testování webové služby a skripty DB pro změnu časového pásma položky dodávky. To mi ušetřilo úsilí a během krátké doby jsme mohli dosáhnout lepších výsledků.

Zdraví Testování vs. Regresní Testování

Níže je uvedeno několik rozdílů mezi těmito dvěma:

Strategie pro testování mobilních aplikací

Určitě se divíte, proč zde zmiňuji konkrétně mobilní aplikace?

Důvodem je to, že OS a verze prohlížeče pro webové nebo desktopové aplikace se příliš neliší a zejména velikosti obrazovek jsou standardní. Ale u mobilních aplikací velikost obrazovky, mobilní síť, verze OS atd. Ovlivňují stabilitu, vzhled a zkrátka úspěch vaší mobilní aplikace.

Z tohoto důvodu se formulace strategie stává kritickou, když provádíte toto testování v mobilní aplikaci, protože jedno selhání vás může dostat do velkých problémů. Testování musí být provedeno chytře a opatrně.

Následuje několik ukazatelů, které vám pomohou úspěšně provést testování v „mobilní aplikaci“:

# 1) Nejprve se svým týmem analyzujte dopad verze OS na implementaci.

Zkuste najít odpovědi na otázky typu, bude se chování lišit ve všech verzích? Bude implementace fungovat na nejnižší podporované verzi nebo ne? Vyskytnou se problémy s výkonem při implementaci verzí? Existuje nějaká konkrétní vlastnost OS, která by mohla ovlivnit chování implementace? atd.

#dva) Ve výše uvedené poznámce analyzujte také modely telefonů, tj. Existují nějaké funkce telefonu, které ovlivní implementaci? Je implementace změny chování pomocí GPS? Mění se chování implementace u fotoaparátu telefonu? atd. Pokud zjistíte, že to nemá žádný dopad, vyhněte se testování na různých modelech telefonů.

# 3) Pokud nedojde k žádným změnám uživatelského rozhraní pro implementaci, doporučil bych ponechat testování uživatelského rozhraní na nejnižší prioritu, můžete tým informovat (pokud chcete), že uživatelské rozhraní nebude testováno.

# 4) Abyste ušetřili čas, vyhněte se testování na dobrých sítích, protože je zřejmé, že implementace bude fungovat podle očekávání na silné síti. Doporučil bych začít s testováním na 4G nebo 3G síti.

# 5) Toto testování je třeba provést za kratší dobu, ale pokud se nejedná o pouhou změnu uživatelského rozhraní, proveďte alespoň jeden test v terénu.

# 6) Pokud musíte otestovat matici různých operačních systémů a jejich verzí, navrhuji, abyste to udělali chytře. Například pro testování vyberte páry s nejnižší, střední a nejnovější verzí OS. V dokumentu k vydání můžete zmínit, že ne každá kombinace je testována.

# 7) Na podobném řádku pro test příčetnosti implementace uživatelského rozhraní použijte malé, střední a velké velikosti obrazovky, abyste ušetřili čas. Můžete také použít simulátor a emulátor.

Preventivní opatření

Test příčetnosti se provádí, když vám dochází čas, a proto není možné spustit každý testovací případ, a co je nejdůležitější, nemáte dostatek času na naplánování testování. Aby nedošlo k obviňování, je lepší přijmout preventivní opatření.

V takových případech je zcela běžný nedostatek písemné komunikace, dokumentace ke zkouškám a zmeškání.

Abyste zajistili, že tomu nebudete podléhat, ujistěte se, že:

• Nikdy nepřijímejte sestavení pro testování, dokud nedostanete písemný požadavek sdílený klientem. Stává se, že klienti komunikují změny nebo nové implementace ústně nebo v chatu nebo jednoduché liniové 1 v e-mailu a očekávají, že to budeme považovat za požadavek. Přimějte svého klienta, aby poskytl některé základní funkční body a kritéria přijetí.
• Pokud nemáte dostatek času na jejich úhledné napsání, vždy si udělejte hrubé poznámky o svých testovacích případech a chybách. Nikdy je nenechávejte bez dokladů. Pokud je nějaký čas, sdílejte to se svým vedoucím nebo týmem, aby v případě, že něco chybí, mohli na to snadno upozornit.
• Pokud vám a vašemu týmu chybí čas, ujistěte se, že jsou chyby v e-mailu označeny v příslušném stavu? Celý seznam chyb můžete poslat e-mailem týmu a nechat je vývojáři vhodně označit. Vždy držte míč na hřišti druhého.
• Pokud máte Automatizační rámec připraven, použijte to a vyhněte se tomu Ruční testování , tak za kratší dobu můžete pokrýt více.
• Vyhýbejte se scénáři „uvolnění za 1 hodinu“, pokud si nejste 100% jisti, že budete schopni doručit.
• V neposlední řadě, jak již bylo zmíněno výše, připravte podrobný e-mail s oznámením, co je testováno, co je vynecháno, důvody, rizika, které chyby jsou vyřešeny, co jsou ‚Latered‘ atd.

Jako QA byste měli posoudit, co je nejdůležitější částí implementace, kterou je třeba otestovat, a jaké jsou části, které lze vynechat nebo otestovat základně.

I v krátké době si naplánujte strategii, jak chcete dělat, a budete schopni dosáhnout toho nejlepšího v daném časovém rámci.

Testování kouře

Testování kouře není vyčerpávajícím testováním, ale jedná se o skupinu testů, které se provádějí za účelem ověření, zda základní funkce daného sestavení fungují podle očekávání nebo ne. Toto je a vždy by měl být první test, který je třeba provést u jakékoli „nové“ verze.

Když vývojový tým vydá sestavení pro QA pro testování, zjevně není možné otestovat celé sestavení a okamžitě ověřit, zda některá z implementací obsahuje chyby nebo zda je některá z funkčních funkcí porušena.

S ohledem na to, jak bude QA zajistit, aby základní funkce fungovaly dobře?

Odpovědí na tuto otázku bude provedení a Testování kouře .

Jakmile jsou testy označeny jako testy kouře (v testovací sadě), pak je QA přijato sestavení pro hloubkové testování a / nebo regresi. Pokud některý z kouřových testů selže, je sestavení odmítnuto a vývojový tým musí problém vyřešit a vydat nové sestavení pro testování.

Teoreticky je kouřový test definován jako testování na úrovni povrchu, které potvrzuje, že sestavení poskytované vývojovým týmem týmu QA je připraveno k dalšímu testování. Toto testování také provádí vývojový tým před vydáním sestavení týmu QA.

Toto testování se běžně používá při testování integrace, testování systému a testování úrovně přijetí. Nikdy to nezacházejte jako s náhradou za skutečné úplné testování . Skládá se z pozitivních i negativních testů v závislosti na implementaci sestavení.

Příklady zkoušek kouře

Toto testování se běžně používá pro integraci, přijetí a Testování systému .

Ve své kariéře QA jsem vždy přijal sestavení až poté, co jsem provedl kouřovou zkoušku. Pojďme tedy pochopit, co je kouřový test, z pohledu všech těchto tří testů, na několika příkladech.

# 1) Přijímací testování

Kdykoli je QA vydána sestava, kouřová zkouška ve formě Přijímací zkoušky mělo by se udělat.

V tomto testu je první a nejdůležitější kouřovou zkouškou ověření základní očekávané funkčnosti implementace. Takto byste měli ověřit všechny implementace pro konkrétní sestavení.

Vezměme si následující příklady jako implementace provedené v sestavě, abychom porozuměli kouřovým testům pro tyto osoby:

• Implementována funkce přihlášení, která umožňuje registrovaným řidičům úspěšně se přihlásit.
• Implementována funkce řídicího panelu k zobrazení tras, které má řidič dnes provést.
• Implementována funkce pro zobrazení příslušné zprávy, pokud pro daný den neexistují žádné trasy.

Ve výše uvedeném sestavení bude na úrovni přijatelnosti kouřová zkouška znamenat ověření, že základní tři implementace fungují dobře. Pokud je některá z těchto tří porušena, měla by QA sestavení odmítnout.

# 2) Testování integrace

Toto testování se obvykle provádí při implementaci a testování jednotlivých modulů. V Testování integrace úrovni se toto testování provádí, aby se zajistilo, že všechny základní funkce integrace a end-to-end funkce budou fungovat podle očekávání.

Může to být integrace dvou modulů nebo všech modulů dohromady, proto se složitost kouřového testu bude lišit v závislosti na úrovni integrace.

Zvažme následující příklady implementace integrace pro toto testování:

• Implementována integrace modulů trasy a zastávek.
• Implementována integrace aktualizace stavu příjezdu a odrážet to samé na obrazovce zastávek.
• Implementována integrace kompletního vyzvednutí do modulů funkčnosti dodávky.

V tomto sestavení kouřový test nejen ověří tyto tři základní implementace, ale u třetí implementace ověří několik případů také úplnou integraci. Hodně to pomůže zjistit problémy, které se začnou v integraci objevovat, a ty, které si vývojový tým nevšiml.

# 3) Testování systému

Jak název napovídá sám, na úrovni systému zahrnuje kouřové testování testy nejdůležitějších a běžně používaných pracovních toků systému. To se provádí až poté, co je kompletní systém připraven a otestován, a toto testování na úrovni systému lze označit také jako kouřové testování před regresním testováním.

Před zahájením regrese celého systému se testují základní funkce typu end-to-end jako součást kouřového testu. Sada kouřových testů pro celý systém zahrnuje testovací případy typu end-to-end, které budou koncoví uživatelé velmi často používat.

To se obvykle provádí pomocí automatizačních nástrojů.

Důležitost v metodice SCRUM

V dnešní době se projekty při realizaci projektů stěží řídí metodikou Waterfall, většinou se všechny řídí Agile a SKRUMÁŽ pouze. Ve srovnání s tradiční metodou vodopádu má Smoke Testing vysoké uznání u SCRUM a Agile.

Pracoval jsem 4 roky ve SCRUM . A jak víme, že ve SCRUM jsou sprinty kratšího trvání, a proto je extrémně důležité provést toto testování, aby bylo možné chybné sestavení okamžitě nahlásit vývojovému týmu a opravit také.

Následuje několik odnést o důležitosti tohoto testování ve SCRUM:

• Z čtrnáctidenního sprintu je poločas přidělen QA, ale někdy se sestavení QA zpozdí.
• Ve sprintech je nejlepší pro tým, že problémy jsou hlášeny v rané fázi.
• Každý příběh má sadu kritérií přijatelnosti, takže testování prvních 2–3 kritérií přijetí se rovná kouřovému testování této funkce. Zákazníci odmítnou dodávku, pokud selže jedno kritérium.
• Představte si, co se stane, pokud vám vývojový tým dodá sestavení za 2 dny a na demo zbývají pouze 3 dny a narazíte na selhání základní funkce.
• V průměru má sprint příběhy v rozmezí od 5 do 10, proto je při předání sestavení důležité před přijetím sestavení do testování zajistit, aby byl každý příběh implementován podle očekávání.
• Když má být testován a regresován celý systém, je aktivitě věnován sprint. Čtrnáct dní možná o něco méně na otestování celého systému, proto je před zahájením regrese velmi důležité ověřit nejzákladnější funkce.

Kouřový test vs Testování přejímky

Testování kouře přímo souvisí s testováním přijatelnosti sestavení (BAT).

V BAT provádíme stejné testování - abychom ověřili, zda sestavení selhalo a zda systém funguje dobře nebo ne. Někdy se stává, že když se vytvoří sestavení, zavedou se některé problémy a když se doručí, sestavení nefunguje pro QA.

Řekl bych, že BAT je součástí kouřové kontroly, protože pokud systém selhává, jak můžete jako QA přijmout sestavení pro testování? Nejen funkce, ale i samotný systém musí fungovat, než bude QA pokračovat v hloubkovém testování.

Cyklus zkoušky kouře

Následující vývojový diagram vysvětluje cyklus testování kouře.

Jakmile je sestavení nasazeno na QA, základním cyklem je, že pokud kouřový test projde, sestavení je přijato týmem QA pro další testování, ale pokud selže, je sestavení odmítnuto, dokud nebudou nahlášené problémy opraveny.

Testovací cyklus

Kdo by měl provést kouřový test?

Do tohoto typu testování není zapojen celý tým, aby nedošlo ke ztrátě času u všech QA.

Testování kouře je v ideálním případě prováděno vedoucím QA, který se na základě výsledku rozhodne, zda předat sestavení týmu pro další testování nebo jej odmítnout. Nebo při absenci vedení může toto testování provést také samotná QA.

V době, kdy se jedná o projekt velkého rozsahu, může skupina QA také provést toto testování a zkontrolovat případné zastávky. Ale v případě SCRUM tomu tak není, protože SCRUM je plochá struktura bez vedení nebo manažerů a každý tester má své vlastní odpovědnosti za své příběhy.

Proto jednotlivé QA provádějí toto testování příběhů, které vlastní.

Proč bychom měli automatizovat kouřové testy?

Toto testování je prvním testem provedeným na sestavení vydaném vývojovým týmem. Na základě výsledků tohoto testování se provádí další testování (nebo je sestavení odmítnuto).

Nejlepším způsobem, jak toto testování provést, je použít automatizační nástroj a naplánovat spuštění kouřové sady při vytvoření nového sestavení. Možná si myslíte, proč bych měl „Automatizovat soupravu pro testování kouře“?

Podívejme se na následující případ:

jak otevřít soubory bin ve Windows 10

Řekněme, že vám zbývá týden od vydání a z celkového počtu 500 testovacích případů se vaše kouřová testovací sada skládá z 80–90. Pokud začnete všechny tyto 80–90 testovací případy provádět ručně, představte si, kolik času vám bude trvat? Myslím, že 4-5 dní (minimálně).

Ale pokud použijete automatizaci a vytvoříte skripty ke spuštění všech těchto 80-90 testovacích případů, pak v ideálním případě budou spuštěny za 2-3 hodiny a výsledky budete mít okamžitě s sebou. Nezachránilo to váš drahocenný čas a poskytlo vám výsledky o zabudování mnohem méně času?

Před 5 lety jsem testoval aplikaci pro finanční projekci, která zohledňovala údaje o vašem platu, úsporách atd. A promítal vaše daně, úspory, zisky v závislosti na finančních pravidlech. Spolu s tím jsme měli přizpůsobení pro země, které jsou závislé na zemi a její daňová pravidla použitá ke změně (v kódu).

Pro tento projekt jsem měl 800 testovacích případů a 250 testovacích případů kouře. S využitím selenu bychom mohli snadno automatizovat a získat výsledky těchto 250 testovacích případů za 3-4 hodiny. Šetřilo to nejen náš čas, ale ukázalo nám to co nejdříve o showstopperech.

Proto, pokud není možné automatizovat, využijte pro toto testování automatizaci.

Výhody a nevýhody

Nejprve se podívejme na výhody, které má ve srovnání s několika nevýhodami co nabídnout.

Výhody:

• Snadné provedení.
• Snižuje riziko.
• Vady jsou identifikovány ve velmi rané fázi.
• Šetří úsilí, čas a peníze.
• Automaticky běží rychle.
• Nejméně rizika a problémy integrace.
• Zlepšuje celkovou kvalitu systému.

Nevýhody:

• Toto testování se nerovná ani nenahrazuje úplné funkční testování.
• Dokonce i poté, co kouřový test projde, můžete najít chyby showstopper.
• Tento typ testování je nejvhodnější, pokud můžete automatizovat jinak, mnoho času se věnuje ručnímu provádění testovacích případů, zejména ve velkých projektech, které mají kolem 700-800 testovacích případů.

Test kouře by měl být rozhodně proveden na každém sestavení, protože poukazuje na hlavní selhání a showstoppery ve velmi rané fázi. To platí nejen pro nové funkce, ale také pro integraci modulů, řešení problémů a improvizaci. Je to velmi jednoduchý proces, který se provádí a dosahuje správných výsledků.

Toto testování lze považovat za vstupní bod pro úplné funkční testování funkčnosti nebo systému (jako celku). Ale předtím, tým QA by měl mít jasno v tom, jaké testy mají být provedeny jako kouřové testy . Toto testování může minimalizovat úsilí, ušetřit čas a zlepšit kvalitu systému. Ve sprintech si drží velmi důležité místo, protože času ve sprintech je méně.

Toto testování lze provádět ručně i pomocí automatizačních nástrojů. Nejlepší a upřednostňovaný způsob je však použití automatizačních nástrojů, které vám ušetří čas.

Rozdíl mezi testováním kouře a zdravého rozumu

Většinou jsme zmateni mezi významem Testování příčetnosti a Testování kouře. Nejprve jsou tato dvě testování způsobem “ odlišný “A provedeno v různých fázích testovacího cyklu.

Následuje schematické znázornění jejich rozdílů:

TESTOVÁNÍ KOUŘE

• Toto testování vzniklo v Hardware testování praxe prvního zapnutí nového hardwaru a jeho považování za úspěch, pokud nezačne hořet a kouřit. V softwarovém průmyslu je toto testování povrchním a širokým přístupem, při kterém se testují všechny oblasti aplikace, aniž by se dostaly příliš hluboko.
• Test kouře je skriptován, a to buď pomocí písemné sady testů, nebo automatizovaného testu
• Zkouška kouře je navržena tak, aby se letmým způsobem dotkla všech částí aplikace. Je to mělké a široké.
• Toto testování se provádí, aby se zajistilo, že nejdůležitější funkce programu fungují, ale neobtěžují se jemnějšími detaily. (Například ověření sestavení).
• Toto testování je normální kontrola stavu sestavení aplikace před provedením hloubkového testování.

TESTOVÁNÍ SANITY

• Test zdravého rozumu je úzký regresní test zaměřený na jednu nebo několik oblastí funkčnosti. Test příčetnosti je obvykle úzký a hluboký.
• Tento test je obvykle skriptovaný.
• Tento test se používá k určení, že malá část aplikace po menší změně stále funguje.
• Toto testování je zběžné testování, provádí se vždy, když zběžné testování stačí k prokázání, že aplikace funguje podle specifikací. Tato úroveň testování je podmnožinou regresního testování.
• Tím je ověřit, zda jsou požadavky splněny, či nikoli, a to nejprve kontrolou všech funkcí.

Doufám, že máte jasno v rozdílech mezi těmito dvěma obrovskými a důležitými typy testování softwaru. Neváhejte se podělit o své myšlenky v sekci komentáře níže !!

Doporučené čtení

• Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
• Rozdíl mezi stolním počítačem, klientským serverem a webovým testováním
• Funkční testování vs. nefunkční testování
• Testování stahování e-knih Primer
• Alfa testování a beta testování (kompletní průvodce)
• Příručka pro testování přenositelnosti s praktickými příklady
• Typy testování softwaru: Různé typy testování s podrobnostmi
• Funkční testování vs. Testování výkonu: Mělo by se provádět současně?