Interview otázky a odpovede na pohovore – manuálne testovanie

Priprav sa na pracovné pohovory o testovaní softvéru pomocou nášho komplexného zoznamu so 114 otázkami a odpoveďami na manuálne testovanie, určené pre začiatočníkov aj skúsených uchádzačov.

Obsah

Interview otázky na pohovory o manuálnom testovaní pre nováčikov

Otázka č. 1. Čo si predstavujete pod pojmom testovanie softvéru?

Odpoveď: Testovanie softvéru je proces hodnotenia systému s cieľom skontrolovať, či spĺňa obchodné požiadavky. Meria celkovú kvalitu systému z hľadiska atribútov, ako napríklad – správnosť, úplnosť, použiteľnosť, výkon atď. V podstate sa používa na zabezpečenie kvality softvéru pre zainteresované strany aplikácie.

Otázka č. 2. Prečo je potrebné testovanie?
Odpoveď: Testovanie softvéru potrebujeme z týchto dôvodov:

• Testovanie poskytuje zainteresovaným stranám istotu, že produkt funguje tak, ako má.
• Chyby, ktorým sa dá vyhnúť a ktoré unikli ku koncovému používateľovi/zákazníkovi bez riadneho testovania, pridávajú vývojovej spoločnosti zlú povesť.
• Chyby odhalené v skoršej fáze SDLC vedú k nižším nákladom a nižšiemu využitiu zdrojov na opravu.
• Šetrí čas vývoja odhalením problémov v skoršej fáze vývoja.
• Testovací tím dodáva vývoju softvéru ďalší rozmer tým, že poskytuje iný pohľad na proces vývoja produktu.

Otázka č.3. Kedy by sme mali ukončiť testovanie softvéru?
Odpoveď: Testovanie (manuálne aj automatizované) možno zastaviť, keď je splnená jedna alebo viacero z týchto podmienok:

• Po vykonaní testovacích prípadov – fázu testovania možno zastaviť, keď sa po poslednej známej oprave chyby vykoná jeden kompletný cyklus testovacích prípadov s dohodnutou hodnotou percenta úspešnosti.
• Po splnení termínu testovania – Testovanie sa môže zastaviť po splnení termínov, keď v systéme nezostali žiadne problémy s vysokou prioritou.
• Na základe strednej doby medzi poruchami (MTBF) – MTBF je časový interval medzi dvoma poruchami. Na základe rozhodnutí zainteresovaných strán, ak je MTBF pomerne veľká, možno fázu testovania zastaviť.
• Na základe hodnoty pokrytia kódu – Fázu testovania možno zastaviť, keď automatizované pokrytie kódu dosiahne určitú hraničnú hodnotu s dostatočným percentom úspešnosti a bez kritickej chyby.

Otázka č. 4. Čo je zabezpečenie kvality (quality assurance) a aké rôzne činnosti sa podieľajú na zabezpečení kvality?

Odpoveď: Zabezpečenie kvality je procesný prístup, ktorý kontroluje, či je proces vývoja produktu správny a v súlade so všetkými normami. Považuje sa za preventívne opatrenie. Identifikuje totiž nedostatky v procese tvorby softvéru. Zahŕňa činnosti, ako je preskúmanie dokumentov, preskúmanie testovacích prípadov, prechádzky, kontrola atď.

Otázka č. 5. Čo je kontrola kvality (quality control) a aké sú rôzne typy testovania, ktoré sa podieľajú na kontrole kvality?

Odpoveď: Kontrola kvality je prístup zameraný na produkt, ktorý kontroluje, či vyvinuté riešenie spĺňa všetky stanovené požiadavky. Považuje sa za nápravné opatrenie, pretože testuje vytvorený produkt s cieľom nájsť chyby. Zahŕňa rôzne typy testovania, ako napríklad funkčné testovanie, testovanie výkonu, testovanie použiteľnosti atď.

Otázka č. 6. Aký je rozdiel medzi verifikáciou a validáciou?
Odpoveď: Medzi verifikáciou a validáciou sú tieto hlavné rozdiely:

1.	Verifikácia je proces hodnotenia rôznych artefaktov, ako aj procesu vývoja softvéru. Vykonáva sa s cieľom zabezpečiť, aby vyvíjaný produkt bol v súlade s normami.	Validácia je proces overovania, či vyvinutý softvérový produkt zodpovedá špecifikovaným obchodným požiadavkám.
2.	Je to statický proces analýzy dokumentov, a nie skutočného konečného produktu.	Zahŕňa dynamické testovanie softvérového produktu jeho spustením.
3.	Verifikácia je procesne orientovaný prístup.	Validácia je prístup orientovaný na produkt.
4.	Odpovedá na otázku: „Vytvárame produkt správne?“.	Odpovedá na otázku: „Budujeme správny produkt?“
5.	Chyby zistené počas overovania si vyžadujú menšie náklady/zdroje na opravu ako chyby zistené vo fáze validácie.	Chyby zistené počas validácie si vyžadujú väčšie náklady/zdroje. Neskôr objavená chyba má vyššie náklady na jej opravu.

Otázka č. 7. Čo je SDLC – Software development life cycle?
Odpoveď: SDLC je skratka pre životný cyklus vývoja softvéru. Označuje všetky činnosti vykonávané počas vývoja softvéru: zber požiadaviek, analýzu požiadaviek, návrh, kódovanie alebo implementáciu, testovanie, nasadenie a údržbu.

Otázka č.8. Vysvetlite STLC – životný cyklus testovania softvéru.
Odpoveď: Software testing life cyckle – životný cyklus testovania softvéru sa vzťahuje na všetky činnosti vykonávané počas testovania softvérového produktu. Fázy zahŕňajú:

• Analýza a validácia požiadaviek – V tejto fáze sa analyzujú a validujú dokumenty s požiadavkami a definuje sa rozsah testovania.
• Plánovanie testovania – V tejto fáze sa definuje stratégia plánu testovania, odhad testovacieho úsilia spolu so stratégiou automatizácie a výber nástrojov.
• Návrh a analýza testov – Tu sa navrhujú testovacie prípady, pripravujú sa testovacie údaje a implementujú sa automatizačné skripty.
• Nastavenie testovacieho prostredia – Pripraví sa testovacie prostredie, ktoré presne simuluje reálne prostredie.
• Vykonanie testov – Pripravia sa testovacie prípady, nahlásia sa chyby a po ich vyriešení sa znovu otestujú.
• Uzavretie testov a podávanie správ – Pripraví sa správa o uzavretí testov, ktorá obsahuje zhrnutie konečných výsledkov testov, poznatky a metriky testov.

Otázka č. 9. Aké sú rôzne typy testovania?
Odpoveď: Testovanie možno všeobecne definovať na dva typy:

• Funkčné testovanie – Funkčné testovanie zahŕňa overenie funkčných špecifikácií systému.
• Nefunkčné testovanie – Nefunkčné testovanie je typ testovania, ktorý zahŕňa testovanie nefunkčných požiadaviek systému, ako je výkonnosť, škálovateľnosť, bezpečnosť, odolnosť, prenosnosť atď.

Podľa spôsobu, akým sa testovanie vykonáva, ho možno kategorizovať ako:

