ISTQB - CZ glossary

Question 1

případ zneužití (=abuse case)

Answer 1

Případ užití, ve kterém někteří aktéři se zlým úmyslem způsobují škody na systému nebo jiným aktérům.

Question 2

akceptační kritéria (=acceptance criteria)

Answer 2

Výstupní kritéria, která musí komponenta nebo systém splňovat proto, aby mohly být akceptovány uživatelem,
zákazníkem nebo jinou oprávněnou osobou.

Question 3

akceptační testování (=acceptance testing)

Answer 3

Formální testování zohledňující potřeby, požadavky a obchodní procesy uživatele, vykonávané za účelem zjištění, zda systém splňuje akceptační kritéria a které umožňuje uživateli, zákazníkovi nebo jiné autorizované osobě určit, zda má
nebo nemá být daný systém akceptován.

Question 4

usnadnění (=accessibility)

Answer 4

Míra, do jaké může být komponenta nebo systém využíván osobami s nejširší možnou škálou vlastností a schopností k
dosažení stanoveného cíle v konkrétním kontextu použití.

Question 5

testování přístupnosti (=accessibility testing)

Answer 5

Testování s cílem zjistit lehkost, která umožňuje uživatelům s postižením používat komponentu nebo systém.

Question 6

sběr účtů (=account harvesting)

Answer 6

Proces získávání seznamů e-mailových adres pro použití v hromadných e-mailových zprávách.

Question 7

přesnost (=accuracy)

Answer 7

Způsobilost softwarového produktu poskytovat správné nebo dohodnuté výsledky nebo výstupy s potřebnou mírou
přesnosti.

Question 8

testování přesnosti (=accuracy testing)

Answer 8

Proces testování za účelem zjištení přesnosti softwarového produktu.

Question 9

provádění (IDEAL) (=acting (IDEAL))

Answer 9

Fáze v modelu IDEAL (provádění - acting), ve kterém jsou zlepšení vytvořena, aplikována do praxe a nasazena v organizaci. Fáze provádění (acting) se skládá z následujících aktivit: vytvoření řešení, testování řešení/pilot, zdokonalování
řešení a implementace řešení.

Question 10

aktér (=actor)

Answer 10

Uživatel nebo jiná osoba, která určitým způsobem přichází do styku s testovaným systémem.

Question 11

skutečný výsledek (=actual result)

Answer 11

Chování vytvořené/pozorované při testování systému nebo komponenty.

Question 12

ad-hoc revize (=ad hoc reviewing)

Answer 12

Revizní technika prováděná nezávislými revidujícími neformálně bez strukturovaného procesu.

Question 13

ad hoc testování (=ad hoc testing)

Answer 13

Testování prováděné neformálně; není k dispozici příprava formálních testů, nejsou použity žádně techniky návrhu testů,
neexistují žádná očekávání ohledně výsledků a testy jsou prováděny dle libovolného uvážení.

Question 14

adaptabilita (=adaptability)

Answer 14

Schopnost softwarového produktu být adaptován do rozdílných specifikovaných prostředí bez použití jiných činností
nebo prostředků, než těch, které jsou pro tento účel uvažovaným softwarem poskytovány.

Question 15

agilní manifest (=Agile Manifesto)

Answer 15

Prohlášení o hodnotách, které jsou základem pro agilní vývoj softwaru. Tyto hodnoty jsou: (preferování) jednotlivců a interakcí před procesy a nástroji, (preferování) reakce na změnu před sledováním plánu, (preferování) spolupráce se
zákazníkem před vyjednáváním o smlouvě.

Question 16

agilní vývoj softwaru (=Agile software

development)

Answer 16

Skupina metodik vývoje softwaru založená na iterativním inkrementálním vývoji, kde se požadavky a řešení vyvíjejí
během spolupráce v samoorganizujících a mezifunkčních týmech.

Question 17

agilní testování (=Agile testing)

Answer 17

Postup testování pro projekt, který využívá metodiku agilního vývoje softwaru; zahrnuje techniky a metody jako jsou extrémní programování (XP), zachází s vývojem jako se zákazníkem testování a zdůrazňuje princip návrhu test-first.

Question 18

alfa testování (=alpha testing)

Answer 18

Simulované nebo skutečné testování prováděné v testovacím prostředí vývojářské organizace, ale lidmi mimo vývojový
tým.

Question 19

analytická testovací strategie (=analytical test strategy)

Answer 19

Testovací strategie, kdy testovací tým analyzuje testovací bázi, aby identifikoval testovací podmínky, které mají být
pokryty.

Question 20

analytické testování (=analytical testing)

Answer 20

Testování založené na systematické analýze, např. produktových rizik nebo požadavků.

Question 21

analyzovatelnost (=analyzability)

Answer 21

Schopnost softwarového produktu být diagnostikován kvůli nedostatkům nebo příčinám selhání (poruch) v samotném
softwaru nebo kvůli identifikaci částí, které mají být modifikovány.

Question 22

anomálie (=anomaly)

Answer 22

Jakákoliv okolnost, která se liší od očekávání plynoucích ze specifikace požadavků, z dokumentace návrhu, z uživatelské dokumentace, ze standardů atd. nebo z něčích dojmů či zkušeností. Anomálie mohou být nalezeny (mimo jiné, ale ne jenom) během revize (přezkoumání), testování, analýzy, kompilace nebo užívání softwarového produktu nebo
aplikovatelné dokumentace.

Question 23

anti-malware (=anti-malware)

Answer 23

Software, který je použit k detekci a potlačení malwaru.

Question 24

anti-vzor (=anti-pattern)

Answer 24

Opakovaná akce, proces, struktura nebo opakovaně použitelné řešení, které se původně zdálo prospěšné a je běžně
užívané, ale je neefektivní a/nebo kontraproduktivní v praxi.

Question 25

API (=API)

Answer 25

Zkratka pro aplikační programové rozhraní (Application Programming Interface).

Question 26

testování API (=API testing)

Answer 26

Testování kódu, který umožňuje komunikaci mezi různými procesy, programy a/nebo systémy. Testování API často zahrnuje negativní testování, např. validaci robustnosti zpracování dat. Viz také testování rozhraní.

Question 27

hodnotící report (=assessment report)

Answer 27

Dokument, který shrnuje výsledky hodnocení, např. závěry, doporučení a zjištění.

Question 28

hodnotitel (=assessor)

Answer 28

Osoba, která vykonává hodnocení; kterýkoliv člen hodnotícího týmu.

Question 29

atomická podmínka (=atomic condition)

Answer 29

Podmínka, která se dále nedá rozložit, např. taková, která neobsahuje dvě nebo více jednoduchých podmínek spojených pomocí logických operátorů (AND, OR, XOR).

Question 30

vektor útoku (=attack vector)

Answer 30

Cesta nebo způsoby, kterými může útočník se zlým úmyslem získat přístup k systému.

Question 31

testování založené na útoku (=attack-based testing)

Answer 31

Technika založená na zkušenostech, která využívá útoky na software k vyvolání selhání a to zejména takových, které souvisí s bezpečností.

Question 32

útočník (=attacker)

Answer 32

Osoba nebo proces, který se pokouší bez povolení o přístup k datům, funkcím nebo jiným vymezeným oblastem systému s možným zlým úmyslem.

Question 33

atraktivnost (=attractiveness)

Answer 33

Schopnost softwarového produktu být atraktivní (lákavý) pro uživatele.

Question 34

audit (=audit)

Answer 34

Nezávislé zhodnocení produktu, procesu nebo sady procesů prováděné třetí stranou s cílem ohodnocení shody se specifikacemi, standardy, smluvními dohodami nebo jinými kritérii.

Question 35

auditní stopa (=audit trail)

Answer 35

Cesta celým procesem, pomocí které lze zpětně vysledovat původní vstup do procesu (např. data), kdy je procesní výstup brán jako startovní bod. To pak pomáhá při analýze defektu a umožňuje provedení procesního auditu.

Question 36

autentifikace (=authentication)

Answer 36

Procedura s cílem zjistit, zda je osoba nebo proces tím, za koho se vydává.

Question 37

autorizace (=authorization)

Answer 37

Povolení k užívání zdrojů, které je dáno uživateli nebo procesu.

Question 38

automatizovaný testware (=automated testware)

Answer 38

Testware použitý v automatizovaném testování, např. automatizační skripty.

Question 39

hustota defektů v automatizačním kódu (=automation code defect density)

Answer 39

Hustota defektů v komponentě automatizačního kódu testu.

Question 40

dostupnost (=availability)

Answer 40

Míra, do jaké je komponenta nebo systém provozuschopný(-á) a dostupný(-á) pro užívání.

Question 41

