Více než 40 populárních otázek a odpovědí na rozhovor s analytikem QA (SEZNAM 2021)

40 popular test qa analyst interview questions

Nejčastější dotazy Dotaz a odpověď analytika pro testování / zajištění kvality

Při rozhodování o kariéře, ve které chcete být, není rozhodujícím faktorem pouze ten, na kterém si myslíte, že vás může bavit pracovat.

Ale být v této kategorii vyžaduje spoustu dovedností, pochopení odpovědností i nezbytných pracovních povinností pro kariéru, kterou jste si vybrali. Totéž platí při výběru kariéry analytika QA. Vyžaduje to nejen to, abyste byli dobrým testerem, rychlým žákem, mimořádným myslitelem, ale také vyžaduje komplexní řešení problémů.

I když výše uvedených vlastností není dosaženo okamžitě, je zřejmé, že to vyžaduje také zkušenosti a dny tvrdé práce.

Tento článek se bude zabývat všemi aspekty, jejichž znalost je povinná být analytikem QA. Nejčastěji kladené otázky a odpovědi na otázky QA Test Analyst vám poskytnou jasnou představu o vaší přípravě na pohovor.

Populární dotazy k rozhovoru s analytikem QA

Otázka 1) Jaké jsou odpovědnosti analytika QA?

Odpovědět: QA Analyst je ten, kdo zajišťuje, že byla přijata veškerá možná opatření pro testování každé funkce softwarového řešení, a to jak funkčně, tak technicky.

Hlavní povinnosti QA Analyst lze získat takto:

• Provádějte a spravujte všechny činnosti tak, aby splňovaly cíle plánu zkoušek.
• Pro vývoj produktu zvolte procesy vysoké kvality.
• Měl by být schopen analyzovat požadavky a dokumentovat postupy.
• Zdokumentujte a znovu ověřte všechny vady. Nastavte prioritu a závažnost vad.
• Měli by být schopni vytvářet, dokumentovat a udržovat testovací případy.
• Analýza výsledků zkoušek.

Otázka č. 2) Jak chápete plán testování?

Odpovědět: Když máte jasnou představu o tom, co, kdy, jak a kdo, pak se věci ulehčí. Totéž platí i pro testování softwaru, kde testovací plán je dokument, který se skládá z rozsahu, přístupu, zdrojů a osnovy testovacího projektu, jakož i aktivit pro sledování postupu projektu.

Plán zkoušek je záznam procesů, které zahrnují:

• Testovací úkoly
• Testovací prostředí
• Techniky návrhu
• Vstupní a výstupní kritéria
• Jakákoli rizika atd.

Otázka č. 3) Při vývoji produktu zařadit prioritu testovacích úkolů definovaných týmem QA.

Odpovědět: Priorita testovacích úloh je definována následovně:

• Připravuje se plán zkoušek sestávající z osnovy a rozsahu testovacího projektu.
• Testovací případy jsou připraveny k pokrytí všech hlavních a vedlejších funkcí údaji požadovanými pro testování.
• Provádění testovacích případů podle funkcí implementovaných s nadcházejícími sestaveními testovacího projektu v testovacím cyklu.
• Hlášení vad s opětovným ověřením a sledováním jeho průběhu.
• Příprava shrnutí zprávy o provedení testu.

Otázka č. 4) Využijte některé z klíčových výzev, kterým čelí při provádění testování softwaru.

Odpovědět: Protože říkáme, že nikdy nelze dosáhnout úplného testování, je s ním spojeno několik výzev. Ať už je to malý nebo složitý problém, při testování softwaru jakéhokoli projektu čelí některým výzvám.

Níže uvádíme několik klíčových výzev:

• Nedostatek kvalifikovaných testerů, kteří se obvykle potýkají s problémem povědomí o předmětu, stejně jako nedostatek dobrých znalostí o podnikání zákazníka.
• Za faktor se považuje také čas, protože testeři se obvykle zaměřují spíše na pokrytí úkolů než na pokrytí testů při testování kvality, pokud existuje obrovský seznam úkolů, které je třeba dokončit.
• Rozhodnout, který testovací případ musí být proveden jako první as prioritou. Toho je obvykle dosaženo zkušenostmi z práce.
• Správné pochopení požadavků, které mohou vést k tomu, že veškeré vaše testovací snahy budou nulové, pokud bude požadavek nepochopen.
• Nedostupnost nejlepších nástrojů, které jsou nutné k dokončení testování s kratším časem a vyšší účinností.
• Zvládání vztahu mezi testery a vývojáři pomocí dobrých komunikačních a analytických dovedností.