• Testovanie čiernej skrinky (black-box testing)- pri testovaní čiernej skrinky nemusí mať tester žiadne znalosti o vnútornej architektúre alebo implementácii systému. Tester komunikuje so systémom prostredníctvom rozhrania, poskytuje vstupy a overuje prijaté výstupy.
• Testovanie bielej skrinky (white-box testing)- Pri testovaní bielej skrinky tester analyzuje vnútornú architektúru systému, ako aj kvalitu zdrojového kódu na základe rôznych parametrov, ako je optimalizácia kódu, pokrytie kódu, opätovná použiteľnosť atď.
• Testovanie šedej skrinky (grey-box testing)- Pri testovaní šedej skrinky má tester čiastočný prístup k vnútornej architektúre systému, napr. tester môže mať prístup k návrhovým dokumentom alebo štruktúre databázy. Tieto informácie pomáhajú testerovi lepšie testovať aplikáciu.

Otázka č. 10. Čo je to manuálne testovanie?
Odpoveď: Manuálne testovanie je typ testovania, ktorý zahŕňa overenie požiadaviek aplikácie manuálnym vykonaním vopred definovaného súboru testovacích prípadov bez použitia akéhokoľvek automatizačného nástroja.

Otázka.11. Čo je to automatizované testovanie?
Odpoveď: Automatické testovanie je typ testovania softvéru, ktorý zahŕňa automatizované vykonávanie testovacích prípadov (test cases) pomocou automatizačného nástroja. Pomáha skrátiť čas vykonávania testov, pretože testovacie skripty napísané raz, sa môžu automaticky spustiť ľubovoľný počet krát bez akéhokoľvek ľudského zásahu.

Otázka č. 12. Aké sú niektoré výhody automatizovaného testovania?
Odpoveď: Niektoré výhody automatizovaného testovania sú:

• Vykonávanie testov pomocou automatizácie je rýchle a šetrí značné množstvo času.
• Starostlivo napísané testovacie skripty odstraňujú možnosť ľudskej chyby počas testovania.
• Vykonávanie testov možno naplánovať na nočné spustenie pomocou nástrojov CI, ako je Jenkins, ktoré možno nakonfigurovať aj na denné poskytovanie výsledkov testov príslušným zainteresovaným stranám.
• Automatizované testovanie je veľmi náročné na zdroje. Po automatizácii testov si vykonávanie testov nevyžaduje takmer žiadny čas QA.

Otázka č. 13. Aké sú niektoré nevýhody automatizovaného testovania?
Odpoveď: Niektoré nevýhody automatizovaného testovania sú:

• Vyžaduje si kvalifikovaných odborníkov na automatizované testovanie, ktorí píšu testovacie skripty.
• Na písanie skriptov je vopred potrebné vynaložiť dodatočné úsilie.
• Automatizačné skripty sú obmedzené na overenie nakódovaných testov. Týmto testom môže uniknúť nejaká chyba, ktorá je pre človeka (manuálny QA) veľmi nápadná a ľahko identifikovateľná.
• Dokonca aj pri nejakej menšej zmene v aplikácii je potrebná aktualizácia a údržba skriptov.

Otázka č. 14. Čo je testovanie výkonnosti (performance testing)?
Odpoveď: Testovanie výkonnosti je typ nefunkčného testovania, pri ktorom sa hodnotí výkonnosť systému pri očakávanom alebo vyššom zaťažení. Počas testovania výkonnosti sa hodnotia rôzne parametre výkonnosti – čas odozvy, spoľahlivosť, využitie zdrojov, škálovateľnosť atď. Rôzne typy testovania výkonnosti sú – testovanie záťaže, záťažové testovanie, testovanie odolnosti, testovanie nárazov a objemové testovanie.

Otázka č. 15. Čo je to testovacie prostredie?
Odpoveď: Testovacie prostredie je prostredie používané na testovanie aplikácie. Konfigurácia testovacieho prostredia môže pozostávať z hardvérových a softvérových požiadaviek testovanej aplikácie vrátane – operačného systému, hardvérových konfigurácií, softvérových konfigurácií, databázy atď.

Otázka č.16. Čo je to plán testovania?
Odpoveď: Plán testovania je formálny dokument opisujúci rozsah testovania, prístup, ktorý sa má použiť, potrebné zdroje a odhadovaný čas na vykonanie procesu testovania. Je odvodený z dokumentov požiadaviek (špecifikácie požiadaviek na softvér).

Otázka č. 17. Čo je to testovací scenár?
Odpoveď: Testovací scenár je odvodený od prípadu použitia. Používa sa na komplexné testovanie funkcie aplikácie. Jeden testovací scenár sa môže týkať viacerých testovacích prípadov. Testovanie podľa scenára je užitočné najmä vtedy, keď je testovanie časovo obmedzené.

Otázka č. 18. Čo je to testovací prípad (test case)?
Odpoveď: Testovací prípad sa používa na testovanie zhody aplikácie s jej špecifikáciami požiadaviek. Je to súbor podmienok s predpokladmi, vstupnými hodnotami a očakávanými výsledkami v zdokumentovanej podobe.

Otázka č. 19. Aké sú niektoré atribúty testovacieho prípadu?
Odpoveď: Testovací prípad môže mať tieto atribúty:

• TestCaseId – jedinečný identifikátor testovacieho prípadu.
• Test Summary (Zhrnutie testu) – Jednoznačné zhrnutie testovacieho prípadu.
• Description – Podrobný opis testovacieho prípadu.
• Prerequisite alebo pre-condition – Súbor predpokladov, ktoré sa musia dodržať pred vykonaním testovacích krokov.
• Test Steps (Kroky testu) – Podrobné kroky na vykonanie testovacieho prípadu.
• Expected result (Očakávaný výsledok) – Očakávaný výsledok, aby test prešiel.
• Skutočný výsledok – Skutočný výsledok po vykonaní krokov testu.
• Výsledok testu – Stav úspešného/neúspešného vykonania testu.
• Stav automatizácie – Identifikátor automatizácie, či je aplikácia automatizovaná alebo nie.
• Dátum – Dátum vykonania testu.
• Executed by (Vykonal – Meno osoby vykonávajúcej testovací prípad).

Otázka č. 20. Čo sú to údaje o teste (test data)?
Odpoveď: Testovacie údaje sú údaje, ktoré sa používajú na testovanie softvéru s rôznymi vstupmi a pomáhajú skontrolovať, či príslušný výstup zodpovedá očakávanému výsledku alebo nie. Tieto údaje sa vytvárajú na základe obchodných požiadaviek.

Otázka č. 21. Čo je to testovací skript?
Odpoveď: Testovací skript je automatizovaný testovací prípad napísaný v akomkoľvek programovacom alebo skriptovacom jazyku. Ide v podstate o súbor inštrukcií na vyhodnotenie fungovania aplikácie.

Otázka č. 22. Čo je to chyba (error) pri testovaní softvéru?
Odpoveď: Keďže sme všetci ľudia, tak je samozrejmé, že urobíme chybu. Error je podobný prípad, ktorý sa stane pri testovaní softvéru v dôsledku napr. chýbajúceho scenára v požiadavkách, problémov v návrhu alebo chýb v implementácii.

Otázka č. 23. Čo je to „bug“ ?
Odpoveď: Bug je chyba v softvérovom produkte zistená v čase testovania, ktorá spôsobuje jeho neočakávané fungovanie.

