Az agilis szoftverfejlesztés alapvető értékeit tartalmazó nyilatkozat. A fő értékek: az egyének és kölcsönhatásaik fontosabbak, mint az folyamatok és az eszközök, a működő szoftver fontosabb, mint a minden részletre kiterjedő dokumentáció, az ügyféllel való együttműködés fontosabb, mint a szerződéses tárgyalások, a változásokra való reagálás fontosabb, mint a terv követése
A szoftverfejlesztési módszerek csoportja, amely az iteratív fejlesztési modellen alapul, mind a követelmények, mind a megoldások az önszerveződő, széleskörű feladatokkal rendelkező csapatok együttműködése által jönnek létre.
Az agilis módszertannal (mint pl. az extrém programozás, XP) fejlesztett szoftverek tesztelési gyakorlata. A fejlesztést a tesztelés kiszolgálójának tekinti és annak fontosságát hangsúlyozza, hogy a műszaki teszttervezés megelőzi a fejlesztést.
Felhasználó vagy bárki más, lehet egy rendszer is, aki/ami a tesztelt rendszerrel meghatározott kapcsolatban áll.
A szoftvertermék, illetve a folyamat független értékelése annak érdekében, hogy kiderítsük, megfelel-e a szabványoknak, a specifikációknak, az irányelveknek, és/vagy azon dokumentumokban rögzített objektív kritériumoknak, amelyek meghatározzák (1)a termék formáját, illetve tartalmát, (2) a folyamatot, ahogy a terméket elő kell állítani, (3) a szabványoknak, illetve az irányelveknek történő megfelelés mérésének módját
Olyan szoftver használata (pl. felvevő/lejátszó eszközök), amelyekkel a tesztvégrehajtást lehet irányítani, a várt eredményeket össze lehet hasonlítani az aktuális eredményekkel, tesztelési előfeltételeket lehet meghatározni és egyéb tesztirányítási és jelentési funkciókkal is rendelkezik.
Olyan útvonal, amely semmilyen lehetséges bemeneti érték esetén nem hajtódik végre.
Általános és speciális feltételek halmaza, amely engedélyezi egy adott feladat végrehajtását. Az a cél, hogy ne indítsunk olyan feladatokat, amelyek több elvesztetegetett ráfordítást jelentenének, mint az elbukó belépési feltételek kijavítása
A komponens által beolvasott - akár a komponensen belül, vagy kívül tárolt – változó.
A tesztelés, vagy a fejlesztés során alkalmazott leghatékonyabb innovatív eljárások, módszerek, amelyeket általában a többi szervezeti egység is átvehet.
A szoftvertermékek azon tulajdonságai/attribútumai, amik a programokhoz és adatokhoz való jogosulatlan hozzáférést előzik meg. A hozzáférés lehet szándékos vagy akár véletlen is.
Olyan automatizált teszteket tartalmazó készlet, amely az új build-ek integritását validálja, valamint azok alapfunkcióit, stabilitását és tesztelhetőségét verifikálja. Abban az esetben, amikor gyakran készítenek build-eket (pl. agilis projekteknél), ipari gyakorlatnak tekinthető és minden build-en lefuttatják - még a build további tesztelésre való kiadása előtt.
Akkor mondjuk, hogy egy teszt elbukik, ha a tényleges eredménye nem egyezik meg az elvárt eredménnyel.
A szoftvernek egy szűkebb felhasználói körben való külső tesztelése a végső kiadás előtt annak érdekében, hogy meghatározzuk, a szoftver megfelel-e a felhasználók piaci igényeinek. Gyakran megfelel a dobozos (COTS) szoftverek külső átvételi tesztjének.
Olyan teszt, amely magában foglalja egy komponens vagy rendszer szoftverének futtatását.
Olyan progampont, ahol a vezérlési folyamnak két, vagy több alternatív útvonala van. Egy csomópont, amelyből két, vagy több elágazás indul.
A tesztkészlet végrehajtása során a döntési eredmények meghívásának százalékos végrehajtási aránya. 100%-os döntési lefedettség 100%-os elágazási lefedettséget és 100%-os utasítás lefedettséget jelent.
A table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects), which can be used to design test cases.
A legkisebb önállóan tesztelhető szoftver egység.
Olyan környezetet biztosító keretrendszer, amelyben egy komponens egyaránt tesztelhető különállóan valamint a megfelelő segédprogramokkal. Hibakeresési funkciójával támogatja a szoftverfejlesztő munkáját is.
The capability of the software product to interact with one or more specified components or systems.
Feketedoboz tesztelési módszer, amely során olyan teszteseteket készítünk, amelyek az ekvivalencia partíciók egyes reprezentánsait tesztelik. Jellemzően minden egyes ekvivalencia partíciót érdemes legalább egyszer lefedni.
A felhasználó, vagy a megrendelő által a végterméken végzett feketedoboz tesztelés, amely azt hivatott eldönteni, hogy megfelel-e a termék a megfogalmazott (üzleti) elvárásoknak, illetve folyamatoknak.
A szoftver adott feltételek melletti, a specifikáció, vagy más forrás alapján előrejelzett viselkedése.
Környezeti vagy állapotbeli feltételek, amelyeket teljesíteni kell, mielőtt egy komponensen vagy rendszeren tesztet vagy tesztelési folyamatokat kezdenénk.
A szoftver adott feltételek melletti, a specifikáció, vagy más forrás alapján előrejelzett viselkedése.
Emberi tevékenység, amely során helytelen eredmény jön létre.
Szoftverfejlesztési módszertan, amelyet az agilis szoftverfejlesztés során használnak. A legfontosabb jellemzői a páros programozás, az alapos kód felülvizsgálat, minden kódhoz unit teszt készítése, illetve a kód egyszerűsége és átláthatósága.
A szoftver belső struktúrájának elemzésén alapuló tesztelés
Olyan módszer, amelynél a szoftver specifikáció alapján, a program belső szerkezetének ismerete nélkül tervezünk teszteket.
Olyan módszer, amelynél a szoftver specifikáció alapján, a program belső szerkezetének ismerete nélkül tervezünk teszteket.
A rendszer minden olyan összetevője, amely információt és vezérlést biztosít a felhasználó számára a rendszerrel kapcsolatos konkrét feladatok elvégzéséhez.
Egy személy megfigyelésése és reagálásai a szoftvertermék használatából vagy várható használatából fakadóan.
Magas szintű felhasználói, vagy üzleti követelmény, amelyet általában az agilis szoftverfejlesztés során használnak. Jellemzően egy, vagy több, hétköznapi, vagy üzleti nyelven megfogalmazott mondatot tartalmaz, amely leírja, hogy a felhasználónak milyen funkcionalitásra van szüksége, vagy bármilyen egyéb nem-funkcionálisi követelményt fogalmaz meg, továbbá tartalmazza az átvételi kritériumot is.
Egymáshoz kapcsolódó tevékenységek halmaza, amely a bemenő értékekből kimenő értékeket generál.
Szervezeti folyamatok teljesítményének és érettségének javítására szolgáló tevékenységek és ezek eredményinek összessége
Dokumentált eljárásokal és követelményekkel (pl. inspekcióval) jellemzett felülvizsgálat.
A programozási nyelvek egy entitása, ami tipikusan a futtatás legkisebb oszthatatlan egysége.
A szoftvertermék azon képessége, hogy – bizonyos feltételek fennállása esetén - képes a meghatározott igények szerinti működésre.
Olyan követelmény, amely a szoftverrel szemben támasztott funkcionális elvárást írja le.
A komponensnek, vagy a rendszernek a követelmény-dokumentációban meghatározott attribútuma (pl. a megbízhatóságra, a használhatóság, illetve műszaki tervezési jellemzőire).
Egy központi ötlet, vagy szó körül más szavak, ötletek, feladatok, vagy egyéb egységek elrendezését, illetve szerkesztését szolgáló ábra. Gondolattérképeket ötletek létrehozására, megjelenítésére, rendezésére és osztályozására használnak, illetve segíthetnek tanulmányok, szervezetek, problémamegoldások és döntések meghozatalában és leírásában.
A szoftver képességeinek megértése, megtanulása, használata a felhasználó számára, meghatározott feltételek mentén.
Annak meghatározása, hogy a szoftvertermék mennyire érthető meg, mennyire könnyű megtanulni használatát és milyen könnyen kezelhető, ezáltal - meghatározott feltételek mentén - mennyire felhasználóbarát.
A program változóinak, illetve paramétereinek szélsőérték- elemzésén alapuló feketedoboz teszttervezési technika.
A tervezett eredmény létrehozásának képessége.
Egy általánosan elfogadott hüvelykujj-szabály, amely segít elérni a célt.
Olyan dokumentum, amely leírja a szoftver azon hibáit, amelyek a program elégtelen működéséhez vezethetnek.
Olyan műszaki teszttervezési módszer, amely során a tesztelők tapasztalata alapján próbálják megsejteni a tesztelendő szoftverben levő hibákat, illetve ez alapján próbálnak megfelelő teszteket tervezni.
A szoftverben azonosított hibák aránya a szoftver méretéhez viszonyítva (ez utóbbi szabványos mértékegységben kifejezve, mint pl. a kódsorok, vagy az osztályok, illetve funkciópontok száma).
Egy komponens vagy rendszer azon tulajdonsága, hogy bizonyos funkciókat milyen hatékonyan hajt végre (tranzakciók ideje, száma, válaszidő, stb).
Fejlesztési életciklus modell, ahol a projekt részét alkotó kis lépések mindegyike egy kis részt tesz hozzá az általános projektkövetelményekhez. A követelményeket priorizálják és a megfelelő inkrementális egységben a prioritási sorrend szerint szállítják. Ezen életciklusmodell néhány (de nem minden) verziójában minden alprojekt egy „mini V-modell” szerint működik, saját tervezési, megvalósítási és tesztelési fázisokkal.
A komponensek, vagy rendszerek nagyobb egységbe történő összeolvasztásának folyamata.
Olyan fejlesztési életciklus, amely során a projektet nagyszámú iterációk sorozatára bontják. Egy iteráció egy olyan teljes fejlesztési ciklus, amely egy végrehajtható termék (belső vagy külső) kiadását eredményezi, a végső termék egy részhalmazát, amely iterációról iterációra növekedve válik a végső termékké.
Egy alkalmazás azon tulajdonsága, hogy milyen egyszerűen lehet hibákat javítani benne, új vagy megváltozott követelmények illetve környezet miatt szükséges módosításokat eszközölni.
Az alkalmazás átadása után végzett módosítások: hiba javítások, teljesítmény vagy más jellemzők feljavítása illetve megváltozott környezetre/követelményekre való alkalmazása.
Általános és speciális feltételek halmaza, amelyet minden érintettel egyeztetve egy folyamat hivatalos befejezési feltételének tekintünk. A célja, hogy megakadályozzuk az olyan feladatok befejezettnek tekintését, amelyeknek még vannak függőben levő, be nem fejezett részei. A kilépési feltételeket a tesztelés leállításának tervezéséhez és jelentéséhez használjuk. .
Egy (komponensen kívül vagy belül tárolt) változó, amelyet egy komponens írhat.
Olyan ábra, amely az iterációban hátralevő munkamennyiséget mutatja a maradék idő függvényében. Kiolvasható belőle a kivitelezés állapota és várható alakulása. Az X-tengely általában a futam napjait jelöli, míg az Y-tengely a hátralevő munka mennyiségét (általában vagy elméleti mérnökórában, vagy story pontokban.)
Az a tényező, amely a jövőben negatív következményeket okozhat. Általában, mint hatás és valószínűség jelenik meg.
A tesztelés egy olyan megközelítése, mely csökkenti a termék kockázati szintjét és tájékoztatja az érintetteket a kockázat mértékéről már a projekt kezdeti fázisában. Magában foglalhatja mind a termék kockázatainak azonosítását, mind a tesztfolyamat kockázat szerinti vezetését.
A projekt-illetve termékkockázati elemek elemzésének folyamata, amelynek során meghatározzuk a kockázat szintjét, jellemzően a várható kihatásának, illetve a bekövetkezés valószínűségének a a megbecslésével.
Egy kockázat nagysága megadható a hatásának és a valószínűségének karakterisztikájával. A kockázat nagysága, azaz a kockázati szint meghatározza a tesztelés intenzitását is. A kockázati szint kvalitatív (nagy, közepes, kicsi) vagy kvantitatív (30%) módon egyaránt megadható.
Egy olyan folyamat, melyben megelőző méréseket végzünk, és döntéseket hozunk, hogy a megadott szintre csökkentsük, vagy azon a szinten tartsuk a kockázatokat.
Annak mértéke, hogy egy komponens vagy rendszer információt cserélhessen más komponensekkel vagy rendszerekkel.
A szoftver tervének, illetve belső struktúrájának összetettsége megértés, karbantartás, valamint verifikálás szempontjából.
A legkisebb önállóan tesztelhető szoftver egység.
A rendszer, illetve a szoftver összeállítása az alkotóelemeinek száma, jellege és kapcsolatai alapján.
A következő tevékenységek technikai és adminisztratív irányítása: a konfigurációs elemek funkcionális és fizikai karakterisztikáinak meghatározása és dokumentálása, az ezen karakterisztikákhoz képest történő változás irányítása, a változáskezelési és megvalósítási állapot nyomon követése és jelentése, illetve a különböző követelményeknek történő megfelelés.
An aggregation of hardware, software or both, that is designated for configuration management and treated as a single entity in the configuration management process.
A szoftver belső struktúrájának elemzésén alapuló tesztelés
Olyan feltétel vagy képesség, amely a felhasználó számára azért szükséges, hogy megoldjon egy problémát,vagy elérjen egy célt. Ezen feltételnek vagy képességnek a rendszer vagy rendszer komponens által is megvalósíthatónak kell lennie úgy, hogy közben a szerződés, szabvány, specifikáció és egyéb formális dokumentumban támasztott követelményeknek is megfeleljen.
Olyan eszköz, amely támogatja a követelmények, a követelmény jellemzőinek (pl. prioritás, tudás gazda) rögzítését és magyarázó jegyzetek készítését, valamint megkönnyíti a különböző szintű követelmények nyomon követhetőségét és változás menedzsmentjét. Vannak olyan követelménymenedzsment eszközök, melyek a statikus elemzéshez is segítséget nyújtanak, például konzisztencia ellenőrzéssel vagy előre definiált, követelményekre vonatkozó szabályokkal.
Annak százalékos mérőszáma, hogy az adott lefedettségi elemet milyen arányban hajtotta végre a teszteszköz.
A szoftvertermék azon képessége, hogy a szükséges, előírt funkcionalitást meghatározott időtartam vagy meghatározott műveletszám mellett az előre megállapított követelmények szerint látja el.
A komponens, illetve a rendszer eltér az elvárt eredménytől, vagy szolgáltatástól.
Egy olyan értékelés eredménye, amely néhány fontos kérdést, problémát vagy lehetőséget azonosít.
Méréseknél használatos skála és mérési módszertan.
Minőségmenedzsment része, azon tevékenységek és módszerek összessége, amelyek a minőségi követelmények teljesítésére fókuszálnak
A minsőgéi jellemzőkhöz tartozó kockázat.
A tesztelendő rendszer, vagy egy komponens modelljén alapuló teszt, mint a megbízhatóság-növekedés modell, használati modellek, mint a működési profilok, vagy viselkedési modellek, mint a döntési tábla, vagy az állapotátmenet diagramm.
A legkisebb önállóan tesztelhető szoftver egység.
A munkamenet alapú tesztelés mérésének és irányításának egy módszere.
Tetszőleges egyed egy tulajdonságához mérés során hozzárendelt számossága vagy kategóriája.
A műszaki teszttervezési tevékenységet támogató eszköz, amely tesztbemeneteket generál egyéb forrásokból, pl. CASE eszközökből, követelmény menedzsment eszközökből, tesztfeltételekből valamint magából a programkódból.
Olyan fejlesztői tevékenység, amely során minden nap során a teljes rendszert lefordítják és összeszerkesztik (általában éjszaka), hogy mindig elérhető legyen egy olyan konzisztens rendszer, amely tartalmazza a legfrissebb változtatásokat.
Egy komponens vagy rendszer funkcionalitáshoz nem kapcsolódó tulajdonságainak tesztelése, mint például megbízhatóság, hatékonyság, használhatóság, karbantarthatóság és hordozhatóság.
A dokumentáció és a szoftver összefüggő egységeinek vizsgálata, pl. a követelmények és a hozzájuk tartozó tesztesetek közötti kapcsolatra.
A table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects), which can be used to design test cases.
A várt és az aktuális eredmények összehasonlítását támogató forrás. Teszt-orákulum lehet egy másik, benchmark-ként funkcionáló rendszer. Lehet felhasználó kézikönyv, vagy akár egy személy speciális tudása is. A program forráskódja viszont nem lehet teszt-orákulum
Feketedoboz tesztelési módszer, amely során olyan teszteseteket készítünk, amelyek az ekvivalencia partíciók egyes reprezentánsait tesztelik. Jellemzően minden egyes ekvivalencia partíciót érdemes legalább egyszer lefedni.
Egy elemhez rendelt (üzleti) fontosság, például hiba prioritás.
A program olyan belső hibája, amely azt eredményezheti, hogy a szoftver nem tudja teljesíteni az elvárt viselkedését, azaz a program meghibásodásához vezethet.
Olyan dokumentum, amely leírja a szoftver azon hibáit, amelyek a program elégtelen működéséhez vezethetnek.
A program olyan belső hibája, amely azt eredményezheti, hogy a szoftver nem tudja teljesíteni az elvárt viselkedését, azaz a program meghibásodásához vezethet.
A program olyan belső hibája, amely azt eredményezheti, hogy a szoftver nem tudja teljesíteni az elvárt viselkedését, azaz a program meghibásodásához vezethet.
A szoftver belső struktúrájának elemzésén alapuló tesztelés
A szoftver belső struktúrájának elemzésén alapuló tesztelés
A projekt egy időben, költségekben és erőforrásokban korlátozott, adott követelményeknek megfelelő cél érdekében kezdő és végidőpontokkal ellátott koordinált és kontrollált tevékenységek halmaza.
Egy (teszt) projekt menedzsmentjénél, iránytásánál felmerülő kockázat, mint például emberhiány, szoros határidők, változó követelmények, stb.
Két személy, pl.: két tesztelő, egy fejlesztő és egy tesztelő, vagy egy végfelhasználó és egy tesztelő együttesen hibakereséssel foglalkoznak. Általában egy gép előtt ülve felváltva folytatják a tesztelést.
Egy szabadalmaztatott rugalmas iteratív szoftverfejlesztési folyamat keretrendszer, amely 4 projekt életciklus fázisból áll: Elkészítés Kidolgozás Megvalósítás Átadás.
Olyan tesztelés, amely a tesztelendő rendszerre és a megszerzett tesztadatokra dinamikus válaszokat ad. Tipikusan lerövidített tervezési ciklus jellemzi, a műszaki teszttervezés és a teszt megvalósítása csak a teszt tárgyának rendelkezésre állása után történik.
A regresszió kockázatainak kezelésére hivatott tesztelés, mely különböző sajátos technikákat használ. Pl. újrafelhasználható tesztek tervezése, kiterjedt tesztautomatizálás egy vagy több tesztszinten.
Annak meghatározása, hogy a komponens, illetve a szoftver mennyire elérhető és működőképes, amikor szükségessé válik a használata. Gyakran százalékban adják meg.
Bizonyos funkciók, vagy funkciók halmazának elvégzése érdekében összeszervezett komponensek összessége.
Annak fokmérője, hogy egy komponens vagy rendszer mennyire képes az elvárt működésre érvénytelen bemenetek vagy szűkös környezeti erőforrások mellett.
Iteratív, inkrementális keretrendszer az általában agilis szoftverfejlesztést alkalmazó projektekhez.
Egy teszt sikeresnek minősül, ha a kapott eredmény megfelel az elvárt eredménynek.
Akkor mondjuk, hogy egy teszt elbukik, ha a tényleges eredménye nem egyezik meg az elvárt eredménnyel.
Egy dokumentum, ami ideális esetben teljesen, precízen és ellenőrizhetően határozza meg egy komponens vagy rendszer követelményeit, konstrukcióját, viselkedését vagy egyéb karakterisztikáit. A követelmények ellenőrzésének a folyamatát is meghatározhatja.
Olyan módszer, amelynél a szoftver specifikáció alapján, a program belső szerkezetének ismerete nélkül tervezünk teszteket.
Olyan módszer, amelynél a szoftver specifikáció alapján, a program belső szerkezetének ismerete nélkül tervezünk teszteket.
A szoftverelemek (például követelmények, műszaki szoftverterv, vagy kód) elemzése azok futtatása nélkül. Általában támogató eszközök segítségével végzik.
A forráskód elemzése anélkül, hogy a szoftvert futtatnánk.
A szoftver belső struktúrájának elemzésén alapuló tesztelés
Formális, esetleg szerint kötelező jellegű követelmények, amelyeket egy adott munka elvégzési módjának következetes előírására, illetve irányelvek meghatározására használnak (pl. ISO/IEC szabányok, IEEE szabványok és szervezeti szabványok)
Egy fizikai vagy egy absztrakt rendszer kiválasztott viselkedési karakterisztikáinak egy másik rendszer által történő ábrázolása.
Számítógépes programok, folyamatok és esetlegesen a számítógépes rendszer üzemelésére vonatkozó dokumentációk és adatok.
A komponensnek, vagy a rendszernek a követelmény-dokumentációban meghatározott attribútuma (pl. a megbízhatóságra, a használhatóság, illetve műszaki tervezési jellemzőire).
Egy időperiódus, ami akkor kezdődik, amikor a szoftverterméket kigondoljuk és akkor fejeződik be, amikor a szoftvert már nem használják. A szoftver életciklus jellemzően a következő fázisokat tartalmazza: koncepció, követelmény, tervezés, megvalósítás, teszt, installáció és ellenőrzés, operáció és üzemeltetés, valamint időnként egy leállítási fázist. Megjegyzés: a fázisok átfedhetik egymást, vagy akár ismétlődhetnek is.
Valamely hiba hatásának a mértéke a rendszer vagy komponens fejlesztésére vagy működésére.
A tesztelő tapasztalatára, tudására és megérzéseire építő tesztelés.
Egy komponens vagy rendszer azon tulajdonsága, hogy bizonyos funkciókat milyen hatékonyan hajt végre (tranzakciók ideje, száma, válaszidő, stb).
Általános és speciális feltételek halmaza, amelyet minden érintettel egyeztetve egy folyamat hivatalos befejezési feltételének tekintünk. A célja, hogy megakadályozzuk az olyan feladatok befejezettnek tekintését, amelyeknek még vannak függőben levő, be nem fejezett részei. A kilépési feltételeket a tesztelés leállításának tervezéséhez és jelentéséhez használjuk. .
A teszt tárgyához (magához a termékhez) közvetlenül kapcsolódó kockázat.
Konszenzuson alapuló becslési technika, melyet legfőképpen agilis fejlesztésben, a felhasználói forgatókönyvek ráfordításának vagy viszonylagos méretének becslésére használnak. A Wide Band Delphi módszer egy variánsa, melyben különböző értékeket tartalmazó kártyákból álló kártyacsomagot használnak a csapat által végzett becslésben.
A tesztvégrehajtás következménye/kimenete, amely lehet: képernyő, adatváltozás, riport, kiküldött kommunikációs üzenet stb.
Egy vagy több teszteset halmaza.
A teszt tárgyát képező rendszer vagy rendszerkomponens.
A várt és az aktuális eredmények összehasonlítását támogató forrás. Teszt-orákulum lehet egy másik, benchmark-ként funkcionáló rendszer. Lehet felhasználó kézikönyv, vagy akár egy személy speciális tudása is. A program forráskódja viszont nem lehet teszt-orákulum
Olyan teszteszköz, amellyel a teszteléshez adatot állíthatunk elő egy már meglévő adatbázisból. Az eszköz alkalmas lehet egyéb adatok generálására, adatok manipulálására, valamint szerkesztésére is.
A tesztbázis elemzésének és a tesztcél meghatározásának folyamata.
Az összes olyan dokumentum, amelyből a komponensekre vagy rendszerekre vonatkozó követelmények származnak. Ezek azok a dokumentumok, amelyeken a tesztesetek alapulnak. Ha egy ilyen dokumentumot csak formális változáskezelési folyamat során módosíthatnak, a tesztbázist ún. fagyasztott tesztbázisnak nevezik.
A tesztstratégia megvalósítása egy konkrét projektre. Jellemzően a projekt céljain és a kockázatelemzésen alapuló döntéseket, a tesztfolyamatok kiindulópontjait, az alkalmazandó műszaki teszttervezési technikákat, belépési és kilépési kritériumokat valamint a tesztelés fajtáit tartalmazza.
Általános és speciális feltételek halmaza, amelyet minden érintettel egyeztetve egy folyamat hivatalos befejezési feltételének tekintünk. A célja, hogy megakadályozzuk az olyan feladatok befejezettnek tekintését, amelyeknek még vannak függőben levő, be nem fejezett részei. A kilépési feltételeket a tesztelés leállításának tervezéséhez és jelentéséhez használjuk. .
A tesztvégrehajtás következménye/kimenete, amely lehet: képernyő, adatváltozás, riport, kiküldött kommunikációs üzenet stb.
Bemeneti értékek, végrehajtási előfeltételek, elvárt eredmények és végrehajtási utófeltételek halmaza, amelyeket egy konkrét célért vagy a tesztért fejlesztettek (például egy program forgatókönyv végrehajtása, vagy egy követelménynek való megfelelés).
Az alapvető tesztfolyamat a következő tevékenységeket öleli fel: a műszaki teszttervezést, a tesztelés irányítását, a tesztelemzést és tervezést, a teszt megvalósítását és végrehajtását, a kilépési feltételek kiértékelését, valamint a teszt lezárási tevékenységeket.
Olyan teszteszköz, amellyel a teszteléshez adatot állíthatunk elő egy már meglévő adatbázisból. Az eszköz alkalmas lehet egyéb adatok generálására, adatok manipulálására, valamint szerkesztésére is.
A teszttevékenységek során keletkezett adatok összegyűjtése és elemzése, ezt követően az adatokból az érintettek számára egy jelentés készítése.
A tesztvégrehajtás következménye/kimenete, amely lehet: képernyő, adatváltozás, riport, kiküldött kommunikációs üzenet stb.
A tesztelést támogató eszközök együttese, beleértve minden hardver és szoftver eszközt.
Annak százalékos mérőszáma, hogy az adott lefedettségi elemet milyen arányban hajtotta végre a teszteszköz.
A teszttevékenységek tervezése, becslése, monitorozása és irányítása, amelyet általában a tesztmenedzser végez.
Dokumentum, amely tartalmazza a műszaki tesztterv (test design) specifikációt, a teszteset specifikációt és/vagy az eljárás specifikációt.
A teszt végrehajtása egy megszakítás nélküli idő intervallumban. A felderítő teszt során minden tesztszakasz az egyes fejezetekre összpontosít, de a tesztelők egyéb tevékenységekkel, illetve új lehetőségekkel is foglalkozhatnak. Ebben az esetben a tesztelő a teszteseteket menet közben készíti, hajtja végre valamint dokumentálja azok eredményét.
Közös szervezés és menedzsment alatt álló teszttevékenységek csoportja. A tesztszint felelősségi körökhöz kapcsolódik a projekten belül. Tesztszintekre példa a komponens-teszt, integrációs teszt, rendszerteszt és felhasználó teszt.
Legtöbbször teszteljárás specifikációra használt kifejezés, elsősorban automatizált teszt esetén.
A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.
Tesztterv (test plan) készítése vagy módosítása.
Egy meghatározott tesztobjektumon végrehajtott, rendszerkomponensre vagy rendszerre fókuszáló teszttevékenységek csoportja. Példa teszttípusokra: funkcionális teszt, használhatósági teszt, regressziós teszt, stb. Egy teszttípus több tesztszinten is végrehajtható.
Olyan teszteszköz, amely teszteket hajt végre egy kijelölt tesztelemen, és értékeli az eredményeket az elvárt eredmények és az utófeltételek alapján.
A programozási nyelvek egy entitása, ami tipikusan a futtatás legkisebb oszthatatlan egysége.
Egy keretrendszer a szoftverfejlesztési ciklus részletes leírására, a követelményspecifikációtól kezdve az üzemeltetésig. Az V-modell illusztrálja, hogy a teszttevékenység hogyan illeszthető a szoftverfejlesztési életciklusok bármely fázisába.
Annak vizsgálata és konfirmálása, hogy a szoftver tervezett felhasználási céljának megfelelő követelmények teljesülnek-e.
Az adott követelmények teljesülésének vizsgálata és konfirmálása.
Események egy sora, például egy komponens vagy rendszer kezdő és végpontja közötti végrehajtható utasítások.
Egy projekt végén, a projekttagokkal tartott megbeszélés, melyen értékelik a projektet és a tanulságokat egy következő projekt számára.
A számítógép által tárolt elem, amelyet a szoftver a nevén hivatkozva ér el.
A követelmények egy adott tesztszinten történő nyomon követése a különböző tesztdokumentációkon keresztül (pl. tesztterv, műszaki tesztterv specifikáció, teszteset specifikáció, teszteljárás specifikáció, vagy tesztszkript).
Egy adott szervezet, illetve tevékenység hatékonyságának megjelenítését szolgálja. A metrikákat olyan metaforákkal helyettesítik, mint például „számlap” vagy „mutató, vagy más kijelző, amelynek segítségével az autóiparra lehet asszociálni, és így a tevékenység vagy esemény hatása egyszerűen megérthető és hozzáköthető a működési célokhoz.
Azon kilépési feltétel, amelyet a komponensnek, illetve a rendszernek teljesítenie kell, hogy a felhasználó, az ügyfél, vagy más, erre feljogosított személy átvehesse azt
A projekt, vagy a termék életének fázisokra bontása
(1) egy szervezet azon képessége, hogy milyen hatásossággal és hatékonysággal használja elméleti- és gyakorlati munkafolyamatait. (2) egy szoftvertermék azon képessége amelynek köszönhetően elkerülhető, hogy egy esetlegesen fellépő programhiba működési hibát okozzon.
Végrehajtható utasítás, amelyben egy változóhoz hozzá van rendelve egy érték.
Események egy sora, például egy komponens vagy rendszer kezdő és végpontja közötti végrehajtható utasítások.