Otázka č. 5) Definujte testování případů použití.

Odpovědět: Testování případů použití lze definovat jako funkční techniku ​​testování černé skříňky, která zachycuje řadu interakcí, ke kterým došlo mezi „aktéry“ a „systémem“. Zde jsou „herci“ zastoupeni uživateli a jejich interakcemi.

Charakteristiky testování případu použití jsou uvedeny níže:

• Funkční požadavky projektu jsou organizovány.
• Zaznamenává cestu nebo scénáře od začátku do konce.
• Může pokrýt vady integrace, tj. Vady, ke kterým došlo v důsledku interakce mezi různými komponentami.
• Popisuje hlavní toky i výjimečný tok událostí.
• Veškeré předběžné podmínky, které jsou vyžadovány, aby případ použití fungoval, by měly být specifikovány dříve.

Otázka č. 6) Definujte strategii testování.

Odpovědět: Soubor pokynů nebo testovacích přístupů, které obvykle provádí projektový manažer za účelem stanovení návrhu testu a obecného testovacího přístupu, je definován jako Testovací strategie. Najde se jako malá část testovacího plánu a používá ji několik projektů.

Sledují se různé testovací přístupy založené na faktorech, jako je povaha a doména produktu, riziko selhání produktu, odbornost při práci s navrhovanými nástroji atd.

Tyto přístupy jsou dále kategorizovány takto:

• Proaktivní přístup , kde přístup k návrhům testů začíná před vytvořením sestavení. Pomáhá tedy při hledání a opravování chyb před sestavením.
• Reaktivní přístup , kde je testovací přístup zahájen po dokončení návrhu testu a kódování.

Otázka č. 7) Vysvětlete rozdíl mezi kontrolou kvality a zajištěním kvality.

Odpovědět: 'Kontrola kvality' a „Zajištění kvality“ jsou dva hlavní pojmy používané pro jakýkoli testovací projekt nebo produkt. Testeři, kteří v tomto oboru začínají, obvykle nechápou skutečný rozdíl mezi nimi.

Rozuměme rozdílu pomocí níže uvedené tabulky.

Otázka č. 8) Kdy je podle vás nejlepší čas zahájit QA v projektu?

Odpovědět: Podle životního cyklu vývoje softwaru (SDLC) se fáze testování provádí po dokončení fáze „implementace a kódování“. Ale v dnešním scénáři je pro dosažení nejlepších výsledků nutné zahájit QA projektu nebo produktu na začátku projektu.

Dodržování tohoto přístupu povede k hlavním výhodám uvedeným níže:

• Včasné plánování procesu pro splnění očekávání zákazníků.
• Dobrá a zdravá komunikace mezi týmy.
• Poskytuje dostatek času potřebného pro nastavení testovacího prostředí.
• Umožňuje včasnou kontrolu a schválení testovacích plánů.

Otázka č. 9) Rozlišujte procesy ověřování a ověřování.

Odpovědět: Procesy ověřování a ověřování jsou obvykle určeny dvěma slavnými otázkami, tj. „ Budujeme systém správně? “ a 'Budujeme správný systém?' .

Uvidíme další rozdíl mezi těmito dvěma procesy v následující tabulce:

Otázka č. 10) Vysvětlete výhody destruktivního testování.

Odpovědět: Destruktivní testování je definováno jako forma testování prováděného testovacím týmem k určení bodu selhání produktu při různých zatíženích, tj. K vyhodnocení strukturálního výkonu aplikace za účelem stanovení jeho pevnosti, houževnatosti, tvrdosti nebo řekněme robustnosti.

Níže jsou uvedeny výhody destruktivního testování:

• Určuje se slabina designu aplikace.
• Určete životnost aplikace.
• Pomáhá snižovat náklady a selhání.

Otázka č. 11) Jak se opakované testování liší od regresního testování?

Odpovědět: Existuje několik rozdílů mezi opakovaným testováním a regresním testováním.

To lze snadno pochopit z níže uvedené tabulky:

Otázka č. 12) Co víte o testování na základě dat?

Odpovědět: Každému testeru automatizace je zcela jasné, že skripty automatizačního testu pokrývají pouze oblast aplikace, která má být testována, se zaznamenanou posloupností akcí uživatele. Normálně tyto akce neprodukují žádnou chybu, protože pouze vstupní data jsou přijímána za podmínek, které jsme zadali během záznamu.

