Hogyan promptold az AI-t, ha tesztesetet akarsz generálni?

Az AI percek alatt legenerál ötven tesztesetet. A kérdés csak az, hogy azok használhatók-e, vagy a felét úgyis kidobod. A különbség szinte sosem a modellen múlik, hanem azon, hogyan kéred.

Ha annyit írsz be, hogy „írj teszteket a bejelentkezéshez”, általános, sablonos listát kapsz, amit bármelyik tankönyvből kimásolhattál volna. Ha viszont tudod, hogyan építsd fel a promptot, és mit tegyél hozzá a saját kútfőből, akkor az AI-ból egy gyors, fáradhatatlan junior tesztelő lesz, aki neked dolgozik.

Ez a cikk három dologról szól: a jól bevált prompt-mintákról, a stratégiákról, amelyekkel rávezeted az AI-t a jó válaszra, és arról a szakmai többletről, amit csak te tudsz hozzáadni. Az AI teszteset generálás alapjait a Hogyan segíti az AI a tesztesetek generálását? cikkünkben jártuk körül; itt a gyakorlati prompt technikákra fókuszálunk.

1. A jó prompt anatómiája: szerep, kontextus, formátum, korlátok

A leggyakoribb hiba, hogy túl keveset mondunk az AI-nak. Egy jó QA prompt négy dolgot ad meg:

  • Szerep: mondd meg, kinek a fejével gondolkodjon. „Viselkedj tapasztalt manuális tesztelőként.”
  • Kontextus: másold be a konkrét követelményt vagy user storyt az elfogadási kritériumokkal együtt. Az AI csak abból dolgozik, amit lát.
  • Formátum: kérd pontos szerkezetben, hogy azonnal használható legyen. User storykhoz jól működik a Gherkin (Given-When-Then, azaz adott-amikor-akkor) formátum; az API vagy adatbázis szintű teszteknél viszont inkább a lépés és elvárt eredmény táblázat működhet jól. De van ahol a smia manuális tesztekhez is lépésről lépésre utasításokat várnak el, lépésenként elvárt eredménnyel.
  • Korlátok: mondd meg, mire figyeljen. „Külön válaszd a pozitív és a negatív eseteket”, „térj ki a határértékekre”.

Egy sablon, amit nyugodtan módosíthatsz tetszés szerint. Figyeld meg, hogy nem egyből a teszteseteket kéri, hanem előbb egy gondolkodási fázist:

Viselkedj tapasztalt manuális tesztelőként.

FELADAT: az alábbi user story és elfogadási kritériumok alapján generálj teszteseteket.

GONDOLD VÉGIG LÉPÉSRŐL LÉPÉSRE:
1. Azonosítsd a bemeneti mezőket, hozzájuk az érvényes és érvénytelen ekvivalenciaosztályokat, majd a határértékeket.
2. Ha valamelyik esetre a specifikáció nem ad egyértelmű elvárt eredményt, NE találj ki választ: gyűjtsd össze „Nyitott kérdések” cím alatt a fejlesztőnek vagy a terméktulajdonosnak.
3. Ezután írd meg a teszteseteket: külön a pozitív (happy path), a negatív és a határérték-eseteket.

KORLÁTOK:
– Kerüld a redundanciát: egy ekvivalenciaosztályból egy reprezentatív eset elég.
– Given-When-Then formátum, magyar nyelven.

MINTA:
[PÉLDA EGY HELYESEN FORMÁZOTT TESZTESETRE]

KÖVETELMÉNY:
[USER STORY]
[ELFOGADÁSI KRITÉRIUMOK]

A MINTA blokk a példaalapú (few-shot) promptolás lényege: ha beillesztesz egy jól megírt tesztesetet a saját gyakorlatotokból, az AI ugyanabban a formában és részletességgel folytatja. Így nemcsak tartalmat kapsz, hanem a megszokott formátumotokat is megtartod. A „gondold végig lépésről lépésre” rész pedig arra jó, hogy a modell előbb gondolkodjon, és csak utána írjon: így jóval kevesebb logikai hibát vét, mint ha azonnal a kész listát kezdené gyártani.

2. Stratégia: felülről lefelé, szabályokkal, iterációval

A második fontos dolog, hogy az AI-t nem egyetlen tökéletes paranccsal, hanem jó munkamenettel kell rávezetni a használható eredményre. Három dolog segít a legtöbbet.

