Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

ISTQB CTFL > ISTQB - Testování v rámci životního cyklu vývoje > Flashcards

ISTQB - Testování v rámci životního cyklu vývoje Flashcards

(111 cards)

Start Studying
1
Q

Co je to SDLC (Software Development Lifecycle)? (Definice)

A
  1. Model zivotniho cyklu vyvoje softwaru.
  2. Popisuje faze a aktivity při vyvoji softwaru od konceptu po udrzbu.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Vliv SDLC na testovani: Jak ovlivnuji ITERATIVNI A INKREMENTALNI modely (vcetne agilnich) casovani testovani? (FL-2.1.1)

A
  1. Testovani probiha v KAZDE iteraci.
  2. Umoznuje vcasnou zpetnou vazbu.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Vliv SDLC na testovani: Proc je u ITERATIVNICH modelu kladen velky duraz na REGRESNI TESTOVANI? (FL-2.1.1)

A
  1. Aby se zajistilo, ze nove pridane inkrementy (casti produktu) nerozbily jiz existujici a otestovanou funkcionalitu.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Vliv SDLC na testovani: Uvedte alespon 2 aspekty testovani, ktere jsou ovlivneny volbou SDLC. (FL-2.1.1)

A
  1. Nacasovani testovacich aktivit.
  2. Uroven formalnosti dokumentace.
  3. (Rozsah testovani, Pouzite nastroje a techniky, Role a odpovednosti).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Vliv SDLC na testovani: Ktery typ SDLC modelu je charakteristicky jasne definovanymi, po sobe jdoucimi fazemi? (FL-2.1.1)

A
  1. Sekvencni modely (napr. Vodopadovy model, V-model).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Vliv SDLC na testovani: Pro ktery typ SDLC modelu je typicke dodavani funkcni casti produktu v kazdem cyklu? (FL-2.1.1)

A
  1. Iterativni a Inkrementalni modely.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Osvedcene postupy: Jake testovaci aktivite odpovida vyvojova aktivita “specifikace pozadavku”? (FL-2.1.2)

A
  1. Revize pozadavku.
  2. Navrh akceptacnich testu.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Osvedcene postupy: Kdy by mela zacit analyza a navrh testu pro danou uroven testovani podle osvedcenych postupu? (FL-2.1.2)

A
  1. Behem ODPOVIDAJICI vyvojove aktivity (co nejdrive - princip vcasneho testovani).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Osvedcene postupy: Proc by se testeri meli ucastnit revizi pracovnich produktu (napr. pozadavku) jiz v jejich draft verzi? (FL-2.1.2)

A
  1. Pomaha to odhalit defekty v ranych fazich (kdy je oprava nejlevnejsi).
  2. Podporuje to princip “shift left”.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Osvedcene postupy: Je pravda, ze osvedcene postupy testovani jsou aplikovatelne pouze na agilni modely SDLC? (FL-2.1.2)

A
  1. NE. Existuji osvedcene postupy (napr. vcasne testovani, existence odpovidajici testovaci aktivity pro kazdou vyvojovou) aplikovatelne na VSECHNY typy SDLC.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Vliv SDLC na testovani: Ve V-modelu, kdy typicky zacina navrh SYSTEMOVYCH testu? (Aplikace FL-2.1.1)

A
  1. Soubezne s fazi navrhu systemu (system design).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Vliv SDLC na testovani: Jak AGILNI metodiky typicky ovlivnuji formalnost testovaci dokumentace? (FL-2.1.1)

A
  1. Casto preferuji mene formalni a strucnejsi dokumentaci (napr. user stories s akceptacnimi kriterii misto rozsahlych testovacich planu).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Vliv SDLC na testovani: Je snazsi reagovat na zmeny v pozadavcich u vodopadoveho modelu nebo u agilniho modelu? (FL-2.1.1)

A
  1. U agilniho modelu (diky kratkym iteracim a flexibilite).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Osvedcene postupy: Pokud vyvojari pisou kod pro novou funkci, jaka testovaci aktivita by mela byt jejich primarni zodpovednosti? (FL-2.1.2)