systém vyvážených ukazatelů | balanced scorecard) (=balanced scorecard

Answer 41

Nástroj strategického řízení výkonnosti na měření toho, zda jsou provozní aktivity společnosti v souladu s jejími cíli v rámci obchodní vize a strategie.

Question 42

základní sestava (baseline) (=baseline)

Answer 42

Specifikace nebo softwarový produkt, který byl formálně revidován (přezkoumán) nebo bylo dohodnuto předem, že bude sloužit jako základ pro další vývoj. Tento základ může být změněn pouze prostřednictvím formálního procesu změnového řízení.

Question 43

základní blok (=basic block)

Answer 43

Sekvence jednoho nebo více na sebe navazujících spustitelných příkazů, které neobsahují žádné větve. Pozn. uzel v grafu toku řízení představuje základní blok.

Question 44

základní testovací sada (=basis test set)

Answer 44

Sada testovacích případů odvozených z vnitřní struktury komponenty nebo specifikace. Tato sada zajišťuje, že bude dosaženo 100% pokrytí dle specifikovaného kritéria.

Question 45

chování (=behavior)

Answer 45

Odpověď komponenty nebo systému na sadu vstupních hodnot nebo podmínek.

Question 46

srovnávací test (benchmark) (=benchmark test)

Answer 46

(1) Standard, proti kterému je provedeno měření nebo srovnání. (2) Test, který je využíván pro srovnání systémů nebo komponent mezi sebou nebo komponenty nebo systému proti danému standardu.

Question 47

nejlepší postup (best practise) (=best practice)

Answer 47

Dokonalejší metoda nebo inovativní postup, který přispívá ke zlepšení výkonnosti organizace v daném kontextu, obvykle hodnocená jako nejlepší podobnými organizacemi.

Question 48

beta testování (=beta testing)

Answer 48

Simulované nebo skutečné produkční testování prováděné na externí straně lidmi mimo společnost, která produkt vyvinula.

Question 49

testování velký třesk (big-bang) (=big-bang testing)

Answer 49

Koncept integračního testování, ve kterém je integrace softwarových a/nebo hardwarových elementů do komponenty nebo celého systému upřednostňována před integraci v dané úrovni.

Question 50

technika návrhu testů černé skříňky (=black-box test design technique)

Answer 50

Procedura s cílem odvození a/nebo výběru testovacích případů, založená na analýze funkcionální nebo nefunkcionální specifikace komponenty nebo systému bez vazby na jejich interní strukturu.

Question 51

technika testování černé skříňky (=black-box test technique)

Answer 51

Procedura s cílem odvození a/nebo výběru testovacích případů, založená na analýze funkcionální nebo nefunkcionální specifikace komponenty nebo systému bez vazby na jejich interní strukturu.

Question 52

testování černé skříňky (=black-box testing)

Answer 52

Funkcionální nebo nefunkcionální testování bez vztahu k vnitřní struktuře komponenty nebo systému.

Question 53

blokovaný testovací případ (=blocked test case)

Answer 53

Testovací případ, který nelze provést, protože nejsou splněny vstupní podmínky pro jeho provedení.

Question 54

botnet (=botnet)

Answer 54

Síť napadených počítačů nazývaných boti nebo roboti, která je řízena třetí stranou, a která je použita pro posílání malwaru nebo spamu, případně ke spuštění útoků.

Question 55

(integrační) testování zdola- nahoru (=bottom-up testing)

Answer 55

Přírůstkový přístup k integračním testům, kdy jsou nejprve testovány komponenty nejnižší úrovně, které se pak používají k usnadnění testování komponent vyšší úrovně. Tento proces se opakuje, dokud není testována komponenta v nejvyšší úrovni.

Question 56

hraniční hodnota (=boundary value)

Answer 56

Minimální nebo maximální hodnota v rámci setřízené třídy ekvivalence.

Question 57

analýza hraničních hodnot (=boundary value analysis)

Answer 57

Technika návrhu testů (převážně) černé skříňky, ve které jsou testovací případy navrhované s ohledem na hraniční hodnoty.

Question 58

pokrytí hraničních hodnot (=boundary value coverage)

Answer 58

Procento hraničních hodnot, které je vykonáno testovací sadou.

Question 59

větev (=branch)

Answer 59

Základní blok (kódu), který může být vybrán pro provedení na základě konstrukce programu, ve které je k dispozici buďto jedna ze dvou anebo dvě nebo více alternativních cest programu, např. přepínač (case/switch), skok, příkaz goto nebo podmínka.

Question 60

pokrytí větví (=branch coverage)

Answer 60

Procento větvení, které je vykonáno v rámci testovací sady. 100% pokrytí větví znamená jak 100% pokrytí rozhodnutí, tak 100% pokrytí příkazů.

Question 61

testování větví (=branch testing)

Answer 61

Technika návrhu testů bílé skříňky, ve které jsou testovací případy navrhovány tak, aby došlo k provedení (všech) větví.

Question 62

vyrovnávací paměť (buffer) (=buffer)

Answer 62

Zařízení nebo datové úložiště, které slouží k dočasnému ukládání dat z důvodu rozdílných rychlostí toku dat, času nebo výskytu událostí. Důvodem pro využívání vyrovnávací paměti může být i rozdíl v množství dat, které jsou schopny zpracovat zařízení nebo procesy podílející se na jejich přenosu či použití.

Question 63

přetečení vyrovnávací paměti (=buffer overflow)

Answer 63

Selhání přístupu do paměti z důvodu pokusu procesu o uložení dat za hranice délky pevné délky vyrovnávací paměti, což má za následek přepsání přilehlých oblastí paměti nebo vyvolání výjimky přetečení.

Question 64

ověřovací test sestavení (buildu) (=build verification test (BVT))

Answer 64

Sada automatických testů, která validuje integritu každého sestavení a ověřuje její klíčovou funkcionalitu, stabilitu a testovatelnost. Jedná se o postup, kdy jsou dodávky sestavovány velmi často (např. agilní projekty) a tato sada testů je pak spouštěna s každým novým sestavením předtím, než je systém/produkt uvolněn pro další testování.

Question 65

graf burn-down (=burndown chart)

Answer 65

Zveřejněný graf, který znázorňuje pracnost v závislosti na čase v dané iteraci. Zobrazuje stav a trend při plnění úkolů v iteraci. Osa X typicky reprezentuje dny v iteraci, osa Y reprezentuje zbývající pracnost (obvykle buď v ideálních člověko- hodinách nebo v tzv. story points).

Question 66

testování založené na byznysových procesech (=business process-based testing)

Answer 66

Přístup k testování, ve kterém jsou testovací případy navrženy na základě popisů a/nebo znalostí o byznysových procesech.

Question 67

graf volání (=call graph)

Answer 67

Abstraktní reprezentace vztahů mezi voláním jednotlivých programových částí v programu.

Question 68

model hodnocení vyspělosti a zralosti procesů (CMMI) (=Capability Maturity Model Integration (CMMI))

Answer 68

Rámec, který popisuje klíčové elementy efektivního vývoje produktu a procesu údržby. CMMI pokrývá doporučené postupy pro plánování, technické oblasti a řízení vývoje produktu a údržby.

Question 69

nahraj/přehraj (=capture/playback)

Answer 69

Přístup k automatizaci testování, kdy jsou vstupy do testovaného objektu zaznamenány během manuálního testování s cílem vytvořit automatizované testovací skripty, které by mohly být spouštěny (opakovaně) později (tj. přehrány).

Question 70

nástroj nahraj/přehraj (=capture/playback tool)

Answer 70

Typ nástroje pro provádění testů, ve kterém jsou vstupy zaznamenány při ručním testováním s cílem vytvořit automatizované testovací skripty, které mohou být spouštěny později (tj. přehrány). Tyto nástroje jsou často používány na podporu automatizovaného regresního testování.

Question 71

CASE (=CASE)

Answer 71

Zkratka pro počítačem podporované softwarové inženýrství (Computer Aided Software Engineering).

Question 72

CAST (=CAST)

Answer 72

Zkratka pro počítačem podporované testování softwaru (Computer Aided Software Testing).

Question 73

kauzální analýza (=causal analysis)

Answer 73

Analýza defektů s cílem určit jejich kořenovou příčinu.

Question 74

graf příčiny a následku (=cause-effect diagram)

Answer 74

Grafické znázornění, které slouží k uspořádání a zobrazení vzájemných možných vztahů různých kořenových příčin problému. Možné příčiny skutečného nebo potenciálního defektu nebo selhání jsou organizovány v kategoriích a podkategoriích v horizontální stromové struktuře, ve které je (potenciální) defekt nebo selhání znázorněn jako kořenový uzel.

Question 75

graf příčin a následků (=cause-effect graph)

Answer 75

Grafické znázornění vstupů a/nebo podnětů (příčin) a jim odpovídajících výstupů (následků), které může být použito pro návrh testovacích případů.

Question 76

znázornění příčiny a následku (=cause-effect graphing)

Answer 76

Technika návrhu testů černé skříňky, ve které jsou testovací případy navrženy z diagramů příčiny a následku.

Question 77

certifikace (=certification)

Answer 77

Proces potvrzení (např. složením zkoušky), že komponenta, systém nebo osoba je ve shodě s pro ni specifikovanými požadavky.

Question 78

řízení změn (=change management)

Answer 78

(1) Strukturovaný přístup k přechodu jedinců a organizací ze současného do požadovaného budoucího stavu. (2) Řízený způsob, jak dosáhnout změny nebo navrhované změny ve výrobku nebo službě.

Question 79

změnitelnost (=changeability)

Answer 79

Schopnost softwarového produktu umožnit, aby byla specifikovaná modifikace implementována.

Question 80

revize založená na kontrolním | seznamu (=checklist-based reviewing)

Answer 80

Revizní technika, při které se postupuje podle seznamu otázek nebo požadovaných atributů.

Question 81

testování založené na kontrolních seznamech (=checklist-based testing)

Answer 81

Technika testování založená na zkušenostech, kdy tester používá obecný seznam položek (kontrolní seznam), které mají být zaznamenány, zkontrolovány nebo na ně má být pamatováno, příp. soubor pravidel nebo kritérií, proti kterým musí být produkt ověřen.

Question 82

strom klasifikací (=classification tree)

Answer 82

Strom ukazující hiearchicky seřazené třídy ekvivalence, což je použito k návrhu testovacích případů (při užití metody stromu klasifikací).

Question 83

metoda stromové klasifikace (=classification tree method)

Answer 83

Technika návrhu testů černé skříňky, při které jsou testovací případy popsány jako strom klasifikací a navrženy tak, aby došlo k vykonání kombinací představitelů vstupních a/nebo výstupních domén.

Question 84

CLI (=CLI)

Answer 84

Zkratka pro rozhraní k příkazové řádce (command-line interface).

Question 85

testování pomocí příkazové řádky | CLI testování) (=CLI testing

Answer 85

Testování prováděné odesíláním příkazů do testovaného softwaru pomocí speciálního rozhraní založeném na příkazovém řádku.

Question 86

koexistence (=co-existence)

Answer 86

Schopnost softwarového produktu koexistovat s jiným nezávislým softwarem ve společném prostředí sdílejícím společné zdroje.

Question 87

kód (=code)

Answer 87

Počítačové instrukce a definice dat vyjádřené v programovacím jazyce nebo ve formě výstupu z asembleru, kompilátoru nebo jiného překladače.

Question 88

pokrytí kódu (=code coverage)

Answer 88

Analytická metoda, která určuje, jaké části softwaru byly prověřeny (pokryty) testovací sadou, a které části nebyly prověřeny, např. pokrytí příkazů, pokrytí rozhodnutí nebo pokrytí podmínek.

Question 89

závislé chování (=codependent behavior)

Answer 89

Nadměrná emoční nebo psychická závislost na jiné osobě, obzvláště při pokusu změnit stávající (nežádoucí) chování této osoby při současné podpoře tohoto chování. Například při testování softwaru, testeři si stěžují na zpožděnou dodávku softwaru určeného k testování, a přitom si zároveň užívají pocit hrdinství, kdy pracují přesčas. Tím, že takto dokáží získat potřebný čas při pozdních dodávkách, podporují tato zpoždění i do budoucna.

Question 90

kombinační testování (=combinatorial testing)

Answer 90

Technika návrhu testů černé skříňky, při které jsou testovací případy navrženy tak, aby došlo k vykonání specifických kombinací hodnot několika (vstupních) parametrů.

Question 91

krabicový software (COTS - commercial off-the-shelf) (=commercial off-the-shelf (COTS))

Answer 91

Softwarový produkt vyvinutý pro širší trh (tj. pro velké množství zákazníků), který je jim dodáván v jednotné (identické) formě.

Question 92

kompatibilita (=compatibility)

Answer 92

Míra, ve které si může komponenta nebo systém vyměňovat informace s jinými komponentami nebo systémy.

Question 93

kompilátor (=compiler)

Answer 93

Softwarový nástroj, který překládá programy vyjádřené ve vysokoúrovňovém jazyce do jejich ekvivalentu ve strojovém jazyce.

Question 94

složitost (=complexity)

Answer 94

Stupeň složitosti komponenty nebo systému ve smyslu pochopení jejího návrhu a/nebo interní struktury, údržby a ověřování funkčnosti.

Question 95

soulad (=compliance)

Answer 95

Schopnost softwarového produktu dodržovat standardy, konvence nebo pravidla v zákonech a podobných předpisech.

Question 96

testování shody (=compliance testing)

Answer 96

Proces testování s cílem určit shodu komponenty nebo systému.

Question 97

komponenta (=component)

Answer 97

Nejmenší část systému, kterou lze izolovaně testovat.

Question 98

integrační testování komponent (=component integration | testing)

Answer 98

Testování prováděné s cílem odhalit defekty v rozhraních a interakcích mezi integrovanými komponentami.

Question 99

specifikace komponenty (=component specification)

Answer 99

Popis funkčnosti komponenty ve smyslu výstupních hodnot pro dané vstupní hodnoty za specifikovaných podmínek a ve smyslu požadovaného nefunkcionálního chování (např. vytíženost zdrojů).

Question 100

testování komponent (=component testing)

Answer 100

Testování jednotlivých hardwarových nebo softwarových komponent.

Question 101

složená podmínka (=compound condition)

Answer 101

Dvě nebo více jednotlivých podmínek spojených pomocí logického operátoru (AND, OR nebo XOR), např. "A>B AND C>1000".

Question 102

počítačová forenzní věda (=computer forensics)

Answer 102

Praktika určení způsobu, kterým byl proveden úspěšný bezpečnostní útok a vyhodnocení jeho škod.

Question 103

testování souběžnosti (=concurrency testing)

Answer 103

Testování s cílem zjistit, jak komponenta nebo systém zpracovávají souběh dvou nebo více současně probíhajících (konkurenčních) činností. Souběh činností může být dosažen buď jejich překrýváním nebo jejich současným provedením.

Question 104

podmínka (=condition)

Answer 104

Logický výraz, který je možno vyhodnodit jako Pravda nebo Nepravda, např. A>B.

Question 105

pokrytí podmínek (=condition coverage)

Answer 105

Procento výsledků podmínek, které jsou vykonány v rámci testovací sady. Pro 100% pokrytí podmínek je nutno mít každou jednotlivou podmínku v každém rozhodovacím příkazu otestovánu jako Pravda a Nepravda.

Question 106

výsledek (vyhodnocení) | podmínky (=condition outcome)

Answer 106

Vyhodnocení podmínky jako pravdivé (True) nebo nepravdivé (False).

Question 107

testování podmínek (=condition testing)

Answer 107

Technika návrhu testů bílé skříňky, ve které jsou testovací případy navrženy tak, aby jejich provedení vedlo k vykonání podmínek.

Question 108

interval spolehlivosti (=confidence interval)

Answer 108

Časové období, během něhož musí být v oblasti managementu rizik provedeno nouzové (contingency) opatření, aby bylo možné účinně snížit dopad rizika.

Question 109

konfigurace (=configuration)

Answer 109

Skladba komponenty nebo systému, která je definována počtem, vlastnostmi a vzájemným propojením všech jeho součástí.

Question 110

konfigurační audit (=configuration auditing)

Answer 110

Činnost s cílem ověřit obsah knihoven konfiguračních položek, např. z důvodu souladu se standardy (např. normami).

Question 111

správa konfigurací (=configuration control)

Answer 111

Prvek konfiguračního managementu skládající se z vyhodnocení, koordinace, schválení (nebo neschválení) a implementace změn konfiguračních položek po formálním stanovení identifikace konfigurace.

Question 112

výbor pro správu konfigurací (CCB - configuration control | board) (=configuration control board (CCB))

Answer 112

Skupina osob zodpovědných za vyhodnocení a schválení či zamítnutí navrhovaných změn konfiguračních položek a dále za zajištění implementace schválených změn.

Question 113

identifikace konfigurace (=configuration identification)

Answer 113

Součást konfiguračního managementu, která zahrnuje výběr konfiguračních položek systému a zaznamenávání jejich funkcionálních a fyzických charakteristik v technické dokumentaci.

Question 114

konfigurační položka (=configuration item)

Answer 114

Seskupení pracovních produktů, které je ustanoveno pro účely správy konfigurací, a které je dále v tomto procesu považováno za samostatnou entitu.

Question 115

konfigurační management (=configuration management)

Answer 115

Disciplína aplikující technický a administrativní směr a dohled nad položkami konfigurace s cílem identifikace a zdokumentování jejich funkcionálních a nefunkcionálnich charakteristik. Dále aplikující řízení změn těchto vlastností, nahrávání a reportování změn zpracování a stavu implementace a ověření souladu se stanovenými požadavky.

Question 116

nástroj pro konfigurační management (=configuration management tool)

Answer 116

Nástroj podporující identifikaci a správu konfiguračních položek, jejich změn a verzí a uvolnění jejich základních sestav (baselines).

Question 117

konfirmační testování (=confirmation testing)

Answer 117

Testování, které spouští testovací případy, jež v minulém běhu selhaly, s cílem ověřit úspěšnost nápravných opatření.

Question 118

konzultační testovací strategie (=consultative test strategy)

Answer 118

Testovací strategie, při níž testovací tým spoléhá na vstup jednoho nebo více klíčových zainteresovaných stran (key stakeholders) s cílem určit podrobnosti této strategie.

Question 119

konzultační testování (=consultative testing)

Answer 119

Testování řízené poradenstvím a pokyny vhodných odborníků mimo testovací tým (např. experti na danou technologii a/nebo v daném oboru podnikání).

Question 120

model založený na obsahu (=content-based model)

Answer 120

Procesní model, který poskytuje podrobný popis dobrých technických postupů, např. testovacích.

Question 121

kontinuální reprezentace (=continuous representation)

Answer 121

Reprezentace modelu schopnosti a zralosti (např. CMM/CMMI), kdy jsou jednotlivé úrovně zlepšování procesů v rámci svých procesních oblastí seřazeny v doporučeném pořadí.

Question 122

smluvní akceptační testování (=contractual acceptance | testing)

Answer 122

Akceptační testování prováděné za účelem ověření, zda systém splňuje dané smluvní požadavky.

Question 123

kontrolní graf (=control chart)

Answer 123

Nástroj pro statistickou kontrolu procesu používaný k jeho sledování a určení toho, zda je statisticky řízen. Graficky zobrazuje průměrnou hodnotu a horní a dolní kontrolní limity (nejvyšší a nejnižší hodnoty) procesu.

Question 124

řídící tok (=control flow)

Answer 124

Posloupnost, ve které jsou jednotlivé operace vykonávány během provádění položky testování.

Question 125

analýza řídícího toku (=control flow analysis)

Answer 125

Forma statické analýzy, založená na znázornění unikátních cest (sekvencí událostí) při průběhu skrz komponentu nebo systém. Analýza řídícího toku vyhodnocuje integritu jeho struktur a hledá jeho možné anomálie jako např. uzavřené smyčky nebo logicky nedosažitelné procesní kroky.

Question 126

graf řídícího toku (=control flow graph)

Answer 126

Abstraktní reprezentace všech možných posloupností událostí (cest) při spuštění komponenty nebo systému.

Question 127

testování řídícího toku (=control flow testing)

Answer 127

Přístup k testování založený na struktuře, při kterém jsou testovací případy založeny na vykonání specifických posloupností událostí. Existují různé techniky testování řídícího toku, např. testování rozhodnutí, testování podmínek, testování cest, a platí, že každá z nich má specifický přístup a úroveň pokrytí řídícího toku.

Question 128

konvergenční metrika (=convergence metric)

Answer 128

Metrika, která ukazuje posun směrem k definovanému kritériu, např. konvergence celkového počtu provedených testů k celkovému počtu testů plánovaných k provedení.

Question 129

testování konverze (=conversion testing)

Answer 129

Testování softwaru použitého ke konverzi dat z existujících systémů pro užití v systémech, které existující systémy nahrazují.

Question 130

firemní dashboard (=corporate dashboard)

Answer 130

Prezentace stavu firemních výkonnostních ukazatelů ve formě dashboardu.

Question 131

cena kvality (=cost of quality)

Answer 131

Celkové náklady vynaložené na činnosti a záležitosti spojené s kvalitou a často také rozdělené na náklady na prevenci, ohodnocení, interní vady a externí vady.

Question 132

pokrytí (=coverage)

Answer 132

Míra (vyjádřená v procentech), do jaké byla konkrétní položka prověřena nebo otestována testovací sadou.

Question 133

analýza pokrytí (=coverage analysis)

Answer 133

Měření poměru dosaženého pokrytí vzhledem ke stanovenému pokrytí daného elementu během provádění testu s odkazem na předem stanovená kritéria. Tato kritéria jsou definována, aby bylo možné rozhodnout, zda je potřebné dále testovat, a pokud ano, tak jaké testovací případy použít.

Question 134

položka pokrytí (=coverage item)

Answer 134

Atribut nebo kombinace atributů, které jsou odvozeny z jedné nebo více testovacích podmínek pomocí určité techniky testování, umožňující měření důkladnosti provádění testu.

Question 135

nástroj pro pokrytí (=coverage tool)

Answer 135

Nástroj poskytující objektivní měření toho, jaké strukturální prvky (např. příkazy nebo rozhodnutí) byly prověřeny testovací sadou.

Question 136

klíčový faktor úspěchu (=critical success factor)

Answer 136

Prvek nezbytný pro organizaci nebo projekt určující naplnění jejich poslání. Klíčovými faktory úspěchu jsou ty kritické faktory nebo činnosti potřebné pro zajištění úspěchu.

Question 137

kritické procesy testování (CTP) (=Critical Testing Processes (CTP))

Answer 137

Model založený na obsahu s cílem zlepšení testovacího procesu postavený na dvanácti kritických procesech. Tyto zahrnují řídící procesy, pomocí kterých členové a management posuzují pravomoce a kritické procesy, u kterých výkonnost ovlivňuje zisk a reputaci firmy.

Question 138

cross-site skriptování (XSS) (=cross-site scripting (XSS))

Answer 138

Zranitelnost, která umožňuje útočníkům vložit škodlivý kód do jinak benigních (neškodných) internetových stránek.

Question 139

software na zakázku (=custom software)

Answer 139

Software vyvinutý speciálně pro skupinu uživatelů nebo zákazníků. Opak ke krabicovému softwaru.

Question 140

specifický nástroj (=custom tool)

Answer 140

Softwarový nástroj, který byl vyvinut speciálně pro skupinu uživatelů nebo zákazníků.

Question 141

cyklomatická složitost (=cyclomatic complexity)

Answer 141

Maximální počet lineárních nezávislých cest programem. Cyklomatická složitost může být vypočítána z diagramu jako L- N+2P, kde L=počet hran/spojení, N=počet uzlů, P=počet nespojených částí (nebo orientačně v kódu jako počet podmínek + 1).

Question 142

denní sestavení (daily build) (=daily build)

Answer 142

Aktivita vývoje, při které je celý systém zkompilován a sestaven každý den (často během noci), takže je kdykoliv k dispozici kompletní systém včetně všech posledních změn.

Question 143

dashboard (=dashboard)

Answer 143

Reprezentace dynamických měření provozní výkonnosti nějaké organizace nebo činnosti za použití metrik, které jsou metaforou prvků na palubní desce automobilu jakými jsou například vizuální číselník, čítač, apod. Důsledek událostí nebo činností tak může být snadno pochopen v souvislosti s provozními cíli.

Question 144

definice dat (=data definition)

Answer 144

Vykonatelný příkaz, ve kterém je proměnné přiřazena hodnota.

Question 145

datový tok (=data flow)

Answer 145

Abstraktní znázornění posloupnosti a možných změn stavu datových objektů, kde stav objektu je vytvořený, použitý nebo zrušený.

Question 146

analýza datového toku (=data flow analysis)

Answer 146

Forma statické analýzy založená na definici a použití proměnných.

Question 147

pokrytí toku dat (=data flow coverage)

Answer 147

Procento dvojic "definice-použití" (definition-use), které jsou pokryty testovací sadou.

Question 148

testování toku dat (=data flow testing)

Answer 148

Technika návrhu testů bílé skříňky, při které jsou testovací případy navrženy tak, aby došlo k provedení dvojic "definice- užití" pro dílčí proměnné.

Question 149

zatemnění dat (=data obfuscation)

Answer 149

Transformace dat, která způsobuje komplikované rozpoznání původních dat pro člověka.

Question 150

ochrana osobních dat (=data privacy)

Answer 150

Ochrana osobních údajů či jinak citlivých informací před nežádoucím prozrazením.

Question 151

kvalita dat (=data quality)

Answer 151

Atribut dat, který indikuje jejich správnost s ohledem na předdefinovaná kritéria, např. očekávání byznysu, požadavky na integritu dat, konzistenci dat, apod.

Question 152

testování řízené daty (=data-driven testing)

Answer 152

Skriptovací technika, která uchovává vstupy a očekávané výsledky v tabulce nebo tabulkovém procesoru tak, aby jeden řídící skript mohl vykonat všechny testy v tabulce. Testování řízené daty se často využívá jako podpora pro nástroje na (automatizované) provedení testů, například nástroje typu nahraj/přehraj (capture/playback).

Question 153

testování integrity databáze (=database integrity testing)

Answer 153

Testování metod a procesů pro přístup a řízení dat (databáze) s cílem zajistit, aby 1) metody přístupu, procesy a pravidla pro data fungovala podle očekávání; 2) data nebyla při přístupu do databáze poškozena nebo neočekávaně odstraněna, aktualizována nebo vytvořena.

Question 154

dd cesta (decision-to-decision) (=dd-path)

Answer 154

Cesta mezi dvěma rozhodnutími algoritmu nebo dvěma rozhodovacími uzly odpovídajícího grafického znázornění průchodu algoritmem, která neobsahuje žádná jiná rozhodnutí.

Question 155

ladění (debugging) (=debugging)

Answer 155

Proces hledání, analyzování a odstraňování příčin selhání v softwaru.

Question 156

nástroj pro ladění (debugging tool) (=debugging tool)

Answer 156

Nástroj používaný programátory na reprodukování selhání, prověření stavu programů a nalezení odpovídající chyby. Nástroje pro ladění (debuggery) umožňují programátorům spouštět programy krok za krokem, přerušit běh programu na libovolném příkaze, nastavit a přezkoumat proměnné programu.

Question 157

rozhodnutí (=decision)

Answer 157

Typ příkazu, ve kterém má tok řízení možnost volby mezi dvěma nebo více cestami, jež vedou k sadám následných aktivit.

Question 158

pokrytí rozhodnutí a podmínek (=decision condition coverage)

Answer 158

Procento výstupů všech podmínek a všech rozhodnutí, které jsou vykonány v rámci testovací sady. 100% pokrytí rozhodnutí a podmínek znamená jak 100% pokrytí podmínek, tak 100% pokrytí rozhodnutí.

Question 159

testování podmínek a rozhodnutí (=decision condition testing)

Answer 159

Technika návrhu testů bílé skříňky, ve které jsou testovací případy navrhovány tak, aby došlo k provedení výsledků podmínek a rozhodnutí.

Question 160

pokrytí rozhodnutí (=decision coverage)

Answer 160

Pokrytí výstupů rozhodnutí.

Question 161

výsledek rozhodnutí (=decision outcome)

Answer 161

Výsledek rozhodnutí určující následující příkaz, který má být proveden.

Question 162

rozhodovací tabulka (=decision table)

Answer 162

Tabulka, která ukazuje kombinace vstupů a/nebo podnětů (příčin) spolu s jejich přiřazenými výstupy a/nebo úkony (důsledky), a kterou je možno použít k návrhu testovacích případů.

Question 163

testování dle rozhodovací tabulky (=decision table testing)

Answer 163

Technika testů černé skříňky, při které jsou testovací případy navrženy tak, aby došlo k provedení kombinací vstupů a/nebo podnětů (příčin) uvedených v rozhodovací tabulce.

Question 164

testování rozhodnutí (=decision testing)

Answer 164

Technika návrhu testů bílé skříňky, při které jsou testovací případy navrhovány tak, aby došlo k provedení výstupů rozhodnutí.

Question 165

defekt (=defect)

Answer 165

Nedokonalost nebo nedostatek v pracovním produktu, na jehož základě (tento pracovní produkt) nesplňuje své specifikace nebo požadavky na něj kladené.

Question 166

hustota defektů (=defect density)

Answer 166

Počet defektů pracovního produktu vztažený k jednotkové (tj. normované) velikosti.

Question 167

procento zjištěných defektů (DDP | - defect detection percentage) (=Defect Detection Percentage (DDP))

Answer 167

Poměr počtu defektů nalezených na dané úrovni testování vzhledem k součtu celkového počtu defektů zjištěných na této úrovni, počtu defektů na všech dalších úrovních testování a počtu defektů z produkčního prostředí.

Question 168

management defektů (=defect management)

Answer 168

Proces identifikace a zaznamenávání defektů včetně jejich klasifikace, zkoumání, přijímání opatření k jejich řešení a uzavírání v případě vyřešení.

Question 169

komise pro management defektů (=defect management committee)

Answer 169

Smíšený tým zainteresovaných osob, kteří mají na starosti management defektů od počátečního objevení po konečné rozhodnutí (odstranění, odložení nebo zrušení defektu). V některých případech se jedná o stejný tým jako výbor pro správu konfigurací.

Question 170

nástroj pro management defektů (=defect management tool)

Answer 170

Nástroj, který napomáhá zaznamenávání a sledování stavů defektů.

Question 171

maskování defektu (=defect masking)

Answer 171

Situace, při které není díky výskytu jednoho defektu odhalen defekt jiný.

Question 172

report o defektu (=defect report)

Answer 172

Zaznamenání výskytu defektu, jeho povahy a stavu.

Question 173

taxonomie defektů (=defect taxonomy)

Answer 173

Systém (hiearchických) kategorií, navržený jako užitečná pomůcka pro reprodukování klasifikovaných defektů.

Question 174

typ defektu (=defect type)

Answer 174

Element taxonomie defektů. Taxonomie defektů mohou být identifikovány s ohledem na celou řadu činitelů. Tyto činitele mohou být např. fáze nebo aktivita vývoje, ve které k defektu došlo (chyba ve specifikaci, chyba při kódování), povaha defektu (chyba typu N+1), nesprávnost (např. nesprávný relační operátor, chyba v syntaxi programovacího jazyka, nevhodný předpoklad) nebo problém ve výkonnosti (překročení časového limitu, nedostatečná dostupnost).

Question 175

technika návrhu testů založená na defektech (=defect-based test design technique)

Answer 175

Procedura pro odvození a/nebo výběr testovacích případů zaměřená na jeden nebo více typů defektů, kdy jsou testy vyvíjeny na základě znalostí o těchto typech defektů.

Question 176

dvojice definice-užití (=definition-use pair)

Answer 176

Sdružení definice proměnné s následným použitím této proměnné. Proměnné jsou použity pro výpočty (např. násobení) nebo pro řízení (např. testu nebo kódu) při jeho spuštění (předpřipravené testování).

Question 177

dodávka (=deliverable)

Answer 177

Jakýkoliv (pracovní) produkt, který musí být dodán někomu jinému, než autorovi daného produktu.

Question 178

demilitarizovaná zóna (DMZ) (=demilitarized zone (DMZ))

Answer 178

Fyzická nebo logická část sítě, která obsahuje a vystavuje externě orientované služby organizace nedůvěryhodné síti, obyčejně Internetu.

Question 179

Demingův cyklus (=Deming cycle)

Answer 179

Iterativní čtyřkrokový proces řešení problémů (naplánuj-proveď-ověř-jednej), který se obvykle používá při zlepšování procesů.

Question 180

odepření služeb (DOS) (=denial of service (DOS))

Answer 180

Bezpečnostní útok jehož cílem je přetížit systém (nelegitimními) požadavky tak, že legitimní požadavky nemohou být zpracovány.

Question 181

testování založené na návrhu (=design-based testing)

Answer 181

Přístup k testování, ve kterém jsou testovací případy navrženy na základě (znalosti) architektury a/nebo detailního návrhu komponenty nebo systému (např. testy rozhraní mezi komponentami nebo systémy).

Question 182

testování od stolu (=desk checking)

Answer 182

Testování softwaru nebo specifikace pomocí manuální simulace běhu (např. testování algoritmu s využitím tužky a papíru).

Question 183

vývojářské testování (=development testing)

Answer 183