Haladj felülről lefelé. Ne a konkrét teszteseteknél kezdd, hanem fölöttük. A sorrend: nézze meg a rendelkezésre álló információt a szükséges, de hiányzó információkra gyűjtsön kérdéseket, előbb bontsd részekre a funkciót (modulok, folyamatlépések, felhasználói útvonalak), aztán készíttess tervet a teszttervezési stratégiák szerint (például ekvivalenciaosztályok, határérték-elemzés, döntési tábla), és csak a végén generáltass konkrét teszteseteket. Így a részletek egy átgondolt vázra épülnek, nem véletlenszerűen.

A részekre bontástól és a tervtől azt várjuk el, hogy ezeket a szinteket hiánytalanul lefedje:

  • Először a fő, pozitív útvonal (happy path).
  • Aztán a negatív és érvénytelen bemenetek.
  • Majd a peremesetek és a határértékek.
  • Végül a szükséges tesztadatok.

Ha a terv ezeket lefedi, a tesztesetek generálása már szinte csak kitöltés: az AI sokkal alaposabban dolgozik egy kész vázra, mint egy nagy, általános „adj minden tesztesetet” kérésre.

Használj előre megírt szabályokat. Nem kell minden promptban elölről elmagyaráznod, hogyan néz ki nálatok egy jó teszteset. Gyűjtsd össze a szabályokat egyszer egy külön fájlba, és kérd meg az AI-t, hogy minden generálásnál tartsa be őket. Egy ilyen teszteset-szabalyok.md például így nézhet ki:

# Teszteset-írási szabályok
– Minden esetnek legyen egyértelmű előfeltétele, lépéssora és elvárt eredménye.
– Egy teszteset egy dolgot ellenőrizzen.
– Given-When-Then formátum, magyar nyelven.
– Minden funkcióhoz legyen legalább egy negatív eset és egy határeset.
– Azonos ekvivalenciaosztályból csak egy reprezentatív eset készüljön.
– Ha egy elvárt eredmény nem derül ki a specifikációból, nyitott kérdésként jelöld, ne találd ki.
– Hivatkozz a követelmény azonosítójára.
– A tesztadatok ne tartalmazzanak valós személyes adatot.

A promptban ezután elég ennyit írnod: „A csatolt teszteset-szabalyok.md szerint generálj teszteseteket az alábbi user storyhoz az elkészült terv alapján.” Magát a fájlt megadhatod csatolt dokumentumként, bemásolhatod a prompt elejére, vagy beállíthatod a chateszköz egyéni utasításai (Custom Instructions) közé, így minden beszélgetésben automatikusan érvényes. A nagy előnye, hogy az olyan visszatérő szabályok, mint a redundancia-szűrés vagy a nyitott kérdések kigyűjtése, ide kerülnek egyszer, és nem kell minden promptban megismételned őket. A szabálylista bármikor módosítható és bővíthető, ahogy a csapatotok tanul, és így minden tesztelőnél, minden feladatnál konzisztens marad a kimenet.

Iterálj, ne fogadd el az első választ. A kapott listát kezeld piszkozatként. Kérdezz vissza: „Milyen peremeset maradt ki?“, „Milyen feltételezésekkel éltél, amikor ezeket írtad?”. Ez utóbbi aranyat ér: ha megkéred az AI-t, hogy sorolja fel a feltételezéseit, gyakran pont a követelmény homályos pontjaira világít rá, amelyeket neked is tisztáznod kell a fejlesztővel vagy a terméktulajdonossal. Két-három ilyen kör alatt olyan tesztkészlet áll össze, amihez egyedül órákig gyűjtögettél volna ötleteket.

3. Amit te teszel hozzá: a kockázat és a prioritás

Van amit az AI nem tud, így nem tudod kiadni a kezedből. Az AI nagyszerűen termel mennyiséget, de egy dolgot nem tud: nem ismeri a te projekted valódi tétjeit.

Az AI nem tudja, hogy nálatok a fizetési modul ehyetlen hibája súlyosabb, mint az export táblázat tíz kinézeti, számítási és strukturális hibája. Nem tudja, melyik úton jár a felhasználók kilencven százaléka. Nem ismeri a szabályozási kockázatot, a korábbi éles hibák történetét, vagy azt, hogy melyik integráció szokott rendszeresen eltőrni.

Ezeket Te ismered:

  • Prioritás: a legenerált ötven esetből te döntöd el, melyik az a tíz, aminek mindenképp zöldnek kell lennie a kiadás előtt.
  • Kockázatalapú fókusz: te mondod meg, hol legyen az AI a legalaposabb, és mit nem érdemes egyáltalán tesztelni.
  • Hihető, de hibás esetek kiszűrése: a nyelvi modellnek nincs orákuluma, vagyis önmagától nem tudja, mi a helyes elvárt eredmény. Ha a specifikáció nem tér ki valamire, nem akad el, hanem magabiztosan kitalálja az elvárást. Ezt csak az veszi észre, aki érti a domaint. Épp ezért érdemes a promptban eleve nyitott kérdésként kigyűjtetni a hiányzó elvárásokat, ahogy a fenti sablon is teszi: a legértékesebb tesztelői munka sokszor nem a teszt, hanem a jó kérdés a fejlesztő felé, még a tesztelés előtt.

Más szóval: a prompt pontosan annyit ér, amennyi kockázati minta áll mögötte. Az AI a szélességet adja, te a mélységet ott, ahol számít. Erről, hogy mennyire bízhatunk meg a gép által generált esetekben, a AI által generált tesztesetek: mennyire megbízhatóak valójában? cikkünkben írtunk bővebben.

4. Egy fontos kikötés: mit enged a céged?

Mielőtt bármit bemásolnál egy AI-ba, tisztázni kell egy kérdést, ami nem technikai, hanem jogi és adatvédelmi. A teszteset generáláshoz ugyanis gyakran valódi követelményeket, belső dokumentumokat, néha éles vagy éleshez hasonló adatokat adnánk át egy külső szolgáltatónak.

Ebből több kérdés is fakad. Mennyire engedi ezt egyáltalán a céged szabályzata? Mennyire lehet és kell anonimizálni a bemenetet, mielőtt kimegy? Nem szivárognak-e ki belső, bizalmas információk egy nyilvános modellen keresztül? Ezekre a kérdésekre egy későbbi cikkben részletesen visszatérünk.

A lényeg viszont már most egyszerű: az AI-t teszteset generálásra csak akkor használd, ha ezt a céged kifejezetten engedi. A legjobb prompt sem ér semmit, ha közben megsérted a céges adatkezelési szabályokat.

Összegzés

A jó teszteset generálás három rétegből áll. A felszínen a prompt-minták vannak: a szerep, a kontextus, a formátum és a korlátok tudatos megadása. Alatta a munkamenet: bontsd részfeladatokra, és iterálj, ahelyett hogy egyetlen paranccsal próbálnál mindent kicsikarni. A legmélyén pedig az marad, amit a gép nem tud pótolni: a te kockázat- és prioritásérzéked.

Az AI egy gyors junior, aki fáradhatatlanul dolgozik, de nem tudja, hol a tét. Te vagy a senior, aki tudja, hova kell nézni. A jó prompt ennek a kettőnek a találkozása.

Megosztás

Kérsz értesítést a legújabb cikkekről?

Kapcsolódó cikkek

20 év szoftvertesztelés után ezt látjuk minden sikeres szoftverprojektben

Húsz év és több száz projekt után az ember már nem az egyedi eseteket jegyzi meg, hanem az ismétlődő mintákat. A legérdekesebb felismerés az, hogy a sikeres szoftverprojektek mennyire hasonlítanak egymásra. Más az iparág, más a technológia, más a csapat, mégis ugyanazok az elvek térnek vissza bennük, újra és újra. A kudarcok ezzel szemben mind

T&M vagy fix projekt? Melyik tesztelési modell mikor működik jobban?

Amikor egy cég külső tesztelési partnert von be, az egyik legkorábbi kérdés nem szakmai, hanem pénzügyi: milyen konstrukcióban dolgozzunk együtt? A válasz sokszor a beszerzési reflexből születik: „adjatok egy fix árat, hogy tudjam, mennyibe kerül”. Érthető igény, de nem mindig a legjobb döntés. A fix ár és a másik klasszikus modell, a T&M (Time and

Scroll to Top

Elérhető tesztelőink

Nézze meg szakértőink profiljait, tapasztalatát és kompetenciáit, és találja meg a projektjéhez illő szakembert.

2006 — 2026

20 ÉVES A PASSED!

20 éve a szoftverminőség szolgálatában.

Két évtized szakértelem, fejlődés és elkötelezettség a szoftvertesztelés mellett.

PASSED

Töltse le tesztelőink szakmai profilját

Adja meg elérhetőségét egyszer és férjen hozzá valamennyi elérhető profilhoz.