Na tomto místě přichází testování založené na datech, kde chceme, aby aplikace fungovala podle očekávání pro jakýkoli typ vstupních hodnot. Za tímto účelem nejsou data požadovaná pro testování na základě dat pevně zakódována, ale testovací skripty berou svá data ze zdrojů dat, jako jsou soubory CSV, zdroje ODBC atd.

Abychom to shrnuli, testování založené na datech provádí ve smyčce následující akce:

sql server 2012 rozhovor otázky a odpovědi pro zkušené pdf

• Vezme vstupní testovací data z úložiště.
• Data zadaná do aplikace k provádění akcí.
• Ověřte skutečné výsledky s očekávanými.
• Znovu opakujte stejné kroky s novými vstupními daty testu.

Otázka č. 13) Co je matice sledovatelnosti? Je to nutné pro každý projekt?

Odpovědět: Matice sledovatelnosti v jakémkoli projektu je prostředek sledování pokroku projektu týkajícího se implementace nových funkcí, zdokonalení stávajících funkcí atd. Prostřednictvím matice sledovatelnosti můžete vždy sledovat vývoj projektu se všemi aspekty udržovanými podle datum.

Matice sledovatelnosti požadavku se skládá z níže uvedených parametrů, které jsou ve skutečnosti podle dokumentu se specifikací požadavku.

Mezi parametry matice sledovatelnosti požadavků patří:

• Každá část dokumentu požadavku je bod, který má být zahrnut v RTM (Matice sledovatelnosti požadavku).
• Nadpis každého bodu je nadpisem každé sekce ve specifikaci požadavku.
• Odpovídající každému bodu jsou uvedena ID testovacích případů, která jsou zapsána pro danou část.
• BUG / ID nové funkce je také uvedeno v každé sekci.
• Nejdůležitějším bodem je, že se také udržuje sledování prvku, ve kterém bylo implementováno sestavení projektu a jeho funkce.
• Další parametr zahrnuje, zda je sekce plně testována nebo je stále ve stavu testování.

Otázka č. 14) Popište výhody agilního testování.

Odpovědět: Být testerem, zaměřením na dodávku kvalitního produktu za kratší dobu díky porozumění požadavku koncového uživatele a co je nejdůležitější, bez vad ze strany koncového uživatele. Zde přichází na řadu agilní testování, které sleduje princip agilního vývoje softwaru a rychle ověřuje požadavky klienta.

Níže jsou uvedeny výhody agilního testování:

• Do testování je zahrnut cross-funkční agilní tým, který zase přináší výsledky v častých intervalech.
• Šetří spoustu času a peněz.
• Zahrnuje méně dokumentace a čas od času zpětnou vazbu od koncového uživatele.
• Do osobní komunikace je zapojen nejen tester, ale celý tým včetně manažera, zákazníka a vývojáře.
• V důsledku každodenních schůzek lze problémy předem dobře určit.
• Zvýšení produktivity týmu a lepší pochopení technických aspektů projektu.

Otázka č. 15) Co je negativní testování?

Odpovědět: Negativní testování je metoda zajišťující, že stabilita produktu nebo aplikace je zachována, nebo řekněme nezklame, když je uveden neočekávaný vstup. Hlavním účelem této formy testování je ověření aplikace proti případným neplatným vstupním údajům.

Tato forma testování je známá také jako „Testování selhání“ nebo „testování chybové cesty“ a jeho hlavním účelem je zkontrolovat spolehlivost funkce aplikace za negativních scénářů. Rovněž odhaluje softwarovou slabost, odhaluje chyby a poskytuje jasnou představu o poškození dat.

Otázka č. 16) Rozlišovat testování ad hoc a průzkumné testování?

Odpovědět: Mezi testováním Ad-hoc a průzkumným testováním existuje několik rozdílů.

Podívejme se na rozdíly v následující tabulce:

Otázka č. 17) Proč je upřednostňováno testování automatizace před manuálním testováním?

Odpovědět: Jak testování automatizace, tak ruční testování mají ve světě testování svůj význam a existenci.

Níže jsou uvedeny některé důležité aspekty, díky nimž je upřednostňováno testování automatizace před manuálním testováním:

• Ke spuštění testu lze použít pokaždé stejný testovací skript, takže testování automatizace je považováno za nejspolehlivější a nejúčinnější.
• Nejvýhodnější v případě regresního testování a opakovaného provádění.
• Testování automatizace je považováno za nákladově efektivní v případě dlouhodobého provádění, a zajišťuje tak lepší kvalitu softwaru.
• Testovací skripty jsou opakovaně použitelné, rychlé a výsledky vidí všichni.
• Nástroje používané k testování automatizace jsou ve srovnání s manuálním přístupem rychlejší a spolehlivější.

