40+ populárnych otázok a odpovedí na otázky týkajúce sa testu analytikov QA (ZOZNAM 2021)

40 popular test qa analyst interview questions

Najčastejšie kladené otázky a odpovede na otázky týkajúce sa testu / zabezpečenia kvality:

Pri rozhodovaní o kariére, v ktorej chcete byť, nie je rozhodujúcim faktorom iba ten, na ktorom si myslíte, že ho môže baviť pracovať.

Ale byť v tejto kategórii si vyžaduje veľa zručností, porozumenie zodpovednosti a nevyhnutné pracovné povinnosti pre kariéru, ktorú ste si vybrali. To isté platí pri výbere kariéry analytika QA. Vyžaduje to nielen to, aby ste boli dobrým testerom, rýchlym učiacim sa, mimoriadnym mysliteľom, ale tiež to vyžaduje komplexné riešenie problémov.

Aj keď vyššie uvedené vlastnosti nie sú dosiahnuté okamžite, zjavne to vyžaduje skúsenosti a dni tvrdej práce.

Tento článok sa bude zaoberať všetkými aspektmi, ktorých znalosť je povinná byť analytikom QA. Najčastejšie otázky a odpovede na otázky týkajúce sa pohovoru s analytikom QA vám poskytnú jasnú predstavu o príprave vášho pohovoru.

Populárne otázky na rozhovor s analytikom QA

Otázka 1) Aké sú zodpovednosti analytika QA?

Odpoveď: QA Analyst je ten, ktorý zaisťuje, že boli urobené všetky možné opatrenia na testovanie každej funkcie softvérového riešenia, a to funkčne aj technicky.

Medzi hlavné zodpovednosti QA Analyst možno zaradiť nasledujúce:

• Vykonajte a spravujte všetky činnosti tak, aby boli splnené ciele plánu testov.
• Pre vývoj produktu zvoľte procesy vysokej kvality.
• Mali by byť schopní analyzovať požiadavky a dokumentovať postupy.
• Dokumentujte a znova overte všetky chyby. Nastavte prioritu a závažnosť porúch.
• Mali by byť schopní vytvárať, dokumentovať a udržiavať testovacie prípady.
• Analýza výsledkov skúšky.

Otázka 2) Ako chápete plán testovania?

Odpoveď: Keď máte jasnú predstavu o tom, čo, kedy, ako a kto, potom sa všetko uľahčí. To isté platí aj pre testovanie softvéru, keď je plán testovania dokumentom, ktorý pozostáva z rozsahu, prístupu, zdrojov a osnovy testovacieho projektu, ako aj z činností na sledovanie postupu projektu.

Plán skúšky je záznamom procesov, ktoré zahŕňajú:

• Testovacie úlohy
• Testovacie prostredie
• Dizajnové techniky
• Kritériá vstupu a výstupu
• Akékoľvek riziká atď.

Otázka 3) Zaraďte prioritu testovacích úloh definovaných tímom QA do vývoja produktu.

Odpoveď: Priorita testovacích úloh je definovaná takto:

• Pripravuje sa plán testov, ktorý pozostáva z náčrtu a rozsahu projektu testovania.
• Testovacie prípady sú pripravené na pokrytie všetkých hlavných a vedľajších funkcií dátami potrebnými na testovanie.
• Vykonanie testovacích prípadov podľa funkcionalít implementovaných s nadchádzajúcimi zostavami testovacieho projektu v testovacom cykle.
• Hlásenie chýb s opätovným overením a sledovaním jeho priebehu.
• Príprava súhrnu správy o vykonaní testu.

Otázka č. 4) Zaradiť niektoré z kľúčových výziev, ktorým čelia pri vykonávaní Testovania softvéru.

Odpoveď: Pretože hovoríme, že úplné testovanie nemožno nikdy dosiahnuť, je s ním spojené niekoľko výziev. Či už je to malý alebo zložitý problém, pri testovaní softvéru ľubovoľného projektu čelia niektorým výzvam.

Nižšie je uvedených niekoľko kľúčových výziev:

• Nedostatok kvalifikovaných testerov, ktorí zvyčajne čelia problému povedomia o subjekte, ako aj nedostatku dobrých znalostí o podnikaní zákazníka.
• Za faktor sa považuje aj čas, pretože testeri sa zvyčajne zameriavajú skôr na pokrytie úloh než na pokrytie testov testovaním kvality, ak existuje obrovský zoznam úloh, ktoré je potrebné dokončiť.
• Rozhodnúť, ktorý testovací prípad sa musí vykonať ako prvý a prioritne. Spravidla sa to dosiahne skúsenosťou z práce.
• Správne pochopenie požiadaviek, ktoré môže viesť k tomu, že vaše testovacie úsilie bude nulové, ak bude požiadavka nesprávne pochopená.
• Nedostupnosť najlepších nástrojov, ktoré sú potrebné na dokončenie testovania s kratším časom a vyššou účinnosťou.
• Riešenie vzťahov medzi testermi a vývojármi pomocou dobrých komunikačných a analytických schopností.