Otázka č. 24. Čo je to „defect“?
Odpoveď: Defekt je nesúlad s požiadavkou na produkt zistený vo výrobe (po uvedení produktu do prevádzky).

Otázka č. 25. Aké sú niektoré atribúty hlásenia defektov?
Odpoveď: Niektoré z atribútov hlásenia chyby sú:

• DefectId – jedinečný identifikátor chyby.
• Defect Summary (Zhrnutie defektu) – jednoriadkové zhrnutie defektu, skôr názov defektu.
• Defect Description (Popis defektu) – podrobný opis defektu.
• Kroky na reprodukciu – kroky na reprodukciu chyby.
• Expected Result (Očakávaný výsledok) – očakávané správanie, od ktorého sa aplikácia v dôsledku chyby odchyľuje.
• Skutočný výsledok – aktuálny chybný stav aplikácie v súvislosti s chybou.
• Závažnosť chyby – na základe kritickosti chyby môže byť toto pole nastavené na hodnotu minor (menej závažná), medium (stredne závažná), major (závažná) alebo show stopper (stopka).
• Priorita – na základe naliehavosti chyby možno toto pole nastaviť na stupnici od P0 do P3.

Otázka č. 26. Aké sú niektoré z nástrojov na správu chýb alebo defektov?
Odpoveď: Niektoré z najpoužívanejších nástrojov na správu defektov sú – Jira, Bugzilla, Redmine, Mantis, Quality Center a iné.

Otázka č. 27. Čo je to hustota defektov (defect density)?
Odpoveď: Hustota defektov je miera hustoty defektov v systéme. Možno ju vypočítať vydelením počtu identifikovaných chýb celkovým počtom riadkov kódu (alebo metód či tried) v aplikácii alebo programe.

Otázka č. 28. Čo je to priorita chýb (defect priority)?
Odpoveď: Priorita defektu je naliehavosť odstránenia defektu. Zvyčajne sa priorita defektu stanovuje na stupnici P0 až P3, pričom defekt P0 má najväčšiu naliehavosť opravy.

Otázka č. 29. Čo je to závažnosť defektu (defect severity)?
Odpoveď: Závažnosť defektu je závažnosť defektu, ktorý má vplyv na funkčnosť. Na základe organizácie môžeme mať rôzne úrovne závažnosti defektu od menej závažnej až po kritickú alebo show stopper (najkritickejšia chyba, ktorá pozastaví vývoj alebo implementáciu softvéru).

Otázka č. 30. Uveďte príklad defektov s nízkou prioritou – nízkou závažnosťou, nízkou prioritou – vysokou závažnosťou, vysokou prioritou – nízkou závažnosťou a vysokou prioritou – vysokou závažnosťou.
Odpoveď: Nižšie sú uvedené príklady pre rôzne kombinácie priority a závažnosti:

• Nízka priorita-Nízka závažnosť: Pravopisná chyba na stránke, po ktorej sa používatelia často nepohybujú.
• Nízka priorita-Vysoká závažnosť: Pád aplikácie v niektorých veľmi okrajových prípadoch.
• Vysoká priorita-Nízka závažnosť: Mierna zmena farby loga alebo pravopisná chyba v názve spoločnosti.
• Vysoká priorita-Vysoká závažnosť: Problém s funkciou prihlásenia.

Otázka č.31. Čo je to „blocker“?
Odpoveď: Blocker je chyba s vysokou prioritou a vysokou závažnosťou. Zabraňuje alebo blokuje testovanie aj niektorej inej významnej časti aplikácie.

Otázka č. 32. Čo je to kritická chyba (critical bug)?
Odpoveď: Kritická chyba je chyba, ktorá má vplyv na hlavnú funkčnosť aplikácie a aplikácia nemôže byť dodaná bez odstránenia tejto chyby. Od chyby blokovania sa líši tým, že neovplyvňuje ani neblokuje testovanie iných častí aplikácie.

Otázka č. 33. Vysvetlite životný cyklus chyby (bug life cycle) alebo rôzne stavy chyby.

Odpoveď: Bug pri vývoji softvéru prechádza týmito fázami

• Nový (New) – chyba alebo defekt sa po zistení nachádza v stave Nový.
• Priradený (Assigned) – Novo zistená chyba po pridelení príslušnému vývojárovi je v stave Priradená.
• Otvorený (Open) – Keď vývojár pracuje na chybe, chyba sa nachádza v stave Otvorená.
• Odmietnutý/Nie je bug (Rejected/Not a bug) – Chyba leží v stave Odmietnutá v prípade, že vývojár usúdi, že chyba nie je pravá.

• Odložený (Deferred) – Odložená chyba je chyba, ktorej oprava sa na základe naliehavosti a kritickosti chyby odloží na určitý čas (na ďalšie vydania).
• Opravený (Fixed) – Keď vývojár chybu vyrieši, označí ju ako opravenú.
• Testovaný(Test) – Keď je chyba opravená, je pridelená testerovi a počas tohto obdobia je označená ako testovaná.
• Znovu otvorený (Reopened) – Ak tester nie je spokojný s vyriešením problému, chyba sa presunie do stavu Znovu otvorená.
• Overený (Verified) – Po fáze Testovanie, ak má tester pocit, že chyba je vyriešená, je označená ako overená.
• Uzavretý (Closed) – Po overení chyby sa chyba presunie do stavu Uzavretá.

Otázka č. 34. Aké sú rôzne techniky navrhovania testov (test design techniques)?

Odpoveď: Techniky návrhu testov sú rôzne štandardy navrhovania testov, ktoré umožňujú systematické a všeobecne akceptované testovacie prípady. Rôzne techniky návrhu testov možno rozdeliť na techniky statického návrhu testov a techniky dynamického návrhu testov.

1.      Techniky statického návrhu testov – techniky návrhu testov, ktoré zahŕňajú testovanie bez spustenia kódu. Rôzne techniky statického návrhu testov možno ďalej rozdeliť na dve časti: manuálne a pomocou nástrojov.

• Manuálne techniky statického návrhu testov
• Priebežný test (Walkthrough)
• Neformálne preskúmanie (Informal reviews)
• Technické revízie (Technical reviews)
• AuditKontrola
• Preskúmanie manažmentom (Technical review)

2.      Techniky statického návrhu testov pomocou nástrojov

• Statická analýza kódu – zahŕňa analýzu rôznych ciest a tokov v aplikácii a rôznych stavov testovacích údajov.
• Súlad so štandardmi programovania – Hodnotí sa súlad kódu s rôznymi štandardmi programovania.
• Analýza metrík kódu – Nástroj používaný na statickú analýzu je potrebný na vyhodnotenie rôznych metrík, ako sú riadky kódu, zložitosť, pokrytie kódu atď.

3.      Techniky dynamického návrhu testov – Techniky dynamického návrhu testov zahŕňajú testovanie spustením testovaného systému.

• Techniky návrhu testov založené na špecifikácii (Specification-based) –  Techniky návrhu testov založené na špecifikácii sa označujú aj ako testovanie čiernej skrinky (black-box testing). Tieto techniky zahŕňajú testovanie na základe špecifikácie testovaného systému bez znalosti jeho vnútornej architektúry.
• Techniky návrhu testov založené na štruktúre (Structure-based) – Označujú sa aj ako testovanie bielej skrinky (white-box testing). Pri týchto technikách sa na vykonanie testovania vyžaduje znalosť kódu alebo vnútornej architektúry systému.
• Založené na skúsenostiach (Experienced-based) –  techniky založené na skúsenostiach sú založené na skúsenostiach alebo intuícii testera. Dve najbežnejšie formy testovania založeného na skúsenostiach sú – adhoc testovanie a prieskumné testovanie.

Otázka č. 35. Čo je statické testovanie (Static Testing)?

Odpoveď: Statické testovanie je druh testovania na preskúmanie pracovných produktov alebo dokumentácie, ktoré sa vytvárajú počas celého projektu. Umožňuje preskúmať špecifikácie, obchodné požiadavky, dokumentáciu, procesy a funkčné požiadavky v počiatočnej fáze testovania.

Aby testeri, ktorí sa na ňom podieľajú, mohli podrobnejšie pochopiť požiadavky pred začatím životného cyklu testovania, ktorého zámerom je pomôcť pri dodaní kvalitného produktu.

Otázka č. 36. Čo je to dynamické testovanie (Dynamic Testing)?

Odpoveď: Typ testovania vykonávaný spustením testovanej aplikácie buď manuálne, alebo pomocou automatizácie sa nazýva dynamické testovanie.

Otázka č. 37. Vysvetlite rôzne typy techník návrhu testov založených na špecifikácii (specification-based test design techniques).

Odpoveď: Techniky návrhu testov založené na špecifikácii sa označujú aj ako testovanie čiernej skrinky. Zahŕňa testovanie na základe špecifikácie testovaného systému bez znalosti jeho vnútornej architektúry. Rôzne typy testov založených na špecifikácii alebo techniky testovania čiernej skrinky sú:

• Rozdelenie podľa ekvivalencie (Equivalence partitioning) – zoskupenie testovacích údajov do logických skupín alebo tried ekvivalencie s predpokladom, že všetky položky údajov ležiace v triedach budú mať rovnaký efekt na aplikáciu.
• Analýza hraničných hodnôt (Boundary value analysis) – testovanie pomocou hraničných hodnôt tried ekvivalencie, ktoré sa berú ako vstupné údaje testu.
• Rozhodovacie tabuľky (Decision tables) –  testovanie pomocou rozhodovacích tabuliek zobrazujúcich správanie aplikácie na základe rôznych kombinácií vstupných hodnôt.
• Graf príčiny a následku (Cause-effect graph)- Testovanie pomocou grafického znázornenia výsledku a všetkých faktorov, ktoré ovplyvňujú výsledok.
• Testovanie prechodov medzi stavmi (State transition testing) – Testovanie založené na modeli stavového stroja.
• Testovanie prípadov použitia (Use case testing)- Testovanie vykonávané pomocou prípadov použitia.

Otázka č. 38. Vysvetlite rozdelenie tried ekvivalencie (equivalence class partitioning).

Odpoveď: Rozdelenie tried ekvivalencie je technika testovania čiernej skrinky založená na špecifikácii. Pri rozdeľovaní tried ekvivalencie sa množina vstupných údajov, ktoré definujú rôzne podmienky testovania, rozdelí do logicky podobných skupín tak, že použitie čo i len jedného testovacieho údaju zo skupiny na testovanie možno považovať za podobné použitiu všetkých ostatných údajov v tejto skupine.

Napríklad na testovanie programu Square (program, ktorý vypíše štvorec čísla) môžu byť triedy ekvivalencie – množina záporných čísel, celých čísel, desatinných čísel, množiny veľkých čísel atď.

Otázka č. 39. Čo je to analýza hraničných hodnôt (boundary value analysis)?

Odpoveď: Analýza hraničných hodnôt je technika testovania softvéru na navrhovanie testovacích prípadov, pri ktorej sa ako vstup do testovacích prípadov berú hraničné hodnoty tried rozdelenia tried ekvivalencie, napr. ak testovacie údaje ležia v rozsahu 0-100, analýza hraničných hodnôt bude obsahovať testovacie údaje – 0,1, 99, 100.

Otázka č.40. Čo je to testovanie pomocou rozhodovacej tabuľky (decision table testing)?

Odpoveď: Testovanie pomocou rozhodovacích tabuliek je typ techniky návrhu testov založenej na špecifikácii alebo technika testovania čiernej skrinky, pri ktorej sa testovanie vykonáva pomocou rozhodovacích tabuliek zobrazujúcich správanie aplikácie na základe rôznych kombinácií vstupných hodnôt.

Rozhodovacie tabuľky sú obzvlášť užitočné pri navrhovaní testovacích prípadov pre komplexné obchodné scenáre zahŕňajúce overovanie aplikácií s viacerými kombináciami vstupov.

Otázka č.41. Čo je to graf príčin a následkov (cause-effect graph)?

Odpoveď: Testovanie pomocou grafu príčin a následkov je technika návrhu testov čiernej skrinky, pri ktorej sa na návrh testov používa grafické znázornenie vstupu, t. j. príčiny, a výstupu, t. j. následku. Táto technika používa rôzne zápisy reprezentujúce vzťahy AND, OR, NOT atď. medzi vstupnými podmienkami vedúcimi k výstupu.

Otázka č. 42. Čo je to testovanie prechodov medzi stavmi (state transition testing)?

Odpoveď: Testovanie prechodov stavov je technika návrhu testov čiernej skrinky založená na modeli stavového stroja. Testovanie prechodov medzi stavmi je založené na koncepcii, že systém možno definovať ako súbor viacerých stavov a prechod z jedného stavu do druhého sa uskutoční v dôsledku nejakej udalosti.

Otázka č. 43. Čo je testovanie prípadov použitia (use case testing)?

Odpoveď: Testovanie prípadov použitia je prístup testovania čiernej skrinky, pri ktorom sa testovanie vykonáva pomocou prípadov použitia. Scenár prípadu použitia sa považuje za interakciu medzi aplikáciou a aktérmi (používateľmi). Tieto prípady použitia sa používajú na zobrazenie požiadaviek, a preto môžu slúžiť aj ako základ pre akceptačné testovanie.

Otázka č. 44. Čo je to pokrytie testov (test coverage)?

Odpoveď: Je to metrika, ktorá meria množstvo testovania vykonaného na softvéri pri vykonávaní testovacích prípadov. Pokrytie testov pre akýkoľvek softvér možno vypočítať ako percentuálny podiel počtu pokrytých testovacích oblastí alebo položiek pokrytia vzhľadom na celkový počet testovacích oblastí.

Čím vyššie je pokrytie testov, tým viac častí softvéru je pokrytých testovacími prípadmi, a teda tým efektívnejšie je testovanie.

Otázka č. 45. Čo je testovanie založené na štruktúre (structure-based testing)?

Odpoveď: Techniky návrhu testov založené na štruktúre sa označujú aj ako testovanie bielej skrinky (white-box testing). Pri týchto technikách sa na vykonanie testovania vyžaduje znalosť kódu alebo vnútornej architektúry systému. Rôzne druhy testovania založené na štruktúre alebo techniky testovania bielej skrinky sú:

• Testovanie príkazov (Statement testing) – technika testovania bielej skrinky, pri ktorej sú testovacie skripty navrhnuté tak, aby vykonávali príkazy kódu aplikácie. Jej pokrytie sa meria ako počet riadkov kódu alebo príkazov vykonaných testovacími skriptami.
• Rozhodovacie testovanie/ testovanie vetiev (Decision testing/branch testing) – technika testovania, pri ktorej sú testovacie skripty navrhnuté tak, aby vykonávali rôzne rozhodovacie vetvy (napr. podmienky if-else) v aplikácii. Jej pokrytie sa meria ako percento rozhodovacích bodov z celkového počtu rozhodovacích bodov v aplikácii.
• Testovanie podmienok (Condition testing) – Testovanie podmienok je prístup testovania, pri ktorom testujeme aplikáciu s výsledkami True aj False pre každú podmienku. Preto pre n podmienok budeme mať 2n testovacích skriptov.
• Testovanie viacerých podmienok (Multiple condition testing) – Pri testovaní viacerých podmienok sa rôzne kombinácie výsledkov podmienok testujú aspoň raz. Preto pre 100 % pokrytie budeme mať 2^n testovacích skriptov. Toto je veľmi vyčerpávajúce a je veľmi ťažké dosiahnuť 100 % pokrytie.
• Testovanie určením podmienok (Condition determination testing) – Je to optimalizovaný spôsob testovania viacerých podmienok, pri ktorom sa vyradia kombinácie, ktoré neovplyvňujú výsledky.
• Testovanie ciest (Path testing) – Testovanie nezávislých ciest v systéme (cesty sú vykonateľné príkazy od vstupných po výstupné body).

Otázka č. 46. Čo je to pokrytie kódu (code coverage)?

Odpoveď: Pokrytie kódu je miera množstva kódu pokrytého testovacími skriptami. Poskytuje predstavu o časti aplikácie pokrytej testovaním.

Otázka 47. Čo je testovanie príkazov a pokrytie príkazov v testovaní bielej skrinky (Statement testing and statement coverage in white box testing)?

Odpoveď: Testovanie výrokov (statements) je prístup testovania bielej skrinky, pri ktorom sú testovacie skripty navrhnuté tak, aby vykonávali príkazy kódu.

Pokrytie príkazov je miera percenta príkazov kódu vykonaných testovacími skriptami z celkového počtu príkazov kódu v aplikácii. Pokrytie príkazov je najmenej preferovanou metrikou na kontrolu pokrytia testov.

Otázka č. 48. Čo je to rozhodovacie testovanie alebo testovanie vetiev (decision testing or branch testing)?

Odpoveď: Rozhodovacie testovanie alebo testovanie vetiev je prístup testovania bielej skrinky (white-box testing), pri ktorom sa pokrytie testov meria percentom rozhodovacích bodov (napr. podmienok if-else) vykonaných z celkového počtu rozhodovacích bodov v aplikácii.

Otázka č.49. Aké sú rôzne úrovne testovania?

Odpoveď: Testovanie sa môže vykonávať na rôznych úrovniach počas procesu vývoja. Vykonávanie testovacích činností na viacerých úrovniach pomáha pri včasnej identifikácii chýb. Rôzne úrovne testovania sú –

1.      Unit testy

2.      Integračné testovanie (Integration Testing)

3.      Systémové testovanie (System Testing)

4.      Akceptačné testovanie (Acceptance Testing)

Otázka č. 50. Čo je to unit testing?

Odpoveď: Unit testing je prvou úrovňou testovania a zahŕňa testovanie jednotlivých modulov softvéru. Zvyčajne ho vykonávajú vývojári.

Otázka č. 51. Čo je integračné testovanie?

Odpoveď: Integračné testovanie sa vykonáva po unit testovaní. Pri integračnom testovaní testujeme skupinu súvisiacich modulov. Jeho cieľom je nájsť problémy s prepojením medzi modulmi.

Otázka č. 52. Aké sú rôzne typy integračného testovania?

Odpoveď: Rôzne typy integračného testovania sú –

1.      ‚Veľký tresk‘ integračného testovania – Pri veľkom tresku integračného testovania sa testovanie začína až po integrácii všetkých modulov.

2.      Integračné testovanie zhora nadol – Pri integrácii zhora nadol sa testovanie/integrácia začína od najvyšších modulov k modulom nižšej úrovne.

3.      Integračné testovanie zdola nahor – Pri integrácii zdola nahor sa testovanie začína od modulov nižšej úrovne k modulom vyššej úrovne v hierarchii.

4.      Hybridné integračné testovanie – Hybridné integračné testovanie je kombináciou integračného testovania zhora nadol aj zdola nahor. Pri tomto prístupe sa integrácia začína od strednej vrstvy a testovanie sa vykonáva v oboch smeroch

Otázka č. 53. Čo je to stub?

Odpoveď: V prípade integračného testovania zhora nadol sa mnohokrát moduly nižšej úrovne nevyvíjajú pri začatí testovania/integrácie s modulmi najvyššej úrovne. V týchto prípadoch sa používajú stubs alebo fiktívne moduly, ktoré simulujú fungovanie modulov poskytovaním pevne zadaného alebo očakávaného výstupu na základe vstupných hodnôt.

Otázka č.54. Čo je to ovládač (driver)?

Odpoveď: V prípade integračného testovania zdola nahor sa ovládače používajú na simuláciu práce modulov najvyššej úrovne s cieľom testovať súvisiace moduly nižšie v hierarchii.

Otázka č.55. Čo je to testovanie systému?

Odpoveď: Systémové testovanie je úroveň testovania, pri ktorej sa testuje celý softvér ako celok. Pri testovaní systému sa kontroluje súlad aplikácie s jej obchodnými požiadavkami.

Otázka č. 56. Čo je akceptačné testovanie?

Odpoveď: Akceptačné testovanie je testovanie, ktoré vykonáva potenciálny koncový používateľ alebo zákazník s cieľom skontrolovať, či softvér vyhovuje obchodným požiadavkám a či ho možno prijať na používanie.

Otázka č. 57. Čo je to testovanie UAT?

Odpoveď: Testovanie UAT je posledná fáza životného cyklu testovania. Jeho hlavným cieľom je overiť, či softvér funguje v súlade s obchodnými požiadavkami. Zabezpečuje tiež, že aplikácia je užívateľsky prívetivá a dokáže čo najlepšie zvládnuť zložité scenáre pred uvoľnením produktu pre reálnych používateľov.

Otázka č. 58. Čo je to testovanie na konci projektu (End-To-End Testing)?

Odpoveď: End-to-End testovanie je typ testovania, pri ktorom sa testuje celá aplikácia s cieľom overiť, či každá funkcia softvéru funguje podľa očakávaní a či v nej nezostala žiadna medzera. Zabezpečuje, že aplikácia je užívateľsky prívetivá a spĺňa obchodné požiadavky.

Otázka č. 59. Čo je alfa testovanie?

Odpoveď: Alfa testovanie je typ akceptačného testovania, ktoré vykonávajú testeri alebo interní zamestnanci organizácie na pracovisku vývojára.

Otázka č.60. Čo je beta testovanie?

Odpoveď: Beta testovanie je testovanie, ktoré vykonávajú koncoví používatelia na pracovisku koncového používateľa. Umožňuje používateľom poskytnúť vývojovej spoločnosti priame informácie o softvéri.

Otázka č. 61. Čo je to adhoc testovanie?

Odpoveď: Adhoc testovanie je neštruktúrovaný spôsob testovania, ktorý sa vykonáva bez formálnej dokumentácie alebo riadneho plánovania.

Otázka č .62. Čo je to monkey testing?

Odpoveď: Monkey testing je typ testovania, ktorý sa vykonáva náhodne bez akýchkoľvek vopred definovaných testovacích prípadov alebo testovacích vstupov.

Otázka č. 63. Ako sa líši monkey testovanie od adhoc testovania?

Odpoveď: V prípade Adhoc testovania síce neexistujú žiadne preddefinované alebo zdokumentované testovacie prípady, ale testeri napriek tomu majú prehľad o aplikácii. Zatiaľ čo v prípade monkey testovania testeri aplikácii nerozumejú.

Otázka č. 64. Čo je prieskumné testovanie (exploratory testing)?

Odpoveď: Prieskumné testovanie je typ testovania, pri ktorom sa počas skúmania systému alebo vykonávania testovacích prípadov pridávajú a aktualizujú nové testovacie prípady. Na rozdiel od skriptovaného testovania prebieha pri prieskumnom testovaní návrh a vykonávanie testov paralelne.

Otázka č. 65. Čo je to load testing?

Odpoveď: Záťažové testovanie (load testing) je typ výkonnostného testovania, ktorého cieľom je zistiť výkonnosť aplikácie pri očakávanom zaťažení. Počas záťažového testovania hodnotíme čas odozvy, priepustnosť, chybovosť atď. parametre aplikácie.

Otázka č. 66. Čo je to stress testing?

Odpoveď: Záťažové testovanie (stress testing) je typ výkonnostného testovania, pri ktorom sa sleduje správanie aplikácie pri vyššej záťaži, ako je očakávaná. Záťažové testovanie sa vykonáva na zistenie únikov pamäte a robustnosti aplikácie.

Otázka č. 67. Čo je to objemové testovanie (volume testing)?

Odpoveď: Objemové testovanie je typ testovania výkonnosti, pri ktorom sa hodnotí výkonnosť aplikácie s veľkým množstvom údajov. Kontroluje škálovateľnosť aplikácie a pomáha pri identifikácii úzkeho miesta s veľkým objemom údajov.

Otázka č. 68. Čo je to testovanie výdrže alebo Soak testovanie (endurance testing or Soak testing)?

Odpoveď: Testovanie výdrže je typ testovania výkonnosti, ktorého cieľom je nájsť problémy, ako sú úniky pamäte (memory leaks), keď je aplikácia vystavená záťažovým testom počas dlhého časového obdobia.

Otázka č. 69. Čo je to spike testing?

Odpoveď: Spike testing je typ testovania výkonnosti, pri ktorom sa meria výkonnosť aplikácie pri náhlom zvýšení počtu aktívnych používateľov počas záťažového testu.

Otázka č. 70. Čo je to testovanie používateľského rozhrania (UI testing)?

Odpoveď: Testovanie UI alebo používateľského rozhrania je typ testovania, ktorého cieľom je nájsť chyby grafického používateľského rozhrania v aplikácii a skontrolovať, či grafické používateľské rozhranie zodpovedá špecifikáciám.

Otázka č. 71. Čo je to testovanie použiteľnosti (usability testing)?

Odpoveď: Testovanie použiteľnosti je typ testovania, ktorého cieľom je zistiť jednoduchosť používania aplikácie. Jeho cieľom je odhaliť chyby v použiteľnosti aplikácie.

Otázka č. 72. Čo je to testovanie prístupnosti (accessibility testing)?

Odpoveď: Testovanie prístupnosti je typ testovania, ktorého cieľom je určiť jednoduchosť používania alebo fungovania aplikácie špeciálne pre osoby so zdravotným postihnutím.

Otázka č.73. Čo je to testovanie kompatibility (compatibility testing)?

Odpoveď: Testovanie kompatibility je overovanie softvéru s cieľom zistiť, ako je softvér kompatibilný s konkrétnym prostredím – operačným systémom, platformou alebo hardvérom.

Otázka č. 74. Čo je testovanie konfigurácie (configuration testing)?

Odpoveď: Testovanie konfigurácie je typ testovania, ktorý sa používa na vyhodnotenie konfiguračných požiadaviek softvéru spolu s účinkom zmeny požadovanej konfigurácie.

Otázka č .75. Čo je to testovanie lokalizácie (localization testing)?

Odpoveď: Lokalizačné testovanie je typ testovania, pri ktorom hodnotíme prispôsobenie aplikácie(lokalizovanú verziu aplikácie) v konkrétnej kultúre, lokalite alebo krajine.

Otázka č. 76. Čo je to testovanie globalizácie (globalization testing)?

Odpoveď: Globalizačné testovanie je typ testovania, pri ktorom sa hodnotí fungovanie aplikácie na celom svete v rôznych kultúrach, jazykoch, lokalitách a krajinách.

Otázka č. 77. Čo je to negatívne testovanie (negative testing)?

Odpoveď: Negatívne testovanie je typ testovania, pri ktorom sa vyhodnocuje odolnosť aplikácie(graceful exiting alebo hlásenie chýb), keď sú jej poskytnuté neplatné vstupné alebo testovacie údaje.

Otázka č. 78. Čo je to bezpečnostné testovanie (security testing)?

Odpoveď: Testovanie bezpečnosti je typ testovania, ktorého cieľom je vyhodnotiť integritu, autentifikáciu, autorizáciu, dostupnosť, dôvernosť a neodmietnutie testovanej aplikácie.

Otázka č. 79. Čo je penetračné testovanie (penetration testing)?

Odpoveď: Penetračné testovanie alebo pen testing je typ bezpečnostného testovania, pri ktorom sa aplikácia hodnotí(bezpečne využíva) na rôzne druhy zraniteľností, ktoré by mohol zneužiť akýkoľvek hacker.

Otázka č. 80. Čo je testovanie odolnosti (robustness testing)?

Odpoveď: Testovanie robustnosti je typ testovania, ktoré sa vykonáva s cieľom zistiť robustnosť aplikácie, t. j. schopnosť systému správať sa šetrne v prípade chybných testovacích krokov a testovacích vstupov.

Otázka č. 81. Čo je to testovanie súbežnosti (concurrency testing)?

Odpoveď: Testovanie súbežnosti je testovanie viacerých používateľov, pri ktorom sa aplikácia vyhodnocuje analýzou správania aplikácie pri súbežnom prístupe používateľov k tej istej funkcii.

Otázka č. 82. Čo je to testovanie backendu (backend testing)?

Odpoveď: Testovanie backendu je typ testovania, ktorý zahŕňa testovanie backendu systému, ktorý zahŕňa testovanie databáz a API v aplikácii.

Otázka č. 83. Čo je to A/B testovanie (A/B testing)?

Odpoveď: A/B testovanie je typ testovania, pri ktorom sú koncovým používateľom vystavené dva varianty softvérového produktu a na základe analýzy správania používateľov na každom variante sa vyberie lepší variant, ktorý sa potom používa.

Otázka č. 84. Čo je to analýza rizík (risk analysis)?

Odpoveď: Analýza rizík je analýza zisteného rizika a priradenie príslušnej úrovne rizika chybe na základe jej vplyvu na aplikáciu.

Otázka č. 85. Aký je rozdiel medzi regresným testovaním a retestingom?

Odpoveď: Regresné testovanie zahŕňa testovanie aplikácie s cieľom overiť, či nová zmena kódu nemá vplyv na ostatné časti aplikácie. Zatiaľ čo pri retestovaní overujeme, či je opravený problém vyriešený alebo nie.

Otázka č. 86. Aký je rozdiel medzi black-box a white-box testovaním?

Odpoveď: Black-box testing je typ testovania, pri ktorom sa na testovanie nevyžaduje vnútorná architektúra kódu. Zvyčajne sa uplatňuje pri testovaní systému a akceptačnom testovaní.

Zatiaľ čo testovanie bielej skrinky (white-box testing) si vyžaduje znalosť vnútorného návrhu a implementácie testovanej aplikácie. Zvyčajne sa používa na testovanie jednotiek a integračné testovanie.

Otázka č. 87. Aký je rozdiel medzi smoke a sanity testing?

Odpoveď: Rozdiel medzi smoke testovaním a sanity testovaním je nasledovný.

• Smoke testing je typ testovania, pri ktorom sa pred vykonaním vyčerpávajúceho testovania testujú všetky hlavné funkcie aplikácie. Zatiaľ čo sanity testing je podmnožinou regresného testovania, ktoré sa vykonáva, keď sa v aplikácii v novom zostavení vykoná nejaká menšia oprava.
• Smoke testy sú zvyčajne zdokumentované alebo automatizované. Zatiaľ čo sanity testy zvyčajne nie sú zdokumentované alebo nie sú skriptované.

Otázka č. 88. Aký je rozdiel medzi pojmami Release a Build?

Odpoveď: Build je spustiteľný súbor, ktorý vývojári poskytli testovaciemu tímu na testovanie aplikácie. Prechádza rôznymi iteráciami opráv a testovania, kým aplikácia nefunguje podľa očakávaní. Keď je aplikácia stabilná a pripravená pre koncových používateľov, je uvoľnená na trh.

Zatiaľ čo Release je inštalovateľný softvér poskytovaný koncovým používateľom po tom, ako ho certifikuje testovací tím. Počas uvoľnenia akéhokoľvek softvéru pre klienta sa k nemu pripoja poznámky k vydaniu, ktoré obsahujú počet ešte otvorených chýb, pokryté používateľské príbehy, požiadavky na zmeny a verziu vydania.

Otázky na pohovory o manuálnom testovaní pre pokročilých

Otázky č. 89. Aký je rozdiel medzi únikom chyby a vydaním chyby (bug leakage and bug release)?

Odpoveď Únik chýb je, keď sa testovaný softvér dostane na trh a koncový používateľ v ňom nájde chyby. Patria sem chyby, ktoré testovací tím prehliadol počas fázy testovania.

Zatiaľ čo release chýb je, keď sa na trh uvoľní určitá verzia softvéru s niektorými známymi chybami, ktoré sa majú opraviť v neskorších verziách. Tieto typy problémov majú nízku prioritu a uvádzajú sa v poznámkach k vydaniu pri zdieľaní s koncovými používateľmi.

Otázka č. 90. Čo máte na mysli pod pojmom Defect Triage (triedenie chýb)?

Odpoveď: Defect triage je proces, pri ktorom sa určuje priorita chýb na základe rôznych faktorov, ako je závažnosť, riziko, čas potrebný na opravu chyby atď. Na stretnutí sa zúčastňujú rôzne zainteresované strany – vývojový tím, testovací tím, projektový manažér, BA atď. a rozhodujú o priorite odstránenia chýb.

Otázka č. 91. Čo je to test harness? Prečo potrebujeme test harness?

Odpoveď: Test harness je súbor testovacích skriptov a testovacích údajov, ktoré sa zvyčajne spájajú s unit a integračným testovaním. Zahŕňa stubs a ovládače, ktoré sú potrebné na testovanie softvérových modulov a integrovaných komponentov.

Otázka č. 92. Čo je celkové párové testovanie (all pair testing)?

Odpoveď: All pair testing je typ testovania, pri ktorom sa aplikácia testuje so všetkými možnými kombináciami hodnôt vstupných parametrov.

Otázka č. 93. Čo je to testovanie pri poruche (failover testing)?

Odpoveď: Testovanie pri poruche je typ testovania, ktorý sa používa na overenie schopnosti aplikácie prideliť viac zdrojov (viac serverov) v prípade poruchy a preniesť časť spracovania na záložný systém.

Otázka č.  94. Čo je to fuzz testovanie?

Odpoveď: Fuzz testovanie je typ testovania, pri ktorom sa ako vstup do aplikácie poskytne veľké množstvo náhodných údajov s cieľom nájsť bezpečnostné medzery a iné problémy v aplikácii.

Otázka č. 95. Čo je pilotné testovanie (pilot testing)?

Odpoveď: Pilotné testovanie je testovanie vykonávané ako skúšobná prevádzka s obmedzeným počtom používateľov, ktorí hodnotia systém a poskytujú spätnú väzbu pred úplným nasadením.

Otázka č. 96. Čo je to dev-box testovanie?

Odpoveď: Pri dev-box testovaní tester vykonáva testovanie na systéme vývojára s cieľom overiť, či sú hlavné funkcie aplikácie stabilné a pripravené na testovanie.

Otázka č. 97. Čo je to testovanie mutácie (mutation testing)?

Odpoveď: Testovanie mutáciou je typ testovania bielej skrinky, pri ktorom sa zdrojový kód aplikácie zmutuje tak, aby spôsobil určité chyby v jej fungovaní. Potom sa spustia testovacie skripty na kontrolu ich správnosti overením chýb spôsobených mutovaným kódom.

Otázka č. 98. Čo je to matica sledovateľnosti požiadaviek(RTM – requirement traceability matrix)?

Odpoveď: V testovaní softvéru je matica sledovateľnosti požiadaviek tabuľka, ktorá spája požiadavky vysokej úrovne s podrobnými požiadavkami, testovacími plánmi alebo testovacími prípadmi. RTM pomáha zabezpečiť 100 % pokrytie testov.

Otázka č. 99. Čo je to cyklomatická zložitosť?

Odpoveď: Cyklomatická zložitosť je miera počtu nezávislých ciest v aplikácii alebo programe. Táto metrika poskytuje údaj o množstve úsilia potrebného na otestovanie kompletnej funkčnosti. Možno ju definovať výrazom –

L – N + 2P, kde:

L je počet hrán v grafe

N je počet uzlov

P je počet odpojených častí

Otázka č. 100. Aké sú vstupné kritériá pri testovaní softvéru?

Odpoveď Súbor predpokladov, ktoré sú potrebné na začatie testovacej činnosti, zahŕňa testovacie prostredie, testovací nástroj, testovacie údaje, pripojenie k databáze a mnohé ďalšie.

Otázka č. 101. Aké sú výstupné kritériá pri testovaní softvéru?

Odpoveď: Výstupné kritériá sú formálnym súborom podmienok, ktoré špecifikujú dohodnuté vlastnosti alebo stav aplikácie s cieľom označiť ukončenie procesu alebo produktu.