Některé další faktory však určují, že před automatickým testováním je upřednostňováno testování automatizace. Výše uvedené jsou hlavní faktory.

Otázka č. 18) Co rozumíte pod pojmem „Účinnost testu“ a „Účinnost testu“?

Odpověď: Účinnost testu lze definovat jako výpočet počtu zdrojů a testovacího kódu spotřebovaných k provedení nebo řekněme k provedení konkrétní funkce. Určuje také počet zdrojů použitých při vytváření softwarového produktu.

To lze určit podle vzorce:

Účinnost testu = (Počet vyřešených závad / celkový počet předložených závad) * 100

Účinnost testu lze definovat jako míru vyhodnocení testovacího prostředí a jeho vlivu na softwarovou aplikaci. Zde se hodnotí reakce zákazníků, když je splněn požadavek aplikace.

To lze určit podle vzorce:

Účinnost testu (Počet nalezených vad / Počet provedených testovacích případů)

Otázka č. 19) Vysvětlete proces přizpůsobení projektu.

Odpovědět: Přizpůsobení projektu je konzistentní a průběžný proces, který zajišťuje, že výkon projektu je správný a je v souladu s obchodními požadavky. Celý proces zahrnuje kontrolu a úpravu dat projektu podle aktuálních provozních potřeb organizace.

Proces kontroly se provádí na úrovni organizace, ale implementace krejčovských plánů se provádí na úrovni projektu. Hlavním cílem a požadavky organizace, stejně jako vztahy se zákazníky a uživateli, jsou dva hlavní faktory, které by měly být v procesu brány v úvahu.

Několik aspektů podle organizačních cílů v procesu přizpůsobení je:

• Projektový přístup
• Strategie
• Příslušné kontroly a procesy
• Role a odpovědnosti

Otázka č. 20) Jak rozlišujete mezi prioritou a závažností vady v rámci projektu?

Odpovědět: „Priorita“ i „Závažnost“ jsou přiřazeny k chybě pro kategorizaci problémů / chyb v pořadí, ve kterém mají být brány k opravě. Ty jsou založeny na různých faktorech.

Pojďme pochopit více spolu s jejich rozdíly v níže uvedené tabulce:

Otázka č. 21) Proč je u jakékoli aplikace nutné provádět testování výkonu?

Odpovědět: V jednoduchém jazyce se provádí testování výkonu, aby se určilo chování a reakce aplikace v různých situacích. To pomáhá shromažďovat informace týkající se stability aplikace, škálovatelnosti, rychlosti atd.

Důvody pro testování výkonu lze pochopit z následujících bodů:

• Určuje dobu odezvy a výkon komponenty aplikace pod pracovní zátěží.
• Vypočítá se doba odezvy na aktivitu uživatele.
• Vyžaduje zkušené programátory s rozsáhlým technickým jazykem.
• Určuje chování aplikace při zatížení, tj. Kdy se okamžitě zvýší počet uživatelů.

Otázka č. 22) Co je testování založené na specifikacích?

Odpovědět: Jak název sám definuje, testování založené na specifikacích se provádí na základě specifikace požadavků aplikace, kde funkční specifikace slouží jako základ provedených testů.

Tato forma testování je stejná jako „testování černé skříňky“, kdy uživatel zadá více dat a poté je sledován výstup. Je vhodné na všech úrovních testování se specifikací a plánem zkoušek.

Otázka č. 23) Vysvětlete CMMI.

Odpovědět: CMMI znamená Capability Maturity Model Integration. Tento model vyvinul Software Engineering Institute (SEI). Je založen na principu, že kvalitu určují procesy spojené s řízením a vývojem produktu nebo systému.

Poskytuje také pokyny pro zlepšování procesů pro produkt nebo dokonce celou organizaci.

CMMI je rozdělena do 5 úrovní, jak je uvedeno níže:

• Úroveň 1: Počáteční
• Úroveň 2: Podařilo se
• Úroveň 3: Definována
• Úroveň 4: Kvantitativně spravováno
• Úroveň 5: Optimalizováno

Otázka č. 24) Vysvětlete výhody implementace CMMI.

Odpovědět: Implementace CMMI má několik výhod.

Jsou uvedeny takto:

• Poskytuje podrobné pokrytí a podávání zpráv o životním cyklu produktu, a tím pomáhá při zlepšování procesů.
• Stávající standardy organizace, jejich procesy a postupy se zlepšují jako součást implementace CMMI.
• V důsledku implementace CMMI dochází ke zvýšení včasného doručování i spokojenosti zákazníků.
• Vede také k efektivní správě a zvýšeným úsporám nákladů, protože existuje včasná detekce chyb.

Otázka č. 25) Přihlaste se k některým nástrojům pro testování automatizace.

Odpovědět: Některé z nástrojů pro testování automatizace jsou uvedeny níže:

• Selen
• voda
• Větrný mlýn
• MÝDLO
• Telur

Otázka č. 26) Můžeme v testování jednotek provést regresní testování?

Odpovědět: Rozhodně. Regresní testování má otestovat nežádoucí vadu, která mohla být zavedena do kódu jako vedlejší účinek při opravě dalších vad. Testování jednotek je provádění testu spuštění malé nezávislé a jednotlivé části kódu.

Regresní testování lze provádět na jakékoli úrovni, a to od testování jednotky přes integrační testování až po konečné přejímací testování. Regresní testování je testování založené na perspektivě, zatímco testování jednotky je přístup na úrovni (zdola nahoru, shora dolů).

Otázka č. 27) Jaký je rozdíl mezi kouřovým testem a testem zdravého rozumu?

Odpovědět:

• Testování kouře je testování starých prominentních funkcí nebo stávajících funkcí sestavení, zatímco testování příčetnosti je ověřování nově přidaných modulů, opravených defektů v sestavení.
• Nejprve proběhne kouřové testování a poté následuje testování zdravého rozumu.
• Testování kouře zahrnuje testování kritických funkcí zajišťovaných softwarem, takže se rozšiřuje na celý software. Testování zdravého rozumu je naopak zúženo pouze na nedávno přidané moduly a je testováno do hloubky.

Otázka č. 28) Jaké jsou vaše každodenní činnosti jako manuálního testeru ve vaší kanceláři?

Příručka: První věc, kterou zkontroluji v mém systému, je obnovit na palubní desce stav požadavků / vylepšení nebo chyb v aktuální iteraci. Poté následují každodenní volání scrumů a hlášení, diskuse a brainstormingové relace pro definování pomocí testovacích scénářů a testovacích případů.

Tyto případy jsou poté provedeny po přepracování podle kontroly. Liaising s klienty pro nefunkční požadavky je také jednou z hlavních činností na mém talíři.

Q # 29) Jaké jsou vaše každodenní aktivity jako člena testeru automatizace ve vaší kanceláři?

Automatizace: Můj den začíná každodenním setkáním se stavem, které pojednává o výsledcích automatizace včerejška, pro případ, že jsem na nové verzi spustil dávku testovacích případů.

Cyklus provádění lze nazvat Kontrola stavu, abyste zjistili, jak zdravé je sestavení.

Následuje hlášení chyb na základě selhání skriptu, změny designu ve funkčnosti; udržovat skripty / knihovny nebo funkce, automatizovat a odevzdávat nový skript pro nové požadavky a v případě potřeby novou funkci v knihovně funkcí.

Někdy je nutné testovací skripty znovu spustit jednotlivě, aby se pomocí automatizace našly regresní defekty, a také je přidat do testovací sady.

Otázka č. 30) Jak rozlišujete mezi požadavkem a vadou a vylepšením?

Odpovědět : TO požadavek je příběh uživatele, který je nezbytně nutné implementovat, otestovat a doručit.
An zvýšení je přidaná nebo improvizovaná funkce ke stávajícímu.
NA přeběhnout je spíše úplná odchylka od očekávaných uživatelských příběhů.

Také pokud vada odhalí určitou oblast požadavku, která není uvedena, pokud není ve specifikaci uvedeno jinak, lze ji také nazvat jako požadavek nebo jeho část.

Otázka č. 31) Co děláte, když váš vývojář popírá opravu chyby, kterou jste nahlásili?

Odpovědět : Důležitým faktorem, který rozhoduje o odstranění vady, je jí přiřazená „Priorita“. Pokud má vada vysokou prioritu, zátka show, která blokuje hlavní funkce a je důsledně reprodukována, je nutné ji v sestavení opravit.

Totéž je třeba efektivně sdělit vývojářům, protože společně testeři a vývojáři přispívají ke kvalitě dodávaného produktu.

Další aspekty, které mohou vývojáře přesvědčit, aby chybu opravil během krátké doby, jsou kvalitní hlášení chyby a nutí vývojáře pochopit, že oprava chyby má ve vydání zásadní význam.