Otázka č. 5) Definujte testovanie prípadov.

Odpoveď: Testovanie prípadov použitia možno definovať ako funkčnú techniku ​​testovania čiernej skrinky, ktorá zachytáva sériu interakcií, ktoré sa vyskytli medzi „aktérmi“ a „systémom“. Aktérov tu zastupujú používatelia a ich interakcie.

Charakteristiky testovania prípadov použitia sú uvedené nižšie:

• Funkčné požiadavky projektu sú usporiadané.
• Zaznamenáva cestu alebo scenáre od začiatku do konca.
• Môže pokrývať chyby integrácie, t. J. Chyby, ktoré sa vyskytli v dôsledku interakcie medzi rôznymi komponentmi.
• Opisuje hlavné toky aj mimoriadny tok udalostí.
• Všetky predbežné podmienky, ktoré sú potrebné na fungovanie prípadu použitia, by mali byť špecifikované skôr.

Otázka č. 6) Definujte stratégiu testovania.

Odpoveď: Súbor pokynov alebo testovacích prístupov, ktoré zvyčajne vykonáva projektový manažér na určenie koncepcie testu a všeobecného testovacieho prístupu, je definovaný ako stratégia testovania. Nachádza sa ako malá časť plánu testov a je využívaná vo viacerých projektoch.

Sledujú sa rôzne prístupy k testom na základe faktorov, ako je povaha a oblasť produktu, riziko zlyhania produktu, odbornosť pri práci s navrhovanými nástrojmi atď.

Tieto prístupy sú ďalej kategorizované takto:

• Proaktívny prístup , kde prístup testovacích návrhov začína pred vytvorením zostavy. Pomáha tak nájsť a opraviť chyby pred zostavením.
• Reaktívny prístup , kde sa testovací prístup začne po dokončení návrhu a kódovania testu.

Otázka č. 7) Vysvetlite rozdiel medzi kontrolou kvality a zabezpečením kvality.

Odpoveď: 'Kontrola kvality' a „Zabezpečenie kvality“ sú dva hlavné pojmy používané v súvislosti s akýmkoľvek testovacím projektom alebo produktom. Testéri, ktorí sú v tejto oblasti nováčikom, zvyčajne nechápu skutočný rozdiel medzi nimi.

Pochopme rozdiel pomocou nižšie uvedenej tabuľky.

Otázka č. 8) Kedy je podľa vás vhodný čas na začatie QA v projekte?

Odpoveď: Podľa životného cyklu vývoja softvéru (SDLC) sa fáza testovania vykonáva po dokončení fázy „implementácie a kódovania“. Ale v dnešnom scenári je na dosiahnutie najlepších výsledkov potrebné zahájiť QA projektu alebo produktu na začiatku projektu.

Dodržiavanie tohto prístupu povedie k hlavným výhodám uvedeným nižšie:

• Včasné plánovanie procesov na splnenie očakávaní zákazníkov.
• Dobrá a zdravá komunikácia medzi tímami.
• Poskytuje dostatok času, ktorý je potrebný na nastavenie testovacieho prostredia.
• Umožňuje včasnú kontrolu a schválenie plánov testov.

Otázka č. 9) Odlišujte procesy overovania a overovania.

Odpoveď: Procesy overovania a overovania sú zvyčajne určené dvoma známymi otázkami, t. J. „ Budujeme systém správne? “ a 'Budujeme správny systém?' .

V nasledujúcej tabuľke si ukážeme ďalší rozdiel medzi týmito dvoma procesmi:

Otázka č. 10) Vysvetlite výhody deštruktívneho testovania.

Odpoveď: Deštruktívne testovanie je definované ako forma testovania, ktorú vykonáva testovací tím s cieľom určiť bod zlyhania produktu pri rôznych zaťaženiach, t. J. Vyhodnotiť štrukturálny výkon aplikácie s cieľom určiť jeho pevnosť, húževnatosť, tvrdosť alebo povedzme robustnosť.

Nižšie sú uvedené výhody deštruktívneho testovania:

• Zistí sa slabosť návrhu aplikácie.
• Určte životnosť aplikácie.
• Pomáha znižovať náklady a zlyhania.

Otázka č. 11) Ako sa líši opakované testovanie od regresného testovania?

Odpoveď: Medzi opakovaným testovaním a regresným testovaním je niekoľko rozdielov.

To sa dá ľahko pochopiť z nasledujúcej tabuľky:

Otázka č. 12) Čo viete o testovaní na základe údajov?

Odpoveď: Každému automatizačnému testeru je úplne jasné, že skripty automatizačného testu pokrývajú iba oblasť testovanej aplikácie so zaznamenanou postupnosťou akcií používateľa. Za normálnych okolností tieto akcie neprodukujú žiadnu chybu, pretože iba vstupné údaje sa vykonávajú za podmienok, ktoré sme zadali počas záznamu.

