AI a tesztelésben: hogyan indítsunk pilotot, és mire jó valójában?

Egy pilot annyit ér, amennyire tervezhető és mérhető. Érdemes előre rögzíteni néhány alapvető elemet:

Eszközök. Válasszunk ki egy konkrét AI-eszközt és integrációs pontokat (nálunk ez a Claude a VS Code-on belül, Jira és a Testomat.io), és a pilot ideje alatt ne váltogassunk eszközt, így a tapasztalatok összehasonlíthatók maradnak.

Felelősségek. Tisztázzuk, ki fogalmazza meg a promptokat, ki vizsgálja át az AI által generált teszteseteket, és ki dönt arról, hogy egy generált elem bekerülhet-e a végleges teszt állományba. Ezt érdemes egy tapasztalt minőség biztosító kollégára bízni az elején, amíg nem forrja ki magát a folyamat, és nincsenek véglegesített promtjaink és egységesített skilljeink! Az emberi review lépés nem opcionális, ez a minőségbiztosítás egyik kulcseleme.

Időkeret. Egy pár hetes, jól lehatárolt időszak (pl. egy-két sprint) elég ahhoz, hogy érdemi mintát lehessen gyűjteni anélkül, hogy a csapat túlságosan elköteleződne egy még nem bevált munkamódra.

Mérési pontok. Érdemes már a pilot elején meghatározni, mit fogunk nézni a végén.
pl.: Mennyi időt spóroltunk? Hány generált tesztesetet kellett emberi beavatkozással módosítani? Hol bukott el az AI rendszeresen? Milyen pontossággal sikerült behatárolnia a teszteseteket? Ez csak pár példa, de az ezekhez hasonló kérdések kulcsfontosságúak lehetnek egy ilyen pilot projekt esetében.

Néhány dolog, ami nálunk nem működött elsőre:

1. Túl kevés kontextus a promptban. Ha csak a Jira ticketet adtuk meg a kód nélkül, az AI gyakran túl általános, a konkrét implementációtól elszakadó teszteseteket generált. Amint bekerült a tényleges kódrészlet figyelembe vétele is a promptba, a tesztesetek sokkal pontosabbak és relevánsabbak lettek.

2. A generált tesztesetek formátuma nem igazodott a Testomat.io elvárt struktúrájához. Az első körben sok manuális utánigazítás kellett, mire a generált kimenet formátuma illeszkedett ahhoz, ahogyan nálunk a teszteseteket tároljuk és kezeljük.

Ezek nem AI-specifikus problémák, hanem tipikus "új eszköz bevezetése" tapasztalatok, de érdemes előre számolni velük, hogy a csapat ne veszítse el a lendületet az első buktatóknál. Az első pár próbálkozás egészen biztosan nem fogja azt a kimenetelt hozni, amit elképzeltünk, (hacsak nem promtolunk tökéletesen), viszont erre a problémára létezik az ún. Reverse Promt Engineering technika, amit mi is sokszor alkalmazunk.
Ennek a lényege, hogy amikor nem egyből kapod meg a jó választ, hanem 4-5 lépésben, kérdésekkel és javításokkal terelgeted az AI-t, a folyamat végén megkéred, hogy írjon egy olyan promtot, amivel a kívánt eredményt egyetlen kéréssel elérted volna. Ez persze tokenekbe kerül, de csak egyszer, hiszen ha megvan a kívánt promt, ami egy kérésből teljesíti a korábbi 4-5 kérést, nem kell köbbet korrigálni.

Nálunk mára néhány elem beépült a napi rutinba. Elsőnek a Claude kiegészítő VS Code-ban. Amikor valaki egy Jira tickethez tesztesetet készít, vagy egy meglévő automatizált teszt mögötti logikát szeretné dokumentálni, vagy egy dokumentáció nélküli folyamatot szeretne megismerni, rendkívül hasznos partner. Önmagában már ez is sokat segít a tesztelésben. A teljes folyamatot viszont apránként érdemes kidolgozni, átgondolni, majd kis csoportokban tesztelni. Egy AI diven tesztelési flow sok kérdést vet fel, és sok lehetőséget lekell kezelni, ezért erre nincs egyértelmű recept, projekt és leginkább komplexitás függő.

A következő lépések, amiket mi is látunk magunk előtt:

• A pilot tapasztalatait dokumentálni.

• Tovább finomítani, mely tesztelési feladatokra érdemes AI-t bevonni, és melyekre nem (pl. ahol az emberi domain tudás vagy az üzleti kontextus ismerete nélkülözhetetlen).

• Az emberi review lépést megtartani. A cél nem az, hogy az AI helyettesítse a tesztelőt, hanem hogy a tesztelő ideje a valóban kritikus gondolkodásra szabaduljon fel.

Egy AI-pilot sikere nem azon mérhető, hogy mennyire volt tökéletes az első próbálkozás, hanem azon, hogy a csapat képes volt-e tanulni belőle, és fokozatosan, megalapozottan beépíteni a napi munkába.