Q # 32) Co děláte, když váš vývojář popírá, že to, co jste podali, JE CHYBA?

Odpovědět : Nejdůležitější fází životního cyklu defektu je „Odmítnuto“, což znamená, že protokolovaná zpráva o incidentu není platná. Dokument s obchodními požadavky, který uvádí požadavky, může pomoci porozumět softwaru a tím i povaze hlášené události.

Analyzujte chybu a vystavte svá zjištění o chybě vývojáři a týmu. Pokud se jedná o vadu, nikdy ji nezapomeňte zaznamenat. Někdy testeři musí poskytnout analýzu mezer a předložit ji vývojářům. Pokud to nevyřeší konflikty, měli by se do toho pustit starší lidé v týmu.

Otázka č. 33) Co je na prvním místě Re-testování nebo regresní testování?

Odpovědět : Re-testování je na prvním místě, protože je to opětovné spuštění kódu, zjednodušeně řečeno, jedná se o opakované provádění předdefinovaných kroků. Po opravě kódu to nemusí být nutné. Ale regresní test má posoudit vedlejší účinky vyřešené vady.

Určité vyřešení jedné vady a přidání další do kódu není účelem procesu testování. Nejlepší nálezy a nejlepší úlovky testerů jsou obvykle regresní vady. Sestava by nikdy neměla být vydána, aniž by byla regresně testována.

Otázka č. 34) Jaká je alternativa k beta testování?

Odpovědět : Beta testování probíhá na webu klienta s nejmenším zapojením vývojářů a zaznamenává selhání ve skutečném produkčním prostředí. Pokud takový postup neprovádí firma, pak může být bezpečnějším nápadem odeslat produkt nejprve klientům, kteří nejsou ve frontě, aby získali nejnovější verzi.

Několik dní mohou někteří servisní konzultanti v premise klientů používat software, zaznamenávat a monitorovat aktivity, které zajišťují stabilitu vydání v jejich prostředí, takže i když je velká chyba odstraněna, aby mohla být opravena, může být testována dříve jeho doručení cílovému klientovi. Dalším přístupem je zaměněné testování požadavků v týmu pro objektivní testování.

Q # 35) Jaké jsou nevýhody agilní implementace / metodiky, které jste čelili?

Odpovědět : Nevýhody jsou následující:

1. Sprinty jsou obvykle velmi omezené.
2. Dokumentace není prioritou
3. Přepínání mezi PBI (položky nevyřízeného produktu) může být časté.

Q # 36) Proč je analýza dopadu důležitá?

Odpovědět : Abychom si mohli na základě rizik procvičovat, je třeba provést analýzu dopadů. Tímto způsobem lze testovací případy navrhnout tak, aby všechny závažné chyby, kritické z pohledu zákazníka, mohly být vyřešeny dříve. Je třeba se postarat o dobrou studii o podnikání, potřebách klienta a jeho používání softwaru.

Například, nejdůležitějším rizikem spojeným se softwarem v bankovní doméně je Zabezpečení. Jakákoli nová forma přidaná k již existujícímu softwaru může být zranitelná. Dobré množství testování zabezpečení se doporučuje přidáním správných odkazů, přesměrování a navigace na správnou stránku, případně instalací serveru proxy.

Otázka č. 37) S pomocí příkladu každé testování výkonu, zátěžové testování a zátěžové testování?

Odpovědět : Nejlepším případem, který lze použít, je živý web.

Testování výkonu provádí se k ověření závad v systému, když je proveden stav podobný scénáři v reálném čase. Není nutné provádět za stresových podmínek. Výstupy testování výkonu pomáhají zjistit, zda je systém připraven jít do výroby.

U jednoduchého postupu rezervace lístků mohl problém s výkonem způsobit pomalost. Například některý dotaz pomocí spojení je o něco pomalejší, když implementoval zbytečnou klauzuli nebo nevhodně ukládá data v databázi.

Stresové testování je typ testování výkonu, který se provádí uvedením softwaru do extrémních podmínek (velká a nerozložená zátěž, omezené výpočetní zdroje, vysoká souběžnost).

Pokud systém vykazuje určité chování, jako jsou data ztracená nebo poškozená, prostředek využívaný i po odstranění stresu, nereagování nebo neošetřené výjimky, znamená to, že při zátěžovém testování selhalo. Výsledkem může být někdy selhání disku, zbytečné zvýšení počtu GDI.

