TechCodeview

A tesztterv egy részletes dokumentum, amely leírja a szoftvertesztelési területeket és tevékenységeket. Felvázolja a tesztelési stratégiát, a célkitűzéseket, a tesztelési ütemtervet, a szükséges erőforrásokat (emberi erőforrás, szoftver és hardver), a tesztbecslést és a teszteredményeket.

A tesztterv minden szoftver tesztelésének alapja. Ez a legfontosabb tevékenység, amely biztosítja, hogy a tervezett tevékenységek listája megfelelő sorrendben elérhető legyen.

A tesztterv egy sablon a szoftvertesztelési tevékenységek végrehajtásához, mint meghatározott folyamathoz, amelyet a tesztelésvezető teljes mértékben felügyel és irányít. A vizsgálati tervet a tesztvezető (60%), a tesztvezető (20%) és a tesztmérnök (20%) készíti el.

A vizsgálati terv típusai

A teszttervnek három típusa van

• Fő vizsgálati terv
• Fázisvizsgálati terv
• Teszttípus-specifikus vizsgálati tervek

Fő vizsgálati terv

A fő tesztterv egy olyan tesztterv, amely több szintű teszteléssel rendelkezik. Teljes tesztstratégiát tartalmaz.

Fázisvizsgálati terv

A fázistesztterv egy olyan tesztterv, amely a tesztelési stratégia bármely fázisára vonatkozik. Például eszközök listája, tesztesetek listája stb.

Konkrét vizsgálati tervek

Különleges tesztterv a főbb tesztelési típusokhoz, mint például a biztonsági tesztelés, a terhelési tesztelés, a teljesítményteszt stb. Más szóval, egy speciális tesztterv, amelyet nem funkcionális teszteléshez terveztek.

Hogyan írjunk teszttervet

A tesztelési terv elkészítése a tesztmenedzsment folyamat legfontosabb feladata. Az IEEE 829 szerint a tesztterv elkészítéséhez kövesse az alábbi hét lépést.

• Először is elemezze a termék szerkezetét és architektúráját.
• Most tervezze meg a tesztelési stratégiát.
• Határozza meg az összes tesztcélt.
• Határozza meg a tesztelési területet.
• Határozza meg az összes használható erőforrást.
• Minden tevékenységet megfelelő módon ütemezzen.
• Határozza meg az összes tesztteljesítményt.

Tesztterv-összetevők vagy attribútumok

A tesztterv különböző részekből áll, amelyek segítenek a teljes tesztelési tevékenység levezetésében.

Célok: Információkat tartalmaz a modulokról, szolgáltatásokról, tesztadatokról stb., amelyek jelzik, hogy az alkalmazás célja az alkalmazás viselkedése, célja stb.

Hatály: Olyan információkat tartalmaz, amelyeket egy adott alkalmazással tesztelni kell. A hatókör további két részre osztható:

• Hatókörben
• Ki a hatókörből

Hatáskörben: Ezek azok a modulok, amelyeket szigorúan (részletesen) tesztelni kell.

Hatókörön kívül: Ezek azok a modulok, amelyeket nem kell szigorúan tesztelni.

Például , Tegyük fel, hogy van egy Gmail-alkalmazásunk tesztelni, hol tesztelendő funkciók mint például Levél, Elküldött tételek, Beérkezett üzenetek, Piszkozatok írása és a nem tesztelhető funkciók mint például Segítség , és így tovább, ami azt jelenti, hogy a tervezési szakaszban a termékben megadott időkorlát alapján döntjük el, hogy melyik funkcionalitást kell ellenőrizni vagy nem.

Most hogyan döntjük el, hogy mely funkciókat ne teszteljük?

A következő szempontok alapján dönthetjük el, hogy melyik funkciót ne teszteljük:

• Ahogy fentebb látjuk Segítség A funkciók nem kerülnek tesztelésre, mivel azt a műszaki író írta és fejlesztette, és egy másik professzionális író felülvizsgálta.
• Tegyük fel, hogy van egy olyan alkalmazásunk, amelyik rendelkezik P, Q, R és S funkciókat, amelyeket a követelmények alapján kell fejleszteni. De itt az S funkciót már más cég tervezte és használta. Így a fejlesztőcsapat megvásárolja az S-t ettől a cégtől, és további funkciókkal integrálja, mint például a P, Q és R.

Most nem végezzük el az S funkció funkcionális tesztelését, mert azt már valós időben használták. De elvégezzük az integrációs tesztelést és a rendszertesztet a P, Q, R és S funkciók között, mert előfordulhat, hogy az új funkciók nem működnek megfelelően az S funkcióval, ahogy az az alábbi képen is látható:

• Tegyük fel, hogy a termék első kiadásában a kifejlesztett elemek, mint pl P, Q, R, S, T, U, V, W…..X, Y, Z . Most az ügyfél biztosítja a követelményeket az új funkciókhoz, amelyek javítják a terméket a második kiadásban, és az új funkciók is A1, B2, C3, D4 és E5.

Ezt követően a tesztterv során a hatókört mintként írjuk

Hatály

hogyan lehet egy képet a css-n középre helyezni

Tesztelendő tulajdonságok

A1, B2, C3, D4, E5 (új funkciók)

P, Q, R, S, T

Nem tesztelendő tulajdonságok

W…..X, Y, Z

Ezért először ellenőrizni fogjuk az új funkciókat, majd folytatjuk a régi funkciókkal, mert az új funkciók hozzáadása után ez hatással lehet, ami azt jelenti, hogy a hatásterületekre is hatással lesz, ezért egy körben visszafejlődő tesztelést végzünk a P, Q esetében. , R…, T jellemzői.

Vizsgálati módszertan:

Információkat tartalmaz az alkalmazáson végzett különböző típusú tesztelésekről, például a funkcionális tesztelésről, az integrációs tesztelésről és a rendszertesztelésről stb. Ebben döntjük el, hogy milyen típusú tesztelést végezzünk; a különböző funkciókat az alkalmazási követelmények alapján végezzük. És itt azt is meg kell határozni, hogy milyen tesztelést alkalmazunk a tesztelési módszertanokban, hogy mindenki, így a vezetőség, a fejlesztőcsapat és a tesztelő csapat is könnyen megértse, mert a tesztelési feltételek nem szabványosak.

Például, önálló alkalmazáshoz, mint pl Adobe Photoshop , a következő típusú vizsgálatokat végezzük el:

Füstvizsgálat → Funkcionális tesztelés → Integrációs tesztelés → Rendszerteszt → Adhoc tesztelés → Kompatibilitásteszt → Regressziós tesztelés → Globalizációs tesztelés → Kisegítő lehetőségek tesztelése → Használhatósági tesztelés → Megbízhatósági tesztelés → Helyreállítási tesztelés → Telepítési vagy eltávolítási tesztelés

És tegyük fel, hogy tesztelnünk kell a https://www.jeevansathi.com/ alkalmazást, így a következő típusú vizsgálatokat végezzük el:

Megközelítés

Ez az attribútum az alkalmazás folyamatának leírására szolgál a tesztelés során, és későbbi hivatkozásként szolgál.

Az alkalmazás menetét az alábbi szempontok segítségével érthetjük meg:

A magas szintű forgatókönyvek megírásával Az áramlási grafikon megírásával

A magas szintű forgatókönyvek megírásával

Például , tegyük fel, hogy teszteljük a Gmail Alkalmazás:

• Bejelentkezés a Gmailbe – e-mailt küld, és ellenőrzi, hogy az az Elküldött tételek oldalon van-e
• Bejelentkezni …….
• ……
• …….

Ezt azért írjuk, hogy leírjuk azokat a megközelítéseket, amelyeket a termék teszteléséhez kell alkalmazni, és csak a kritikus jellemzők esetében, ahol a magas szintű forgatókönyveket írjuk le. Itt nem az összes forgatókönyv lefedésére koncentrálunk, mert az adott tesztelő mérnök döntheti el, hogy mely funkciókat kell tesztelni vagy sem.