Tu prichádza na rad testovanie na základe dát, kde chceme, aby aplikácia fungovala podľa očakávania pre akýkoľvek typ vstupných hodnôt. Z tohto dôvodu nie sú údaje potrebné na testovanie na základe dát napevno, ale testovacie skripty berú údaje z dátových zdrojov, ako sú súbory CSV, zdroje ODBC atď.

Ak to zhrnieme, testovanie založené na údajoch vykonáva v cykle nasledujúce akcie:

webová stránka, ktorá vám umožňuje sťahovať youtube videá

• Berie vstupné testovacie dáta z úložiska.
• Údaje zadané v aplikácii na vykonávanie akcií.
• Overte skutočné výsledky s očakávanými.
• Rovnaké kroky opakujte s novými vstupnými testovacími údajmi.

Otázka č. 13) Čo je matica sledovateľnosti? Je to potrebné pre každý projekt?

Odpoveď: Matica vysledovateľnosti v ktoromkoľvek projekte je prostriedok na sledovanie postupu projektu v súvislosti s implementáciou nových funkcionalít, vylepšením existujúcich funkcionalít atď. Prostredníctvom matice vysledovateľnosti môžete vždy sledovať priebeh projektu so všetkým zachovaným aspektom podľa dátum.

Matica sledovateľnosti požiadavky pozostáva z nižšie uvedených parametrov, ktoré sú v skutočnosti podľa dokumentu so špecifikáciou požiadavky.

Medzi parametre matice sledovateľnosti požiadaviek patria:

• Každá časť dokumentu s požiadavkami je bodom, ktorý sa má zahrnúť do RTM (Matica sledovateľnosti požiadaviek).
• Nadpis každého bodu je nadpisom každej sekcie v špecifikácii požiadavky.
• Zodpovedajúcim každému bodu sú uvedené ID testovacích prípadov, ktoré sú napísané pre konkrétnu časť.
• BUG / ID novej funkcie je tiež uvedená v každej časti.
• Najdôležitejším bodom je, že sa tiež udržuje sledovanie prvku, v ktorom bolo implementované zostavenie projektu a jeho vlastnosti.
• Ďalším parametrom je, či je sekcia úplne otestovaná alebo či je stále v testovacom stave.

Otázka č. 14) Popíšte výhody agilného testovania.

Odpoveď: Ako tester sa zameriavame na dodanie kvalitného produktu za kratší čas pochopením požiadaviek koncového používateľa a čo je najdôležitejšie, bez defektov zo strany koncového používateľa. Tu prichádza na rad agilné testovanie, ktoré sleduje princíp agilného vývoja softvéru a rýchlo potvrdzuje požiadavky klienta.

Nižšie sú uvedené výhody agilného testovania:

• Do testovania je zahrnutý krížovo funkčný agilný tím, ktorý zase prináša výsledky v častých intervaloch.
• Šetrí veľa času a peňazí.
• Zahŕňa menej dokumentácie a čas od času spätnú väzbu od koncového používateľa.
• Do osobnej komunikácie je zapojený nielen tester, ale celý tím vrátane manažéra, zákazníka a vývojára.
• Výsledkom každodenných stretnutí je, že problémy je možné vopred dobre určiť.
• Zvýšenie produktivity tímu a lepšie pochopenie technických aspektov projektu.

Otázka č. 15) Čo je negatívne testovanie?

Odpoveď: Negatívne testovanie je metóda zabezpečujúca udržanie stability produktu alebo aplikácie alebo povedzme nezlyhanie pri neočakávanom vstupe. Hlavným účelom tejto formy testovania je aplikácia overená proti možným neplatným vstupným údajom.

Táto forma testovania je tiež známa ako „Testovanie poruchy“ alebo „testovanie chybovej cesty“ a jeho hlavným účelom je skontrolovať spoľahlivosť funkcie aplikácie pri negatívnych scenároch. Odhaľuje tiež softvérovú slabosť, zisťuje chyby a poskytuje jasnú predstavu o poškodení údajov.

Otázka č. 16) Odlíšiť ad hoc testovanie a prieskumné testovanie?

Odpoveď: Medzi testovaním ad hoc a prieskumným testovaním je niekoľko rozdielov.

Pozrime sa na rozdiely v nasledujúcej tabuľke:

Otázka č. 17) Prečo je preferované automatické testovanie pred manuálnym testovaním?

Odpoveď: Testovanie automatizácie aj manuálne testovanie majú vo svete testovania svoj význam a existenciu.

Ďalej uvádzame niekoľko dôležitých aspektov, vďaka ktorým sa uprednostňuje testovanie automatizácie pred manuálnym testovaním:

• Na spustenie testu je možné použiť vždy ten istý testovací skript, takže testovanie automatizácie sa považuje za najspoľahlivejšie a najefektívnejšie.
• Najvýhodnejšie v prípade regresného testovania a opakovaného vykonania.
• Automatizačné testovanie sa považuje za nákladovo efektívne v prípade dlhodobého vykonania, a tým zaručuje lepšiu kvalitu softvéru.
• Testovacie skripty sú opakovane použiteľné, rýchle a výsledky vidí každý.
• Nástroje používané na testovanie automatizácie sú v porovnaní s manuálnym prístupom rýchlejšie a spoľahlivejšie.