A
  1. Komponentove testovani (Unit testing) jejich vlastniho kodu.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Osvedcene postupy: “Pro kazdou uroven testovani jsou definovany specificke cile.” Je toto osvedceny postup? (FL-2.1.2)

A
  1. ANO. Pomaha to zajistit, ze kazda uroven plni svuj ucel a nedochazi k duplicitam nebo opomenutim.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Vliv SDLC na testovani: Ktery SDLC model muze vest k situaci, kdy jsou defekty nachazeny az pozde a jejich oprava je nakladna? (FL-2.1.1)

A
  1. Sekvencni modely (napr. Vodopadovy), pokud testovani probiha az na konci.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Vliv SDLC na testovani: Jaky je klicovy prinos testovani v kazde iteraci u iterativnich modelu? (FL-2.1.1)

A
  1. Vcasna zpetna vazba o kvalite inkrementu produktu.<br></br>2. Drivejsi odhaleni defektu.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Osvedcene postupy: Kdyz je vytvoren prvni navrh architektury systemu, jaka testovaci aktivita by mela nasledovat? (FL-2.1.2)

A
  1. Revize navrhu architektury (z pohledu testovatelnosti, splneni ne-funkcnich pozadavku atd.).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Osvedcene postupy: Co znamena, ze “pro kazdou vyvojovou aktivitu existuje odpovidajici testovaci aktivita”? (FL-2.1.2)

A
  1. Ze kazdy pracovni produkt vytvoreny behem vyvoje (napr. pozadavky, navrh, kod) by mel byt nejakym zpusobem otestovan (napr. revizi, statickou analyzou, dynamickym testovanim).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Vliv SDLC na testovani: Muze volba SDLC ovlivnit, jake testovaci nastroje budou pro projekt nejvhodnejsi? (FL-2.1.1)

A
  1. ANO. Napriklad agilni projekty s durazem na CI/CD budou vice vyzadovat nastroje pro automatizaci testu a integracni nastroje.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Osvedcene postupy: Co znamena, ze “pro kazdou vyvojovou aktivitu existuje odpovidajici testovaci aktivita”? (FL-2.1.2)

A
  1. Ze kazdy pracovni produkt vytvoreny behem vyvoje (napr. pozadavky, navrh, kod) by mel byt nejakym zpusobem otestovan (napr. revizi, statickou analyzou, dynamickym testovanim).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Vliv SDLC na testovani: Muze volba SDLC ovlivnit, jake testovaci nastroje budou pro projekt nejvhodnejsi? (FL-2.1.1)

A
  1. ANO. Napriklad agilni projekty s durazem na CI/CD budou vice vyzadovat nastroje pro automatizaci testu a integracni nastroje.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Ktery “test-first” pristup je charakteristicky cyklem Red-Green-Refactor a zamerenim na unit testy? (FL-2.1.3)

A
  1. Test-Driven Development (TDD).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Ktery “test-first” pristup zahrnuje spolupraci celeho tymu (byznys, vyvojari, testeri) pri definovani akceptacnich kriterii ve forme testu? (FL-2.1.3)

A
  1. Acceptance Test-Driven Development (ATDD).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Jaky format se casto pouziva pro popis chovani v Behavior-Driven Development (BDD)? (FL-2.1.3)