Formální nebo neformální testování prováděné obvykle vývojáři ve vývojovém prostředí při implementaci komponenty nebo systému.

Question 184

diagnostika (IDEAL) (=diagnosing (IDEAL))

Answer 184

Fáze v modelu IDEAL, která určuje kde se nacházíme v poměru k tomu, kde chceme být. Fáze diagnostiky se skládá z činností, které vytvářejí doporučení pro dosažení požadovaného stavu, a které pomáhají určit současný a požadovaný stav (kterého chceme dosáhnout).

Question 185

testování dokumentace (=documentation testing)

Answer 185

Testování kvality dokumentace, např. uživatelského nebo instalačního návodu.

Question 186

doména hodnot (=domain)

Answer 186

Sada, ze které jsou vybírány platné vstupní a/nebo výstupní hodnoty.

Question 187

doménová analýza (=domain analysis)

Answer 187

Technika návrhu testů černé skříňky, která se používá k identifikaci efektivních a účinných testovacích případů, a při které může nebo musí být testováno několik proměnných současně. Technika zobecňuje třídy ekvivalence a analýzu hraničních hodnot, zároveň je na nich založená.

Question 188

ovladač (=driver)

Answer 188

Softwarová komponenta nebo testovací nástroj, který nahrazuje komponentu, jež zajišťuje řízení a/nebo volání jiné komponenty nebo systému.

Question 189

dynamická analýza (=dynamic analysis)

Answer 189

Proces vyhodnocující chování (např. výkon paměti, využití procesoru) systému nebo komponenty během spuštění.

Question 190

nástroj pro dynamickou analýzu (=dynamic analysis tool)

Answer 190

Nástroj, který za běhu poskytuje informace o stavu softwarového kódu. Tyto nástroje jsou nejčastěji používány k odhalení neadresovaných ukazatelů (pointer), prověření aritmetiky ukazatele a ke sledování alokace, využití a uvolňování paměti a k označení úniku paměti.

Question 191

dynamické srovnávání (=dynamic comparison)

Answer 191

Srovnávání skutečných a očekávaných výsledků, které je prováděno během doby, kdy software běží, např. pomocí nástroje pro provádění testů.

Question 192

dynamické testování (=dynamic testing)

Answer 192

Testování, které zahrnuje spuštění softwaru, komponenty nebo systému.

Question 193

efektivita (=effectiveness)

Answer 193

Schopnost dosahovat očekávaných výsledků.

Question 194

účinnost (=efficiency)

Answer 194

1.) Schopnost softwarového produktu poskytovat vhodný výkon s ohledem na množství použitých zdrojů a za stanovených podmínek. 2.) Schopnost procesu produkovat zamýšlený výstup s ohledem na množství použitých zdrojů.

Question 195

testování účinnosti (=efficiency testing)

Answer 195

Proces testování s cílem zjistit účinnost softwarového produktu.

Question 196

testování základního pokrytí (=elementary comparison | testing)

Answer 196

Technika testování černé skříňky, při které jsou testovací případy navrženy tak, aby došlo k provedení kombinací vstupů za použití konceptu pokrytí modifikovaných podmínek/rozhodnutí.

Question 197

vložený iterační model (=embedded iterative model)

Answer 197

Část modelu vývoje životního cyklu (softwaru), který používá iterační přístup k detailnímu návrhu, ke kódování a k testování v průběhu rámcového sekvenčního modelu. V takovém modelu se dokumentace obecného návrhu připravuje a schvaluje pro celý projekt, ale detailní návrh, vývoj a testování probíhá v iteracích.

Question 198

emoční inteligence (=emotional intelligence)

Answer 198

Schopnost, kapacita a dovednost identifikovat, zhodnotit a řídit vlastní, cizí a skupinové emoce.

Question 199

emulátor (=emulator)

Answer 199

Zařízení, počítačový program nebo systém, který přijímá stejné vstupy a vydává stejné výstupy jako u daného systému.

Question 200

šifrování (=encryption)

Answer 200

Proces kódování informací, jehož cílem je zajistit, aby původní informace mohly získat pouze autorizované entity, obvykle pomocí zvláštního klíče nebo dešifrovacího procesu.

Question 201

vstupní kritéria (=entry criteria)

Answer 201

Sada podmínek, které určují zahájení prací na daném úkolu.

Question 202

vstupní bod (=entry point)

Answer 202

Spustitelný příkaz nebo procesní krok, který definuje bod, v němž je zamýšlený začátek daného procesu.

Question 203

třída ekvivalence (=equivalence partition)

Answer 203

Část vstupní nebo výstupní domény, pro kterou je na základě specifikace předpokládané chování komponenty nebo systému totožné.

Question 204

pokrytí tříd ekvivalence (=equivalence partition | coverage)

Answer 204

Procento tříd ekvivalence, které jsou vykonány v rámci testovací sady.

Question 205

rozdělení tříd ekvivalence (=equivalence partitioning)

Answer 205

Technika testování černé skřínky, při které jsou (z důvodu optimalizace) testovací případy navrženy tak, aby byl pro pokrytí každé třídy ekvivalence použit právě jeden její typický zástupce.

Question 206

ekvivalentní pracnost pro manuální testování (EMTE - equivalent manual test effort) (=equivalent manual test effort (EMTE))

Answer 206

Pracnost, která by vyžadovalo provedení testů manuálně.

Question 207

chyba (=error)

Answer 207

Lidská činnost, která má za následek nesprávné výsledky.

Question 208

odhadování chyb (=error guessing)

Answer 208

Technika testování, při níž jsou testy odvozeny na základě znalosti testera o již objevených chybách nebo jeho obecných znalostech o nich.

Question 209

tolerance k chybám (=error tolerance)

Answer 209

Schopnost systému nebo komponenty pokračovat v normálním provozu i přes přítomnost chybných vstupů.

Question 210

uniklý defekt (=escaped defect)

Answer 210

Defekt, který nebyl odhalen v předchozí úrovni testování, jež byla zaměřená na odhalení podobného typu defektů.

Question 211

zavádění (model IDEAL) (=establishing (IDEAL))

Answer 211

Fáze v modelu IDEAL (Establishing), kdy je plánováno, jak organizace dosáhne svého cíle. Fáze zavádění se skládá z aktivit definice priorit, stanovení strategie k dosažení definovaného cíle a plánování dílčích akcí.

Question 212

etický hacker (=ethical hacker)

Answer 212

Bezpečnostní tester, který používá hackerské postupy.

Question 213

model excelence Evropské nadace pro management kvality (EFQM - European Foundation for Quality Management) (=European Foundation for Quality Management excellence model (EFQM))

Answer 213

Dobrovolný rámec pro systém managementu kvality organizace, definovaný a vlastněný Evropskou nadací pro management kvality. Je založen na pěti kritériích typu Předpoklad (Enable), pokrývajících to, co organizace dělá, a čtyřech kritériích typu Výsledky (Results), pokrývajících to, čeho organizace dosahuje.

Question 214

řízení výjimek (=exception handling)

Answer 214

Chování komponenty nebo systému v reakci na chybný vstup od uživatele, od jiné komponenty nebo systému, anebo jako projev vnitřní poruchy.

Question 215

vykonatelný příkaz (=executable statement)

Answer 215

Příkaz, který je po zkompilování přeložen do kódu. Při běhu programu bude řízeně vykonán a může provést nějakou činnost s daty.

Question 216

prověřený (=exercised)

Answer 216

O části programu je možno říct, že je prověřený testovacím případem, pokud vstupní hodnota způsobí vykonání této části, čili např. příkazu, rozhodnutí nebo jiného strukturálního prvku.

Question 217

kompletní testování (=exhaustive testing)

Answer 217

Přístup k testování, kdy testovací sada obsahuje všechny kombinace vstupních hodnot a vstupních podmínek.

Question 218

výstupní kritéria (=exit criteria)

Answer 218

Sada podmínek, které určují úspěšné dokončení daného úkolu.

Question 219

výstupní bod (=exit point)

Answer 219

Vykonatelný příkaz nebo krok procesu, který definuje bod, ve kterém má být daný proces ukončen.

Question 220

očekávaný výsledek (=expected result)

Answer 220

Předpokládané pozorovatelné chování komponenty nebo systému spouštěného v určených podmínkách. Chování je určeno specifikací nebo jiným zdrojem.

Question 221

technika návrhu testů založená na zkušenostech (=experience-based test design technique)

Answer 221

Procedura pro návrh nebo výběr testovacích případů, založená na zkušenostech, znalostech a intuici testera.

Question 222

technika testování založená na zkušenostech (=experience-based test technique)

Answer 222

Procedura pro odvození a/nebo výběr testovacích případů založená na zkušenostech, znalostech a intuici testera.

Question 223

testování založené na | zkušenostech (=experience-based testing)

Answer 223

Testování založené na zkušenostech, znalostech a intuici testera.

Question 224

průzkumné testování (=exploratory testing)

Answer 224

Přístup k testování založený na zkušenostech, kdy tester dynamicky (teprve v průběhu samotného testování) navrhuje a provádí testy, a to na základě svých znalostí (často i intuice), průběžného stavu testované položky a výsledků předchozích testů.

Question 225

extrémní programování (XP) (=Extreme programming (XP))

Answer 225

Metodika softwarového inženýrství používaná v agilním vývoji softwaru, ve které jsou hlavními praktikami programování v párech, provádění rozsáhlých revizí, jednotkové testování, jednoduchost a přehlednost veškerého kódu.

Question 226

prostředník (=facilitator)

Answer 226

Lídr a hlavní osoba zodpovědná za inspekci nebo proces revize.

Question 227

tovární akceptační testování (=factory acceptance testing)

Answer 227

Akceptační testy organizované na straně vývoje produktu a prováděné zaměstnanci dodavatelské organizace s cílem určit, zda komponenta nebo systém naplňuje požadavky. Obvykle zahrnuje testování hardwaru i softwaru.

Question 228

(test) selhal (=fail)

Answer 228

Test selhal, pokud jeho skutečný výsledek neodpovídá výsledku očekávanému.

Question 229

testování převzetí (failover testing) (=failover testing)

Answer 229

Testování formou simulace režimů selhání nebo vyvoláním selhání v řízeném prostředí. Po selhání je testován mechanismus převzetí tak, aby bylo zajištěno, že data nejsou ztracena nebo poškozena, a že jakákoliv dohodnutá úroveň služeb je zajištěna (např. dostupnost funkcí nebo doby odezvy).

Question 230

selhání (=failure)

Answer 230

Událost, při které není komponenta nebo systém schopna/-en vykonat požadovanou funkcionalitu v rámci definovaných podmínek.

Question 231

režim selhání (=failure mode)

Answer 231

Fyzický nebo funkcionální projev selhání. Systém v režimu selhání může být například charakterizován pomalým provozem, nesprávnými výstupy nebo úplným ukončením činnosti.

Question 232

analýza režimů selhání a jejich následků (FMEA) (=Failure Mode and Effect Analysis (FMEA))

Answer 232

Systematický přístup k identifikaci rizik a analýze možných způsobů selhání, který se zároveň snaží předejít vzniku těchto rizik.

Question 233

FMECA (analýza režimů selhání, jejich následků a jejich kritičnosti) (=Failure Mode, Effects, and Criticality Analysis (FMECA))

Answer 233

Rozšíření základní metodiky FMEA (analýza režimů selhání a jejich následků), obsahující analýzu kritičnosti, která se používá k mapování pravděpodobnosti režimů selhání (poruchových stavů) proti závažnosti jejich následků. Metodika zdůrazňuje ty režimy selhání, které mají poměrně vysokou pravděpodobnost a zároveň vysokou závažnost následků selhání, což umožňuje, aby nápravná opatření směřovala tam, kde přinesou největší přidanou hodnotu.

Question 234

míra selhání (=failure rate)

Answer 234

Míra všech selhání, která spadají do stejné kategorie, vůči definované měrné jednotce.

Question 235

falešně-negativní výsledek (=false-negative result)

Answer 235

Výsledek testu, který neodhalil přítomnost defektu, který je aktuálně přítomen v testovaném objektu.

Question 236

falešně-pozitivní výsledek (=false-positive result)

Answer 236

Výsledek testu, při kterém je reportován defekt, ačkoliv žádný takový defekt v testovaném objektu neexistuje.

Question 237

útok na chyby (=fault attack)

Answer 237

Řízený a cílený pokus vyhodnotit kvalitu testovaného objektu (zejména spolehlivost) pomocí aktivit, které se pokoušejí vyvolat konkrétní selhání. Obvykle je zaměřen na spolehlivost nebo bezpečnost.

Question 238

injektování chyb (fault injection) (=fault injection)

Answer 238

Proces záměrného přidávání defektů do systému s účelem zjištění, zda je systém schopen defekt detekovat a případně se z něj zotavit. Metoda napodobuje selhání, která by mohla v této oblasti nastat.

Question 239

úmyslné zavádění vad (fault seeding) (=fault seeding)

Answer 239

Proces záměrného přidávání defektů k těm, které už v komponentě nebo systému jsou za účelem sledování míry detekce a odstranění, a odhadování počtu zbývajících defektů. Metoda je obvykle součástí vývojového testování (pre-release) a může být prováděna na každé testovací úrovni (komponentní, integrační nebo systémové).

Question 240

nástroj pro úmyslné zavádění vad | fault seeding) (=fault seeding tool

Answer 240

Nástroj sloužící k úmyslnému zavádění (tzv. zasévání) vad do komponenty nebo systému.

Question 241

odolnost vůči vadám (=fault tolerance)

Answer 241

Schopnost softwarového produktu zachovat definovanou úroveň výkonnosti v případě výskytu softwarových chyb (defektů) nebo v případě porušení jeho definovaného rozhraní.

Question 242

analýza stromu chyb (FTA) (=Fault Tree Analysis (FTA))

Answer 242

Technika používající vizuální modelování k analýze příčin chyb (defektů), jejiž cílem je odhalit specifické chyby vzniklé kombinací logických vztahů mezi poruchami, lidskými chybami a vnějšími událostmi.

Question 243

dosažitelná cesta (=feasible path)

Answer 243

Cesta (např. kódem), pro kterou existuje množina vstupních hodnot a vstupních podmínek umožňující její vykonání.

Question 244

vlastnost (=feature)

Answer 244

Atribut komponenty nebo systému specifikovaný nebo vyplývající z dokumentace požadavků (např. spolehlivost, použitelnost nebo designová omezení).

Question 245

vývoj řízený (užitnými) vlastnostmi (=feature-driven development)

Answer 245

Iterativně inkrementální proces vývoje softwaru řízený z pohledu funkcionalit (vlastností - features) hodnotných pro klienta. Vývoj řízený (užitnými) vlastnostmi je většinou využíván při agilním vývoji softwaru.

Question 246

zjištění (=finding)

Answer 246

Výsledek hodnocení, který identifikuje nějakou důležitou otázku, problém nebo příležitost.

Question 247

konečný automat (=finite state machine)

Answer 247

Výpočetní model, který se skládá z konečného počtu stavů a přechodů mezi těmito stavy, případně včetně souvisejících činností.

Question 248

firewall (=firewall)

Answer 248

Komponenta nebo sada komponent, která řídí příchozí a odchozí síťový provoz na základě předem stanovených bezpečnostních pravidel.

Question 249

formální revize (přezkoumání) (=formal review)

Answer 249

Forma revize (přezkoumání), která dodržuje definovaný proces včetně formálně dokumentovaného výstupu.

Question 250

zakonzervovaná testovací báze (=frozen test basis)

Answer 250

Dokument testovací báze, který lze změnit pouze formálním procesem řízení změn.

Question 251

analýza funkčních bodů (FPA - function point analysis) (=Function Point Analysis (FPA))

Answer 251

Metoda zaměřená na měření velikosti funkcionality informačního systému. Měření je nezávislé na technologii a může být použito jako základ pro měření produktivity, odhad potřebných zdrojů a řízení projektu.

Question 252

funkcionální integrace (=functional integration)

Answer 252

Integrační přístup, který spojuje komponenty nebo systémy za účelem včasného získání základní funkcionality.

Question 253

funkcionální požadavek (=functional requirement)

Answer 253

Požadavek specifikující funkcionalitu, kterou musí komponenta nebo systém vykonat.

Question 254

funkcionální vhodnost (=functional suitability)

Answer 254

Míra, do které komponenta nebo systém poskytuje funkce, které splňují definované a očekávané (byť explicitně nepopsané) potřeby při použití za stanovených podmínek.

Question 255

technika návrhu funkcionálních testů (=functional test design technique)

Answer 255

Procedura odvozování a/nebo výběru testovacích případů na základě analýzy specifikace funkcionality komponenty nebo systému bez odkazu na jeho vnitřní strukturu.

Question 256

funkcionální testování (=functional testing)

Answer 256

Testování prováděné za účelem posouzení shody komponenty nebo systému s funkcionálními požadavky.

Question 257

funkcionalita (=functionality)

Answer 257

Schopnost softwarového produktu poskytovat funkce, které uspokojí stanovené a předpokládané potřeby, pokud je software používán za specifikovaných podmínek.

Question 258

testování funkcionality (=functionality testing)

Answer 258

Proces testování s cílem prověřit funkcionalitu softwarového produktu.

Question 259

fuzzing (fuzz testing) (=fuzz testing)

Answer 259

Technika testování softwaru používaná k odhalení bezpečnostních zranitelností, která na vstup komponenty nebo systému předkládá masivní množství náhodných dat (nazývaných fuzz - chmýří).

Question 260

obecná architektura automatizace testů (=generic test automation architecture)

Answer 260

Reprezentace vrstev, komponent a rozhraní architektury automatizace testů umožňující strukturovaný a modulární přístup k její implementaci.

Question 261

Goal Question Metric (GQM) (=Goal Question Metric | GQM)

Answer 261

Přístup k měření softwaru pomocí třístupňového modelu - koncepční úroveň (Goal - cíl), provozní úroveň (Question - otázka) a kvantitativní úroveň (Metric - metrika).

Question 262

GUI (=GUI)

Answer 262

Zkratka pro grafické uživatelské rozhraní.

Question 263

testování GUI (=GUI testing)

Answer 263

Testování prováděné pomocí interakce s testovaným softwarem prostřednictvím grafického uživatelského rozhraní (GUI - graphical user interface).

Question 264

hacker (=hacker)

Answer 264

Osoba nebo organizace, která je aktivně zapojena do bezpečnostních útoků, obvykle s nepřátelskými úmysly.

Question 265

hardwarově-softwarové integrační testování (=hardware-software integration testing)

Answer 265

Testování prováděné s cílem odhalit defekty v rozhraních a interakcích mezi hardwarovými a softwarovými komponentami.

Question 266

hashování (hashing) (=hashing)

Answer 266

Transformace řetězců proměnné délky do obvykle kratší hodnoty pevné délky nebo klíče. Hashované hodnoty nebo též hashe se běžně používají v tabulkách s rozptýlenými položkami (hashovací tabulka) nebo databázových vyhledávacích funkcích. Kryptografické hashovací funkce se používají pro zabezpečení dat.

Question 267

analýza nebezpečí (=hazard analysis)

Answer 267

Technika používaná k charakterizaci prvků rizika. Výsledek analýzy nebezpečí bude určovat způsoby vývoje a testování systému.

Question 268

heuristické vyhodnocení (=heuristic evaluation)

Answer 268

``` Technika revize (přezkoumání) použitelnosti, která je zaměřena na problémy použitelnosti v uživatelském rozhraní nebo v návrhu uživatelského rozhraní. Revidující pomocí této techniky zkoumá rozhraní a stanovuje jeho shodu s obecně uznávanými principy použitelnosti (heuristika). ```

Question 269

obecný testovací případ (=high-level test case)

Answer 269

Testovací případ bez konkrétních hodnot pro vstupní data a očekávané výsledky.

Question 270

horizontální sledovatelnost (=horizontal traceability)

Answer 270

Sledování požadavků na dané úrovni testů v testovací dokumentaci (např. plán testů, specifikace návrhu testů, specifikace testů, specifikace procedury testů nebo testovací skript).

Question 271

hyperlink (=hyperlink)

Answer 271

Ukazatel na webové stránce, který vede na jinou webovou stránku.

Question 272

nástroj k testování | hypertextových odkazů (=hyperlink test tool)

Answer 272

Nástroj používaný k ověření, že se na internetové stránce nenacházejí žádné chybné hypertextové odkazy.

Question 273

IDEAL (=IDEAL)

Answer 273

Model zlepšování organizace, který slouží jako podklad pro zahájení, plánování a provádění opatření ke zlepšení. IDEAL model je pojmenován dle pěti fází, které popisuje: zahájení, diagnostikování, zavádění, vykonávání a ponaučení.

Question 274

analýza dopadu (=impact analysis)

Answer 274

Identifikace všech pracovních produktů ovlivněných změnou, včetně odhadu zdrojů potřebných k zapracování změny.

Question 275

incident (=incident)

Answer 275

Jakákoliv událost, která vyžaduje prozkoumání.

Question 276

zaznamenávání incidentů (=incident logging)

Answer 276

Zaznamenávání detailů jakéhokoliv incidentu, který se vyskytl např. v průběhu testování.

Question 277

správa incidentů (=incident management)

Answer 277

Proces rozeznávání, prověřování, přijímání opatření a řešení incidentů. Zahrnuje zaznamenávání incidentů, jejich klasifikaci a zjištění dopadu.

Question 278

nástroj na správu incidentů (=incident management tool)

Answer 278

Nástroj umožňující záznam incidentů a sledování jejich stavů. Často podporuje workflow na sledování a kontrolu přidělení, opravy a přetestování incidentu a poskytuje možnosti reportování.

Question 279

report o incidentu (=incident report)

Answer 279

Dokumentace výskytu, povahy a stavu incidentu.

Question 280

inkrementální vývojový model (=incremental development model)

Answer 280

Model životního cyklu vývoje, v němž je rozsah projektu obvykle stanoven na začátku projektového životního cyklu, ale odhady času a nákladů průběžně upravovány v závislosti na zvyšující se míře znalosti produktu ze strany projektového týmu. Produkt je vyvíjen prostřednictvím řady opakujících se cyklů, přičemž v každém je z nich je dodáván přírůstek (produktu), který postupně přidává nové funkcionality produktu.

Question 281

inkrementální testování (=incremental testing)

Answer 281

Testování, při kterém jsou komponenty nebo systémy integrovány a testovány postupně, dokud nedojde k integraci a testování všech (komponent nebo systémů).

Question 282

nezávislost testování (=independence of testing)

Answer 282

Oddělení zodpovědností, které podporuje dosažení objektivního testování

Question 283

indikátor (=indicator)

Answer 283

Míra, která může být využita pro odhad nebo předpověď jiné míry

Question 284

neproveditelná cesta (=infeasible path)

Answer 284

Cesta, která nemůže být prověřena žádnou z možných sad vstupních hodnot.

Question 285

skupinová neformální revize (=informal group review)

Answer 285

Neformální revize prováděná třemi nebo více osobami.

Question 286

neformální revize (přezkoumání) (=informal review)

Answer 286

Forma revize (přezkoumání), která nedodržuje žádný definovaný proces a nemá žádný formálně zdokumentovaný výstup.

Question 287

zajištění informací (=information assurance)

Answer 287

Opatření, která vedou k ochraně a obraně informací a informačních systémů prostřednictvím zajištění jejich dostupnosti, integrity, autentizace, důvěrnosti a nepopiratelnosti. Tato opatření zajišťují také možnost obnovy informačních systémů za pomoci schopností jako je ochrana, detekce a reakce.

Question 288

bezpečnost informací (=information security)

Answer 288

Ochrana informací a informačních systémů před neoprávněným přístupem, použitím, zveřejněním, porušením, změnou nebo zničením s cílem zajistit důvěrnost, integritu a dostupnost.

Question 289

iniciace (model IDEAL) (=initiating (IDEAL))

Answer 289

Fáze modelu IDEAL (Initiation), kdy jsou položeny základy pro úspěšné zlepšování. Fáze iniciace se skládá z aktivit: vytvoření kontextu, zajištění sponzorství (financí, zdrojů, času, podpory managementu) a výběr vhodné infrastruktury.

Question 290

vstup (=input)

Answer 290

Data přijatá komponentou nebo systémem z externího zdroje.

Question 291

obor vstupních hodnot (=input domain)

Answer 291

Oblast i množina jsou v tomto případě asi synonyma, nicméně já si myslím, že domain je přímo matematický pojem "obor hodnot." Ještě ověřím.

Question 292

vstupní hodnota (=input value)

Answer 292

Instance vstupu (vstupní hodnota).

Question 293

vnitřní hrozba (=insider threat)

Answer 293

Bezpečnostní hrozba, která pochází zevnitř organizace, často od autorizovaného uživatele systému.

Question 294

insourcované testování (=insourced testing)

Answer 294

Testování prováděné osobami, které jsou (fyzicky) umístěny společně se členy projektového týmu, ale nejsou zaměstnanci jejich organizace.

Question 295

inspekce (=inspection)

Answer 295

Typ formální revize (přezkoumání) s cílem identifikovat problémy v pracovním produktu, která poskytuje metriky pro zlepšování procesů revize a vývoje softwaru.

Question 296

instalovatelnost (=installability)

Answer 296

Schopnost softwarového produktu být instalován ve specifickém prostředí.

Question 297

testování instalovatelnosti (=installability testing)

Answer 297

Proces testování instalovatelnosti softwarového produktu.

Question 298

instalační návod (=installation guide)

Answer 298

Instrukce, které vedou instalujícího skrz instalační proces, dodané na vhodném médiu. Může se jednat o manuál, návod typu krok za krokem, instalačního průvodce nebo o jakýkoliv jiný podobný procesní popis.

Question 299

průvodce instalací (=installation wizard)

Answer 299

Software dodávaný na jakémkoli vhodném médiu, který provádí osobu provádějící instalaci skrz instalační proces, což obvykle znamená spuštění instalačního procesu, poskytování výsledků instalace a nabídka možností (instalace).

Question 300

instrumentace (=instrumentation)

Answer 300

Vložení dodatečného kódu do programu za účelem shromažďování informací o chování programu během jeho běhu, např. za účelem měření pokrytí kódu.

Question 301

instrumentační nástroj (instrumenter) (=instrumenter)

Answer 301

Softwarový nástroj používaný k provádění instrumentace (vkládání kódu za účelem zjištění dalších informací).

Question 302

vstupní test (intake test) (=intake test)

Answer 302

Zvláštní příklad smoke testu, na základě jehož výsledku se rozhoduje o tom, zda je komponenta nebo systém připraven/a k dalšímu a/nebo podrobnějšímu testování. Vstupní test se obvykle provádí na začátku fáze provádění testů.

Question 303

integrace (=integration)

Answer 303

Proces skládání (kombinování) komponent nebo systémů do rozsáhlejších celků.

Question 304

integrační testování (=integration testing)

Answer 304

Testování prováděné s cílem odhalit chyby na rozhraních a v interakcích mezi integrovanými komponentami nebo systémy.

Question 305

testování rozhraní (=interface testing)

Answer 305

Typ integračního testu, který se zabývá testováním rozhraní mezi komponentami nebo systémy.

Question 306

interoperabilita (schopnost | spolupráce) (=interoperability)

Answer 306

Míra, do jaké si mohou dvě nebo více komponent nebo systémů vyměňovat informace a tyto informace používat.

Question 307

testování interoperability | schopnosti spolupráce) (=interoperability testing

Answer 307

Proces testování, který má za cíl ověřit interoperabilitu (schopnost spolupráce) softwarového produktu.

Question 308

systém detekce narušení (IDS) (=intrusion detection system | IDS)

Answer 308

Systém, který monitoruje činnosti na sedmi vrstvách OSI modelu (od síťové po aplikační vrstvu) tak, aby odhalil porušení bezpečnostní politiky.

Question 309

testování nevalidními hodnotami (=invalid testing)

Answer 309

Testování s využitím takových vstupních hodnot, které by měly být komponentou nebo systémem zamítnuty.

Question 310

testování v izolaci (=isolation testing)

Answer 310

Testování jednotlivých komponent odděleně od okolních, přičemž tyto okolní komponenty jsou v případě potřeby simulovány pomocí stubů a ovladačů.

Question 311

iterativní vývojový model (=iterative development model)

Answer 311

Vývojový životní cyklus, kde je projekt obvykle rozdělený do velkého počtu iterací. Iterace představuje kompletní vývojový cyklus končící dodávkou (interní nebo externí) spustitelného produktu, podmnožinou finálního produktu, který se vyvíjí a narůstá od iterace k iteraci s cílem dosáhnout finálního produktu.

Question 312

testování řízené klíčovými slovy (=keyword-driven testing)

Answer 312

Skriptovací technika využívající datové soubory obsahující nejen testovací data a očekávané výsledky, ale i klíčová slova související s testovanou aplikací. Klíčová slova jsou interpretována speciálními podpůrnými skripty, které jsou vyvolávány řídícími skripty pro test.

Question 313

LCSAJ (=LCSAJ)

Answer 313

Zkratka pro sekvence lineárního kódu a skoků. Skládá se z následujících tří položek (dle zažité konvence se řádky zdrojového kódu číslují): začátek lineární posloupnosti vykonatelných příkazů; konec této lineární posloupnosti; a cílový řádek, na který je řídící tok na konci této lineární posloupnosti přenesen.

Question 314

pokrytí LCSAJ (=LCSAJ coverage)

Answer 314

``` Procento LCSAJ (sekvence lineárního kódu a skoků) komponenty, které bylo pokryto danou testovací sadou. 100% pokrytí LSCAJ znamená automaticky 100% pokrytí rozhodnutí. ```

Question 315

LCSAJ testování (=LCSAJ testing)

Answer 315

Technika návrhu testů bílé skříňky, při které jsou testovací případy navrhovány tak, aby došlo k provedení LCSAJ (sekvence lineárního kódu a skoků).

Question 316

vedoucí hodnotitel (=lead assessor)

Answer 316

Osoba, která vede ohodnocení. V některých případech (např. CMMi a TMMi, kdy je požadováno formální ohodnocení) musí být vedoucí posuzovatel akreditován a formálně vyškolen.

Question 317

zvládnutelnost (=learnability)

Answer 317

Schopnost softwarového produktu umožnit uživateli naučit se jej používat.

Question 318

učení (model IDEAL) (=learning (IDEAL))

Answer 318

Fáze modelu IDEAL (Learning), kdy se účastník učí na základě získaných zkušeností a zlepšuje svou schopnost zavést v budoucnu nové procesy a technologie. Fáze učení se skládá z činností analýzy a ověřování, a návrhu příštích aktivit.

Question 319

úroveň vniknutí (=level of intrusion)

Answer 319

Úroveň, na kterou je testovaný objekt upraven tak, aby mohl být testován.

Question 320

plán testování úrovně (=level test plan)

Answer 320

Plán testování, který je typicky zaměřen na jednu úroveň testování.

Question 321

model životního cyklu (=lifecycle model)

Answer 321

Popis procesů, pracovních toků a činností používaných při vývoji, dodávce, údržbě a vyřazení systému.

Question 322

lineární skriptování (=linear scripting)

Answer 322

Jednoduchá skriptovací technika bez dalších programovacích struktur v kódu.

Question 323

zátěžový profil (=load profile)

Answer 323

Specifikace činnosti, která může při testování komponenty nebo systému nastat v produkci. Zátěžový profil se skládá z určeného počtu virtuálních uživatelů, kteří zpracovávají definovanou sadu operací v určeném časovém rozmezí a podle předdefinovaného provozního profilu.

Question 324

zátěžové testování (=load testing)

Answer 324

Typ testování výkonnosti prováděného za účelem vyhodnocení chování komponenty nebo systému pří různých zátěžích, obvykle mezi očekávanými podmínkami nízkého užití, typického užití a užití ve špičce.

Question 325

nástroj na zátěžové testování (=load testing tool)

Answer 325

Nástroj pro podporu zátěžového testování, pomocí kterého lze simulovat zvyšující se zátěž, např. počet současně pracujících uživatelů a/nebo počet transakcí během určitého časového intervalu.

Question 326

specifický testovací případ (=low-level test case)

Answer 326

Testovací případ s konkrétními hodnotami (na implementační úrovni) pro vstupní data a očekávané výsledky.

Question 327

udržovatelnost (=maintainability)

Answer 327

Míra, s jakou může být komponenta nebo systém modifikován(a) aktéry, kteří mají za úkol provádět údržbu.

Question 328

testování udržovatelnosti (=maintainability testing)

Answer 328

Proces testování s cílem určit udržovatelnost softwarového produktu.

Question 329

údržba (=maintenance)

Answer 329

Proces modifikace komponenty nebo systému po dodávce s cílem opravy defektů, zlepšení atributů kvality nebo přizpůsobení se změněnému prostředí.

Question 330

testování údržby (=maintenance testing)

Answer 330

Testování změn v produkčním systému nebo vlivu změn prostředí na produkční systém.

Question 331

malware (=malware)

Answer 331

Software, jehož cílem je poškodit systém nebo jeho komponenty.

Question 332

skenování malwaru (=malware scanning)

Answer 332

Statická analýza s cílem najít a odstranit škodlivý kód.

Question 333

útok "člověk uprostřed" (man-in- | the-middle) (=man-in-the-middle attack)

Answer 333

Odposlech, napodobování a/nebo pozměňování a následná přesměrování komunikací (např. transakce kreditními kartami) prováděná třetí stranou tak, že uživatel o přítomnosti této třetí strany neví.

Question 334

manažerská revize (přezkoumání) (=management review)

Answer 334

Systematické hodnocení nákupu, dodávky, vývoje, provozu nebo údržby softwaru, provedené jménem managementu, které sleduje postup prací, určuje stav plánů a harmonogramů, potvrzuje požadavky a jejich systémové rozložení nebo vyhodnocuje účinnost manažerských přístupů k dosažení shody se zadáním.

Question 335

kvalita založená na produkci (=manufacturing-based quality)

Answer 335

Pohled na kvalitu, kdy je měřena mírou, do jaké produkt nebo služba odpovídá zamýšlenému návrhu a požadavkům. Kvalita vychází z použitých procesů.

Question 336

hlavní plán testování (=master test plan)

Answer 336

Plán testování, který se používá pro koordinaci testování na více úrovních nebo pro koordinaci různých typů testování.

Question 337

zralost (=maturity)

Answer 337

(1) Schopnost organizace ve vztahu k efektivitě a výkonnosti jejich procesů a pracovních postupů. (2) Míra spolehlivosti, s kterou komponenta nebo systém splňuje potřeby za běžných provozních podmínek.

Question 338

úroveň zralosti (=maturity level)

Answer 338

Stupeň zlepšení procesu v předem vymezené sadě procesních oblastí, při kterém je v této sadě dosaženo všech cílů.

Question 339

model zralosti (=maturity model)

Answer 339

Strukturovaná sada prvků, které popisují některé aspekty zralosti v organizaci, jejíž cílem je pomoc při definování a pochopení procesů organizace. Model zralosti často poskytuje společný jazyk, společnou vizi a rámec pro stanovení priorit opatření ke zlepšení.

Question 340

model MBT (=MBT model)

Answer 340

Jakýkoliv model použitý při testování založeném na modelu.

Question 341

střední doba mezi selháními / poruchami (MTBF) (=mean time between failures (MTBF))

Answer 341

Doba střední hodnoty (např. aritmetický průměr) mezi selháními systému. MTBF je typicky součástí modelu růstu spolehlivosti, který předpokládá, že systém, u něhož dojde k selhání, je okamžitě opraven díky procesu nápravy defektů.

Question 342

střední doba do obnovení | MTTR) (=mean time to repair (MTTR)

Answer 342

Doba střední hodnoty (např. aritmetický průměr), během které se systém zotaví z jakéhokoliv selhání. To obvykle zahrnuje testování s cílem potvrdit, že defekt byl vyřešen.

Question 343

míra (=measure)

Answer 343

Číslo nebo kategorie přiřazená k atributu entity na základě provedeného měření.

Question 344

měření (=measurement)

Answer 344

Proces přiřazení čísla nebo kategorie entitě s cílem popsat její atributy.

Question 345

stupnice měření (=measurement scale)

Answer 345

Stupnice, která vymezuje typ analýzy dat, pro který lze provádět měření.

Question 346

únik paměti (=memory leak)

Answer 346

Selhání přístupu do paměti v důsledku defektu v programové logice dynamického ukládání, kvůli kterému dochází k selhání při uvolnění paměti poté, co ji program přestane používat, a kvůli kterému může eventuálně dojít k selhání tohoto programu a/nebo ostatních současně běžících procesů jako následek nedostatku paměti.

Question 347

metodická testovací strategie (=methodical test strategy)

Answer 347

Testovací strategie, při které testovací tým používá předem stanovenou sadu testovacích podmínek (např. standard kvality nebo kontrolní seznam) nebo sadu všeobecných logických testovacích podmínek, které se mohou týkat konkrétního oboru, aplikace nebo typu testování.

Question 348

metodické testování (=methodical testing)

Answer 348

Testování založené na zavedené sadě testů, např. kontrolním seznamu nebo standardu kvality.

Question 349

metrika (=metric)

Answer 349

Stupnice měření a metoda definovaná pro její měření.

Question 350

milník (=milestone)

Answer 350

Bod v časové ose projektu, ve kterém by měly být k dispozici (i přechodné) výstupy a výsledky, které jsou pro daný bod definovány.

Question 351

myšlenková mapa (=mind map)

Answer 351

Diagram, používaný k vyjádření slov, myšlenek, úkolů nebo jiných položek spojených a uspořádaných kolem centrálního klíčového slova nebo nápadu. Myšlenkové mapy se používají ke generování, vizualizaci, strukturování a třídění myšlenek, a jako pomoc při studiu, organizaci, řešení problémů, rozhodování a psaní.

Question 352

pokrytí modelu (=model coverage)

Answer 352

Míra, vyjádřená v procentech, do které byly elementy modelu pokryty nebo jsou plánovány k pokrytí danou testovací sadou.

Question 353

testovací strategie založená na | modelu (=model-based test strategy)

Answer 353

Testovací strategie, při které testovací tým definuje testware na základě (znalosti) modelů.

Question 354

testování založené na modelu (=model-based testing (MBT))

Answer 354

Testování založené nebo zahrnující modely.

Question 355

modelovací nástroj (=modeling tool)

Answer 355

Nástroj podporující vytváření, doplňování a ověřování modelů softwaru anebo systému.

Question 356

moderátor (=moderator)

Answer 356

Vedoucí nebo jiná hlavní osoba zodpovědná za inspekci nebo jiný proces revize (přezkoumání).

Question 357

modifikované pokrytí podmínek/rozhodnutí (MC/DC) (=modified condition / decision coverage (MC/DC))

Answer 357

Procento pokrytí všech výstupů dílčích podmínek, které nezávisle určují výstup celkového výrazu. 100% modifikované pokrytí dílčích podmínek tím automaticky garantuje i 100% pokrytí všech rozhodnutí celkového výrazu.

Question 358

testování modifikovaných podmínek/rozhodnutí (=modified condition / decision testing)

Answer 358

Technika návrhu testů bílé skříňky, při které jsou testovací případy navrženy tak, aby došlo k vykonání všech výstupů jednotlivých podmínek, které nezávisle určí výsledek rozhodnutí celkového výrazu.

Question 359

monitorovací nástroj (=monitoring tool)

Answer 359

Softwarový nástroj nebo hardwarové zařízení, který(é) je spuštěn/-o souběžně s testovanou komponentou nebo systémem, a dohlíží, zaznamenává a/nebo analyzuje chování této komponenty nebo systému.

Question 360

opičí (monkey) testování (=monkey testing)

Answer 360

Testování ve smyslu náhodného výběru z velkého množství vstupů a náhodného použití ovládacích prvků ("mačkání tlačítek"), při kterém je ignorováno skutečné použití produktu.

Question 361

pokrytí vícenásobných podmínek (=multiple condition coverage)

Answer 361

Procento kombinací všech výstupů jednoduchých podmínek v rámci jednoho příkazu, které jsou prověřeny nějakou testovací sadou. 100% pokrytí vícenásobných podmínek garantuje 100% pokrytí změněných podmínek.

Question 362

testování vícenásobných | podmínek (=multiple condition testing)

Answer 362

Technika návrhu testů bílé skříňky, při které jsou testovací případy navrhovány tak, aby došlo ke spuštění všech kombinací jednotlivých podmíněných výstupů (s použitím jednoho příkazu).

Question 363

analýza mutací (=mutation analysis)

Answer 363

Metoda pro určení důkladnosti testovacích sad pomocí měření míry, v jaké může daná testovací sada rozpoznat originální program od jeho nepatrně se lišících variant (mutantů).

Question 364

testování mutací (=mutation testing)

Answer 364

Testování, ve kterém jsou dvě nebo více variant komponenty nebo systému spouštěny se stejnými vstupy. Výstupy jsou následně vzájemně porovnány a v případě nesrovnalostí analyzovány.

Question 365

Myersové-Briggsové typologie osobnosti (MBTI - Myers-Briggs | Type Indicator) (=Myers-Briggs Type Indicator (MBTI))

Answer 365

Indikátor psychologické preference reprezentující různé osobnosti a komunikační styly osob.

Question 366

pokrytí N-přepínačů (=N-switch coverage)

Answer 366

Procento sekvencí N+1 přechodů, které jsou pokryty testovací sadou.

Question 367

testování N-přepínačů (=N-switch testing)

Answer 367

Způsob testování přechodových stavů, při kterém jsou testovací případy navrženy tak, aby došlo k provedení všech validních sekvencí přechodů N + 1.

Question 368

N-násobné testování (=n-wise testing)

Answer 368

Technika návrhu testů černé skříňky, při které jsou testovací případy navrženy tak, aby došlo k vykonání všech možných nespojitých (diskrétních) kombinací z libovolné sady N vstupních parametrů.

Question 369

negativní testování (=negative testing)

Answer 369

Testy zaměřené na prokázání, že systém či komponenta nepracuje správně. Negativní testování souvisí spíše s postojem testerů než s konkrétním přístupem k testování nebo technikou návrhu testů, např. testování s neplatnými vstupními hodnotami či výjimkami.

Question 370

integrační testování sousedních uzlů (=neighborhood integration testing)

Answer 370

Forma integračního testování, při které jsou všechny sousedící uzly k danému uzlu základem pro integrační testování.

Question 371

zóna sítě (=network zone)

Answer 371

Část sítě s určitým stupněm důvěry. Například Internet nebo veřejná zóna by byly považovány za nedůvěryhodné.

Question 372

neshoda (=non-conformity)

Answer 372

Nesplnění specifikovaného požadavku.

Question 373

nefunkcionální požadavek (=non-functional requirement)

Answer 373

Požadavek, který popisuje chování komponenty nebo systému pro její/jeho zamýšlené použití.

Question 374

technika návrhu nefunkcionálních testů (=non-functional test design technique)

Answer 374

Procedura odvozování a/nebo výběru testovacích případů pro nefunkcionální testování, založený na analýze specifikace komponenty nebo systému bez informace o její/jeho vnitřní struktuře.

Question 375

nefunkcionální testování (=non-functional testing)

Answer 375

Testování prováděné za účelem posouzení shody komponenty nebo systému s nefunkcionálními požadavky.

Question 376

offline MBT (=offline MBT)

Answer 376

Přístup k testování založeného na modelu, při kterém jsou testovací případy generovány do úložiště pro budoucí provedení.

Question 377

online MBT (=online MBT)

Answer 377

Přístup k testování založeného na modelu, při kterém jsou testovací případy generovány a prováděny současně.

Question 378

open source nástroj (=open source tool)

Answer 378

Softwarový nástroj, který je obvykle přes internet k dispozici všem potenciálním uživatelům ve formě zdrojového kódu. Jeho uživatelům je většinou na základě licence dovoleno zkoumat, měnit, zlepšovat a někdy také distribuovat daný software.

Question 379

provozovatelnost (=operability)

Answer 379

Schopnost softwarového produktu umožnit uživateli ho provozovat a řídit.

Question 380

provozní akceptační testování (=operational acceptance testing)

Answer 380

Provozní testování v akceptační testovací fázi, typicky prováděné v (simulovaném) provozním prostředí personálem provozu a/nebo systémovými administrátory zaměřené na provozní aspekty, např. schopnost zotavení, chování zdrojů, instalovatelnost a technickou shodu.

Question 381

provozní prostředí (=operational environment)

Answer 381

Hardwarové a softwarové produkty nainstalované u uživatelů nebo zákazníků v místech, kde bude testovaná komponenta nebo systém používán. Software může obsahovat operační systémy, systémy pro správu databází a další aplikace.

Question 382

provozní profil (=operational profile)

Answer 382

Reprezentace určité sady úkolů, která je prováděna komponentou nebo systémem, a která je založena, pokud je to možné, na chování uživatele při interakci s komponentou nebo systémem, a na pravděpodobnosti jeho výskytu. Úkol je svou povahou více logický než fyzický a může být spuštěn na několika zařízeních nebo v nenavazujích časových úsecích.

Question 383

testování provozního profilu (=operational profile testing)

Answer 383

Statistické testování, které využívá model systémových činností (krátkodobých operací) a pravděpodobnost jejich typického použití.

Question 384

provozní profilování (=operational profiling)

Answer 384

Proces vývoje a implementace provozního profilu.

Question 385

provozní testování (=operational testing)

Answer 385

Testování prováděné s cílem vyhodnotit komponentu (nebo systém) v jejím (jeho) provozním prostředí.

Question 386

ortogonální pole (=orthogonal array)

Answer 386

Dvourozměrné pole konstruované pomocí speciálních matematických postupů tak, aby například výběr jakýchkoliv dvou sloupců v poli obsahoval všechny kombinace párů ze všech různých čísel v poli.

Question 387

testování ortogonálního pole (=orthogonal array testing)

Answer 387

Systematický způsob testování všech kombinací dvojic proměnných pomocí ortogonálních polí. Významně redukuje počet kombinací proměnných při testování všech kombinací dvojic.

Question 388

výstup (=output)

Answer 388

Data přenášená komponentou nebo systémem do externího místa určení.

Question 389

obor výstupních hodnot (=output domain)

Answer 389

Sada, ze které lze vybírat platné výstupní hodnoty.

Question 390

výstupní hodnota (=output value)

Answer 390

Instance výstupu.

Question 391

outsourcované testování (=outsourced testing)

Answer 391

Testování prováděné lidmi, kteří nejsou ve stejné lokaci jako projektový tým a nejsou jeho spolupracovníky.

Question 392

párové programování (=pair programming)

Answer 392

Přístup k vývoji softwaru, při kterém jsou řádky produkčního a/nebo testového kódu komponenty tvořeny dvěma programátory sedícími u jednoho počítače, což v podstatě znamená, že dochází k průběžné revizi kódu v reálném čase.

Question 393

párové testování (=pair testing)

Answer 393

Činnost dvou osob (např. dva testeři, vývojář a tester, koncový uživatel a tester) při společném hledání defektů. Typicky tyto osoby také sdílejí jeden počítač a vzájemně si v průběhu testování předávají jeho obsluhu.

Question 394

integrační testování dvojic (=pairwise integration testing)

Answer 394

Forma integračního testování zaměřená na dvojice komponent, které pracují společně tak, jak je znázorněno na grafu volání.

Question 395

testování dvojic (=pairwise testing)

Answer 395

Technika návrhu testů černé skříňky, při které jsou testovací případy navrhovány tak, aby došlo k provedení všech možných samostatných kombinací každé dvojice vstupních parametrů.

Question 396

Paretova analýza (=Pareto analysis)

Answer 396

Statistická metoda při rozhodování, která se používá pro výběr omezeného počtu faktorů, jejichž společné působení vytváří většinový efekt. Ve významu zlepšování kvality to znamená, že většina problémů (80%) je způsobena několika klíčovými příčinami (20%).

Question 397

(test) prošel (=pass)

Answer 397

Test prošel (úspěšně), pokud jeho skutečný výsledek odpovídá výsledku očekávanému.

Question 398

kritéria úspěchu / selhání (=pass/fail criteria)

Answer 398

Rozhodovací pravidla používaná k určení, zda byla daná položka testů (funkce) nebo vlastnost označena jako úspěch nebo selhání.

Question 399

prolamování hesel (=password cracking)

Answer 399

Bezpečnostní útok, který se snaží získat tajná hesla uložená v počítačovém systému nebo přenášená po síti.

Question 400

cesta (=path)

Answer 400

Sled událostí (např. spustitelných příkazů) komponenty nebo systému ze vstupního do výstupního bodu.

Question 401

pokrytí cest (=path coverage)

Answer 401

Procento cest, které je vykonáno v rámci testovací sady. 100% pokrytí cest znamená 100% LCSAJ pokrytí.

Question 402

vynucení cesty (path senziting) (=path sensitizing)

Answer 402

Výběr sady vstupních hodnot pro vynucení provedení dané cesty.

Question 403

testování cest (=path testing)

Answer 403

Technika návrhu testů bílé skříňky, při které jsou testovací případy navrhovány tak, aby došlo k průchodu cest (v kódu).

Question 404

vzájemná revize (peer review) (=peer review)

Answer 404

Forma revize (přezkoumání) pracovních produktů vykonávaného jinými osobami způsobilými vykonávat tutéž práci.

Question 405

penetrační testování (=penetration testing)

Answer 405

Technika testování, jejíž cílem je odhalení bezpečnostních zranitelností (známých nebo neznámých) k získání neoprávněného přístupu.

Question 406

výkonnost (=performance)

Answer 406

Míra, do které systém či komponenta vykonává své určené funkce v rámci stanovených podmínek týkajících se času nutnému ke zpracování a míře propustnosti.

Question 407

výkonnostní efektivita (=performance efficiency)

Answer 407

Míra, při které komponenta nebo systém využívá čas, prostředky a kapacitu při plnění svých určených funkcí.

Question 408

indikátor výkonnosti (=performance indicator)

Answer 408

Obecná metrika efektivity a/nebo výkonnosti používaná ke směrování a kontrole progresivního vývoje, např. zpoždění termínu dodání (lead-time slip) ve vývoji softwaru.

Question 409

výkonnostní profilování (=performance profiling)

Answer 409

Úkol analýzy (např. identifikace bodů, kde dochází ke zmenšení výkonnosti, na základě generovaných metrik) a ladění výkonnosti softwarové komponenty nebo (softwarového) systému pomocí nástrojů.

Question 410

testování výkonnosti (=performance testing)

Answer 410

Testování s cílem zjistit výkon softwarového produktu.

Question 411

nástroj pro testování výkonnosti (=performance testing tool)

Answer 411

Nástroj podporující testování výkonu, který má obvykle dvě hlavní funkčnosti: generování zátěže a měření testovacích transakcí. Generování zátěže může simulovat jednak více užívatelů, jednak vysoký objem vstupních dat. V průběhu vykonávání se pro vybrané transakce měří a zaznamenávají časové odezvy. Nástroje pro testování výkonu obvykle poskytují reporty založené na testovacích záznamech a grafech zátěže vůči časovým odezvám.

Question 412

čtení založené na perspektivě (=perspective-based reading)

Answer 412

A review technique whereby reviewers evaluate the work product from different viewpoints.

Question 413

pharming (=pharming)

Answer 413

Bezpečnostní útok určený k přesměrování provozu webové stránky na podvodné webové stránky bez vědomí či souhlasu uživatele.

Question 414

odstranění ve stejné fázi (=phase containment)

Answer 414

Procento defektů, které je odstraněno ve stejné fázi životního cyklu softwaru, ve které byly tyto defekty nalezeny.

Question 415

plán fáze testování (=phase test plan)

Answer 415

Plán testování, který obvykle řeší jednu testovací fázi.

Question 416

phishing (=phishing)

Answer 416

Pokus získat osobní nebo citlivé informace vydáváním se za důvěryhodnou entitu v elektronické komunikaci.

Question 417

plánovací poker (=planning poker)

Answer 417

Technika založená na společném souhlasu, většinou používaná k odhadu pracnosti či relativní velikosti uživatelských scénářů v agilním vývoji softwaru. Jde o variaci metody Wideband Delphi s použitím balíčku karet s hodnotami, které představují jednotky, ve kterých tým provádí své odhady.

Question 418

ukazatel (=pointer)

Answer 418

Datový typ, který určuje umístění určitého elementu dat; například adresa v paměti, kde se nachází další záznam zaměstnance, který má být zpracován.

Question 419

přenositelnost (=portability)

Answer 419

Náročnost přenesení softwarového produktu z jednoho hardwarového či softwarového prostředí do jiného.

Question 420

testování přenositelnosti (=portability testing)

Answer 420

Proces testování s cílem zjistit přenositelnost softwarového produktu.

Question 421

porovnání po spuštění (=post-execution comparison)

Answer 421

Porovnání skutečných a očekávaných výsledků, provedené poté, co software ukončil svůj běh.

Question 422

výstupní podmínka (=postcondition)

Answer 422

Environmentální a stavové podmínky, které musí být splněny po provedení testu nebo testovací procedury (komponenty nebo systému).

Question 423

vstupní podmínka (=precondition)

Answer 423

Požadovaný stav položky testování a jejího prostředí před provedením testovacího případu.

Question 424

predikát (=predicate)

Answer 424

Výraz, který může být vyhodnocen jako pravdivý nebo nepravdivý a následně může být použit ke stanovení následného logického rozhodování (během) řídícího toku.

Question 425

priorita (=priority)

Answer 425

Úroveň důležitosti (obvykle z pohledu byznysu) přiřazená nějaké položce, např. defektu.

Question 426

PRISMA (Product RISk | MAnagement) (=PRISMA)

Answer 426

Systematický přístup k testování založený na rizicích, který řeší identifikaci a analýzu rizik produktu s cílem vytvořit z těchto rizik matici založenou na pravděpodobnosti a dopadu.

Question 427

efekt měřící sondy (=probe effect)

Answer 427

Vliv měřícího zařízení na komponentu nebo systém při samotném měření. Příkladem je drobné snížení výkonnosti systému díky vlivu nástroje pro měření nebo sledování výkonnosti při samotném měření.

Question 428

problém (=problem)

Answer 428

Neznámá základní příčina jednoho nebo více incidentů.

Question 429

testování procedur (=procedure testing)

Answer 429

Testování zaměřené na ověření toho, že komponenta nebo systém může pracovat ve spojení s obchodními nebo provozními procedurami nových či stávajících uživatelů.

Question 430

proces (=process)

Answer 430

Sada provázaných aktivit, které přeměňují vstupy na výstupy

Question 431

ohodnocení procesu (=process assessment)

Answer 431

Metodické hodnocení softwarových procesů organizace dle referenčního modelu.

Question 432

test procesního cyklu (=process cycle test)

Answer 432

Technika návrhu testů černé skříňky, při které jsou testovací případy navrženy tak, aby došlo k provedení byznysových postupů a procesů.

Question 433

zlepšení procesu (=process improvement)

Answer 433

Plán aktivit, jehož cílem je zlepšit výkonnost a zralost procesů organizace a výsledek takového plánu.

Question 434

procesní model (=process model)

Answer 434

Rámec, ve kterém jsou procesy stejné povahy zařazeny do celkového modelu, např. model zlepšování testů.

Question 435

procesní referenční model (=process reference model)

Answer 435

Procesní model, který pomocí předepsaných kroků poskytuje základní sadu osvědčených postupů pro zlepšení určitého procesu.

Question 436

strategie testování shody s procesem (=process-compliant test strategy)

Answer 436

Testovací strategie, při které testovací tým dodržuje sadu předdefinovaných procesů, přičemž tyto procesy řeší položky jako dokumentaci, správnou identifikaci, použití báze testování a orákula testování včetně organizace testovacího týmu.

Question 437

testování shody s procesem (=process-compliant testing)

Answer 437

Testování, při kterém je dodržována sada definovaných procesů, např. vydaných externí standardizační institucí.

Question 438

skriptování řízené procesy (=process-driven scripting)

Answer 438

Skriptovací technika, při níž jsou skripty strukturovány do scénářů, které představují případy užití testovaného softwaru. Tyto skripty mohou být parametrizovány pomocí testovacích dat.

Question 439

produktové riziko (=product risk)

Answer 439

Riziko, které ovlivňuje kvalitu produktu.

Question 440

kvalita založená na produktu (=product-based quality)

Answer 440

Pohled na kvalitu, ve kterém je kvalita založena na dobře definované množině atributů kvality. Tyto atributy musí být měřeny objektivním a kvantitativním způsobem. Rozdíly v kvalitě výrobků stejného typu je možno vysledovat zpět až ke způsobu, jakým byly implementovány (odpovídající) specifické atributy kvality.

Question 441

projekt (=project)

Answer 441

Projekt je unikátní soubor koordinovaných a řízených činností s datem zahájení a datem ukončení uskutečněných pro dosažení cíle, který vyhovuje specifickým požadavkům, včetně omezení času, nákladů a zdrojů.

Question 442

projektová retrospektiva (=project retrospective)

Answer 442

Strukturovaný způsob, jak zachytit získané poznatky (lessons learned) a vytvořit konkrétní akční plány pro zlepšení v dalším projektu nebo další fázi projektu.

Question 443

projektové riziko (=project risk)

Answer 443

Riziko, které ovlivňuje úspěch projektu.

Question 444

pseudo-náhodný (=pseudo-random)

Answer 444

Série (obvykle dat), která se zdá být náhodná, ale je ve skutečnosti generována podle nějakého předem stanoveného pořadí.

Question 445

kvalifikace (=qualification)

Answer 445

Proces demonstrování schopnosti naplnit specifikované požadavky. Pozn. termín "kvalifikovaný" se používá k označování odpovídajícího stavu.

Question 446

kvalita (=quality)

Answer 446

Stupeň splnění specifikovaných požadavků a/nebo uživatelských/zákaznických potřeb a očekávání pro danou komponentu, systém nebo proces.

Question 447

zajištění kvality (=quality assurance)

Answer 447

Část řízení kvality zaměřená na poskytování důvěry, že požadavky na kvalitu budou naplněny.

Question 448

atribut kvality (=quality attribute)

Answer 448

Vlastnost nebo charakteristika prvku ovlivňující jeho kvalitu.

Question 449

charakteristika kvality (=quality characteristic)

Answer 449

Kategorie atributů produktu, která se týká kvality.

Question 450

řízení kvality (=quality control)

Answer 450

Provozní techniky a činnosti, část managementu kvality, které jsou zaměřeny na splnění požadavků na kvalitu.

Question 451

QFD (quality function deployment) (=quality function deployment (QFD))

Answer 451

Metoda pro transformaci požadavků uživatelů do návrhu výstupního produktu. Promítá metody pro dosažení kvalitního návrhu do subsystémů, komponent a v neposlední řadě do specifických elementů výrobního procesu.

Question 452

brána kvality (=quality gate)

Answer 452

Speciální milník v projektu. Brány kvality jsou umístěny mezi takovými fázemi projektu, které silně závisí na výsledcích předchozí fáze. Brána kvality zahrnuje formální kontrolu dokumentů předchozí fáze.

Question 453

management kvality (=quality management)

Answer 453

Koordinované činnosti, které mají směrovat a řídit organizaci s ohledem na kvalitu, což obecně znamená zavedení politiky a cílů kvality, její plánování, kontrola, zajištění a zlepšování.

Question 454

riziko kvality (=quality risk)

Answer 454

Produktové riziko se vztahem k atributu kvality.Produktové riziko související s kvalitativními charakteristikami (softwaru).

Question 455

matice RACI (=RACI matrix)

Answer 455

Matice, která popisuje účast různých pozic při dokončování úkolů či dodávaných výstupů pro projekt nebo proces. Je obzvláště užitečná při vyjasňování rolí a odpovědností. RACI je zkratka odvozená ze čtyř hlavních zodpovědností, které se obvykle se používají: vykonává (responsible), ručí (accountable), je konzultováno (consulted), je informováno (informed).

Question 456

náhodné testování (=random testing)

Answer 456

Technika návrhu testů černé skříňky, kdy jsou testovací případy vybrány náhodně (případně s využitím nějakého pseudo- náhodného algoritmu) a to tak, aby výběr odpovídal provoznímu profilu. Tato technika může být použita pro testování nefunkcionálních charakteristik jako je např. spolehlivost nebo výkonnost.

Question 457

Rational Unified Process (RUP) (=Rational Unified Process | RUP)

Answer 457

Vlastní přizpůsobivý iterativní rámec procesu vývoje softwaru, který se skládá ze čtyř fází životního cyklu projektu: založení (inception), zpracování (elaboration), provedení (construction) a převedení (transition).

Question 458

reaktivní testovací strategie (=reactive test strategy)

Answer 458

Testovací strategie, kdy testovací tým čeká s návrhem a provedením testů do doby přejímky softwaru a reaguje až na aktuální testovaný systém.

Question 459

reaktivní testování (=reactive testing)

Answer 459

Testování, které dynamicky reaguje na daný testovaný systém a získané výsledky testů. Reaktivní testování má typicky snížený rozsah plánovacího cyklu, a fáze návrhu a implementace testů se neuskuteční, dokud není k dispozici testovaný objekt.

Question 460

průzkum (=reconnaissance)

Answer 460

Zkoumání cílové oblasti se záměrem získat informace, které mohou být užitečné pro útok.

Question 461

obnovitelnost (=recoverability)

Answer 461

Schopnost softwarového produktu znovu dosáhnout specifikované úrovně výkonu a obnovit poškozená data v případě selhání (poruchy).

Question 462

testování schopnosti zotavení (=recoverability testing)

Answer 462

Proces testování s cílem určit schopnost zotavení softwarového produktu.

Question 463

regrese (=regression)

Answer 463

Zhoršení kvality komponenty nebo systému v důsledku změny.

Question 464

regresní testování (=regression testing)

Answer 464

Testování již dříve testované komponenty nebo systému po modifikaci s cílem zajištění toho, že nedošlo na nezměnených částech softwaru v důsledku provedených změn k výskytu nových nebo dříve neodhalených (skrytých) defektů.

Question 465

regresně averzní testovací strategie (=regression-averse test strategy)

Answer 465

Testovací strategie, při které testovací tým používá různé techniky s cílem řídit regresní rizika, např. automatizaci funkcionálních a/nebo nefunkcionálních regresních testů na jedné nebo více úrovních.

Question 466

regresně-averzní testování (=regression-averse testing)

Answer 466

Testování s využitím různých technik s cílem řídit riziko regrese, například navržením opakovaně použitelného testwaru a rozsáhlou automatizací testů na jedné nebo několika testovacích úrovních.

Question 467

regulatorní akceptační testování (=regulatory acceptance | testing)

Answer 467

Akceptační testování prováděné za účelem ověření, zda systém odpovídá příslušným zákonům, zásadám a předpisům.

Question 468

poznámky k vydání (release note) (=release note)

Answer 468

Dokument identifikující položky testů, jejich konfigurace, současný stav a jiné informace dodané vývojem pro testování (nebo případně pro jiné zainteresované) na začátku fáze provádění testů.

Question 469

bezporuchovost (spolehlivost) (=reliability)

Answer 469

Míra, v jaké je po daný časový úsek a za stanovených podmínek schopna komponenta nebo systém vykonávat požadovanou funkci.

Question 470

model růstu spolehlivosti (=reliability growth model)

Answer 470

Model, který ukazuje růst spolehlivosti komponenty nebo systému v průběhu kontinuálního testování, a to jako následek odstranění defektů, které způsobují selhání spolehlivosti.

Question 471

testování spolehlivosti (=reliability testing)

Answer 471

Proces testování s cílem určit spolehlivost softwarového produktu.

Question 472

nahraditelnost (=replaceability)

Answer 472

Schopnost softwarového produktu být používán místo jiného specifikovaného softwarového produktu pro stejný účel ve stejném prostředí.

Question 473

požadavek (=requirement)

Answer 473

Ustanovení obsahující kritéria, která mají být splněna.

Question 474

nástroj pro správu požadavků (=requirements management tool)

Answer 474

Nástroj, který podporuje záznam požadavků, atributů požadavků (např. priorita, zodpovědnost) a poznámek a dále usnadňuje sledovatelnost přes jednotlivé vrstvy požadavků a změnového řízení požadavků. Některé nástroje pro řízení požadavků také poskytují podporu pro statickou analýzu jako je např. kontrola konzistence a kontrola porušení předdefinovaných pravidel pro řízení požadavků.

Question 475

fáze požadavků (=requirements phase)

Answer 475

Časové období v životním cyklu vývoje softwaru, během které jsou definovány a dokumentovány požadavky na softwarový produkt.

Question 476

testování založené na požadavcích (=requirements-based testing)

Answer 476

Způsob testování, při kterém je návrh testovacích případů založen na cílech testování a testovacích podmínkách odvozených z požadavků, tedy např. testy, které spouštějí určité funkce nebo měří nefunkcionální charakteristiky jako spolehlivost nebo použitelnost.

Question 477

využití zdrojů (=resource utilization)

Answer 477

Schopnost softwarového produktu použít příslušná množství a druhy zdrojů, (například množství hlavní a vedlejší paměti používané programem nebo velikosti požadovaných dočasných souborů) v případě, kdy software plní svou funkci za stanovených podmínek.

Question 478

testování vytíženosti zdrojů (=resource utilization testing)

Answer 478

Proces testování s cílem určit vytíženost zdrojů softwarového produktu.

Question 479

výsledek (=result)

Answer 479

Důsledek/výsledek provedení testu. Zahrnuje výstupy na obrazovce, změny dat, reporty a odeslané komunikační zprávy.

Question 480

kritéria opětovného spuštění (=resumption criteria)

Answer 480

Kritéria použitá k opětovnému spuštění celého nebo části testování, které bylo dříve pozastaveno.

Question 481

požadavky na znovuzahájení (=resumption requirements)

Answer 481

Definováná sada testovacích aktivit, které se musí opakovat, pokud je testování znovu zahájeno po pozastavení.

Question 482

retrospektiva (=retrospective meeting)

Answer 482

Setkání po dokončení projektu (nebo iterace), během kterého členové projektového týmu hodnotí projekt a snaží se získat ponaučení pro další projekt.

Question 483

revize (přezkoumání) (=review)

Answer 483

Činnost, během níž je pracovní produkt nebo proces hodnocen jednou nebo více osobami s cílem najít problémy a navrhnout vylepšení.

Question 484

plán revizí (přezkoumání) (=review plan)

Answer 484

Dokument, popisující přístup, zdroje a harmonogram zamýšlených aktivit v oblasti revizí (přezkoumání). Mimo jiné identifikuje dokumenty a kód k revizi, typy revize, které mají být užity, účastníky, vstupní a výstupní kritéria, která mají být použita v případě formálních revizí a zdůvodnění jejich volby. Plán revizí je záznamem procesu plánování revizí.

Question 485

revizní nástroj (=review tool)

Answer 485

Nástroj, který podporuje proces revize (přezkoumání). Mezi jeho typické vlastnosti patří plánování revizí, podpora sledování stavu, podpora komunikace, podpora vzdálené spolupráce při revizi a udržování úložiště pro sběr a reportování metrik.

Question 486

revidující (=reviewer)

Answer 486

Účastník revize (přezkoumání), který identifikuje problémy v pracovním produktu.

Question 487

riziko (=risk)

Answer 487

Faktor, který může v budoucnu vést k negativním důsledkům. Obvykle je vyjádřen pomocí dopadu a pravděpodobnosti.

Question 488

analýza rizik (=risk analysis)

Answer 488

Souhrnný proces identifikace a ohodnocení rizik.

Question 489

ohodnocení rizik (=risk assessment)

Answer 489

Proces analýzy identifikovaných rizik s cílem určení úrovně rizik.

Question 490

identifikace rizik (=risk identification)

Answer 490

Proces identifikace rizik pomocí technik jako jsou např. brainstorming, kontrolní seznamy nebo historie selhání.

Question 491

dopad rizika (=risk impact)

Answer 491

Škoda, které bude způsobena v případě, že se riziko skutečně projeví.

Question 492

úroveň rizika (=risk level)

Answer 492

Kvalitativní nebo kvantitativní míra rizika definovaná pomocí jeho dopadu a pravděpodobností, že riziko nastane.

Question 493

pravděpodobnost rizika (=risk likelihood)

Answer 493

Odhadnutá pravděpodobnost, že se z rizika stane skutečný výsledek nebo událost.

Question 494

řízení rizik (=risk management)

Answer 494

Koordinované aktivity zaměřené na nasměrování a řízení organizace s ohledem na rizika.

Question 495

zmírnění rizik (=risk mitigation)

Answer 495

Proces, při kterém jsou učiněna rozhodnutí a aplikována ochranná opatření, a to tak, aby došlo buďto ke snížení rizik na definovanou úroveň nebo k udržení rizik v určitých mezích.

Question 496

typ rizika (=risk type)

Answer 496

Sada rizik seskupených podle jednoho nebo více společných faktorů.

Question 497

testování založené na rizicích (=risk-based testing)

Answer 497

Testování, při němž je management, výběr, prioritizace a využívání testovacích činností a zdrojů založeno na odpovídajících typech rizik a jejich úrovních.

Question 498

robustnost (=robustness)

Answer 498

Míra, při které může komponenta nebo systém fungovat správně v případě neplatných vstupů nebo rušivých podmínkách prostředí.

Question 499

testování robustnosti (=robustness testing)

Answer 499

Proces testování s cílem určit robustnost softwarového produktu.

Question 500

revize založena na roli (=role-based reviewing)

Answer 500

Revizní technika, v níž revidující hodnotí pracovní produkt z pohledu různých rolí zúčastněných stran.