Niektoré ďalšie faktory však určujú, že pred automatickým testovaním sa uprednostňuje testovanie automatizácie. Vyššie uvedené sú hlavné faktory.

Otázka č. 18) Čo rozumiete pod pojmami „Účinnosť testu“ a „Účinnosť testu“?

Odpoveď: Účinnosť testu možno definovať ako výpočet počtu zdrojov a testovacieho kódu spotrebovaných na vykonanie alebo povedzme na vykonanie konkrétnej funkcie. Určuje tiež počet zdrojov použitých pri vytváraní softvérového produktu.

To možno určiť vzorcom:

Účinnosť testu (Počet vyriešených chýb / celkový počet predložených chýb) * 100

Účinnosť testu možno definovať ako mieru hodnotenia testovacieho prostredia a jeho vplyvu na softvérovú aplikáciu. Tu sa hodnotí reakcia zákazníka, keď sú splnené požiadavky aplikácie.

To možno určiť vzorcom:

Účinnosť testu (Počet nájdených chýb / počet vykonaných testovacích prípadov)

Otázka č. 19) Vysvetlite proces prispôsobenia projektu.

Odpoveď: Prispôsobenie projektu je konzistentný a nepretržitý proces, ktorý zaisťuje, že výkonnosť projektu je správna a je v súlade s obchodnými požiadavkami. Celý proces zahŕňa kontrolu a úpravu údajov o projekte podľa aktuálnych prevádzkových potrieb organizácie.

Proces kontroly sa vykonáva na organizačnej úrovni, ale implementácia plánov na mieru sa vykonáva na úrovni projektu. Hlavným cieľom a požiadavkami organizácie, ako aj vzťahmi so zákazníkmi a používateľmi sú dva hlavné faktory, ktoré by sa mali v procese brať do úvahy.

Niekoľko aspektov podľa cieľov organizácie v rámci procesu krajčírstva je:

• Projektový prístup
• Stratégie
• Príslušné kontroly a procesy
• Úlohy a zodpovednosti

Otázka č. 20) Ako rozlišujete medzi prioritou a závažnosťou chyby v rámci projektu?

Odpoveď: Chyby sú priradené k prioritám aj závažnostiam na účely kategorizácie problémov / chýb v poradí, v akom sa majú opraviť. Vychádzajú z rôznych faktorov.

Poďme pochopiť viac spolu s ich rozdielmi v nasledujúcej tabuľke:

Otázka č. 21) Prečo je potrebné pre každú aplikáciu vykonať testovanie výkonu?

Odpoveď: V jednoduchom jazyku sa vykonáva testovanie výkonu, aby sa určilo správanie a reakcia aplikácie v rôznych situáciách. To pomáha zhromažďovať informácie týkajúce sa stability, škálovateľnosti, rýchlosti aplikácie atď.

Dôvody na vykonávanie testov výkonnosti možno pochopiť z nasledujúcich bodov:

• Určuje čas odozvy a výkon aplikačnej súčasti v rámci pracovného zaťaženia.
• Vypočíta sa čas odozvy na aktivitu používateľa.
• Vyžaduje skúsených programátorov s rozsiahlym technickým jazykom.
• Určuje správanie aplikácie pri zaťažení, t. J. Keď sa okamžite zvýši počet používateľov.

Otázka č. 22) Čo je to testovanie založené na špecifikáciách?

Odpoveď: Ako už samotný názov definuje, testovanie založené na špecifikáciách sa vykonáva na základe špecifikácie požiadaviek aplikácie, kde funkčné špecifikácie slúžia ako základ vykonaných testov.

Táto forma testovania je rovnaká ako testovanie „čiernej skrinky“, keď používateľ zadáva viac údajov a potom je pozorovaný výstup. Je vhodné na všetkých úrovniach testovania so špecifikáciou a plánom skúšok.

Otázka č. 23) Vysvetlite CMMI.

Odpoveď: CMMI znamená Capability Maturity Model Integration. Tento model vyvinul Software Engineering Institute (SEI). Je založená na princípe, že kvalitu určujú procesy zapojené do riadenia a vývoja produktu alebo systému.

Poskytuje tiež pokyny na zlepšenie procesov pre produkt alebo dokonca pre celú organizáciu.

CMMI je rozdelená do 5 úrovní, ako je uvedené nižšie:

• Úroveň 1: Počiatočné
• Úroveň 2: Organizovaný
• Úroveň 3: Definovaný
• Úroveň 4: Kvantitatívne riadené
• Úroveň 5: Optimalizované

Otázka č. 24) Vysvetlite výhody implementácie CMMI.

Odpoveď: Implementácia CMMI má niekoľko výhod.

Sú uvedené takto:

• Poskytuje podrobné pokrytie a správy o životnom cykle produktu, a tým pomáha pri zlepšovaní procesov.
• Existujúce štandardy organizácie, ich procesy a postupy sa zlepšujú ako súčasť implementácie CMMI.
• V dôsledku implementácie CMMI došlo k zvýšeniu včasného dodania, ako aj k spokojnosti zákazníkov.
• Vedie to tiež k efektívnemu riadeniu a zvýšeniu úspor nákladov, pretože k včasnému odhaleniu chýb dôjde.

Otázka č. 25) Prihláste sa k niektorým nástrojom na testovanie automatizácie.

Odpoveď: Niektoré z nástrojov na testovanie automatizácie sú uvedené nižšie:

• Selén
• voda
• Veterný mlyn
• MYDLO
• Telúr

Otázka č. 26) Môžeme urobiť regresné testovanie v testovaní jednotiek?

Odpoveď: Určite. Regresné testovanie spočíva v otestovaní nežiaducej chyby, ktorá mohla byť do kódu vložená ako vedľajší účinok pri opravovaní ďalších chýb. Testovanie jednotiek je vykonanie testu spustenia malej nezávislej a individuálnej časti kódu.

Regresné testovanie je možné vykonať na akejkoľvek úrovni, od testovania jednotiek až po testovanie integrácie až po konečné testovanie prijatia. Regresné testovanie je testovanie založené na perspektíve, zatiaľ čo testovanie jednotiek je prístupom na úrovni (zdola nahor, zhora nadol).

Otázka č. 27) Aký je rozdiel medzi testovaním dymu a testom zdravého rozumu?

Odpoveď:

• Testovanie dymu je testovanie starých významných alebo existujúcich funkcií zostavy, zatiaľ čo testovanie zdravého rozumu je overovanie novo pridaných modulov a opravených chýb v zostave.
• Najprv sa uskutoční testovanie dymu a potom nasleduje test príčetnosti.
• Testovanie dymu pokrýva testovanie kritických funkcií zabezpečovaných softvérom, takže sa rozširuje na celý softvér. Testovanie zdravého rozumu je na druhej strane zúžené iba na nedávno pridané moduly a je testované podrobne.

Otázka č. 28) Aké sú vaše denné aktivity ako manuálneho testera vo vašej kancelárii?

Príručka: Prvá vec, ktorú skontrolujem v mojom systéme, je obnovenie informačného panela o stave požiadaviek / vylepšení alebo chýb v aktuálnej iterácii. Po ňom nasledujú denné volania skrumáže a správy, diskusie a brainstormingové stretnutia s cieľom definovať testovacie scenáre a testovacie prípady.

Tieto prípady sa potom vykonajú po prepracovaní podľa preskúmania. Jednou z hlavných aktivít na mojom stole je tiež komunikácia s klientmi pre nefunkčné požiadavky.

Otázka č. 29) Aké sú vaše denné aktivity ako člena testera automatizácie vo vašej kancelárii?

Automatizácia: Môj deň začína denným stretnutím o stave, ktoré pojednáva o včerajších výsledkoch automatizácie, pre prípad, že by som na nové zostavenie spustil dávku testovacích prípadov.

Cyklus vykonávania sa dá nazvať Kontrola stavu, aby ste zistili, aké zdravé je zostavenie.

Nasleduje hlásenie chýb na základe zlyhania skriptu, zmeny návrhu vo funkčnosti; udržiavať skripty / knižnice alebo funkcie, automatizovať a odbavovať nový skript pre nové požiadavky a v prípade potreby novú funkciu v knižnici funkcií.

Niekedy je potrebné testovacie skripty znovu spustiť jednotlivo, aby sa pomocou automatizácie našli chyby regresie a pridali sa tiež do testovacej sady.

Otázka 30) Ako rozlišujete medzi požiadavkou a chybou a vylepšením?

Odpoveď : TO požiadavka je príbeh používateľa, ktorý je nevyhnutné implementovať, testovať a dodať.
An vylepšenie je pridaná alebo improvizovaná funkcia k existujúcemu.
TO vada je skôr úplná odchýlka od očakávaných používateľských príbehov.

Pokiaľ vada odhalí určitú oblasť požiadavky, ktorá nie je uvedená, pokiaľ nie je v špecifikácii uvedené inak, možno ju tiež nazvať ako požiadavka alebo jej súčasť.

Otázka č. 31) Čo urobíte, keď váš vývojár odmietne opravu chyby, ktorú ste nahlásili?

Odpoveď : Dôležitým faktorom, ktorý rozhoduje o odstránení chyby, je priradená „priorita“. Ak má chyba vysokú prioritu, zátka prehliadky, ktorá blokuje hlavné funkcie a je dôsledne reprodukovaná, je potrebné ju opraviť v zostave.

To isté treba vývojárom sprostredkovať efektívne, pretože testeri a vývojári spoločne prispievajú ku kvalite dodávaného produktu.

Ďalšími aspektmi, ktoré môžu vývojára presvedčiť, aby chybu opravili v krátkom čase, sú hlásenie chyby o kvalite a to, aby vývojári pochopili skutočnosť, že odstránenie chyby má vo vydaní prvoradý význam.