Například, Pokud by web hostovaný na stroji, který již spotřebovává obrovskou paměť nebo jej bombarduje opakovanými požadavky, neměl by vás zavěsit ani odhlásit.

Zátěžové testování sleduje chování systému a neustále zvyšuje zátěž systému, dokud není dosaženo prahové hodnoty. Modely pracovního vytížení, metriky a úrovně zátěže jsou obvykle vstupem do zátěžového testování.

Například, čas na získání dostupnosti místa ve vlaku se postupně zvyšuje, když se čas rezervace Tatkal kvóty přiblíží, protože počet uživatelů, kteří se poté přihlásili do systému, se zvyšuje s tím, že doba rezervace Tatkal se blíží 10:00 nebo 11:00.

Otázka č. 38) Co bylo jednou z vašich největších výzev při provádění regresního testování?

Odpovědět : Při provádění regresního testování mohou být různé výzvy.

• Opakované provádění testů nemusí být pro testery tak vzrušující.
• Časově náročné, protože někdy takové testování vyžaduje přemýšlení.
• Napadená obchodní hodnota.
• Nesprávný výběr regresních testovacích případů může přeskočit hlavní regresní defekt, který má být nalezen.
• Reprodukce vady produkce se proto stává nekonzistentní.
• Velká sada k provedení.

Otázka č. 39) Pokud budete požádáni o zdokumentování testovacích scénářů, testovacích případů, testovacích plánů, testovací strategie, s čím začnete a v jakém pořadí bude následovat zbytek?

Odpovědět : Sekvence bude Testovací strategie, Testovací plán, Testovací scénáře a nakonec Testovací případy.

Q # 40) Co když mi chybí dokumentace některého z výše uvedených? Řekněme, že mi chybí dokumentace plánu zkoušek, jaké to bude mít důsledky?

Odpovědět : Pokud zmeškáme zdokumentování Testovacího plánu, bude existovat prázdnota pro rozsah testování jeho objektivního přístupu a důrazu na testování. Bude pak těžké určit vlastnosti, které se mají testovat, techniky testování, vyhovět nebo nevyhovět kritériím a nakonec hlavní riziko spojené s testováním.

Q # 41) Jak byste začali testovat sestavení, které jste nedávno dostali: Existuje nějaký přístup, který používáte, např. nejprve začít s kouřovým testem, poté s testem zdravého rozumu

Odpovědět : Testování kouře> Testování zdravého rozumu> Průzkumné testování> Testování funkčnosti> Regresní testování a konečné ověření produktu.

Q # 42) Vysvětlete formát zprávy o chybě, kterou jste sledovali?

Odpovědět :

Hlášení o chybě by mělo obsahovat následující informace:

• ID chyby
• Mapování na požadavek / vylepšení / stávající chyba
• Shrnutí / název chyby
• Verze produktu
• Přednost
• Konfigurace (specifikace systému)
• Předpoklady
• Kroky
• Očekávaný výsledek
• Skutečný výsledek
• Protokoly. Snímky, videoklipy
• Postavení
• Další poznámky

Otázka č. 43) Jak vybíráte případy regresního testu nebo tvoříte sadu regresních testů?

Odpovědět : Ano. Toto je výsledek analýzy dopadů. Jedná se o jednoduché mapování funkcí používaných nebo přístupných v různých oblastech, které testujete, jeho integraci s dalšími funkcemi a v celém rozsahu jako testování systému od konce k konci nebo toku.

Můžete také vyzvednout vady, které byly dříve uloženy pro stejnou funkčnost v předchozích sestaveních. V ideálním případě by jedna vada měla být regresně testována pomocí alespoň pěti různých testovacích případů, které používají tuto funkci.

Q # 44) Můžete přijít s příkladem následujících vad

• Porucha s vysokou prioritou s nízkou prioritou
• Vada s vysokou prioritou a nízkou závažností

Odpovědět : Vada, která zhroutí aplikaci, když je reprodukována pouze v daném časovém razítku v konkrétním operačním systému, může být vada vysoké závažnosti a vady nízké priority.

Vada, která je podána proti pohledu, který se neotevře dvojitým kliknutím, ale otevře se pravým tlačítkem, může mít vadu s vysokou prioritou a nízkou závažností.

Otázka č. 45) Napište jeden efektivní testovací případ, abyste otestovali, zda je daný papír bílý papír?

Odpovědět: Pokud barva zdrojového inkoustu, kterou píšete na bílý papír, zůstává stejná, je papír bílý. Například pokud píšete na bílý papír s červeným inkoustem, barva inkoustu zůstane v peru červená a na papíře se objeví také červená.

