A legtöbb teszteset már azelőtt kudarcot vall, hogy egyetlen hibát is felfedezne. Homályos ellenőrzőlistaként íródnak, hiányoznak belőlük az előfeltételek, több műveletet egyesítenek egy lépésbe, vagy olyan pontatlanul írják le a várt eredményeket, hogy két tesztelő, aki ugyanazt az esetet olvassa, nem értene egyet abban, mit jelent a „sikeres” minősítés. 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 kevésbé a tesztelési készségről, inkább az ellenőrzés tervezéséről szól. A pénzügyi szolgáltatások területén ezt „maker-checker” folyamatnak nevezik. A nukleáris parancsnokságoknál ez a „kétfős szabály”. Az elv ugyanaz: a kritikus feladatok soha nem támaszkodhatnak egyetlen, ellenőrizetlen műveletre. Egy jól megírt teszteset ugyanezt a szigorúságot építi be a szoftverbe. Elkülöníti az elvárásokat a megfigyelt eredményektől, így a kettő közötti eltérés lehetetlenné válik, hogy figyelmen kívül hagyják.
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árt eredményeket, amelyek szükségesek egy funkció megfelelő működésének ellenőrzéséhez. Minden tesztesetnek egyedi azonosítóval, előfeltételekkel és várt 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óvá tenni a termék változásai közepette.
Mik azok a tesztesetek?
A teszteset egy strukturált dokumentum, amely pontosan meghatározza azokat a 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. Nem tesztterv (amely a tesztelési stratégiát vázolja fel) és nem is 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 teszteli. Egy ilyen funkcióra vonatkozó teszteset a következő elemeket határozná meg:
- A felhasználó által végrehajtott lépéseket és a rendszer várható válaszát leíró műveletek
- 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 tartalmazó bemeneti adatokat a különböző eredmények teszteléséhez, valamint a sikeres és sikertelen forgatókönyvek ellenőrzéséhez
Kézi és automatizált tesztesetek összehasonlítása
A mesterséges intelligencia (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ális tesztesetektő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 által végrehajtva |
| Sebesség | Lassú és időigényes, mivel az embereknek manuálisan kell bevinniük az adatokat és ellenőrizniük az eredményeket | 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 rendkívül jól megismételhetők és konzisztensek |
| 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 megváltozása esetén a szkriptek frissítéséhez technikai karbantartás szükséges |
| 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 tennének, Ön már észleli a regressziókat. Minden kódmódosítás magában hordozza annak a kockázatát, hogy valami, ami eddig működött, meghibásodjon. 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 átalakítja a bejelentkezési kódot, és véletlenül megzavarja a munkamenetkezelést, akkor ez a teszteset jelzi a problémát a staging környezetben.
A „megfelelt/nem felelt” kifejezést tényként, nem pedig véleményként kell kezelnie. Az olyan homályos várt eredmények, mint például „a rendszer megfelelően reagál”, arra kényszerítik az egyes tesztelőket, hogy maguk értelmezzék, mit jelent a „megfelelő”. Két tesztelő futtatja ugyanazt az esetet, az egyik „megfelelt” minősítést ad, a másik hibát jelöl meg, és így a csapat a szoftver helyett a nézeteltérés kijavításával foglalkozik. 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ő az ellenőr, és mindkettőjüknek ugyanazt a nyelvet kell beszélniük.
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 ott van minden szélsőséges eset, minden megoldás és minden „ó, ne felejtsd el ellenőrizni az X-et is” láthatatlan térképe. Amikor az illető szabadságra megy vagy csapatot vált, a térkép vele együtt távozik. A kifejezett előfeltételekkel és határértékekkel ellátott, dokumentált tesztesetek 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 önálló lépés, saját várt eredménnyel, akkor a hiba a 4. lépésnél jelentkezik: „Kattintás a »Visszaállítási link küldése« gombra → várt sikerüzenet helyett 500-as hibaüzenet érkezett. ” Ez a pontosság drámaian lerövidíti a hibakeresés idejé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átni fogja, mi kerül lefedésre, és mi marad 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-cím, érvénytelen formátum, többszörös kérés), és csak háromra van tesztesete, akkor a hiányosság látható és számszerűsíthető. Ez a láthatóság az, ami a tesztelést a „teszteltük” 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. Rögzíti 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
- Végrehajtási lépések
- 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ítségével ezeket a hibakeresés vagy a jelentések készítése során könnyen nyomon lehet követni, rendszerezni és hivatkozni rájuk.
Példa: TC_LOGIN_001
Leírás: Ez megmagyarázza, hogy a teszteset milyen funkciót ellenőriz. 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 nélkül előfordulhat, hogy a tesztelők ugyanazt a tesztet különböző feltételek mellett futtatják, és eltérő 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ő végrehajt 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ó beír 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 mit kell tennie a rendszernek, 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 vezérlőpultra
- A felhasználói munkamenet létrehozása sikeresen megtörtént
Ha a hitelesítő adatok érvénytelenek, a rendszernek 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ához szükséges készségeit!
Tudta-e? A csapatok mindössze 2,1%-a tartja optimalizáltnak a mesterséges intelligencia 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-dokumentumokat), 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 a funkció, azaz visszanyerheti-e 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énik, 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 nem megfelelően definiált? Ha igen, kérjen pontosítást az érintett érdekelt féltől.
Ez az egyértelműség alapot ad ahhoz, hogy egy világos célt fogalmazzon 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ű helyzetleírás, 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 így nézhetnek ki:
- Sikeres visszaállítás: Ellenőrizze, hogy a 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-mailt küldenek be, 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ő jelszavak elutasításra kerüljenek
- 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ó: Hogyan készítsünk és valósítsunk meg minőségbiztosítási ellenőrzőlistát
3. lépés: Tervezze meg a tesztet, és határozza meg 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álhatóságot 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 szerepre 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 szerepeket:
- Minőségbiztosítási tesztelő: Funkcionális és regressziós tesztek, például a bejelentkezési folyamatok, az űrlapok érvényesítése vagy a fizetési folyamatok ellenőrzése
- Biztonsági csapat: Hitelesítéssel, hozzáférés-vezérléssel vagy adatnyilvánossággal kapcsolatos sebezhetőségeket vizsgáló tesztek
- Fejlesztő: Egyedi funkciókhoz, például jelszó-hasholáshoz vagy token-generáláshoz készült egységtesztek
Hogyan fogják lebonyolítani a tesztet?
- Mely eszközökön és operációs rendszereken fog futni a teszt?
- Milyen eszközöket vagy tesztelési keretrendszereket fogunk használni?
- A tesztet manuálisan vagy egy AI-ügynök segítségével fogják végrehajtani?
- Hogyan rögzítik az eredményeket – 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 le 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 gondoskodjon arról, hogy minden lépés egy műveletet tartalmazzon. 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 rajta található 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 | Sikeres üzenet jelenik meg: „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 a lépéseket és a várt eredményeket az alternatív forgatókönyvekhez (amelyeket korábban már tárgyaltunk). Í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ók vagy konfigurációs fájlok, amelyek segítenek a háttérrendszerrel kapcsolatos problémák diagnosztizálásában, ha egy teszt sikertelen
- Követelménydokumentumok, amelyek a tesztesetet a felhasználói történethez vagy az általa ellenőrzött átvételi kritériumokhoz rendelik
- Tesztadatfájlok, 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éshez: OpenAPI-specifikációk vagy végpontdokumentá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 teszteset felülvizsgálata
A teszteset végrehajtása előtt ossza meg azt 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 világosak és egymás után követik 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 olyan minőségi jellemzőt, 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 minden feltételezést kifejezetten dokumentálnak
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”ként. Minden sikertelen lépés esetén azonnal jelentsen hibát, és kapcsolja azt vissza a tesztesethez. Továbbá, ha bármilyen váratlan viselkedés jelentkezik, amely nem egyértelműen sikeres vagy sikertelen, jegyezze fel azt a megjegyzések mezőbe a későbbi áttekintés céljából.
További információ: 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-szerkezet 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ás itt az állapotfüggőség: 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) az összes lépés során meg kell maradniuk.
Tesztelő: Rahul D.
A vizsga időpontja: 2026. március 9.
Teszteset azonosító: TC_CHECKOUT_003
Leírás: Ellenőrizze, hogy a bejelentkezett felhasználó elvégezheti-e a vásárlást a mentett hitelkártya és a standard szállítási mód használatával.
Előfeltételek:
- A felhasználói fiókban legalább egy mentett hitelkártya és egy mentett szállítási cím található
- 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 megfelelt |
| Ugrás a kosár oldalára | A kosárban a megfelelő termék, mennyiség és részösszeg jelenik meg | Ahogy várható volt | Átment |
| Kattintson a „Tovább a pénztárhoz” gombra | A szállítási oldal betöltésekor a mentett cím előre kiválasztva jelenik meg | Ahogy várható volt | Á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éggel együtt jelenik meg | Ahogy várható volt | Átment |
| Ellenőrizze a megadott hitelkártya adatait, majd kattintson a „Megrendelés” gombra. | Megjelenik a megrendelés-visszaigazoló oldal a megrendelésszámmal, a termékösszefoglalóval és a várható szállítási dátummal | A fizetési oldal hibaüzenettel újraindul: „A fizetés feldolgozása nem lehetséges” | Hiba |
Eredményösszefoglaló: A fizetési folyamat helyesen kezeli a kosárból a szállításra történő átvitelt, de a fizetés feldolgozása nem sikerül a mentett hitelkártyák esetében. 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 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.
A vizsga időpontja: 2026. május 9.
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ő
- Az adminisztrátori jogosultságokkal rendelkező hitelesítési token generálásra került és érvényes
- 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 megfelelt |
| 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ód, helyes testtel | Átment |
| Küldje el újra ugyanazt a POST-kérelmet azonos e-mail-címmel | A válasz 409-es konfliktus 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ó létrehozva | Hiba |
| POST-kérés küldése hiányzó „email” mezővel | A válasz 400-as „Bad Request” hibakódot ad vissza, é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 megadott azonosítóval | A válasz 200 OK kódot ad vissza, és a felhasználói adatok megegyeznek az eredeti adatcsomaggal | Ahogy várható volt | Á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 határok)
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és várható eredménye a blokkolás, nem pedig a siker.
Tesztelő: Marcus L.
A vizsga időpontja: 2026.08.09.
Teszteset azonosító: TC_RBAC_002
Leírás: Ellenőrizze, hogy a „Viewer” 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: egy „Admin” szerepkörrel, egy pedig „Viewer” szerepkörrel.
- A munkaterületen legalább egy, az adminisztrátor által létrehozott projekt található
- A felhasználó a Firefox 130 böngészőben, Windows 11 rendszeren van bejelentkezve
| Lépés | Várható eredmény | Tényleges eredmény | Megfelelt/Nem megfelelt |
| Lépjen a Projektek oldalra | A felhasználó 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 űrlap | Nem töltődött be űrlap; az eszköztipp azt jelzi: „Nincs hozzáférési jogosultsága” | Átment |
| Nyisson meg egy meglévő projektet, és próbálja meg szerkeszteni a címet | 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 gátló tényező).
Melyek a legjobb eszközök a tesztesetek kezeléséhez?
A tesztesetek kezelhetők egy erre a célra kifejlesztett 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ási funkcióra van szüksége, vagy csupán 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. Nincs szó egy dedikált tesztmenedzsment-eszközről, de 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 teszteset-munkafolyamatokat építsenek ki külön eszköz használata nélkül.
A ClickUp legfontosabb funkciói
- Rugalmas hierarchia a tesztesetek rendezéséhez terekben, mappákban és listákban, a teszt típusára, prioritására és környezetére 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 személy 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éshez kapcsolódó jelentések (követelményenkénti lefedettség, ciklusonkénti sikerarány) nem a kész minőségbiztosítási jelentésekre, hanem egyedi irányítópultokra szorulnak.
A ClickUp árai
ClickUp értékelések és vélemények
- 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-es értékelő:
A ClickUp-ban leginkább azt szeretem, hogy mindent egy helyen egyesí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éget, é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 helyen egyesí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éget, és világos áttekintést nyújt arról, ki miért felelős, valamint hogy a projektek éppen hol tartanak egy adott pillanatban.
Legalkalmasabb: Olyan minőségbiztosítási vezető számára, aki azt szeretné, hogy egy sikertelen teszt egyetlen kattintással a fejlesztő hibajeggyé váljon, és a PR, a tesztlépések és a sprint mind ugyanazon a feladaton belül láthatóak legyenek.
Hagyja ki, ha: A tesztciklusa nagyrészt automatizált. Ha a tesztcsomagjának 80%-a CI-folyamatból fut, akkor olyan eszközre van szüksége, amely beolvassa a futtatási eredményeket, nem pedig olyanra, ahol az állapotot ember frissíti.
TestRail
A TestRail egy speciális tesztkezelő platform, amelyet azoknak a minőségbiztosítási csapatoknak fejlesztettek ki, akiknek strukturált ellenőrzésre van szükségük a teljes tesztelési folyamatuk felett. A platform kezeli a tesztesetek írásának, futtatásának és jelentéskészítésének teljes ciklusát, miközben a DevOps és a CI/CD integrációk biztosítják az eredmények beolvasását.
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, GitHub, Jenkins, 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 megszakíthatja a nyomonkövethetőséget
- A teszt-tárházak mérete több ezerre nő, így a mappákra épülő rendszerben nehéz eligazodni
A TestRail árai
- Professional: 39 USD/felhasználó/hónap
- Vállalati: 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-es értékelő:
A TestRail-ben 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 összetartó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 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-ben 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 összetartó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 idejű nyomon követése hihetetlenül hasznos volt 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ős minőségbiztosítási csapat számára, amely kiadásonként formális tesztciklusokat futtat, és ahol a vezetőnek a „2.0-s kiadás hány százaléka került végrehajtásra és ment át a teszteken” kérdésre egy irányítópultról kell választ adnia, nem pedig egy táblázatból.
Hagyja ki, ha: A tesztkészlete néhány száz esetnél kevesebb, vagy a tesztelői egyben fejlesztők is. Ilyen méretnél a felhasználónkénti költség és a külön bejelentkezés olyan jelentéseket eredményez, amelyeket úgyis figyelmen kívül hagy.
Zephyr
A Zephyr a SmartBear Jira-hoz készült tesztkezelő bővítménye, amelyet úgy fejlesztettek ki, hogy a tesztesetek kezelése a Jira felületén belül történjen. Támogatja mind a manuális, mind az automatizált tesztelést, és kiterjedt jelentéskészítési és nyomonkövethetőségi funkciókkal rendelkezik az agilis és vállalati csapatok számára.
A Zephyr legfontosabb jellemző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 nagymértékű újrafelhasználásához és rendszerezéséhez
- Több mint 70 azonnal használható jelentés, amelyek a tesztelési lefedettséget, a végrehajtás előrehaladását és a hibák nyomon követését fedik le
- 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 rendszerekkel
A Zephyr korlátai
- A licenc a Jira-felhasználónként, nem pedig tesztelőnként érvényes
- A nagy tesztadatbázisok (több ezer teszteset) kezelése nehezebbnek tűnhet, mint az olyan önálló eszközök esetében, 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ói támogatáshoz vannak szokva
A Zephyr árai
- Essential: 5,99 USD/felhasználó/hó-tól (11–50 felhasználó)
- Standard: 6,81 USD/felhasználó/hónap-tól (11–50 felhasználó)
- Haladó: 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-es é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. 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 esetén. Ezenkívül az eszköz egyik legjobb funkciója, hogy a teszteseteket sikeresnek vagy sikertelennek minősítheti, valamint mellékleteket is hozzáadhat.
Legalkalmasabb: Szabályozott vagy gyakori auditoknak kitett csapatok (például a fintech vagy az egészségügy területén), amelyeknek minden tesztet egy Jira-követelményhez kell társítaniuk, és minden hibát vissza kell vezetniük arra a tesztre, amelyik felfedezte azt – mindezt egyetlen Atlassian-instancián 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ént árazott önálló eszköz olcsóbb.
Jira
A Jira az Atlassian projektmenedzsment- és hibajelentő 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 egy kifejezetten tesztmenedzsmentre szánt eszköz, sok csapat használja olyan megoldások mellett, mint a Zephyr Scale vagy az Xray, hogy a meglévő Jira-konfigurációjukon belül kezeljék a teszteseteket.
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 munkájának nyomon követési módjához
- 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 piaci 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 az állapotváltozások alapján műveleteket indítanak el a projektekben
A Jira korlátai
- A teszteset-kezeléshez 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
- Vállalati: 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, amellyel nyomon követhetem és vizualizálhatom az összes munkaprojektem teljesítményét a munkacsoportom összes tagjával együttműködve, mivel kategóriájában a legjobb virtuális teljesítményre képes, így könnyebben elérhetem minden szakmai célomat.
A Jira az egyik kedvenc digitális programom, amellyel 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ényt nyújtja, így könnyebbé teszi az összes szakmai célom elérését.
Legalkalmasabb: 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 egyedi Jira-feladat típusokként, az rögtön megmutatja, hogy a volumen indokolja-e egy bővítmény használatát.
Hagyja ki, ha: Már tudja, hogy szüksége van tesztkezelésre. Ha egyből egy bővítményt vagy önálló eszközt választ, elkerülheti az áttérést, amikor az egyedi hibajelentés-típusok már nem skálázhatók tovább.
A tesztesetek készítésekor elkerülendő gyakori hibák
Kerülje el azokat a teszteset-írási hibákat, amelyek csökkenthetik azok általános hatékonyságát.
| Hiba | Mit tegyen helyette |
|---|---|
| A tesztesetek túl késői megí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ásban 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 teszt befejezése után milyen állapotban kell lennie a rendszernek (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 „happy path” adatai | Minden beviteli mezőhöz szükség van legalább egy olyan értékre, 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ásainak elhanyagolása | Rendeljen minden tesztesethez prioritást az üzleti hatás, 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 okosabb 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 teszteset független, a legvalószínűbb hibaforrásokat célozza meg, é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.
Írjon 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őtte futtattak-e. Ha 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 szükség van az „és” szóra, oszd két esetre.
Teszteljen a határok mentén
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: felismeri azokat az „off-by-one” hibákat, amelyeket a véletlenszerű bemenetek nem vesznek észre.
Használja az ekvivalencia-particionálást a felesleges esetek kiszűrésére
Csoportosítsa azokat az 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, így 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álassza szét a tesztadatokat és a tesztlépéseket
Ha egy lépésbe „enter test@example.com” szöveget ír be, akkor a tesztkörnyezet minden változásakor újra kell írnia a lépést. A lépéseket általános formában tartsa („adja meg a regisztrált e-mail címet”), a tényleges értékeket pedig egy tesztadat-mezőben vagy fájlban tárolja. Így ugyanazok a lépések szerkeszté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 elkerülési arányát
Az instabil teszt a termékben nem létező hiba 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 tesztek milyen gyakran váltanak át siker és bukás között azonos build-ek esetén. Ha egy teszt havonta többször is instabilnak bizonyul, írja át vagy távolítsa el. Kombinálja ezt a hibaelkerülési aránnyal (azok a termelésben talált hibák, amelyeket a tesztesetnek kellett volna kiszűrnie), hogy lássa, hol gyenge a lefedettség, és ne csak azt, hol zajos.
Automatizálja a leggyakrabban futtatott tesztjeit
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ában lévő szkriptekbe, és használjon mesterséges intelligenciával támogatott eszközöket önjavító lokátorokkal azokon a helyeken, ahol a felhasználói felület elemei gyakran változnak. Ezáltal a tesztelőknek több ideje marad a felfedező jellegű munkára és azokra a szoftvertesztelési feladatokra, amelyek megítélést igényelnek, mint például a használhatóság vizsgálata és a szélsőséges esetek felkutatása.
Hogyan írjunk és futtassunk teszteseteket a ClickUp-ban
A fenti eszközök részben bemutatjuk, hol jön képbe a ClickUp. Ez a rész 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 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 feladatleírást a végrehajtási lépések sorrendjének é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 munkafolyamatát: Még nem indult → 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őnek rendel hozzá, prioritással, függőségekkel és határidővel. A GitHub- és GitLab-integrációk segítségével a hibát közvetlenül ahhoz a PR-hez kapcsolhatja, amelyben felmerült. Ha a kiváltó ok egy kódhiba, akkor a hibajelentést hozzárendelheti a ClickUp Codegen Agenthez, amely elolvassa a feladatot, a kapcsolódó specifikációkat és megjegyzéseket, megírja a javítást, majd megnyit egy pull requestet, amelynek előrehaladását 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 a sprint-áttekintésekhez szükséges összes háttérinformációt megkapják anélkül, hogy az egyes feladatokat át kellene kutatniuk a teljes kép összeállításához.
Futtasson 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ázatos nézet hagyományos tesztmátrixként működik, ha több tucat teszteset eredményét kell áttekintenie. Szűrjön a felelős személy szerint a munkaterhelés kiegyensúlyozása érdekében, vagy a prioritás szerint, hogy a füstteszt során először a kritikus útvonalakra összpontosítson.
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.
Kezelje hatékonyan tesztelési munkafolyamatait
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. Az ú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 bemutatott 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áljon ingyen 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, elegendő lefedettséget biztosítva redundancia nélkül.
Mi a különbség a tesztesetek és a teszt szkriptek között?
A teszteset dokumentálja, hogy 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 automatizált változata: olyan kód, amely programozási úton hajtja végre ugyanezeket 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 több műveletet egybe, é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, előfeltételekkel, lépésekkel, tesztadatokkal és várt eredményekkel. Egy forgatókönyvből általában 3–10 teszteset születik, amelyek lefedik a normál eseteket, az érvénytelen bemeneteket é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ásodszor a tesztesetek, amelyek a végrehajtást irányítják.
A pozitív teszteset érvényes bemeneti adatokat használ, és sikerre számít: 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 arra számít, hogy a rendszer hibátlanul kezelje a hibát: helytelen jelszó esetén a rendszer a „Hibás jelszó” üzenetet jeleníti meg anélkül, hogy munkamenetet hozna létre. 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 meghatározza a teljes tesztelési munka hatókörét, megközelítését, erőforrásait és ütemtervét. A tesztcsomag egy adott futtatásra csoportosított tesztesetek gyűjteménye, például a „2.1-es kiadás regressziós tesztcsomagja”. A teszteset mindkettőn belül az atomikus egység: egy dokumentált ellenőrzés, amelynek eredménye „megfelelt” vagy „nem felelt meg”. A terv határozza meg a stratégiát, a csomag a hatókört, az eset pedig az eredményt.