Otázka č. 32) Čo urobíte, keď váš vývojár odmietne, že to, čo ste podali, je CHYBA?

Odpoveď : Najdôležitejšou fázou životného cyklu chyby je „Zamietnuté“, čo znamená, že správa o zaznamenanom incidente nie je platná. Dokument s obchodnými požiadavkami, v ktorom sú uvedené požiadavky, môže pomôcť porozumieť softvéru, a tým aj podstate oznámeného incidentu.

Analyzujte chybu a svoje zistenia o chybe vystavte vývojárovi a tímu. Ak ide o chybu, nikdy ju nezabudnite prihlásiť. Testeri niekedy musia poskytnúť analýzu rozdielov a to isté predložiť vývojárom. Ak to nevyrieši konflikty, mali by sa doň postaviť starší ľudia v tíme.

Otázka č. 33) Čo bude najskôr Re-testovanie alebo regresné testovanie?

Odpoveď : Opätovné testovanie je na prvom mieste, pretože sa jedná o opätovné spustenie kódu, jednoduchšie povedané, ide o opakované vykonávanie vopred definovaných krokov. Po oprave kódu to nemusí byť potrebné. Regresným testom je ale posúdenie vedľajších účinkov vyriešenej chyby.

Určite riešenie jednej chyby a pridanie ďalšej do kódu nie je účelom procesu testovania. Najlepšie nálezy a úlovky testerov sú zvyčajne regresné chyby. Zostava by nikdy nemala byť vydaná bez toho, aby bola testovaná regresiou.

Otázka č. 34) Aká je alternatíva k beta testovaniu?

Odpoveď : Beta testovanie sa koná na stránkach klienta s najmenším zapojením vývojárov, pričom sa zaznamenávajú zlyhania v skutočnom produkčnom prostredí. Ak firma takýto postup nevykonáva, potom môže byť bezpečnejším nápadom dodať produkt najskôr klientom, ktorí nie sú v rade na získanie najnovšej verzie.

Niekoľko dní môžu niektorí servisní konzultanti v kancelárii klientov používať softvér, zaznamenávať a monitorovať aktivity, ktoré zabezpečujú stabilitu vydania v ich prostredí, takže aj napriek tomu, že bude odstránená veľká chyba, bude možné ju predtým otestovať ich doručenie cieľovému klientovi. Ďalším prístupom je zamenené testovanie požiadaviek v tíme na objektívne testovanie.

Otázka č. 35) Aké sú nevýhody agilnej implementácie / metodiky, ktorým ste čelili?

Odpoveď : Nevýhody sú nasledujúce:

1. Sprinty sú zvyčajne veľmi obmedzené.
2. Dokumentácia nie je prioritou
3. Prepínanie medzi PBI (produktovými položkami) môže byť časté.

Otázka č. 36) Prečo je analýza dopadu dôležitá?

Odpoveď : Aby ste si mohli na základe rizík nacvičiť, je potrebné urobiť dopadovú analýzu. Týmto spôsobom je možné testovacie prípady navrhnúť tak, aby bolo možné vyriešiť všetky závažné chyby, kritické z pohľadu zákazníka. Je potrebné sa postarať o dobrú štúdiu podniku, potrieb klientov a ich používania softvéru.

Napríklad, najdôležitejšie riziko spojené so softvérom v bankovej oblasti je bezpečnosť. Akákoľvek nová forma pridaná k už existujúcemu softvéru môže byť zraniteľná. Dobré množstvo bezpečnostných testov sa odporúča pridať správne odkazy, presmerovanie a navigáciu na správnu stránku a v prípade potreby nainštalovať proxy.

Otázka č. 37) S pomocou príkladu každé testovanie výkonu, stresové testovanie a testovanie záťaže?

Odpoveď : Najlepším prípadom, ktorý je tu k dispozícii, je živá webová stránka.

Testovanie výkonu sa vykonáva na overenie závad v systéme pri prechode do stavu podobného scenáru v reálnom čase. Nie je potrebné vykonávať za namáhaných podmienok. Výstupy testovania výkonu pomáhajú zistiť, či je systém pripravený na výrobu.

V prípade jednoduchého postupu rezervácie letenky mohol problém s výkonom spôsobiť pomalosť. Napríklad niektorý dotaz pomocou spojenia je o niečo pomalší, čo implementovalo zbytočnú klauzulu alebo nevhodné ukladanie údajov do databázy.

Stresové testovanie je typ testovania výkonu, ktorý sa vykonáva uvedením softvéru do extrémnych podmienok (veľké a nerozložené zaťaženie, obmedzené výpočtové zdroje, vysoká súbežnosť).

Ak systém vykazuje určité správanie, napríklad stratené alebo poškodené údaje, zdroj využitý aj po odstránení stresu, nereagovania alebo nespracovaných výnimiek, znamená to, že pri stresovom testovaní zlyhal. Výsledkom môže byť niekedy zlyhanie disku, zbytočné zvýšenie počtu GDI.

Napríklad, Ak by web hostený na stroji, ktorý už spotrebúva obrovskú pamäť alebo ho bombarduje opakovanými požiadavkami, nemal by vás zavesiť ani odhlásiť.

Testovanie záťaže sleduje správanie systému a neustále zvyšuje zaťaženie systému, kým nedosiahne prahovú hodnotu. Modely pracovného zaťaženia, metriky a úrovne zaťaženia sú zvyčajne vstupom do testovania zaťaženia.

Napríklad, čas na získanie dostupnosti miesta vo vlaku sa postupne zvyšuje, keď sa čas rezervácie kvóty Tatkal priblíži, pretože počet používateľov potom prihlásených do systému sa zvyšuje s časom rezervácie Tatkal blízko 10:00 alebo 11:00.

Otázka č. 38) Čo bolo jednou z vašich najväčších výziev pri regresnom testovaní?

Odpoveď : Pri vykonávaní regresného testovania môžu byť rôzne výzvy.

• Opakované vykonávanie testov nemusí byť pre testerov také vzrušujúce.
• Časovo náročné, pretože niekedy také testovanie vyžaduje premýšľanie.
• Napadnutá obchodná hodnota.
• Nesprávny výber prípadov regresných testov môže preskočiť nájdenie závažnej regresnej chyby.
• Reprodukcia chyby výroby sa tak stáva nekonzistentnou.
• Veľká suita na vykonanie.

Otázka č. 39) Ak sa zobrazí výzva na zdokumentovanie testovacích scenárov, testovacích prípadov, testovacích plánov, testovacej stratégie, s čím začnete a v akom poradí bude nasledovať zvyšok?

Odpoveď : Postupnosť bude Testovacia stratégia, Testovací plán, Testovacie scenáre a nakoniec Testovacie prípady.

Otázka č. 40) Čo ak mi chýba dokumentovanie niektorého z vyššie uvedených údajov? Povedzme, že mi chýba dokumentácia plánu testov, aké to bude mať následky?

Odpoveď : Ak zmeškáme zdokumentovanie plánu testov, dôjde k neplatnosti rozsahu testovania jeho objektívneho prístupu a dôrazu na testovanie. Potom bude ťažké určiť vlastnosti, ktoré sa majú testovať, techniky testovania, vyhovieť alebo nevyhovieť kritériám a nakoniec veľké riziko spojené s testovaním.

Otázka č. 41) Ako by ste začali testovať zostavenie, ktoré ste nedávno dostali: Existuje nejaký prístup, ktorý sledujete napr. najskôr začať s testovaním dymu, potom s testom zdravého rozumu?

Odpoveď : Testovanie dymu> Testovanie zdravého rozumu> Prieskumné testovanie> Testovanie funkčnosti> Regresné testovanie a konečná validácia produktu.

Otázka č. 42) Vysvetlite formát hlásenia o chybe, ktorým ste sa riadili?

Odpoveď :

Hlásenie o chybe by malo obsahovať nasledujúce informácie:

• ID chyby
• Mapovanie na požiadavku / vylepšenie / existujúca chyba
• Zhrnutie / názov chyby
• Verzia produktu
• Priorita
• Konfigurácia (technické parametre systému)
• Podmienky
• Kroky
• Očakávaný výsledok
• Skutočný výsledok
• Záznamy. Momentky, videoklipy
• Postavenie
• Ďalšie poznámky

Otázka č. 43) Ako vyberáte prípady regresného testu alebo ako formujete sadu regresných testov?

Odpoveď : Áno. Toto je výsledok analýzy dopadov. Jedná sa o jednoduché mapovanie funkcií používaných alebo prístupných v rôznych oblastiach, ktoré testujete, ich integráciu s ostatnými funkciami a priebežne ako testovanie systému end-to-end alebo flow.

Môžete tiež vyzdvihnúť chyby, ktoré boli predtým zaregistrované pre rovnakú funkčnosť v predchádzajúcich zostaveniach. V ideálnom prípade by mala byť jedna chyba regresne testovaná pomocou najmenej piatich rôznych testovacích prípadov, ktoré využívajú danú funkčnosť.

Otázka č. 44) Môžete prísť s príkladom nasledujúcich chýb

• Porucha vysokej závažnosti s nízkou prioritou
• Závada s vysokou prioritou a nízkou závažnosťou

Odpoveď : Poruchou, ktorá spôsobí zlyhanie aplikácie, keď sa reprodukuje iba v danom časovom limite na konkrétnom operačnom systéme, môže byť chyba vysokej závažnosti a chyby s nízkou prioritou.

Porucha, ktorá je podaná proti zobrazeniu, ktoré sa neotvára dvojitým kliknutím, ale otvára sa pravým tlačidlom myši, môže byť chybou s vysokou prioritou a nízkou závažnosťou.

Otázka č. 45) Napíšte jeden efektívny testovací prípad a vyskúšajte, či je daný papier bielym papierom?

Odpoveď: Pokiaľ farba zdrojového atramentu, ktorým píšete, na biely papier zostáva rovnaká, potom je papier biely. Napríklad, ak píšete na biely papier s červeným atramentom, farba atramentu zostane v pere červená a tiež sa na papieri zobrazí červená.

Poznámka: Existuje mnoho ďalších odpovedí na túto otázku. Na každú takúto platnú odpoveď môžete myslieť logicky.

Otázka č. 46) Čo je testovanie charty?

Odpoveď: Testovanie relácie uskutočňované na základe cieľov a programov uvedených v charte pred začiatkom testovania sa nazýva testovanie charty.

Testovanie sa tu vykonáva v pevne stanovenom časovom intervale s menším zameraním na dokumentáciu a väčším zameraním iba na testovanie. Jedná sa o iný variant prieskumného testovania, pri ktorom testovací technici overujú softvér v časovom rámci ( Napríklad, iba 2 hodiny) na základe vyvinutej heuristiky.

Otázka č. 47) Aký je váš prístup, keď máte vydanie s vysokou prioritou vydané vo veľmi krátkom čase?

Odpoveď: V takýchto prípadoch môže byť dobre premyslený plán prospešný.

Na pomoc pri testovaní v scenári nedostatku času môžete urobiť toto: -

• Používanie existujúcich aktualizovaných automatizačných skriptov na vykonávanie regresného testovania.
• Testovanie scenárov založených na toku sa končí.
• Vykonávanie testovacích prípadov s vysokou prioritou a ak to čas dovoľuje, prepnite na prípady s nízkou prioritou.
• Opätovné testovanie chýb s vysokou prioritou zaznamenaných v predchádzajúcich verziách.
• Rýchle testovanie softvéru
• Vývojári môžu byť požiadaní, aby spustili testy jednotky, aby získali väčšie pokrytie pri testovaní.

Otázka č. 48) Píšete testovacie prípady na akékoľvek zariadenie alebo predmet v okolí (napríklad: stolička)?

Odpoveď: Rada by tu bola: Vždy začnite zhromažďovaním požiadaviek. Ukazuje vašu zrelosť smerom k životnému cyklu vývoja softvéru. Po výbere objektu môžete pokojne klásť otázky.

V tomto prípade:-

• O aký typ stoličky ide? Kancelárska stolička, študijný stolík, pohovka, jedálenský stolík, pohodlná stolička?
• Aký materiál sa používa na výrobu stoličky - drevo, oceľ, plast, čalúnenie?
• Požiadajte o rozmery (výška, hmotnosť podľa typu stoličky).
• Požiadajte o dostupnosť. A na základe toho začnite koncipovať vaše prípady.

Testovacie prípady by sa líšili pre každý typ stoličky, čo je lepšie ponechať na vašu schopnosť myslenia ( Napríklad, účel stoličky, rozmery podľa typu stoličky, prenosné-nepitné, ľahké, možnosti nákupu).

Pre každú stoličku a testovacím prípadom výkonu môže byť: na odvodenie pevnosti v ťahu alebo maximálnej nosnosti.

Otázka č. 49) Dá sa všetko automatizovať?

Odpoveď: - Do istej miery áno. Ale automatizačné nástroje, rovnako ako iný softvér, majú svoje obmedzenia. Stále sa bude inovovať testovaný softvér alebo testovaná aplikácia.

Neexistuje teda žiadna záruka, že testovanie softvéru môže prebiehať bez manuálneho zásahu. Nakoniec, nástroj je rovnako inteligentný ako tester. Je to iba testovanie softvéru a ďalší softvér. Je to kód / skripty / knižnice, ktoré musia byť dostatočne inteligentné na testovanie a hľadanie chýb.

Záver

Dúfam, že vám toto cvičenie pomôže rozohriať sa niektorými otázkami, ktoré vám skvele naštartujú rozhovory a zdokonalia vašu sebadôveru pri odpovedaní na otázky. Môžu existovať aj ďalšie otázky založené na scenároch, ktoré môžu vyjsť z vášho životopisu / profilu.

Preto je vždy vhodné nacvičiť si falošný pohovor sám so sebou, aby sa pohovor ukázal ako prospešný pre anketára aj kandidáta. Pamätajte, že analytik kvality je viac ako len testovací inžinier, ktorého spätná väzba je dôležitá nielen pre kvalitu produktu, ale aj pre postup pri testovaní softvéru.

Ďakujem a veľa šťastia pri rozhovoroch!

Odporúčané čítanie

• Dotazy a odpovede na pohovor
• 25+ najpopulárnejších otázok a odpovedí na rozhovory s ADO.NET
• 25 najlepších otázok a odpovedí na agilné testovacie pohovory
• Spock Interview Otázky s odpoveďami (najobľúbenejšie)
• ETL Testovacie otázky a odpovede na pohovor
• 20 najobľúbenejších otázok a odpovedí na pohovory s TestNG
• Top 30+ populárnych otázok a odpovedí na rozhovor s uhorkou
• Top 50 najpopulárnejších otázok a odpovedí na rozhovory s CCNA