Poznámka: Existuje mnoho dalších odpovědí na tuto otázku. Na jakoukoli takovou platnou odpověď můžete přijít se základní logikou.

Otázka č. 46) Co je to Charta testování?

Odpovědět: Testování relace prováděné na základě cílů a agend uvedených v listině před zahájením testování je známé jako testování listiny.

Testování se zde provádí ve fixním časovém úseku s menším zaměřením na dokumentaci a větším zaměřením pouze na testování. Jedná se o jinou variantu průzkumného testování, při které testovací inženýři ověřují software v časovém rámci ( Například, pouhé 2 hodiny) na základě vyvinuté heuristiky.

Q # 47) Jaký je váš přístup, když máte vydání s vysokou prioritou, které má být dodáno ve velmi krátké době?

Odpovědět: V takových případech může být dobře promyšlený plán přínosný.

K usnadnění testování ve scénáři nedostatku času lze provést následující: -

• Používání existujících aktualizovaných automatizačních skriptů pro provádění regresního testování.
• Testování scénářů založených na toku končí každý konec.
• Provádění testovacích případů s vysokou prioritou a pokud to čas dovolí, přepněte na případy s nižší prioritou.
• Opětovné testování chyb s vysokou prioritou u předchozích verzí.
• Rychlé testování softwaru
• Vývojáři mohou být požádáni o spuštění testů jednotek, aby získali větší pokrytí při testování.

Otázka č. 48) Psát testovací případy na jakékoli zařízení / předmět v okolí (Příklad: židle)?

Odpovědět: Rada by zde byla: Vždy začněte s požadavky na shromažďování. Ukazuje vaši vyspělost směrem k životnímu cyklu vývoje softwaru. Po výběru objektu můžete klidně klást otázky.

V tomto případě:-

• O jaký typ židle se jedná? Kancelářská židle, studijní stůl, rozkládací židle, jídelní židle, pohodlná židle?
• Jaký materiál se používá k výrobě židle - dřevo, ocel, plast, čalounění?
• Zeptejte se na rozměry (výška, hmotnost podle typu židle).
• Zeptejte se na dostupnost. A na základě toho začněte koncipovat vaše případy.

Zkušební případy by se lišily pro každý typ židle, což je lepší ponechat pro vaše schopnosti myšlení ( Například, účel židle, rozměry podle typu židle, přenosná-nepitná, lehká, možnosti nákupu).

Pro každou židli a testovacím případem výkonu může být: odvodit pevnost v tahu nebo maximální nosnost.

Q # 49) Lze vše automatizovat?

Odpovědět: - Do jisté míry ano. Ale automatizační nástroje, stejně jako jiný software, mají svá omezení. Testovaný software nebo testovaná aplikace se budou stále upgradovat.

Neexistuje tedy žádná záruka, že testování softwaru může probíhat bez ručního zásahu. Koneckonců, nástroj je stejně chytrý jako tester. Je to jen testování softwaru a další software. Je to kód / skripty / knihovny, které musí být dostatečně inteligentní, aby testovaly a nacházely vady.

Závěr

Doufám, že vám toto cvičení pomůže zahřát se na několik otázek a dá vám skvělý start do vašich rozhovorů a zdokonalí vaši důvěru při odpovídání na otázky. Mohou také existovat další otázky založené na scénářích, které mohou vycházet z vašeho životopisu / profilu.

Proto je vždy vhodné procvičovat si falešný rozhovor s vlastní rukou, aby se rozhovor ukázal být přínosem jak pro tazatele, tak pro kandidáta. Pamatujte, že analytik kvality je více než testovací technik, jehož zpětná vazba je důležitá nejen pro kvalitu produktu, ale také pro postup, který se používá při testování softwaru.

Děkuji a hodně štěstí při rozhovorech!

Doporučené čtení

• Dotazy a odpovědi na pohovor
• 25+ nejoblíbenějších dotazů a odpovědí na rozhovor s ADO.NET
• 25 nejlepších agilních testovacích otázek a odpovědí na rozhovor
• Spock Interview Otázky s odpověďmi (nejoblíbenější)
• ETL Testing Interview Otázky a odpovědi
• 20 nejoblíbenějších otázek a odpovědí na rozhovor s TestNG
• Top 30+ populárních otázek a odpovědí na rozhovor s okurkou
• Top 50 nejoblíbenějších dotazů a odpovědí na rozhovor s CCNA