Az áramlási grafikon megírásával

A folyamatábra azért készült, mert a magas szintű forgatókönyvek megírása kicsit időigényes folyamat, ahogy az alábbi képen is látható:

Folyamatos grafikonokat készítünk, hogy a következő előnyökkel rendelkezzünk, például:

• A lefedés egyszerű
• Az összevonás egyszerű

A megközelítés két részre osztható, amelyek a következők:

• Felülről lefelé megközelítés
• Alulról felfelé megközelítés

Feltevés

Információkat tartalmaz egy olyan problémáról vagy problémáról, amely a tesztelési folyamat során fordult elő, és amikor a tesztterveket írjuk, akkor a biztos feltételezések születnek, például erőforrások és technológiák stb.

Kockázat

Ezekkel a kihívásokkal kell szembenéznünk, hogy tesztelhessük az alkalmazást a jelenlegi kiadásban, és ha a feltételezések kudarcot vallanak, akkor kockázatokkal kell szembenéznünk.

Például, a kérelem, megjelenési dátum hatálya elhalasztható.

Mérséklési terv vagy készenléti terv

Ez egy tartalék terv, amely felkészült a kockázatok vagy problémák leküzdésére.

mb vs gb

Lássunk egy példát a feltételezésre, a kockázatra és a készenléti tervre együtt, mert ezek összefüggenek egymással.

Bármely termékben a feltevés azt fogjuk elérni, hogy mind a 3 tesztelő mérnök ott legyen a termék elkészültéig, és mindegyikükhöz különböző modulokat rendelnek hozzá, például P, Q és R. Ebben a konkrét forgatókönyvben a kockázat ez lehet az, ha a tesztmérnök a közepén hagyja el a projektet.

Ezért a készenléti terv minden funkcióhoz egy elsődleges és egy alárendelt tulajdonos lesz hozzárendelve. Tehát ha az egyetlen tesztelő mérnök távozik, a beosztott tulajdonos átveszi az adott funkciót, és segít az új tesztmérnöknek is, hogy megértse a hozzárendelt modulokat.

A feltételezések, a kockázatok és a mérséklési vagy készenléti tervek mindig pontosan a terméken szerepelnek. A különböző típusú kockázatok a következők:

• Ügyfél nézőpontja
• Erőforrás megközelítés
• Műszaki vélemény

Szerep és felelősség

Meghatározza a teljes feladatot, amelyet a teljes tesztelőcsoportnak el kell végeznie. Ha jön egy nagy projekt, akkor a Tesztkezelő az a személy, aki a teszttervet írja. Ha 3-4 kis projekt van, akkor a tesztmenedzser minden egyes projektet hozzárendel minden tesztvezetőhöz. Ezután a tesztvezető megírja a projekt teszttervét, amelyet hozzárendelnek.

Lássunk egy példát, ahol megértjük a tesztmenedzser, a tesztvezető és a tesztmérnökök szerepét és felelősségét.

Szerep: Tesztvezető

Név: Ryan

Felelősség:

• Készítse el (írja és tekintse át) a teszttervet
• Vezesse le a találkozót a fejlesztőcsapattal
• Vezesse le a találkozót a tesztelő csapattal
• Vezesse le a találkozót az ügyféllel
• Tartson egy havi stand up értekezletet
• Aláírja a kiadási megjegyzést
• Eszkalációk és problémák kezelése

Szerep: Tesztvezető

Név: Harvey

Felelősség:

• Készítse el (írja és tekintse át) a teszttervet
• Tartson napi stand up értekezletet
• Tekintse át és hagyja jóvá a tesztesetet
• Készítse elő az RTM-et és a jelentéseket
• Modulok hozzárendelése
• Kezelési ütemterv

Szerep: Tesztmérnök 1, Tesztmérnök 2 és Tesztmérnök 3

Név: Louis, Jessica, Donna

Modulok hozzárendelése: M1, M2 és M3

Felelősség:

• Írja meg, tekintse át és hajtsa végre a tesztdokumentumokat, amelyek tesztesetekből és tesztforgatókönyvekből állnak
• Olvassa el, tekintse át, értse meg és elemezze a követelményt
• Írja le az alkalmazás menetét
• Hajtsa végre a tesztesetet
• RTM a megfelelő modulokhoz
• Hibakövetés
• Készítse el a teszt végrehajtási jelentést, és közölje a tesztvezetővel.

Menetrend

A munkához szükséges időzítés magyarázatára szolgál, vagy ez az attribútum lefedi, hogy az egyes tesztelési tevékenységek pontosan mikor kezdődjenek és mikor fejeződjenek be? És a pontos adatok is szerepelnek minden vizsgálati tevékenységnél az adott dátumra vonatkozóan.

Ezért, amint az alábbi képen láthatjuk, hogy az adott tevékenységhez lesz kezdő és befejező dátum; egy adott build minden egyes tesztelésekor meglesz a megadott dátum.

Például

• Tesztesetek írása
• Végrehajtási folyamat

Hibakövetés

Ez általában eszközök segítségével történik, mivel nem tudjuk manuálisan nyomon követni az egyes hibák állapotát. És arról is szólunk, hogy miként közöljük a tesztelési folyamat során azonosított hibákat, és hogyan küldjük vissza a fejlesztőcsapatnak, és a fejlesztőcsapat hogyan válaszol. Itt megemlítjük az olyan hibák prioritását is, mint a magas, közepes és alacsony.

A hibakövetés különböző szempontjai a következők:

A hiba nyomon követésének technikái
…..
……
……
……Hibakövető eszközök
Az eszköz nevéhez kommentálhatjuk, amelyet a hibák nyomon követésére fogunk használni. A leggyakrabban használt hibakövető eszközök a Jira, Bugzilla, Mantis és Trac stb.<Súlyosság
A súlyosság a következő lehet:
Blokkoló vagy showtopper
…..
….. (magyarázza meg egy példával a teszttervben)
Például , hiba lesz a modulban; nem tudunk továbbmenni más modulok tesztelésére, mert ha a hiba blokkolva van, folytathatjuk a többi modul ellenőrzését.
Kritikai
……
….. (magyarázza meg egy példával a teszttervben)
Ebben a helyzetben a hibák hatással lesznek az üzletre.
Jelentősebb
….
…. (magyarázza meg a teszttervben szereplő példával)
Kisebb
…..
….. (magyarázza meg egy példával a teszttervben)
Ezek a hibák azok, amelyek befolyásolják az alkalmazás megjelenését és érzetét.Kiemelten fontos
Magas P1
…..
Közepes-P2
…..
Alacsony-P3
…..
…..
P4

Ezért a business high, medium és low hibáinak prioritása alapján P1, P2, P3 és P4 kategóriába soroljuk.

Tesztkörnyezetek

Ezekben a környezetekben fogjuk tesztelni az alkalmazást, és itt kétféle környezetünk van, amelyek a szoftver és hardver konfigurációt.

A szoftver konfiguráció különböző részleteket jelent Operációs rendszer mint például Windows, Linux, UNIX és Mac és különféle Böngészők mint Google Chrome, Firefox, Opera, Internet Explorer , stb.

És a hardver konfiguráció a különböző méretekre vonatkozó információkat jelenti RAM, ROM és processzorok .

Például

• A Szoftver a következőket tartalmazza:

szerver

Megjegyzés: A fenti szerverek azok a kiszolgálók, amelyeket a tesztelőcsoport az alkalmazás tesztelésére használ.

Ügyfél

Megjegyzés: A fenti adatok megadják azokat a különféle operációs rendszereket és böngészőket, amelyekben a tesztelő csapat tesztelni fogja az alkalmazást.

• A Hardver a következőket tartalmazza:

szerver : Sun StarCat 1500

Ezt a szervert használhatja a tesztelő csapat az alkalmazás tesztelésére.

Ügyfél:

A következő konfigurációval rendelkezik, ami a következő:

Megjegyzés: Ez biztosítja a tesztelő csapat rendszereinek konfigurációját.

A szoftver telepítésének folyamata
……
…..
…..

A fejlesztőcsapat biztosítja a szoftver telepítésének konfigurációját. Ha a fejlesztőcsapat még nem biztosítja a folyamatot, akkor azt Feladatalapú fejlesztésként (TBD) írjuk a teszttervbe.

Belépési és kilépési feltételek

Ez egy szükséges feltétel, amelyet a tesztelési folyamat megkezdése és leállítása előtt teljesíteni kell.

Belépési kritériumok

A belépési feltételek a következő feltételeket tartalmazzák:

• A fehér doboz tesztelését be kell fejezni.
• Értse és elemezze a követelményt, és készítse el a tesztdokumentumokat, vagy amikor a tesztdokumentumok elkészültek.
• A tesztadatoknak készen kell lenniük.
• Build vagy a pályázatot el kell készíteni
• A modulokat vagy funkciókat a különböző tesztelő mérnökökhöz kell hozzárendelni.
• A szükséges erőforrásnak készen kell állnia.

Kilépési feltételek

A kilépési feltételek a következő feltételeket tartalmazzák:

• Amikor az összes teszteset végrehajtásra kerül.
• A legtöbb tesztesetnek ilyennek kell lennie átment .
• A hibák súlyosságától függ, ami azt jelenti, hogy nem lehetnek blokkolók vagy nagyobb hibák, míg néhány kisebb hiba létezik.

Mielőtt elkezdené a funkcionális tesztelést, a fentiek mindegyikét Belépési kritériumok követni kell. Miután elvégeztük a funkcionális tesztelést és előtte integrációs tesztelést végzünk, akkor a Kilépési kritériumok a funkcionális tesztelést érdemes követni, mert a kilépési kritériumok %-át mind a fejlesztési, mind a tesztmenedzserrel való találkozás dönti el, mert az ő együttműködésükkel lehet elérni a százalékot. De ha a funkcionális tesztelés kilépési kritériumait nem követik, akkor nem léphetünk tovább az integrációs teszteléssel.

Itt súlyossága alapján a hiba azt jelenti, hogy a tesztelő csapat úgy döntött volna, hogy továbblép a következő fázisokban.

Teszt automatizálás

Ennek során a következőkről döntünk:

• Melyik funkciót kell automatizálni, és melyiket nem szabad automatizálni?
• Melyik automatizálási teszteszközt melyik automatizálási keretrendszeren fogjuk használni?

A tesztesetet csak az első kiadás után automatizáljuk.

Itt felmerül a kérdés, hogy mi alapján mi akarat döntse el, mely funkciókat kell tesztelni?

A fenti képen láthatjuk, hogy a leggyakrabban használt funkciókat újra és újra tesztelni kell. Tegyük fel, hogy ellenőriznünk kell a Gmail alkalmazást, ahol a lényeges funkciók találhatók Levél, Elküldött tételek és Beérkezett üzenetek írása . Tehát ezeket a funkciókat fogjuk tesztelni, mert a kézi tesztelés több időt vesz igénybe, és egyben monoton munkává is válik.

Most, hogyan döntjük el, hogy mely funkciókat nem teszteljük?

Tegyük fel a segítséget A Gmail alkalmazás funkcióját nem teszteljük újra és újra, mert ezeket a funkciókat nem használják rendszeresen, így nem kell gyakran ellenőriznünk.

De ha egyes funkciók instabilok és sok hibát tartalmaznak , ami azt jelenti, hogy ezeket a funkciókat nem fogjuk tesztelni, mert manuális tesztelés közben újra és újra tesztelni kell.

Ha van egy funkció, amelyet gyakran kell tesztelni , de az adott szolgáltatás követelményének változására számítunk, ezért nem ellenőrizzük, mert a kézi tesztesetek megváltoztatása kényelmesebb, mint az automatizálási tesztszkriptben.

Erőfeszítés becslése

Ebben megtervezzük azt az erőfeszítést, amelyet minden csapattagnak meg kell tennie.

Teszt szállítható

Ezek azok a dokumentumok, amelyek a tesztelő csapat kimenete, amelyeket a termékkel együtt átadtunk a vevőnek. A következőket tartalmazza:

Teszt terv Teszt esetek Tesztszkriptek RTM (Requirement Traceability Matrix) Hibajelentés Teszt végrehajtási jelentés Grafikonok és metrikák Kiadási megjegyzések

Grafikonok és metrikák

Grafikon

mini eszköztár excel

Ebben a típusokról fogunk beszélni grafikonok elküldjük, és minden grafikonból mintát is adunk.

Amint látjuk, öt különböző grafikonunk van, amelyek a tesztelési folyamat különböző aspektusait mutatják be.

1. grafikon: Ebben megmutatjuk, hogy az egyes modulokban hány hibát azonosítottak és hány hibát javítottak ki.

2. grafikon: Az 1. ábra azt mutatja, hogy hány kritikus, nagyobb és kisebb hibát azonosítottak minden modulnál, és hányat javítottak ki a megfelelő moduloknál.

3. grafikon: Ezen a konkrét grafikonon a építsünk bölcs grafikont , ami azt jelenti, hogy minden buildben hány hibát azonosítottak és javítottak ki minden modulnál. A modul alapján meghatároztuk a hibákat. Hozzátesszük R hogy mutassa a hibák számát P és Q-ban, és azt is összeadjuk S a P, Q és R hibáinak megjelenítésére.

4. grafikon: A tesztvezeték megtervezi a Bug Trend elemzés grafikont, amely havonta készül, és elküldi a Vezetőségnek is. És ez olyan, mint az előrejelzés, amely a termék végén történik. És itt is megtehetjük értékelje a hibajavításokat ahogy azt megfigyelhetjük ív rendelkezik egy felfelé irányuló tendencia az alábbi képen.

5. grafikon: A Tesztkezelő megtervezte ezt a típusú grafikont. Ez a grafikon célja, hogy megértse a hibák értékelésében mutatkozó hiányosságokat és a ténylegesen előfordult hibákat, és ez a grafikon segít a hibák értékelésének javításában is.

Metrikák

A fentiekhez hasonlóan elkészítjük a hibaeloszlási grafikont, ami az 1. ábrán látható, és a fent említett adatok segítségével megtervezzük a mérőszámokat is.

Például

A fenti ábrán megőrizzük az adott projektben részt vevő összes tesztmérnök nyilvántartását, valamint azt, hogy hány hibát azonosítottak és javítottak ki. Ezeket az adatokat későbbi elemzésekhez is felhasználhatjuk. Ha új követelmény jelentkezik, a korábban talált hibák száma alapján a fenti mutatók alapján eldönthetjük, hogy kinek biztosítsuk a kihívást jelentő szolgáltatást tesztelésre. És jobb helyzetben leszünk, ha tudjuk, hogy ki tudja nagyon jól kezelni a problémás funkciókat, és megtalálja a maximális számú hibát.

Kiadási megjegyzés: Ez egy dokumentum, amelyet a termék kiadásakor készítenek el, és amelyet a tesztmenedzser ír alá.

Az alábbi képen láthatjuk, hogy a végterméket fejlesztik és telepítik az ügyfélnél, és a legújabb kiadás neve Beta .

A Kiadási megjegyzés a következőkből áll:

• Használati utasítás.
• Függőben lévő és nyitott hibák listája.
• A hozzáadott, módosított és törölt szolgáltatások listája.
• Azon platformok listája (Operációs rendszer, Hardver, Böngészők), amelyen a terméket tesztelték.
• Platform, amelyen a terméket nem tesztelték.
• A jelenlegi kiadásban javított hibák listája, valamint az előző kiadásban javított hibák listája.
• Telepítési folyamat
• A szoftver verziói

Például

Feltételezem, hogy Beta az alkalmazás második kiadása az első kiadás után Alpha kiszabadul. Az első kiadásban azonosított hibák egy része, amelyet a későbbi kiadásban javítottak. És itt mutatjuk be az újonnan hozzáadott, módosított és törölt funkciók listáját az alfa kiadástól a béta kiadásig.

Sablon

Ez a rész tartalmazza a termékben használt dokumentumok összes sablonját, és az összes tesztelő mérnök csak ezeket a sablonokat fogja használni a projektben a termék konzisztenciájának megőrzése érdekében. Itt különböző típusú sablonokat találunk, amelyeket a teljes tesztelési folyamat során használunk, például:

• Teszteset sablon
• Teszteset áttekintési sablon
• RTM sablon
• Hibajelentés sablon
• Teszt végrehajtási jelentés

Lássunk egy mintát a tesztterv dokumentumból

1 oldal

3. oldal-18. oldal

20. oldal

Az 1. oldalon elsősorban csak a Verziók, szerző, megjegyzések és felülvizsgálta mezőkben, és miután a vezető jóváhagyta, a részleteket megemlítjük a Jóváhagyása és a jóváhagyás dátuma mezőket.

A teszttervet többnyire a tesztmenedzser hagyja jóvá, és a tesztmérnökök csak átnézik. És amikor megérkeznek az új funkciók, módosítjuk a teszttervet és elvégezzük a szükséges módosításokat Változat mezőben, majd újra elküldjük további felülvizsgálatra, frissítésre és a vezető jóváhagyására. A vizsgálati tervet minden alkalommal frissíteni kell, ha bármilyen változás történik. A 20. oldalon a Hivatkozások adja meg az összes dokumentum részleteit, amelyeket a tesztterv dokumentum elkészítéséhez fogunk használni.

Jegyzet:

Ki írja a teszttervet?

• Tesztvezeték → 60%
• Tesztkezelő → 20%
• Tesztmérnök → 20%

Ezért, mint fentről láthatjuk, a termék 60%-ában a teszttervet a Tesztvezető írja.

Ki vizsgálja felül a teszttervet?

• Tesztvezeték
• Tesztkezelő
• Teszt mérnök
• Vevő
• Fejlesztői csapat

A tesztelő mérnök felülvizsgálja a teszttervet a modul szempontjából, a tesztmenedzser pedig a teszttervet az ügyfél véleménye alapján.

Ki hagyja jóvá a teszttervet?

• Vevő
• Tesztkezelő

Ki írja a tesztesetet?

• Tesztvezeték
• Teszt mérnök

Ki vizsgálja felül a tesztesetet?

tkinter gomb

• Teszt mérnök
• Tesztvezeték
• Vevő
• Fejlesztői csapat

Ki hagyja jóvá a teszteseteket?

• Tesztkezelő
• Tesztvezeték
• Vevő

Vizsgálati terv irányelvei

• Összecsukja teszttervét.
• Kerülje az átfedéseket és a redundanciát.
• Ha úgy gondolja, hogy nincs szüksége egy fent említett szakaszra, törölje azt, és folytassa tovább.
• Pontosíts. Ha például egy szoftverrendszert ad meg a tesztkörnyezet részeként, akkor csak a név helyett a szoftver verzióját említse meg.
• Kerülje a hosszú bekezdéseket.
• Lehetőség szerint használjon listákat és táblázatokat.
• Szükség esetén frissítse a tervet.
• Ne használjon elavult és nem használt dokumentumot.

A tesztterv fontossága

• A tesztterv irányt ad gondolkodásunknak. Ez olyan, mint egy szabálykönyv, amit be kell tartani.
• A tesztterv segít meghatározni a teszt alatti szoftveralkalmazás minőségének ellenőrzéséhez szükséges erőfeszítéseket.
• A tesztterv segít azoknak az embereknek megérteni a teszt részleteit, amelyek külsőre vonatkoznak, például fejlesztők, üzletvezetők, ügyfelek stb.
• Az olyan fontos szempontokat, mint a tesztelési ütemterv, a tesztstratégia, a teszt hatóköre stb. dokumentálják a teszttervben, hogy a vezetőség áttekinthesse és más hasonló projektekhez felhasználhassa.