Otázka č. 102. Aký je rozdiel medzi testovaním a ladením (testing and debugging)

Odpoveď: Testovanie vykonáva predovšetkým testovací tím s cieľom nájsť chyby v systéme. Zatiaľ čo ladenie je činnosť, ktorú vykonáva vývojový tím. Pri ladení sa zisťuje a odstraňuje príčina chyby. Tým sa odstráni chyba a zabráni sa jej výskytu aj v budúcnosti.

Ďalším rozdielom medzi týmito dvoma činnosťami je – testovanie sa môže vykonávať bez akejkoľvek internej znalosti architektúry softvéru. Zatiaľ čo ladenie si vyžaduje znalosť softvérovej architektúry a programovania.

Otázka č. 103. Vysvetlite agilnú metodiku.

Odpoveď: Agilná metodika vývoja softvéru je založená na iteratívnom a inkrementálnom prístupe. V tomto modeli je aplikácia rozdelená na menšie zostavy, na ktorých spoločne pracujú rôzne multifunkčné tímy, čo zabezpečuje rýchle dodanie spolu s prispôsobením sa meniacim sa potrebám v rovnakom čase.

Otázka č. 104. Čo je to scrum?

Odpoveď: Scrum je proces implementácie agilnej metodiky. V scrume je čas rozdelený na šprinty a po ich dokončení sa dodáva produkt.

Otázka č. 105. Aké sú rôzne roly v scrume?

Odpovede: Rôzne roly v scrume sú –

1.      Vlastník produktu (product owner) – Vlastník produktu vlastní celý vývoj produktu, prideľuje úlohy tímu a pôsobí ako rozhranie medzi scrumovým tímom (vývojovým tímom) a zainteresovanými stranami.

2.      Scrum Master – Scrum Master dohliada na to, aby sa v tíme dodržiavali pravidlá a vedie meetingy.

3.      Scrum tím – Scrum tím sa zúčastňuje na scrum stretnutiach a plní pridelené úlohy.

Otázka č. 106. Čo je to scrum meeting?

Odpoveď: Scrum meeting je každodenné stretnutie v rámci scrum procesu. Toto stretnutie vedie scrum master a na tomto stretnutí sa definuje aktualizácia práce z predchádzajúceho dňa spolu s úlohami a kontextom na ďalší deň.

Otázka č. 107. Vysvetlite pojem TDD (Test Driven Development).

Odpoveď: Testami riadený vývoj je metodika vývoja softvéru, pri ktorej sa vývoj softvéru riadi testovacími prípadmi vytvorenými pre implementovanú funkcionalitu. Pri TDD sa najprv vytvoria testovacie prípady a potom sa napíše kód, ktorý má prejsť testami. Neskôr sa kód refaktoruje podľa noriem.

Otázka č. 108. Aký je rozdiel medzi skrytými a maskovanými chybami?

Odpoveď: Latentný (skrytý) defekt je neidentifikovaný defekt, ktorý je prítomný v aktuálnej verzii, ale nie je viditeľný, pretože nikdy neboli splnené podmienky, za ktorých by sa defekt mohol nájsť. Tieto typy defektov sa objavia len vtedy, keď sa spustí určitá udalosť, ktorá zakrývala ich prítomnosť.

Zatiaľ čo maskovaný defekt je existujúci defekt, ktorý ešte nespôsobil žiadnu poruchu, pretože iná chyba ho zamaskovala alebo zabránila jeho odhaleniu.

Otázka č. 109. Čo je cyklus PDCA pri testovaní softvéru?

Odpoveď: Cyklus PDCA je kľúčom k neustálemu zlepšovaniu procesov pri vývoji softvéru. Zahŕňa tieto 4 kroky –

• PLAN – naplánujte zámery, ciele a iniciatívy, ktoré pomôžu dosiahnuť spokojnosť zákazníka.
• DO – Realizuje plán do praxe. Ak chcete slúžiť zákazníkovi s vyššou kvalitou a spokojnosťou, je potrebné mať dobrý plán na realizáciu.
• CHECK – Kontrola postupu realizácie plánu. Výsledok ukáže, ako presne bolo plánovanie vykonané.
• ACT – Konanie na základe výsledkov s cieľom vykonať ďalšie zlepšenia, ktoré pomáhajú pri dosahovaní plánovaných cieľov.

Otázka č. 110. Čo je to kaskádovanie chýb (Defect Cascading)?

Odpoveď: Kaskádovanie defektov je vyvolanie defektu iným defektom. Dochádza k nemu vtedy, keď testovací tím nezachytí defekt a ten vyvolá ďalší defekt.

Otázka č. 111. Čo je to testovacia metrika?

Odpoveď: Metrika testov je kvantitatívna analýza, ktorá pomáha pri monitorovaní pokroku softvérového projektu. Každý projekt má svoj vlastný časový harmonogram, takže zabezpečenie včasného dodania projektu si vyžaduje stanovenie výsledkov v rôznych intervaloch a tento aspekt merania pokroku zabezpečujú testovacie metriky.

Otázka č. 112. Čo je kontextovo riadené testovanie (Context-driven testing)?

Odpoveď: Testovanie riadené kontextom je typ testovania, ktorý zahŕňa prijatie testovacích postupov a metodík a niekedy ich prispôsobenie na základe kontextu projektu.

Pri tomto type testovania sa namiesto dodržiavania osvedčených postupov riadime tým, čo je pre projekt najlepšie, na základe zručností, skúseností a úsudku testovacieho tímu.

Otázka č. 113. Ako môžete testovať aplikáciu bez dokumentu s požiadavkami?

Odpoveď: Aplikáciu možno testovať bez formálneho dokumentu požiadaviek pomocou nasledujúcich opatrení –

• Preskúmaním aplikácií, ktoré majú podobný charakter.
• Testovanie na základe ideálnej skúsenosti používateľa. Aj bez toho, aby mal tester k dispozícii akékoľvek požiadavky, môže testovať používateľskú prívetivosť aplikácie.
• Použitím prieskumného testovania. Keďže nie je k dispozícii žiadna dokumentácia, tak testeri môžu použiť prieskumné testovanie a testovať aplikáciu za behu s praktickejším prístupom.
• Kladenie čo najväčšieho počtu otázok a brainstorming s rôznymi zainteresovanými stranami – produktovými manažérmi, vývojármi atď.

Otázka č. 114. Ako napísať efektívne testovacie prípady?

Odpoveď: Efektívne testovacie prípady môžeme napísať pomocou nasledujúcich prístupov.

• Nasledovaním techník návrhu testov, ako je analýza hraničných hodnôt, rozdelenie tried ekvivalencie, testovanie pomocou rozhodovacej tabuľky atď.
• Písaním jasných a stručných testovacích prípadov, ktoré nie sú nejednoznačné.
• Pri vytváraní efektívnych testovacích prípadov pomáha aj dodržiavanie jednotnej nomenklatúry.
• Vyhýbanie sa redundancii vedie k plytvaniu zdrojmi aj časom. Dobré testovacie prípady teda nemusia mať žiadnu redundanciu.
• Používanie matice sledovateľnosti požiadaviek pomáha zabezpečiť maximálne pokrytie testov.