A legtöbb teszteset már azelőtt kudarcot vall, hogy egyetlen hibát is felfedezne. Ezeket a teszteseteket homályos ellenőrzőlistaként írják meg, hiányoznak belőlük az előfeltételek, több műveletet egyetlen lépésbe csomagolnak, vagy olyan pontatlanul írják le a várt eredményeket, hogy két tesztelő, aki ugyanazt a tesztesetet olvassa, nem értene egyet abban, mit jelent a „siker”. Az eredmény: a hibák átcsúsznak, a tesztfutások nem reprodukálhatók, és a minőségbiztosítás biztonsági háló helyett szűk keresztmetszetté válik.
A jó teszteset írása nem annyira a tesztelési készségekről szól, hanem inkább az ellenőrzés tervezéséről. A pénzügyi szolgáltatásokban ezt „maker-checker” folyamatnak nevezik. A nukleáris parancsnokságon „kétfős szabálynak” hívják. Az elv ugyanaz: a kritikus feladatok soha nem támaszkodhatnak egyetlen, ellenőrizetlen műveletre. A jól megírt teszteset ugyanezt a szigorúságot építi be a szoftverbe. Elkülöníti az elvárásokat a megfigyelésektől, így a kettő közötti eltérés lehetetlenné válik, hogy figyelmen kívül hagyjuk.
Megmutatjuk, hogyan kell teszteseteket írni, miért fontosak, és hogyan lehet idővel javítani a tesztesetek minőségét.
TL;DR
A teszteset meghatározza azokat a pontos lépéseket, bemeneti adatokat és várható eredményeket, amelyek szükségesek egy funkció helyes működésének ellenőrzéséhez. Minden tesztesetnek egyedi azonosítóval, előfeltételekkel és várható eredményekkel kell rendelkeznie, hogy az eredmény ellenőrizhető legyen. Ez az útmutató bemutatja a hétlépéses írási folyamatot, három kidolgozott példát, valamint azt, hogyan lehet a tesztcsomagot megbízhatónak tartani a termék változásai során.
Mik azok a tesztesetek?
A teszteset egy strukturált dokumentum, amely meghatározza azokat a pontos lépéseket, bemeneti adatokat, előfeltételeket és várt eredményeket, amelyek szükségesek ahhoz, hogy ellenőrizni lehessen, egy adott szoftver megfelelően működik-e. Ez nem egy tesztterv (amely a tesztelési stratégiát vázolja fel) és nem is egy teszt szkript (egy automatizált kód, amely programozási úton hajtja végre a lépéseket). A teszteset az a specifikáció, amelyre mindkettő épül.
Példa: Egy webalkalmazás bejelentkezési funkcióját teszteled. Egy ilyen funkcióra vonatkozó teszteset a következő elemeket határozná meg:
- Olyan műveletek, amelyek leírják a felhasználó által végrehajtott lépéseket és a várt rendszerreakciókat
- Azok a feltételek, amelyek meghatározzák azokat a szabályokat, amelyeknek teljesülniük kell ahhoz, hogy a rendszer folytathassa az egyes lépéseket
- Adjon meg példaértékeket az adatokhoz, hogy különböző kimeneteleket tesztelhessen, és ellenőrizhesse mind a sikeres, mind a sikertelen forgatókönyveket.
A manuális és az automatizált tesztesetek összehasonlítása
Az AI ma már a legtöbb tesztelési munkafolyamat része. A PractiTest 2026-os „State of Testing Report” című jelentése szerint a tesztelési szakemberek 76,8%-a használja az AI-t a minőségbiztosításban, ahol a tesztesetek létrehozása (69,6%) és a szkriptek karbantartása (59,6%) a két leggyakoribb felhasználási terület. Ez a változás leginkább az automatizált teszteseteknél látható, ezért érdemes tudni, miben különböznek a manuálisaktól.
| Paraméter | Kézi tesztesetek | Automatizált tesztesetek |
|---|---|---|
| Végrehajtás | Egy emberi tesztelő végzi el, aki egy dokumentált lépéssorozatot követ | Szoftvereszközök, szkriptek vagy mesterséges intelligencia-ügynökök végrehajtásával |
| Sebesség | Lassú és időigényes, mivel az adatokat az embereknek manuálisan kell bevitelniük, és az eredményeket is nekik kell ellenőrizniük | Több száz tesztesetet képes egyszerre végrehajtani |
| Ismételhetőség | Hajlamos az emberi hibákra és a lépések következetlen értelmezésére | A teszt szkriptek megfelelő karbantartása esetén a folyamat rendkívül jól megismételhető és konzisztens |
| CI/CD-integráció | Az emberi szűk keresztmetszetek miatt nehéz integrálni a gyorsan változó szállítási folyamatokba | Közvetlenül integrálható a CI/CD-folyamatokba, így minden buildnél elvégezhetőek a tesztek |
| Karbantartás | A követelmények változása esetén a dokumentumokat manuálisan kell frissíteni | A felhasználói felület vagy a logika változása esetén a szkriptek frissítéséhez technikai karbantartásra van szükség |
| Ideális | Felfedező jellegű tesztek | Ismétlődő és regressziós tesztek |
Miért fontosak a jól megírt tesztesetek?
Még mielőtt a felhasználók hibajelentést nyújtanának be, Ön már észleli a regressziókat. Minden kódmódosítás magában hordozza annak a kockázatát, hogy megszakít valamit, ami eddig működött. Egy jól megírt teszteset állandó ellenőrzőponttá válik, amely minden telepítés után lefuttatásra kerül. Ha egy fejlesztő egy év múlva átírja a bejelentkezési kódot, és véletlenül megszakítja a munkamenetkezelést, akkor ez a teszteset jelzi a problémát a staging környezetben.
Tegye a „megfelelt/nem felelt” eredményt ténykévé, ne véleménykévé. Az olyan homályos várt eredmények, mint például „a rendszer megfelelően reagál”, arra kényszerítik minden tesztelőt, hogy saját maga értelmezze, mit jelent a „megfelelő”. Két tesztelő futtatja ugyanazt az esetet, az egyik „megfelelt”-nek jelöli, a másik hibát jelenti, és most a csapat a szoftver helyett a nézeteltérést hibakereséssel próbálja megoldani. Ha a várt eredmény így szól: „a rendszer a következő hibaüzenetet jeleníti meg: »Érvénytelen jelszó«, és a felhasználót a bejelentkezési oldalon tartja“, akkor nincs helye az értelmezésnek. Az eredmény vagy egyezik, vagy nem. Ez a kétfős szabály a gyakorlatban: a teszteset a készítő, a tesztelő pedig az ellenőr, és mindkettőjüknek ugyanazt a nyelvet kell beszélnie.
A hallgatólagos tudást újrafelhasználható erőforrássá alakítja. A legtöbb csapatban a vezető minőségbiztosítási mérnök fejében van egy láthatatlan térkép minden szélsőséges esetről, minden kiskapuról, minden „ó, ne felejtsd el ellenőrizni az X-et is” típusú megjegyzésről. Amikor az illető szabadságra megy vagy csapatot vált, a térkép vele együtt távozik. A dokumentált tesztesetek, amelyek egyértelmű előfeltételeket és határértékeket tartalmaznak, strukturáltan megőrzik ezt a tudást. Egy új, a csapatba csatlakozó tesztelő már az első napon előveheti a TC_LOGIN_005 tesztesetet, és tesztelheti az „öt kísérlet után fiókzárás” folyamatot anélkül, hogy bárkitől is megkérdezné, mi a küszöbérték, vagy hogyan áll vissza az időzítő.
A hibákat pontos lépésekre szűkíted le, nem általános területekre. Ha egy teszteset a „navigálj az oldalra, írd be a hitelesítő adatokat, majd kattints a Küldés gombra” műveleteket egyetlen lépésbe csomagolja, és a teszt sikertelen, akkor csak annyit tudsz, hogy „valami elromlott a bejelentkezési folyamatban”. ” Ha viszont minden művelet külön lépés, saját várt eredménnyel, akkor a hiba a 4. lépésre vezethető vissza: „Kattints a „Visszaállítási link küldése” gombra → várt sikerüzenet helyett 500-as hibaüzenet jelent meg.” Ez a pontosság drámaian lerövidíti a hibakeresési időt, mert a fejlesztő pontosan tudja, melyik interakció váltotta ki a hibát, nem csak azt, hogy melyik funkcióterületen kell keresnie.
Láthatja, mi került lefedésre, és mi maradt ki. Strukturált tesztesetek nélkül a tesztelési lefedettség csupán találgatás. Ezekkel minden esetet visszavezethet egy követelményhez, és azonnal észreveheti a hiányosságokat. Ha a jelszó-visszaállítási funkciójának hat forgatókönyve van (sikeres visszaállítás, lejárt link, újrahasznosított link, nem regisztrált e-mail, érvénytelen formátum, többszörös kérés), és csak háromra van tesztesete, a hiányosság látható és számszerűsíthető. Ez a láthatóság az, ami a tesztelést a „kipróbáltuk” szintről a „pontosan ezt teszteltük, ezt nem, és ezt a kockázatot vállaljuk” szintre emeli.
A jó teszteset összetevői
Egy hasznos teszteset nem csupán leírja, mit kell tesztelni. Meghatározza a kontextust, a végrehajtási lépéseket és a rendszer várható viselkedését is, hogy egy másik tesztelő, fejlesztő vagy termékmenedzser is el tudja végezni a tesztet, és ellenőrizhesse az eredményt.
A teszteset összetevői a következők:
- Egyedi azonosító
- Cél vagy leírás
- Előfeltételek
- A végrehajtás lépései
- Várható eredmények
- Tényleges eredmények összehasonlítás céljából
A fentebb bemutatott weboldal-bejelentkezési funkció példájához a tesztesetnek a következőket kell tartalmaznia:
Teszteset-azonosító: Minden tesztesetnek egyedi azonosítóra van szüksége. Egy funkció tesztelésekor a minőségbiztosítási csapatok gyakran több tesztesetet is létrehoznak, amelyek hasonló feltételeket ellenőriznek. A teszteset-azonosító segít ezek könnyű nyomon követésében, rendszerezésében és hivatkozásában a hibakeresés vagy a jelentéskészítés során.
Példa: TC_LOGIN_001
Leírás: Ez elmagyarázza, hogy a teszteset mely funkciót ellenőrzi. Rövid összefoglalást nyújt, hogy a tesztesetet elolvasó bárki azonnal megértse annak célját.
Példa: Ellenőrizze, hogy egy regisztrált felhasználó érvényes hitelesítő adatokkal sikeresen be tud-e jelentkezni az alkalmazásba.
Előfeltételek: Az előfeltételek leírják a teszteset végrehajtása előtt szükséges rendszerállapotot. Ezek hiányában előfordulhat, hogy a tesztelők ugyanazt a tesztet különböző feltételek mellett futtatják, és inkonzisztens eredményeket kapnak.
Példák:
- A felhasználói fióknak már léteznie kell a rendszerben
- A felhasználói fióknak aktívnak kell lennie, és nem lehet zárolva
- A bejelentkezési oldalnak elérhetőnek kell lennie
Lépések: Ezek azok a műveletek, amelyeket a felhasználó vagy a tesztelő hajt végre a teszteset végrehajtása során. Minden lépésnek egyértelműnek és egymást követőnek kell lennie, hogy a csapat bármely tagja képes legyen a tesztet reprodukálni.
- A felhasználó a bejelentkezési oldalra navigál
- A felhasználó megad egy regisztrált e-mail-címet
- A felhasználó beírja a helyes jelszót
- A felhasználó rákattint a Bejelentkezés gombra
Várható eredmények: Ez határozza meg, hogy a rendszernek mit kell tennie, ha a funkció megfelelően működik.
- Ha a hitelesítő adatok érvényesek, a rendszer hitelesíti a felhasználót
- A felhasználó átirányításra kerül a műszerfalra
- A felhasználói munkamenet létrehozása sikeresen megtörtént
Ha a hitelesítő adatok érvénytelenek, a rendszernek a megfelelő hibaüzenetet kell megjelenítenie.
Tényleges eredmények: Ezek a tesztes megfigyeléseit rögzítik a teszteset futtatása után. Ha a megfigyelt viselkedés eltér a várt eredménytől, a problémát hibaként rögzítik.
Példa megfigyelésre:
- Érvényes hitelesítő adatokat adott meg, de „Érvénytelen jelszó” hibaüzenetet kapott
Most pedig vegyük hasznára a tesztesetek írásában szerzett készségeidet!
Tudta? A csapatok mindössze 2,1%-a tartja optimalizáltnak az AI-tesztelési gyakorlatát, míg több mint 85% még mindig a kezdeti vagy kísérleti szakaszban van. A leggyakoribb felhasználási terület a tesztesetek generálása (69,6%), nem pedig olyan stratégiai feladatok, mint a kockázatok azonosítása (19,9%).
Hogyan írjunk teszteseteket (lépésről lépésre)
A teszteset írása hét lépésből áll: a követelmény elemzése, a forgatókönyvek felsorolása, a szerkezet megtervezése, a lépések leírása a várt eredményekkel, a kontextus hozzáadása, a felülvizsgálat, majd a végrehajtás és a naplózás.
1. lépés: Elemezze a követelményeket
Mielőtt megírná a tesztesetet, tisztázza magában, hogy mit kell tennie a funkciónak. Ehhez át kell tekintenie a rendelkezésre álló dokumentumokat – a PRD-ket (termékkövetelmény-leírásokat), a felhasználói történeteket, a funkcióleírásokat és a tervezési dokumentumokat –, és azonosítania kell minden olyan funkciót, amelyet ellenőrizni kell.
Példa: Olyan funkciót fejleszt, amely lehetővé teszi a felhasználók számára, hogy e-mailen keresztül állítsák vissza a jelszavukat. Ahhoz, hogy ehhez kapcsolódó tesztesetet készítsen, a következőket kell megértenie:
- Milyen problémát old meg ez a funkció, azaz vissza tudja-e szerezni a felhasználó a fiókjához való hozzáférést, ha elfelejti a jelszavát?
- Milyen műveleteket hajthat végre a felhasználó, azaz kérhet-e visszaállítási linket, megkaphatja-e azt e-mailben, és beállíthat-e új jelszót?
- Mi történjen, ha ezeket a műveleteket végrehajtják, azaz a rendszer elküldi-e a visszaállítási linket, és lehetővé teszi-e a felhasználó számára, hogy sikeresen frissítse a jelszavát?
- Vannak-e bármilyen korlátozások, azaz a link egy meghatározott idő elteltével lejár, vagy egy használat után érvényét veszti?
- Vannak-e érvényesítési szabályok, azaz az új jelszónak meg kell-e felelnie bizonyos formátum- vagy hosszúsági követelményeknek?
- Van olyan funkció, amely homályos vagy nincs pontosan meghatározva? Ha igen, kérjen pontosítást az érintett érdekelt féltől.
Ez az egyértelműség alapot nyújt ahhoz, hogy egy világos célt határozzon meg a tesztesetéhez.
Cél: Ellenőrizze, hogy egy regisztrált felhasználó sikeresen vissza tudja-e állítani a jelszavát e-mailen keresztül.
2. lépés: A különböző tesztforgatókönyvek azonosítása
Ezután sorolja fel azokat a tesztforgatókönyveket, amelyeket ellenőriznie kell. A tesztforgatókönyv egy magas szintű helyzet, amely általában több tesztesetre ágazik szét, amelyek különböző bemeneti adatokat és kimeneti eredményeket fednek le.
A jelszó-visszaállítási funkció esetében a forgatókönyvei például a következőképpen nézhetnek ki:
- Sikeres visszaállítás: Ellenőrizze, hogy egy regisztrált felhasználó kérhet-e visszaállítási linket, és beállíthat-e új jelszót
- Nem regisztrált e-mail: Tesztelje, mi történik, ha olyan e-mail címet adnak meg, amely nem létezik a rendszerben
- Lejárt link: Ellenőrizze, hogy a rendszer blokkolja-e a hozzáférést, ha a lejárat után rákattintanak a visszaállítási linkre.
- Újrahasznosított link: Ellenőrizze, hogy egy már használt visszaállítási linket nem lehet újra felhasználni
- Érvénytelen új jelszó: Ellenőrizze, hogy a formátumkövetelményeknek nem megfelelő jelszavakat elutasítja-e a rendszer
- Többszörös visszaállítási kérések: Tesztelje, melyik link marad érvényes, ha a felhasználó egymás után többet is kér
Az itt bemutatott minden egyes forgatókönyv egy vagy több tesztesetet eredményez, amelyek konkrét bemeneti adatokat és feltételeket fednek le. A funkció ilyen módon történő lebontása biztosítja, hogy a tesztelés kiterjedjen mind a várt viselkedésre, mind pedig azokra a szélsőséges esetekre, amelyekkel a valódi felhasználók elkerülhetetlenül szembesülni fognak.
További információk: Hogyan készítsünk és vezessünk be minőségbiztosítási ellenőrzőlistát
3. lépés: Tervezd meg a tesztet, és állítsd be a tesztesetek felépítését
Az ismétlődő regressziós teszteléshez olyan struktúrára van szükség, amely lehetővé teszi a tesztesetek és azok eredményeinek következetes dokumentálását. Egy jól meghatározott teszteset-sablon biztosítja ezt a következetességet, és lehetővé teszi az újrafelhasználást anélkül, hogy minden alkalommal a nulláról kellene kezdeni.
Tervezze meg a tesztelés végrehajtását az alábbi elemek tisztázásával:
Ki fogja elvégezni a tesztet?
Milyen szerepkörre vagy képesítésre van szüksége a tesztet végző személynek? A teszt összetettségétől és a szükséges emberi beavatkozástól függően ossza ki a szerepköröket:
- Minőségbiztosítási tesztelő: Funkcionális és regressziós tesztek, például a bejelentkezési folyamatok, az űrlap-érvényesítések vagy a fizetési folyamatok ellenőrzése
- Biztonsági csapat: A hitelesítéssel, a hozzáférés-vezérléssel vagy az adatok nyilvánosságra kerülésével kapcsolatos sebezhetőségeket vizsgáló tesztek
- Fejlesztő: Egyedi funkciókhoz, például a jelszó-hasholáshoz vagy a token-generáláshoz készült egységtesztek
Hogyan fogják lefolytatni a tesztet?
- Mely eszközökön és operációs rendszereken fog futni a teszt?
- Mely eszközöket vagy tesztelési keretrendszereket fogja használni?
- A tesztet manuálisan vagy egy AI-ügynök segítségével hajtják végre?
- Hogyan kerülnek rögzítésre az eredmények – egy tesztkezelő eszközben, táblázatban vagy hibajelentő rendszerben?
Melyek az előfeltételek?
Sorolja fel az 1. lépés előtt teljesülnie kellő összes feltételt, és gondoskodjon arról, hogy mindegyiket a tesztelő ellenőrizhesse:
Példa:
- Létezik felhasználói fiók a „test@example.com” e-mail-címmel
- A felhasználó kijelentkezett a rendszerből
- Az e-mail szolgáltatás aktív és képes üzeneteket kézbesíteni
- A tesztkörnyezet elérhető és működik
Milyen tesztadatokat fogunk használni?
Határozza meg a teszt futtatásához szükséges pontos bemeneti értékeket – érvényes adatokat, érvénytelen adatokat és határértékeket.
Példa:
- Érvényes: regisztrált e-mail cím „test@example. com”, a formátumkövetelményeknek megfelelő jelszó
- Érvénytelen: nem regisztrált e-mail-cím, a jelszó nem éri el a minimális karakterkorlátot
- Határérték: a jelszó pontosan a minimális és maximális karakterkorláton belül van
4. lépés: Írja meg a tesztlépéseket és a várt eredményeket
Bontsa le a végrehajtási folyamatot egymást követő lépésekre. Használjon következetes terminológiát, és ügyeljen arra, hogy minden lépéshez csak egy művelet tartozzon. A lépések meghatározásakor vázolja fel a várt eredményt is, valamint azt, hogy mi minősül sikernek vagy kudarcnak.
A jelszó-visszaállítási folyamatot folytatva a tesztelési lépések a következőképpen néznének ki:
| Lépések | Várható eredmény |
| Lépjen a bejelentkezési oldalra | A bejelentkezési oldal betöltődik, és megjelenik rajta egy kattintható „Elfelejtette a jelszavát?” link |
| Kattintson a „Jelszó elfelejtése” gombra | A felhasználót átirányítják a jelszó-visszaállítási kérelem oldalára |
| Írja be e-mail címét az E-mail mezőbe | Az e-mail cím érvényes, nincs érvényesítési hiba |
| Kattintson a „Visszaállítási link küldése” gombra | A sikerüzenet a következő: „A visszaállítási link elküldve a test@example.com címre” |
| Nyissa meg az e-mailben található visszaállítási linket | A felhasználót átirányítják az új jelszó létrehozásának oldalára |
| Írjon be egy érvényes új jelszót | A jelszómező hiba nélkül fogadja a bevitt adatokat |
| Kattintson a „Jelszó visszaállítása” gombra | Megjelenik a sikerüzenet, és a felhasználó átirányításra kerül a bejelentkezési oldalra |
Most határozza meg az alternatív forgatókönyvek (amelyeket korábban már tárgyaltunk) lépéseit és várható eredményeit. Írja le, mi történik, ha a felhasználó érvénytelen e-mail-címet ad meg, vagy a jelszó nem felel meg az előre meghatározott kritériumoknak.
Bónusz: Így automatizálhatja a dokumentációt mesterséges intelligencia segítségével az összes teszteset esetében.
5. lépés: Csatolja a releváns mellékleteket
Csatoljon releváns dokumentumokat vagy mellékleteket, amelyek segítenek a tesztelőknek a teszteset teljes kontextusban és félreérthetetlenül végrehajtani. Ezek között szerepelhetnek:
- Magyarázatokkal ellátott képernyőképek a felhasználói felületről a legfontosabb lépéseknél
- Képernyőfelvételek, amelyek bemutatják, hogyan hajthatja végre a tesztet különböző forgatókönyvekben, és milyen eredményekre számíthat
- Rendszer naplófájlok vagy konfigurációs fájlok, amelyek segítenek a háttérrendszer problémáinak diagnosztizálásában, ha egy teszt sikertelen
- Követelménydokumentumok, amelyek összekapcsolják a tesztesetet az általa érvényesített felhasználói történettel vagy átvételi kritériumokkal
- Tesztadatkészletek, amelyek érvényes és érvénytelen bemeneti adatokat, illetve generált adatokat tartalmaznak, például hitelkártyaszámokat, véletlenszerű címeket vagy felhasználói hitelesítő adatokat
- Készítsen dokumentációt, amely tartalmazza a konkrét szoftververziót, a szükséges hardvert, az operációs rendszert és az esetleges biztonsági engedélyeket
- API-tesztelés esetén az OpenAPI specifikációk vagy az végpontokra vonatkozó dokumentáció, amely részletesen leírja a kérésmódszereket, a paramétereket és a várt állapotkódokat
6. lépés: A tesztesetek felülvizsgálata
A megírt tesztesetet a végrehajtás előtt ossza meg egy kollégájával vagy egy tapasztaltabb minőségbiztosítási vezetővel. Az áttekintés során ellenőrizze, hogy:
- A teszteset átfogó, és lefed minden, a követelményekből levezethető lehetséges forgatókönyvet.
- A lépések egyértelműek, és egymást követő sorrendben ábrázolják a tényleges végrehajtási folyamatot
- Minden várt eredmény egy megfigyelhető kimenetet (üzenetet, átirányítást, állapotkódot) nevez meg, nem pedig egy olyan tulajdonságot, mint például a „helyesen működik”.
- A tesztadatok és az előfeltételek teljesek és pontosak
- Az írás során felállított bármely feltételezést kifejezetten dokumentáljuk
7. lépés: Végrehajtás és az eredmények naplózása
Végezze el a tesztet, és jegyezze fel a tényleges eredményt az egyes várt eredmények mellé. Minden lépésnél jelölje meg a tesztet „sikeres” vagy „sikertelen” minősítéssel. Minden sikertelen lépés esetén azonnal jelentsen hibát, és kapcsolja azt a tesztesethez. Továbbá, ha bármilyen váratlan viselkedés fordul elő, amely nem egyértelműen sikeres vagy sikertelen, jegyezze fel azt a megjegyzések mezőbe további vizsgálat céljából.
További információk: Hogyan használható a mesterséges intelligencia a minőségbiztosításban?
Példák tesztesetek írására
Ez a három példa bemutatja, hogyan alkalmazkodik ugyanaz a teszteset-struktúra a különböző típusú szoftverteszteléshez. Mindegyik a jelen útmutató korábbi részében bemutatott összetevőket és lépésformátumot használja, de a komplexitás, a tesztadatok és a hibahelyzetek attól függően változnak, hogy mit ellenőriz.
1. példa: E-kereskedelmi fizetési folyamat (felhasználói felület, több lépésből álló munkafolyamat)
Egy online kiskereskedő minőségbiztosítási csapata az ünnepi akciót megelőzően teszteli a fizetési folyamatot. A folyamat több oldalt ölel fel: kosár → szállítás → fizetés → visszaigazolás. A legfőbb kihívást itt az állapotfüggőség jelenti: minden lépés attól függ, hogy az előző lépés megfelelően lezárult-e, és a tesztadatoknak (a kosár tartalma, a szállítási cím, a fizetési mód) minden lépés során meg kell maradniuk.
Tesztelő: Rahul D.
A teszt dátuma: 2026.03.09.
Teszteset-azonosító: TC_CHECKOUT_003
Leírás: Ellenőrizze, hogy egy bejelentkezett felhasználó el tud-e végezni egy vásárlást a mentett hitelkártya és a standard szállítás használatával.
Előfeltételek:
- Létezik felhasználói fiók, amelyhez legalább egy mentett hitelkártya és egy mentett szállítási cím tartozik
- Legalább egy termék van raktáron, és a kosárba került
- A tesztkörnyezet Chrome 128-on és macOS-en fut.
| Lépés | Várható eredmény | Tényleges eredmény | Megfelelt/Nem felelt meg |
| Lépjen a kosár oldalára | A kosárban a megfelelő termék, mennyiség és részösszeg jelenik meg | Ahogy vártuk | Átment |
| Kattintson a „Tovább a fizetéshez” gombra | A szállítási oldal betöltésekor a mentett cím előre kiválasztva jelenik meg | Ahogy vártuk | Átment |
| Válassza a „Normál szállítás” lehetőséget, majd kattintson a „Tovább” gombra | A fizetési oldal betöltése, amelyen a rendelés végösszege a szállítási költségekkel együtt jelenik meg | Ahogy vártuk | Átment |
| Ellenőrizze a mentett hitelkártya adatait, majd kattintson a „Megrendelés” gombra. | A megrendelés-visszaigazoló oldal megjelenik a megrendelésszámmal, a termékösszefoglalóval és a becsült szállítási dátummal | A fizetési oldal hibaüzenettel töltődik be újra: „A fizetés feldolgozása nem lehetséges” | Hiba |
Eredményösszefoglaló: A fizetési folyamat a kosárból a szállításig minden rendben működik, de a mentett hitelkártyákkal történő fizetés feldolgozása sikertelen. Hiba rögzítve: a tokenizált kártya lekérdezése időtúllépésbe kerül, ha a fizetési átjáró 3 másodpercnél tovább tart a válaszadással.
2. példa: REST API végpont (nincs felhasználói felület, bemeneti/kimeneti érvényesítés)
Egy backend-fejlesztő teszteli a „Create User” API-végpontot, mielőtt azt a frontend-csapat felhasználná. Nincs olyan felület, amelyen végig kellene kattintani: a teszteset közvetlenül ellenőrzi a kérések hasznos adatait, a válasz kódjait és az adatok állandóságát. A legfőbb kihívás a rendszerek közötti szerződés tesztelése, nem pedig a felhasználói élményé.
Tesztelő: Sarah S.
Teszt dátuma: 2026.09.05.
Teszteset-azonosító: TC_API_USER_001
Leírás: Ellenőrizze, hogy a /api/v1/users címre küldött POST-kérés létrehoz-e egy új felhasználót, és visszaadja-e a helyes választ.
Előfeltételek:
- Az API-tesztkörnyezet működik és elérhető
- Létrehozásra került és érvényes az adminisztrátori jogosultságokkal rendelkező hitelesítési token
- Az adatbázisban nem létezik olyan felhasználó, akinek az e-mail címe „newuser@testdomain.com” lenne.
| Lépés | Várható eredmény | Tényleges eredmény | Megfelelt/Nem felelt meg |
| Küldjön POST kéréset a /api/v1/users címre érvényes hasznos adattal: { "name": "Test User", "email": "newuser@testdomain.com", "role": "viewer" } | A válasz 201-es kódot ad vissza, amelynek JSON-törzse tartalmazza a felhasználói azonosítót, nevet, e-mail címet és szerepkört. | 201-es kóddal, helyes testtel | Átment |
| Küldje el újra ugyanazt a POST-kérést azonos e-mail-címmel | A válasz 409-es hibakódot ad vissza, a következő üzenettel: „Ezzel az e-mail-címmel már létezik felhasználó” | 200 OK válasz; duplikált felhasználó lett létrehozva | Hiba |
| Küldj el egy POST-kérést hiányzó „email” mezővel | A válasz 400-as „Bad Request” hibakódot ad vissza, az alábbi érvényesítési hibával: „Az e-mail megadása kötelező” | 400 – a várt eredmény | Átment |
| Futtassa a GET /api/v1/users/{id} lekérdezést az 1. lépésben kapott azonosítóval | A válasz 200 OK kódot ad vissza, és a felhasználói adatok megegyeznek az eredeti hasznos adattal | Ahogy vártuk | Átment |
Eredményösszefoglaló: Az végpont helyesen hozza létre a felhasználókat és ellenőrzi a kötelező mezőket, de nem biztosítja az e-mail címek egyediségét adatbázis-szinten. Hiba nélkül jöttek létre duplikált rekordok. A hiba súlyossági szintje: Magas.
3. példa: Szerepköralapú hozzáférés-vezérlés (biztonság, jogosultsági korlátok)
Egy biztonsági csapat egy megfelelőségi audit előtt teszteli, hogy az alkalmazás helyesen korlátozza-e a műveleteket a felhasználói szerepkörök alapján. A legfőbb kihívás az, hogy nem azt teszteli, hogy egy funkció működik-e, hanem azt, hogy a funkciót megfelelően elutasítja-e a rendszer. A legtöbb lépésnél a várt eredmény a blokkolás, nem pedig a siker.
Tesztelő: Marcus L.
Teszt dátuma: 2026.09.08.
Teszteset-azonosító: TC_RBAC_002
Leírás: Ellenőrizze, hogy a „Megtekintő” szerepkörrel rendelkező felhasználó nem hozhat létre, nem szerkeszthet és nem törölhet projekteket.
Előfeltételek:
- Két fiók létezik: az egyik „Admin” szerepkörrel, a másik „Viewer” szerepkörrel rendelkezik.
- A munkaterületen legalább egy projekt létezik, amelyet az adminisztrátor hozott létre.
- A néző be van jelentkezve a Firefox 130-as verziójában, Windows 11 rendszeren
| Lépés | Várható eredmény | Tényleges eredmény | Megfelelt/Nem megfelelt |
| Lépjen a Projektek oldalra | A néző a projektlistát írásvédett módban látja; a „Projekt létrehozása” gomb el van rejtve vagy letiltva | A gomb látható, de szürkén jelenik meg | Átment |
| Próbálja meg rákattintani a „Projekt létrehozása” gombra | A rendszer megakadályozza a műveletet; nem töltődik be az új projekt űrlapja | Nem töltődött be űrlap; a tooltip a következő üzenetet jeleníti meg: „Nincs hozzáférési jogosultsága” | Átment |
| Nyisson meg egy meglévő projektet, és próbálja meg szerkeszteni a címét | A Cím mező nem szerkeszthető, vagy a rendszer megakadályozza a mentést | A Cím mező szerkeszthető volt; a módosítások sikeresen mentésre kerültek | Hiba |
| Próbálja meg törölni a projektet a három pontból álló menü segítségével | A „Törlés” opció el van rejtve, vagy a művelet engedélyezési hiba miatt blokkolva van | A Törlés opció nem látható a menüben | Átment |
Eredményösszefoglaló: A létrehozási és törlési jogosultságok a „Megtekintők” számára megfelelően korlátozottak, de a szerkesztési jogosultságok nem érvényesülnek mezőszinten. A „Megtekintő” olvasási jogosultsággal rendelkezik, mégis módosíthatja a projektcímeket. A hiba súlyossági besorolása: Kritikus (megfelelés akadályozó).
Melyek a legjobb eszközök a tesztesetek kezeléséhez?
A tesztesetek kezelhetők egy speciális minőségbiztosítási eszközben (TestRail, Zephyr), egy általános projektmenedzsment eszközben (ClickUp, Jira) vagy egy táblázatkezelő programban; a megfelelő választás attól függ, hogy beépített végrehajtásra van-e szükséged, vagy csak nyomon követésre.
ClickUp
A ClickUp for Software Teams egy projektmenedzsment-platform, ahol a tesztesetek feladatokként jelennek meg a hozzájuk kapcsolódó sprintek, hibajelentések és pull requestek mellett. Noha nem egy dedikált tesztmenedzsment-eszköz, rugalmas feladatstruktúrája lehetővé teszi a csapatok számára, hogy egyedi állapotok, mezők és feladat típusok segítségével építsenek ki teszteset-munkafolyamatokat anélkül, hogy külön eszközre lenne szükségük.
A ClickUp legfontosabb funkciói
- Rugalmas hierarchia a tesztesetek Spaces-ekben, mappákban és listákban való szervezéséhez, testtípusra, prioritásra és környezetre vonatkozó egyéni mezőkkel
- Több mint 15 ClickUp-nézet (tábla, lista, táblázat) a tesztvégrehajtás nyomon követéséhez állapot, felelős vagy sprint szerint
- Dokumentumok a PRD-k, teszttervek és környezetbeállítási útmutatók tárolásához a hozzájuk tartozó tesztesetek mellett
- Beépített csevegő a minőségbiztosítók és a fejlesztők közötti kommunikációhoz, anélkül, hogy át kellene váltani a Slackre vagy az e-mailre
- AI-alapú feladatösszefoglalók a ClickUp Brain segítségével a sprint-áttekintések során a gyors kontextus megértéséhez
A ClickUp korlátai
- Nincs natív tesztfutó motor
- A tesztelésre vonatkozó jelentések (követelményenkénti lefedettség, ciklusonkénti sikerarány) nem a kész QA-jelentésekkel, hanem egyedi irányítópultokkal készülnek.
A ClickUp árai
A ClickUp értékelései és véleményei
- G2: 4,6/5 (több mint 14 100 értékelés)
- Capterra: 4,6/5 (több mint 4600 értékelés)
Mit mondanak a valódi felhasználók a ClickUp-ról?
Íme, mit mond erről egy G2-értékelő:
A ClickUp-ban leginkább azt szeretem, hogy mindent egy helyre összegyűjt. A feladatok, az ütemtervek, a jegyzetek és a frissítések mind ugyanabban a rendszerben találhatók, ami csökkenti az eszközök közötti oda-vissza váltogatást. Nagyra értékelem a rugalmasságot is. Testreszabhatjuk az állapotokat, a mezőket és a nézeteket, hogy azok illeszkedjenek a csapatunk tényleges munkamódszeréhez. Ez megkönnyíti a rendszerezést, és világos áttekintést nyújt arról, ki miért felelős, valamint hogy a projektek éppen hol tartanak.
A ClickUp-ban leginkább azt szeretem, hogy mindent egy helyre összpontosít. A feladatok, az ütemtervek, a jegyzetek és a frissítések mind ugyanabban a rendszerben találhatók, ami csökkenti az eszközök közötti oda-vissza váltogatást. Nagyra értékelem a rugalmasságot is. Testreszabhatjuk az állapotokat, a mezőket és a nézeteket, hogy azok illeszkedjenek a csapatunk tényleges munkamódszeréhez. Ez megkönnyíti a szervezettség fenntartását, és világos áttekintést nyújt arról, ki miért felelős, valamint hogy a projektek éppen hol tartanak.
Legalkalmasabb: Olyan minőségbiztosítási vezető számára, aki szeretné, ha egy sikertelen teszt egyetlen kattintással a fejlesztő hibajegyzékébe kerülne, és a PR, a tesztlépések és a sprint mind egy feladatból láthatók legyenek.
Hagyja ki, ha: A tesztciklusa nagyrészt automatizált. Ha a tesztcsomagjának 80%-a CI-pipeline-ból fut, akkor olyan eszközre van szüksége, amely beolvassa a végrehajtási eredményeket, nem pedig olyanra, ahol egy ember frissíti az állapotot.
TestRail
A TestRail egy speciális tesztkezelő platform, amelyet olyan minőségbiztosítási csapatok számára fejlesztettek ki, amelyeknek strukturált ellenőrzésre van szükségük a teljes tesztelési folyamatuk felett. Kezelése kiterjed a tesztesetek írásának, futtatásának és jelentéskészítésének teljes ciklusára, a DevOps és a CI/CD integrációk segítségével, amelyek az eredményeket továbbítják a rendszerbe.
A TestRail legfontosabb funkciói
- Központosított teszteset- és tesztcsomag-kezelés, projektek között újrafelhasználható tesztesetekkel
- Teszttervek és mérföldkövek a tesztfutások szervezéséhez és ütemezéséhez a sprintek és kiadások során
- Részletes jelentések lefedettségi elemzéssel, az előrehaladás nyomon követésével és a végrehajtási előzményekkel
- Integrációk a Jira, a GitHub, a Jenkins, az Azure DevOps és több mint 20 egyéb DevOps-eszközzel
- REST API a feladatok automatizálásához és a tesztadatok külső rendszerekkel való szinkronizálásához
A TestRail korlátai
- Nincs natív követelmény- vagy hibakövetés – a csapatoknak külső eszközökre, például a Jira-ra kell támaszkodniuk, ami megnehezítheti a nyomon követhetőséget
- A mappákra épülő rendszerezés nehezen áttekinthetővé válik, ahogy a teszttárak több ezerre bővülnek
A TestRail árai
- Professional: 39 USD/felhasználó/hónap
- Enterprise: 78 USD/felhasználó/hónap
A TestRail értékelései és véleményei
- G2: 4,4/5 (több mint 600 értékelés)
- Capterra: 4,3/5 (több mint 160 értékelés)
Mit mondanak a valódi felhasználók a TestRailről?
Íme, mit mond erről egy G2-értékelő:
A TestRail-ben számomra a legértékesebb az, hogy biztonságos és jól szervezett környezetet biztosít a minőségbiztosítási csapatunknak a teszttervek, tesztesetek és tesztfutások kezeléséhez. Nagyra értékelem, hogy milyen egyszerű a tesztcsomagok felépítése és megvalósítása, valamint a korábban létrehozott tesztesetek újrafelhasználása. A Jira-val és a CI/CD-eszközökkel való integrációk koherensebbé és könnyebben nyomon követhetővé tették a munkafolyamatunkat. A tesztelés előrehaladásának és lefedettségének valós időben történő nyomon követése hihetetlenül hasznosnak bizonyult a sprinttervezés és a jelentések készítése során. Minőségbiztosítási mérnökként végzett mindennapi munkám során a TestRail használata jelentős időmegtakarítást jelentett számomra.
A TestRail-lel kapcsolatban számomra az a legértékesebb, hogy biztonságos és jól szervezett környezetet biztosít a minőségbiztosítási csapatunknak a teszttervek, tesztesetek és tesztfutások kezeléséhez. Nagyra értékelem, hogy milyen egyszerű a tesztcsomagok felépítése és megvalósítása, valamint a korábban létrehozott tesztesetek újrafelhasználása. A Jira-val és a CI/CD-eszközökkel való integrációk összefüggőbbé és könnyebben nyomon követhetővé tették a munkafolyamatunkat. A tesztelés előrehaladásának és lefedettségének valós időben történő nyomon követése rendkívül hasznosnak bizonyult a sprinttervezés és a jelentések készítése során. Minőségbiztosítási mérnökként végzett mindennapi munkám során a TestRail használata jelentős időmegtakarítást jelentett számomra.
Legalkalmasabb: Öt vagy több főből álló minőségbiztosítási csapat számára, amely kiadásonként formális tesztciklusokat futtat, és ahol a vezetőnek egy irányítópultról – nem pedig egy táblázatból – kell megválaszolnia azt a kérdést, hogy „a 2.0-s kiadás hány százaléka került végrehajtásra és teljesült sikeresen”.
Hagyja ki, ha: a tesztkészlete néhány száz esetnél kevesebb, vagy a tesztelői egyben fejlesztők is. Ilyen méretű tesztkészlet esetén a felhasználónkénti költség és a külön bejelentkezés olyan jelentéseket eredményez, amelyeket úgysem fog megnézni.
Zephyr
A Zephyr a SmartBear Jira-hoz készült tesztkezelő bővítménye, amelyet úgy alakítottak ki, hogy a teszteseteket közvetlenül a Jira felületén lehessen kezelni. Támogatja mind a manuális, mind az automatizált tesztelést, és kiterjedt jelentéskészítési és nyomonkövetési funkciókat kínál az agilis és vállalati csapatok számára.
A Zephyr legfontosabb funkciói
- Natív Jira-integráció – tesztesetek létrehozása, összekapcsolása és végrehajtása közvetlenül a Jira-feladatokból
- Projektek közötti hierarchikus tesztkönyvtárak a tesztesetek nagy léptékű újrafelhasználásához és rendszerezéséhez
- Több mint 70 azonnal használható jelentés, amelyek kiterjednek a tesztelési lefedettségre, a végrehajtás előrehaladására és a hibák nyomon követésére
- BDD-támogatás Gherkin szintaxissal a viselkedésvezérelt fejlesztési munkafolyamatokhoz
- CI/CD-integrációk a Jenkins, GitHub, GitLab, Bitbucket és Bamboo szolgáltatásokkal
A Zephyr korlátai
- A licencelés Jira-felhasználónként történik, nem tesztelőnként
- A nagy tesztadatbázisok (több ezer teszteset) kezelése nehezebbnek tűnhet, mint az olyan önálló eszközöknél, mint a TestRail
- A támogatás az Atlassian Marketplace-en keresztül történik, ami egy további réteget jelent azoknak a csapatoknak, amelyek a gyártók közvetlen támogatásához vannak szokva.
A Zephyr árai
- Essential: 5,99 USD/felhasználó/hónap-tól (11–50 felhasználó)
- Standard: 6,81 USD/felhasználó/hónap-tól (11–50 felhasználó)
- Advanced: 8,73 USD/felhasználó/hónap-tól (11–50 felhasználó)
A Zephyr értékelései és véleményei
- G2: 4,1/5 (több mint 80 értékelés)
- Capterra: Nincs elég értékelés
Mit mondanak a valódi felhasználók a Zephyr-ről?
Íme, mit mond erről egy G2-értékelő:
Ez a legjobb eszköz a tesztesetek közvetlen importálásához Excel-táblázatból. Ennek az eszköznek a használatával a tesztelők munkája kevesebb, mint a tesztesetek Jira-ba történő importálása esetén. Ezenkívül az eszköz egyik legjobb funkciója, hogy a teszteseteket sikeresnek vagy sikertelennek jelölheti, valamint mellékleteket is hozzáadhat.
Ez a legjobb eszköz a tesztesetek közvetlen importálásához Excel-táblázatból. Ennek az eszköznek a használatával a tesztelők munkája kevesebb, mint a tesztesetek Jira-ba történő importálása. Ezenkívül az eszköz egyik legjobb funkciója, hogy a teszteseteket sikeresnek vagy sikertelennek jelölheti, valamint mellékleteket is hozzáadhat.
Legalkalmasabb: Szabályozott vagy gyakori auditoknak alávetett csapatok (fintech, egészségügy) számára, amelyeknek minden tesztet egy Jira-követelményhez kell kapcsolniuk, és minden hibát vissza kell vezetniük ahhoz a teszthez, amelyik felfedezte, mindezt egyetlen Atlassian-példányon belül.
Hagyja ki, ha: A Jira-instanciája nagy, a minőségbiztosítási csapata pedig kicsi. Egy 200 felhasználói helyet biztosító Jira 10 tesztelővel 190 olyan Zephyr-licencet fizet, amelyet senki sem nyit meg; egy tesztelőnkénti árazású önálló eszköz olcsóbb.
Jira
A Jira az Atlassian projektmenedzsment- és hibajelentés-követő platformja, amelyet a mérnöki és minőségbiztosítási csapatok széles körben használnak a sprintek, hibák és fejlesztési munkafolyamatok kezelésére. Bár nem kifejezetten tesztkezelő eszköz, sok csapat a Zephyr Scale vagy az Xrayhez hasonló megoldásokkal együtt használja a meglévő Jira-konfigurációjukon belüli teszteset-kezeléshez.
A Jira legfontosabb funkciói
- Scrum- és Kanban-táblák a sprintek, a backlogok és az agilis tesztelési munkafolyamatok kezeléséhez
- Testreszabható munkafolyamatok, hibajelentés-típusok és mezők, amelyek igazodnak a csapat munkakövetési módszereihez
- Fejlett ütemtervek a csapatok közötti tervezéshez és a függőségek nyomon követéséhez (Premium)
- Több mint 1 000 piactéri integráció, beleértve a GitHubot, a Confluence-t, a Slacket és a CI/CD-eszközöket
- Automatizálási szabályok, amelyek a hibajelentések frissítései vagy állapotváltozásai alapján műveleteket indítanak el a projektekben
A Jira korlátai
- A tesztesetek kezeléséhez egy Marketplace-bővítményre (Zephyr Scale, Xray) van szükség, amelynek felhasználónkénti díja a Jira-előfizetésen felül fizetendő.
- A nem technikai háttérrel rendelkező felhasználók számára meredekebb a tanulási görbe, és a bevezetési költségek nagyobb csapatok esetében jelentősen megnőhetnek
A Jira árai
- Ingyenes
- Standard: 7,91 USD/felhasználó/hónap
- Premium: 14,54 USD/felhasználó/hónap
- Enterprise: Egyedi árazás
Jira értékelések és vélemények
- G2: 4,3/5 (több mint 7 900 értékelés)
- Capterra: 4,4/5 (több mint 15 400 értékelés)
Mit mondanak a valódi felhasználók a Jiráról?
Íme, mit mond erről egy G2-értékelő:
A Jira az egyik kedvenc digitális programom, amelynek segítségével nyomon követhetem és vizualizálhatom az összes munkaprojektem teljesítményét a munkacsoportom összes tagjával együttműködve, mivel a kategóriájában a legjobb virtuális teljesítményképességeket kínálja, így könnyebbé téve az összes szakmai célom elérését.
A Jira az egyik kedvenc digitális programom, amellyel nyomon követhetem és vizualizálhatom az összes munkaprojektem teljesítményét a munkacsoportom minden tagjával együttműködve, mivel a kategóriájában a legjobb virtuális teljesítményképességeket kínálja, így könnyebbé téve az összes szakmai célom elérését.
Leginkább alkalmas: Olyan mérnöki csapatok számára, amelyek még mérlegelik, hogy egyáltalán szükségük van-e dedikált tesztkezelésre. Ha először néhány tesztciklust futtatnak egyéni Jira-feladat típusokként, az rögtön megmutatja, hogy a tesztmennyiség indokolja-e egy plugin használatát.
Ugorja át, ha: Már tudja, hogy szüksége van tesztkezelésre. Ha egyből egy bővítményhez vagy önálló eszközhöz fordul, elkerülheti az áttérést, amikor az egyéni probléma-típusok már nem skálázhatók tovább.
A tesztesetek létrehozásakor elkerülendő gyakori hibák
Kerülje el ezeket a teszteset-írási hibákat, amelyek csökkenthetik a tesztelés általános hatékonyságát.
| Hiba | Mit tegyen helyette |
|---|---|
| A tesztesetek túl késői írása | Vonja be a tesztelőket a követelmények összegyűjtésének és a tervezés fázisába, hogy a kódolás megkezdése előtt azonosíthassák a lehetséges problémákat. |
| A tesztesetek nem frissülnek | Frissítse a tesztesetet, amint a funkció új frissítést kap, a funkcionalitásában változás történik, vagy a felhasználói felület megváltozik. |
| Nincsenek utólagos feltételek | Határozza meg, hogy a rendszernek hogyan kell kinéznie a teszt befejezése után (a tesztfelhasználó törölve, a kosár kiürítve, a munkamenet lezárva), hogy a következő eset tiszta állapotból indulhasson |
| Kizárólag a várt események adatai | Minden beviteli mezőhöz legalább egy olyan értékre van szükség, amelyet a rendszernek el kell utasítania. Dokumentálja, hogyan jön létre vagy kerül lekérésre az adatkészlet |
| A tesztesetek prioritásának elmulasztása | Rendeljen minden tesztesethez prioritást az üzleti hatások, a használat gyakorisága és a hiba kockázata alapján. Ez segít összpontosítani a tesztelési erőfeszítéseket, és megalapozottabb döntéseket hozni a költségvetés és a tesztelési módszerek tekintetében. |
Hogyan tarthatja hasznosnak a teszteseteket hosszú távon
Egy tesztcsomag akkor marad megbízható, ha minden egyes eset független, a legvalószínűbb hibaforrásokra irányul, és azonnal kivonásra kerül, amint már nem ad megbízható eredményt. Ez a hat gyakorlat különbözteti meg azokat a tesztcsomagokat, amelyek évekig felderítik a hibákat, azoktól, amelyeket már a második sprint után figyelmen kívül hagynak.
Írj független, atomi teszteket
Egy tesztesetnek saját állapotot kell létrehoznia, és soha nem szabad attól függenie, hogy egy másik esetet előbb futtattak-e le. Amikor a TC_CHECKOUT_003 feltételezi, hogy a TC_CHECKOUT_002 egy terméket hagyott a kosárban, egy hiba öt hibává duzzad, és az egész reggeledet azzal töltöd, hogy kiderítsd, melyik hiba volt valós. Ha egy tesztcímben szerepel az „és” szó, oszd két esetre.
Teszteljen a határeseteknél
A hibák az elfogadott bemeneti értékek szélén halmozódnak fel, nem pedig a közepén. Ha egy jelszómező 8–128 karaktert fogad el, tesztelje a 7, 8, 128 és 129 karakteres jelszavakat is, ne csak a kényelmes 12 karakteres jelszót. A határérték-elemzés éppen ezért szerepel formális technikaként az ISO/IEC/IEEE 29119-4 teszttervezési szabványban: kiszűri azokat az „off-by-one” hibákat, amelyeket a véletlenszerű bemenetek elmulasztanak.
Használja az ekvivalencia-particionálást a felesleges esetek kiszűrésére
Csoportosítsa azokat a bemeneti adatokat, amelyeket a rendszernek azonos módon kell kezelnie, majd teszteljen egy reprezentatív példát minden csoportból. Minden érvényes e-mail-formátum ugyanúgy viselkedik a bejelentkezési űrlapon, ezért egy érvényes e-mail is elegendő. A user@example.com, a jane@company.com és a bob@domain.org címek három különálló esetként történő tesztelése megháromszorozza a karbantartási terhelést anélkül, hogy növelné a lefedettséget.
Válaszd szét a tesztadatokat és a tesztlépéseket
Ha egy lépésbe „enter test@example.com” szöveget ír be, azt jelenti, hogy a tesztkörnyezet minden változásakor újra kell írnia a lépést. Tartsa a lépéseket általános formában („adja meg a regisztrált e-mail címet”), és a tényleges értékeket tárolja egy tesztadat-mezőben vagy fájlban. Így ugyanazok a lépések módosítás nélkül futtathatók a staging, a QA és az előkészítési környezetben, és egy negatív teszthez szükséges új adatkészlet beillesztése csupán egy soros módosítást igényel.
Kövesse nyomon a megbízhatatlan teszteket és a hibák áteresztési arányát
A megbízhatatlan teszt valódi termékhiba nélkül is következetlenül bukik meg, és minden ilyen teszt arra tanítja a csapatot, hogy figyelmen kívül hagyja a piros eredményeket. Kövesse nyomon, hogy az egyes esetek milyen gyakran váltanak át siker és kudarc között azonos build-eknél. Ha egy eset havonta többször is megbízhatatlanná válik, írja át vagy távolítsa el. Kombinálja ezt a hibaelkerülési aránnyal (a termelésben talált hibák, amelyeket a tesztesetnek kellett volna észlelnie), hogy lássa, hol gyenge a lefedettség, és ne csak azt, hol zajos.
Automatizálja a leggyakrabban futtatott teszteket
A regressziós, a füstteszt és a nagy gyakoriságú funkcionális tesztek a legalkalmasabbak az automatizálásra, mivel minden buildnél futnak, és ritkán változnak. Helyezze át ezeket a CI/CD-folyamat szkriptjeibe, és használjon mesterséges intelligenciával támogatott eszközöket önjavító lokátorokkal ott, ahol a felhasználói felület elemei gyakran változnak. Ezáltal a tesztelőknek több idejük marad a felfedező jellegű munkára és azokra a szoftvertesztelési feladatokra, amelyek megítélést igényelnek, például a használhatóság vizsgálatára és a szélsőséges esetek felkutatására.
Hogyan írjunk és futtassunk teszteseteket a ClickUp-ban
A fenti eszközök szakasz bemutatja, hol illeszkedik be a ClickUp. Ez a szakasz a tényleges beállítást mutatja be, az útmutató korábbi lépéseihez igazítva.
Szervezze meg a teszteset-könyvtárát! Hozzon létre egy teret a termékéhez, egy mappát minden funkcióterülethez (pl. hitelesítés, fizetések, bevezetés), valamint egy listát minden tesztciklushoz vagy sprinthez. Minden feladat egy-egy külön tesztesetté válik. Használja a ClickUp egyéni mezőit olyan elemek rögzítéséhez, mint a teszteset-azonosító, az előfeltételek, a tesztadatok, a prioritási szint és a környezet.
Írja be a tesztlépéseket közvetlenül a feladatba. Használja a feladat leírását a egymást követő végrehajtási lépések és a várt eredmények dokumentálására. Az ellenőrzőlisták jól használhatók olyan lépésenkénti folyamatoknál, ahol a tesztelőnek le kell jelölnie az egyes műveleteket, míg a leírás tartalmazza a kontextust, például az előfeltételeket és a tesztadatokat.
Kövesse nyomon a végrehajtást és az eredményeket. Hozzon létre egyedi állapotokat, amelyek tükrözik a tesztelési munkafolyamatot: Még nem kezdődött el → Folyamatban → Sikerült → Sikertelen → Blokkolva. Ha egy teszt sikertelen, alakítsa át hibajelentéssé, vagy hozzon létre egy kapcsolódó feladatot, amelyet a fejlesztőhöz rendel, prioritással, függőségekkel és határidővel. A GitHub és a GitLab integrációk segítségével a hibát közvetlenül összekapcsolhatja azzal a PR-rel, amelyben felmerült. Ha a kiváltó ok egy kódhiba, akkor a hibajelentést hozzárendelheti a ClickUp Codegen Agenthez, amely elolvassa a feladat leírását, a kapcsolódó specifikációkat és a megjegyzéseket, megírja a javasolt javítást, majd megnyit egy pull requestet felülvizsgálatra, és a haladást visszajelzi a feladathoz.
Profi tipp: A minőségbiztosítási vezetők azonnali áttekintést kaphatnak bármely feladatról, ha megkérik a ClickUp Brain-t, hogy foglalja össze a nyitott hibajelentéseket. Így minden szükséges háttérinformáció a rendelkezésükre áll a sprint-áttekintésekhez, anélkül, hogy az egyes feladatokat át kellene kutatniuk a teljes kép összeállításához.
Futtassa a tesztciklusokat nézetek segítségével. Használja az állapot szerint csoportosított Tábla nézetet, hogy a tesztfutás során egy pillantásra láthassa a sikeres/sikertelen eredmények eloszlását. A Táblázat nézet hagyományos tesztmátrixként működik, ha több tucat teszteset eredményeit kell áttekintenie. Szűrjön feladatkijelölt szerint a munkaterhelés kiegyensúlyozása érdekében, vagy prioritás szerint, hogy a füstteszt során először a kritikus útvonalakra koncentrálhasson.
A ClickUp tesztkezelési sablon központosított megoldást kínál a teljes tesztelési munkafolyamat kezelésére, több funkcióterületen, tesztforgatókönyvben és szélsőséges esetekben egy helyen. Használja a felhasználói visszajelzések nyomon követésére, a tesztütemtervek kezelésére, a tesztek előrehaladásának figyelemmel kísérésére, valamint a sikeres/sikertelen eredmények értékelésére anélkül, hogy különböző eszközök között kellene váltogatnia.
A tesztelési munkafolyamatok hatékony kezelése
Egy teszteset akkor érdemli ki a helyét, ha két ember függetlenül futtathatja, és ugyanazt az eredményt kapja: siker vagy hiba. A jelen útmutatóban szereplő minden elem (lépésenként egy művelet, egyértelmű előfeltételek, értelmezésre nem hagyó várt eredmények) ezt az egyetlen szabványt szolgálja. Ha már a ClickUp-ban tervezi a sprinteket, a fent ismertetett beállítás segítségével teszteseteket írhat, futtathat és nyomon követhet a feltárt hibákkal együtt, anélkül, hogy újabb eszközt kellene használnia.
Regisztrálj ingyenesen a ClickUp-ra
Gyakran feltett kérdések a tesztesetekről
Hány tesztesetnek kell lennie egy követelményhez?
Egy adott követelményhez egy vagy akár tíz teszteset is szükséges lehet, attól függően, hogy hány forgatókönyvet, szélsőséges esetet és bemeneti variációt foglal magában. A cél az, hogy minden reális útvonalat lefedjünk, és elegendő lefedettséget biztosítsunk redundancia nélkül.
Mi a különbség a tesztesetek és a teszt szkriptek között?
A teszteset dokumentálja, mit kell tesztelni és milyen eredményre kell számítani, és manuális végrehajtásra készült. A teszt szkript viszont ennek az automatizált változata: olyan kód, amely programozási úton hajtja végre ugyanazokat a lépéseket.
Mennyire kell részletesnek lenniük a tesztlépéseknek?
Bontsa a tesztet logikus, egymást követő lépésekre, amelyek előzetes kontextus nélkül is könnyen követhetők. Ne csoportosítson össze több műveletet, és ne bonyolítsa feleslegesen a tesztet.
Egy tesztforgatókönyv egy sorban meghatározza, mit kell tesztelni („Ellenőrizze a jelszó-visszaállítást”); egy teszteset pedig meghatározza, hogyan, az előfeltételekkel, lépésekkel, tesztadatokkal és várt eredményekkel együtt. Egy forgatókönyv általában 3–10 tesztesetet eredményez, amelyek lefedik a normál esetet, az érvénytelen beviteleket és a határfeltételeket. Elsőként a forgatókönyvek jönnek, és ezek határozzák meg a lefedettség tervezését; másodsorban a tesztesetek következnek, és ezek irányítják a végrehajtást.
A pozitív teszteset érvényes bemeneti adatokat használ, és sikeres kimenetet vár: a helyes e-mail-cím és jelszó bejelentkezést eredményez. A negatív teszteset érvénytelen vagy váratlan bemeneti adatokat használ, és azt várja, hogy a rendszer hibátlanul kezelje a hibát: helytelen jelszó esetén a rendszer a munkamenet létrehozása nélkül a „Érvénytelen jelszó” üzenetet jeleníti meg. A kiforrott tesztcsomagokban a pozitív és negatív tesztesetek aránya nagyjából 1:3 és 1:5 között mozog, mivel a legtöbb termelési hiba a hibaútvonalakon fordul elő, nem pedig a normál működési útvonalakon.
A tesztterv határozza meg a teljes tesztelési munka hatókörét, megközelítését, erőforrásait és ütemtervét. A tesztcsomag egy tesztesetekből álló gyűjtemény, amelyeket egyetlen futtatásra csoportosítottak, például „regressziós csomag a 2.1-es kiadáshoz”. A teszteset mindkettőn belül az alapegység: egy dokumentált ellenőrzés, amelynek eredménye siker vagy kudarc. A terv határozza meg a stratégiát, a csomag a hatókört, az eset pedig az eredményt.