1. Given-When-Then (Dano-Kdyz-Pak).
26
Co je spolecnym jmenovatelem vsech "test-first" pristupu? (FL-2.1.3)
1. Testy jsou psany PRED produkcnim kodem a RIDI vyvoj.
27
Uvedte alespon jeden prinos Test-Driven Development (TDD). (FL-2.1.3)
1. Lepsi navrh kodu (testovatelnejsi). 2. Vysoke pokryti kodu testy.
3. (Rychla zpetna vazba, Podpora refaktoringu).
28
Jaky je hlavni cil Acceptance Test-Driven Development (ATDD)? (FL-2.1.3)
1. Zajistit, ze vyvijeny software splnuje byznys potreby a akceptacni kriteria definovana z pohledu uzivatele/byznysu.
29
Co znamena DevOps? (FL-2.1.4)
1. Kultura, sada postupu a nastroju zamerena na spolupraci Development (vyvoje) a Operations (provozu) pro rychlejsi a spolehlivejsi dodavani aplikaci a sluzeb.
30
Jak Kontinualni Integrace (CI) v DevOps ovlivnuje testovani? (FL-2.1.4)
1. Vyžaduje castou integraci kodu do sdileneho repozitare. 2. Kazda integrace je automaticky overena buildem a AUTOMATIZOVANYMI testy (napr. unit, integracnimi).
31
Co znamena Kontinualni Dorucovani/Nasazovani (CD) v kontextu DevOps? (FL-2.1.4)
1. Rozsireni CI, ktere automatizuje dalsi faze dorucovani, vcetne nasazeni do testovacich a potencialne i produkcnich prostredi.
32
Jaky je hlavni dopad CI/CD pipeline na testovaci aktivity v DevOps? (FL-2.1.4)
1. Obrovsky tlak na AUTOMATIZACI testu na vsech urovnich. 2. Testy musi byt rychle a spolehlive.
33
Co znamena "Shift Right" testovani v kontextu DevOps? (FL-2.1.4)
1. Testovani a monitorovani probihajici i v PRODUKCNIM prostredi za ucelem ziskani zpetne vazby o skutecnem chovani a vykonu.
34
Jak DevOps ovlivnuje roli testera? (FL-2.1.4)
1. Testeri uzce spolupracuji s vyvojari a provozem. 2. Casto se vice podileji na automatizaci a integraci testu do CI/CD. 3. Kvalita je sdilenou zodpovednosti.
35
Je pravda, ze v DevOps se provadi pouze automatizovane testy? (FL-2.1.4)
1. NE. I kdyz je duraz na automatizaci velky, manualni testovani (napr. explorativni, pouzitelnosti) ma stale sve misto.
36
Ktera DevOps praktika umoznuje konzistentni a rychle vytvareni testovacich prostredi pomoci kodu? (FL-2.1.4)
1. Infrastruktura jako kod (Infrastructure as Code - IaC).
37
Jaky typ testu (krome funkcniho) je casto zduraznovan a integrovany do CI/CD pipeline v DevOps? (FL-2.1.4)
1. Nefunkcni testy (napr. vykonnostni, bezpecnostni).
38
Cilem BDD je vytvorit scenare, kterym rozumi jak technicti, tak netechnicti clenove tymu. Je toto tvrzeni spravne? (FL-2.1.3)
1. ANO. BDD pouziva jednoduchy, strukturovany jazyk (casto Given-When-Then) pro lepsi komunikaci a sdilene porozumeni.
39
Muze TDD pomoci pri refaktoringu kodu? (FL-2.1.3)
1. ANO. Sada existujicich unit testu vytvorenych behem TDD poskytuje jistotu, ze refaktoring nezmenil chovani kodu (testy by mely stale prochazet).
40
Co je hlavni myslenkou principu "SHIFT LEFT" v testovani? (FL-2.1.5)
1. Provadet testovaci a s kvalitou souvisejici aktivity co NEJDRIVE v zivotnim cyklu vyvoje softwaru.
41
Uvedte alespon jeden priklad aktivity "SHIFT LEFT". (FL-2.1.5)
1. Zapojeni testeru do revizi pozadavku. 2. Staticka analyza kodu. 3. (Psani unit testu vyvojari, Tvorba akceptacnich testu behem definovani pozadavku).
42
Proc je "SHIFT LEFT" povazovan za nakladove efektivni? (FL-2.1.5)
1. Protoze defekty odhalene a opravene v ranych fazich jsou MNOHEM LEVNEJSI na opravu nez defekty nalezene pozdeji.
43
Ktery ze 7 principu testovani primo podporuje myslenku "SHIFT LEFT"? (Aplikace FL-1.3.1, FL-2.1.5)
1. Princip c. 3: Vcasne testovani setri cas a penize.
44
Co je hlavnim ucelem RETROSPEKTIVY v (agilnim) tymu? (FL-2.1.6)
1. Reflektovat dosavadni praci. 2. Identifikovat moznosti pro ZLEPSENI budoucich procesu, spoluprace a pracovnich postupu.
45
Kdo se typicky ucastni RETROSPEKTIVY? (FL-2.1.6)
1. Cely tym (vyvojari, testeri, Scrum Master, Product Owner atd.).
46
Jake tri zakladni otazky se casto resi na RETROSPEKTIVE? (FL-2.1.6)
1. Co se nam darilo (pokracovat)? 2. Co se nam nedarilo (zmenit/prestat)? 3. Co bychom mohli zkusit jinak/zlepsit?
47
Jaky by mel byt typicky vystup z RETROSPEKTIVY? (FL-2.1.6)
1. Konkretni, meritelne, dosazitelne, relevantni a casove ohranicene (SMART) AKCNI BODY pro zlepseni.
48
Jak retrospektivy prispivaji ke KONTINUALNIMU ZLEPSOVANI (Kaizen)? (FL-2.1.6)
1. Tim, ze se konaji pravidelne, umoznuji tymu ucit se z vlastnich zkusenosti a postupne adaptovat a zlepsovat sve procesy.
49
Muze retrospektiva pomoci zlepsit kvalitu hlaseni o defektech v tymu? (Aplikace FL-2.1.6)
1. ANO. Tym se muze na retrospektive dohodnout na lepsich standardech nebo postupech pro hlaseni defektu, pokud identifikuji, ze soucasny zpusob je neefektivni.
50
Princip "shift left" znamena, ze se veskere testovani provadi pouze na zacatku projektu a pozdeji uz ne. Je toto tvrzeni spravne? (FL-2.1.5)
1. NE. "Shift left" znamena zacit s testovacimi aktivitami drive, ale neznamena to zanedbavani testovani v pozdejsich fazich.
51
Jsou retrospektivy uzitecne pouze pro agilni tymy? (FL-2.1.6)
1. NE. I kdyz jsou typicke pro agilni metodiky, princip reflexe a hledani zlepseni muze byt uzitecny v jakemkoli tymu nebo projektu (napr. jako "lessons learned" na konci projektu).
52
Na co se zameruje KOMPONENTOVE (UNIT) TESTOVANI? (FL-2.2.1)
1. Na testovani jednotlivych, izolovatelnych softwarovych komponent (modulu, trid, funkci).
53
Jaky je hlavni CIL KOMPONENTOVEHO TESTOVANI? (FL-2.2.1)
1. Overit, ze kazda komponenta funguje spravne sama o sobe podle sve specifikace. 2. Hledani defektu UVNITR komponenty.
54
Kdo typicky provadi KOMPONENTOVE TESTOVANI? (FL-2.2.1)
1. Vyvojari.
55
Na co se zameruje INTEGRACNI TESTOVANI KOMPONENT? (FL-2.2.1)
1. Na testovani rozhrani a interakci mezi jiz otestovanymi a nasledne integrovanymi komponentami.
56
Jaky je hlavni CIL INTEGRACNIHO TESTOVANI KOMPONENT? (FL-2.2.1)
1. Odhalit defekty v rozhranich a v interakcich mezi komponentami. 2. Overit, zda komponenty spravne spolupracuji.
57
Na co se zameruje SYSTEMOVE TESTOVANI? (FL-2.2.1)
1. Na testovani kompletniho, integrovaneho systemu jako celku.
58
Jaky je hlavni CIL SYSTEMOVEHO TESTOVANI? (FL-2.2.1)
1. Overit, zda cely system splnuje specifikovane funkcni i ne-funkcni pozadavky. 2. Hodnoti se celkove chovani systemu.
59
Kdo typicky provadi SYSTEMOVE TESTOVANI? (FL-2.2.1)
1. Nezavisly testovaci tym.
60
Na co se zameruje INTEGRACNI TESTOVANI SYSTEMU? (FL-2.2.1)
1. Na testovani rozhrani a interakci mezi testovanym systemem a JINYMI systemy nebo externimi sluzbami.
61
Jaky je hlavni CIL INTEGRACNIHO TESTOVANI SYSTEMU? (FL-2.2.1)
1. Overit, ze system spravne komunikuje a spolupracuje s EXTERNIMI systemy.
62
Na co se zameruje AKCEPTACNI TESTOVANI? (FL-2.2.1)
1. Na formalni testovani z pohledu uzivatele, zakaznika nebo jinych zainteresovanych stran.
63
Jaky je hlavni CIL AKCEPTACNIHO TESTOVANI? (FL-2.2.1)
1. Overit, zda je system PRIPRAVEN K NASAZENI.
2. Overit, zda system splnuje BYZNYS POTREBY a akceptacni kriteria (VALIDACE).
64
Kdo typicky provadi UZIVATELSKE AKCEPTACNI TESTOVANI (UAT)? (FL-2.2.1)
1. Koncovi uzivatele.
65
Co je ALFA TESTOVANI? (FL-2.2.1)
1. Forma akceptacniho testovani provadena potencialnimi uzivateli/zakazniky ve VÝVOJÁŘSKÉM (nebo kontrolovanem) prostredi.
66
Co je BETA TESTOVANI (Field testing)? (FL-2.2.1)
1. Forma akceptacniho testovani provadena skutecnymi uzivateli v JEJICH VLASTNIM (nebo realnem) prostredi bez primeho dohledu vyvojaru.
67
Ktera uroven testovani typicky vyzaduje testovaci zastupne objekty (stubs) a ovladace (drivers) pro izolaci? (FL-2.2.1)
1. Komponentove testovani (Unit Testing).
68
Ktera uroven testovani se nejvice zabyva overovanim splneni byznys pozadavku a vhodnosti produktu pro dany ucel? (Aplikace FL-2.2.1)
1. Akceptacni testovani.
69
Testovani komunikace mezi modulem pro objednavky a modulem pro platby v ramci jednoho e-shopu je prikladem jake urovne testovani? (Aplikace FL-2.2.1)
1. Integracni testovani komponent.
70
Testovani, zda novy e-shop spravne komunikuje s externi platebni branou (systemem treti strany), je prikladem jake urovne testovani? (Aplikace FL-2.2.1)
1. Integracni testovani systemu.
71
Ktery typ akceptacniho testovani se zameruje na to, zda system muze byt efektivne spravovan provoznim personalem? (FL-2.2.1)
1. Provozni akceptacni testovani (OAT).
72
Na jakou otazku odpovida FUNKCNI TESTOVANI? (FL-2.2.2)
1. "CO system dela?" (Overuje funkce a vlastnosti).
73
Na jakou otazku odpovida NEFUNKCNI TESTOVANI? (FL-2.2.2)
1. "JAK DOBRE system funguje?" (Overuje charakteristiky kvality jako vykon, pouzitelnost).
74
Uvedte alespon 3 priklady charakteristik kvality testovanych behem NEFUNKCNIHO TESTOVANI (podle ISO 25010). (FL-2.2.2)
1. Vykonnostni efektivita. 2. Schopnost interakce (Pouzitelnost). 3. Bezpecnost (Security). 4. (Bezporuchovost/Spolehlivost, Kompatibilita, Udrzovatelnost, Flexibilita/Prenositelnost).
75
Na cem je zalozeno TESTOVANI METODOU BILE SKRINKY (White-box)? (FL-2.2.2)
1. Na znalosti VNITRNI STRUKTURY kodu, architektury nebo navrhu systemu.
76
Jaky je hlavni cil TESTOVANI METODOU BILE SKRINKY? (FL-2.2.2)
1. Dosahnout urciteho stupne POKRYTI STRUKTURY (napr. prikazu, vetvi). 2. Odhalit defekty v logice kodu.
77
Na cem je zalozeno TESTOVANI METODOU CERNE SKRINKY (Black-box)? (FL-2.2.2)
1. Na SPECIFIKACICH a EXTERNIM CHOVANI systemu, bez znalosti jeho vnitrni implementace.
78
Jaky je hlavni cil TESTOVANI METODOU CERNE SKRINKY? (FL-2.2.2)
1. Overit, zda system splnuje specifikovane pozadavky a chova se podle ocekavani na zaklade danych vstupu.
79
Ktery typ testovani by overoval, zda se uzivatel muze prihlasit do systemu pomoci spravneho jmena a hesla? (Aplikace FL-2.2.2)
1. Funkcni testovani.
80
Ktery typ testovani by meril, jak rychle system zobrazi vysledky vyhledavani pri 100 soucasne prihlasenych uzivatelich? (Aplikace FL-2.2.2)
1. Nefunkcni testovani (konkretne vykonnostni testovani / zatezove testovani).
81
Ktery typ testovani by se zameril na overeni, ze vsechny podminky v IF-ELSE prikazu byly alespon jednou vykonany? (Aplikace FL-2.2.2)
1. Testovani metodou bile skrinky (konkretne testovani vetvi).
82
Jaky je ucel KONFIRMACNIHO TESTOVANI (Re-testing)? (FL-2.2.3)
1. Overit, ze puvodne nahlaseny defekt byl USPESNE OPRAVEN.
83
Kdy se typicky provadi KONFIRMACNI TESTOVANI? (FL-2.2.3)
1. PO TOM, co vyvojari oznami, ze defekt opravili a je k dispozici nova verze softwaru.
84
Jaky je ucel REGRESNIHO TESTOVANI? (FL-2.2.3)
1. Overit, ze zmeny provedene v softwaru (napr. oprava defektu, nova funkce) NEZPUSOBILY NEZAMERNE negativni dopady (regrese) v JIZ EXISTUJICICH castech systemu.
85
Kdy se typicky provadi REGRESNI TESTOVANI? (FL-2.2.3)
1. PO KAZDE zmene v softwaru nebo jeho prostredi.
86
Co je to ANALYZA DOPADU (Impact Analysis) v kontextu regresniho testovani? (FL-2.2.3)
1. Analyza, ktera pomaha identifikovat, ktere casti systemu mohly byt zmenou ovlivneny a ktere testy by mely byt prioritne spusteny v ramci regresniho testovani.
87
Proc jsou regresni testy casto vhodnym kandidatem na AUTOMATIZACI? (FL-2.2.3)
1. Protoze regresni sady byvaji rozsahle a spousteji se casto (po kazde zmene), takze automatizace setri cas a usili.
88
Tester znovu spousti test, ktery predtim selhal, aby overil, ze oprava vyvojare funguje. Jde o konfirmacni nebo regresni testovani? (Aplikace FL-2.2.3)
1. Konfirmacni testovani.
89
Po implementaci nove platebni metody v e-shopu testeri overuji, ze stale funguje registrace uzivatelu a vyhledavani produktu. Jde o konfirmacni nebo regresni testovani? (Aplikace FL-2.2.3)
1. Regresni testovani.
90
Lze nefunkcni testy (napr. vykonnostni) provadet na urovni komponentoveho testovani? (Aplikace FL-2.2.1, FL-2.2.2)
1. ANO. Nektere nefunkcni charakteristiky (napr. efektivita vyuziti zdroju komponentou) mohou byt testovany jiz na urovni komponent.
91
Je mozne, aby testovaci pripad byl zaroven funkcni a navrzeny pomoci techniky cerne skrinky? (Aplikace FL-2.2.2)
1. ANO. Napriklad test overujici prihlasovaci funkci (funkcni) muze byt navrzen na zaklade specifikace (cerna skrinka), aniz by tester znal implementaci.
92
Co je hlavnim cilem TESTOVANI UDRZBY? (FL-2.3.1)
1. Overit, ze zmeny v jiz PROVOZOVANEM systemu byly implementovany spravne.
2. Overit, ze zmeny nezpusobily nezamerne negativni dopady (regrese).
93
Uvedte alespon 2 typicke SPOUSTECE (Triggers) pro TESTOVANI UDRZBY. (FL-2.3.1)
1. Modifikace (napr. vylepseni, opravy, hotfixy).
2. Migrace (napr. zmena provozniho prostredi).
3. (Vyrazeni z provozu).
94
Co zahrnuje MODIFIKACE jako spoustec testovani udrzby? (FL-2.3.1)
1. Planovana vylepseni (nove funkce).
2. Opravne zmeny (opravy defektu).
3. Hotfixy (rychle opravy kritickych defektu).
95
Co je to MIGRACE v kontextu testovani udrzby? (FL-2.3.1)
1. Zmena provozniho prostredi, ve kterem system bezi (napr. novy OS, databaze, hardware, cloud).
96
Na co se muze zamerit testovani pri VYRAZENI SYSTEMU Z PROVOZU? (FL-2.3.1)
1. Testovani archivace dat.
2. Testovani obnovy archivovanych dat.
3. (Testovani konverze dat do noveho systemu).
97
Na jakych faktorech zavisi ROZSAH testovani udrzby? (FL-2.3.1)
1. Mira rizika zmeny.
2. Velikost stavajiciho systemu.
3. Rozsah samotne zmeny.
98
Co je to ANALYZA DOPADU (Impact Analysis) v kontextu testovani udrzby? (FL-2.3.1)
1. Analyza, ktera identifikuje, ktere casti systemu budou zmenou (primou ci neprimou) ovlivneny a jaky bude potrebny rozsah testovani.
99
Zahrnuje testovani udrzby KONFIRMACNI testovani? (FL-2.3.1)
1. ANO. Overuje se, ze provedena zmena (napr. oprava) byla implementovana spravne.
100
Zahrnuje testovani udrzby REGRESNI testovani? (FL-2.3.1)
1. ANO. Overuje se, ze provedena zmena nezpusobila nezamerne negativni dopady v nezmenenych castech systemu.
101
Pri testovani nove verze operacniho systemu, na kterem bezi stavajici aplikace, jde o jaky typ spoustece testovani udrzby? (Aplikace FL-2.3.1)
1. Migrace (zmena provozniho prostredi).
102
Oprava bezpecnostni zranitelnosti v produkcnim systemu je prikladem jakeho typu MODIFIKACE? (Aplikace FL-2.3.1)
1. Opravna zmena (nebo Hotfix, pokud jde o kritickou a rychlou opravu).
103
Pridani moznosti platby pres PayPal do existujiciho e-shopu je prikladem jakeho typu MODIFIKACE? (Aplikace FL-2.3.1)
1. Planovane vylepseni (Enhancement).
104
Proc je analyza dopadu dulezita pred provedenim testovani udrzby? (FL-2.3.1)
1. Pomaha urcit efektivni rozsah testovani (co vsechno je potreba otestovat) a tim setri cas a zdroje, pricemz minimalizuje riziko opomenuti dulezitych testu.
105
Testovani udrzby se tyka pouze oprav chyb. Je toto tvrzeni spravne? (FL-2.3.1)
1. NE. Tyka se jakychkoli zmen v provozovanem systemu, vcetne vylepseni, migraci nebo vyrazeni.
106
Je nutne provadet regresni testovani i pri malych opravach (hotfixech) v ramci testovani udrzby? (FL-2.3.1)
1. ANO, obecne je to doporuceno, protoze i mala zmena muze mit nezamerne dopady. Rozsah regresniho testovani by mel odpovidat riziku.
107
Firma se rozhodla ukoncit provoz stareho CRM systemu a zajistit, aby vsechna data klientu byla spravne prevedena do noveho systemu a stara data bezpecne smazana. O jaky spoustec testovani udrzby se jedna? (Aplikace FL-2.3.1)
1. Vyrazeni z provozu (s prvky migrace/konverze dat).
108
Je analyza dopadu soucasti testovani udrzby nebo ji predchazi? (FL-2.3.1)
1. Analyza dopadu typicky PREDCHAZI samotnemu testovani udrzby (a casto i implementaci zmeny), protoze pomaha definovat rozsah potrebneho testovani.
109
Testovani udrzby se provadi pouze na softwaru, ktery je jiz v produkcnim provozu. Je toto tvrzeni spravne? (FL-2.3.1)
1. ANO. Testovani udrzby se tyka modifikaci a zmen v systemu, ktery jiz byl nasazen a je pouzivan.
110
Pokud se meni pouze konfigurace serveru, na kterem bezi aplikace, je potreba provest testovani udrzby? (FL-2.3.1)
1. ANO. Jde o formu migrace (zmena provozniho prostredi) a je potreba overit, ze aplikace v nove konfiguraci funguje spravne (funkcni i ne-funkcni aspekty).
111
Ktery typ testovani je obzvlast dulezity pri testovani udrzby, aby se zajistilo, ze zmeny neovlivnily negativne existujici funkcionalitu? (FL-2.2.3, FL-2.3.1)
1. Regresni testovani.

ISTQB CTFL (4 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions