Bevezető
A szoftvertesztelés területén az elmúlt években jelentős változásokat hozott a mesterséges intelligencia térhódítása. Egyre több eszköz jelenik meg a piacon, amelyek az AI technológiát ígérik megoldásként különböző tesztelési kihívásokra. De vajon ezek az eszközök tényleg beváltják a hozzájuk fűzött reményeket? Képesek-e hatékonyan segíteni a tesztelők mindennapi munkáját?
Új cikksorozatunkban górcső alá vesszük a legígéretesebb AI-alapú tesztelési eszközöket. Minden eszközt alaposan megvizsgálunk, gyakorlati szempontból értékelünk, és őszinte véleményt formálunk a használhatóságukról, hatékonyságukról és valós értékükről a tesztelési folyamatban.
Ebben a cikkben a TestCraft platformot vesszük nagyító alá. Ez az eszköz azt ígéri, hogy az AI segítségével leegyszerűsíti és felgyorsítja a tesztesetek létrehozását és karbantartását. A cikkben részletesen bemutatjuk az eszköz képességeit, kipróbáljuk a gyakorlatban, és megosztjuk tapasztalatainkat, hogy pontosabb képet kaphassatok arról, mire lehet számítani az eszköz használata során.
A cikk hosszúsága miatt a cikket két részletben mutatjuk be
Mit igér a TestCraft?
A TestCraft egy ingyenes és nyílt forráskódú böngésző kiegészítő, amely a szoftvertesztelési munkát hivatott támogatni.
A weboldala: https://home.testcraft.app/
A dokumentáció alapján képes:
- Egy felhasználó által kijelölt képernyő területen megtalálni, hogy milyen felületi objektumok vannak.
- A megtalált objektumokra teszteket írni.
- Az általunk kiválasztott generált tesztesetekből automatizálni Playwright, Cypress, vagy Selenium eszközökre Javascript, Typescript, Java, C#, vagy Python nyelven.
Az eszköz alapból használja az openAI gpt-4o-mini modeljét, de lehetőség van saját szerveren futó model használatára is.
A vizsgálat kritériumai
Egy AI támogatott teszteszköz vizsgálati kritériumait nem egyszerű feladat meghatározni. A vizsgálat célja kettős: egyrészt az eszköz gyakorlati használhatóságának felmérése, másrészt a hagyományos tesztelési módszerekkel való összehasonlítása. Nyilván a végső cél az, hogy el tudjuk dönteni, hogy használható-e tényleges munka támogatására, vagy „többe kerül a leves, mint a hús”, és a technológia még nem áll ott, hogy valós projekten is megállja a helyét. Ennek eldöntése érdekében a kínált funkciókat össze kell vetni a jelenleg használt eljárásokkal és minőségi, valamint időbeli összehasonlítást végezni a kettő között.
Minőségi szempontok
A minőség gyakran szubjektív megítélés alá esik. Az AI által generált tesztek minőségének a megállapítása bizonyos szempontból szubjektív lesz, ugyanakkor igyekszünk néhány mérhető értékre is kitérni.
Technikai szempont
Az esetek többségében technikailag nem mindegy, hogy milyen fejlesztői keretrendszert használtak az oldal létrehozása során, így minden esetben érdemes többféle alkalmazást is megvizsgálni.
Tesztelés szakmai szempontok
Megvizsgáljuk, hogy milyen követelménylefedettséggel dolgozik az eszköz. Mennyi jó, mennyi rossz tesztesetet generál. Generál-e negatív utas esetet. Van-e olyan, amikor egy követelményt nem fed le teljesen.
Megnézzük azt is, hogy a generált tesztek mennyire olvashatók, mennyire strukturáltak, mennyire használhatók fel újra.
AI „jósága”
Vannak olyan mutatók, amikkel egy-egy AI megoldást szoktak mérni. A könnyebb emészthetőség érdekében ezeket a mutatókat nem tüntetjük fel és nem számoljuk ki. Ehhez egy külön, AI metrikákat magyarázó cikkre lenne szükség. Azokat a következtetéseket, amik a mért eredmények alapján meg lehet tenni, a mutatók nélkül is le tudjuk vonni.
Használt oldalak
Két, eltérő technológiájú és komplexitású oldalon vizsgáljuk meg az eszközt.
Egyszerűbb oldal
Az alábbi oldalon található egy regisztrációs űrlap:
https://parabank.parasoft.com/parabank/register.htm
Ennél az oldalnál nincs szükség további információra. Könnyedén kitalálható a felületről a működése a felületi elemek ismeretében.
A továbbiakban, mint az „egyszerű oldal” hivatkozunk rá.
Bonyolultabb oldal
Tekintettel arra, hogy valószínűleg a frontend kód, illetve annak szövegezése (label, címke, hint) képezi az alapját az AI által használt információknak, így az esetleges hibás működést olyan weboldallal lehetne legjobban előhozni, aminél ezekből nem feltétlenül kideríthető a helyes működés.
Erre az alábbi oldalon található kereső felületet fogjuk használni: https://www.bardiauto.hu/webshop/cikkszam/kereso
Itt járműalkatrészeket lehet vásárolni. A kereső felület pedig ebben nyújt segítséget. Alapból a cikkszám kereső fül az aktív, de van további 4 „füle” a keresőnek: alvázszám, személy, teher, motor. Értelemszerűen az alvázszám füllel alvázszám alapján megtalált típushoz lehet alkatrészeket keresni, a személy, teher és motor füllel személyautó, teherautó vagy motor adható meg, majd további legördülőkkel kereshetőek hozzájuk alkatrészek. Ezek fontos információk lesznek az összevetésnél.
A továbbiakban, mint a „bonyolult oldal” hivatkozunk rá
Felületi objektumok meghatározása képernyő kijelöléssel
Ez a funkció csak közvetve vizsgálható, mert alapból a generált tesztek azok, amikből kiderül, hogy pontosan milyen elemet hagyott ki az eszköz vagy vett észre.
Kritérium
- Azt várjuk el, hogy minden objektumot megtaláljon a kijelölt területen, az egyszerű és a bonyolultabb oldalon is.
Tesztírás a megtalált objektumokra
Ennél a funkciónál érdemes az eredményt összevetni azzal, hogy egy manuális tesztelő milyen teszteket írna a felületre.
Továbbá érdemes megjegyezni az ehhez szükséges időt is, mert biztosan lesz átfedés a gépi és emberi esetek között, így megtudjuk, hogy mennyi időt nyertünk a géppel és mennyi idő megy el az esetleges korrekciókra.
Kritériumok
- Generált esetek „valid”-sága százalékosan. (Nem valid 0%, félig valid 50%, valid 100% súlyozással)
- Minőségben való eltérés AI és ember által írt tesztesetekben.
- Lefedettségben való eltérés AI és ember által írt tesztesetekben.
Időben való eltérés AI és ember által írt tesztesetekben. (generálás + emberi korrekció)
Kiválasztott esetek automatizálása
Mivel a TestCraft által nyújtott automatizálási eszköz-nyelv mátrix eléggé széleskörű, így a vizsgálatot a manapság népszerű Playwright-Python párosra korlátozzuk.
Talán ennél a funkciókörnél a legnehezebb az összevetés, hiszen ahány tesztelt alkalmazás, annyiféle problémába lehet belefutni automatizálás során.
Lássunk néhányat:
- Dinamikus ID-al felruházott objektumok egyéb információk nélkül. Ebben az esetben nagyon nehéz jó lokátorokat írni az objektumokra.
- Semmilyen információ nincs arra, hogy az oldal készen áll-e a következő interakcióra. Ebben az esetben egy túl korai kattintás fals hibához vezethet.
- Olyan objektumok lekezelése, melyek csak néha jelennek meg.
Az alapos vizsgálat elengedhetetlen feltétele, hogy a fentiek tükrében az eszközt „nehezített pályán” is megvizsgáljuk. Így ebben az esetben egyéb oldalrészleteket is meg fogunk nézni.
A kritériumok ezeknek megfelelően
- Generált kód formázottsága
- Generált kód szervezettsége
- Lokátorok minősége
- Objektumokra való várakozás kezelése
- Alkalmanként megjelenő objektumok lekezelése
Időbeni különbség emberi automatizmushoz képest + korrekciós idő
Egyszerű oldal vizsgálata
Objektumok megtalálása
Kijelöljük a regisztrációs űrlapot:
A területen található és megtalált objektumok:
- 1 oldalcím ✔
- 1 tájékoztató üzenet ✘ (Erre az objektumra nem gondolt.)
- 11 mező ✔
- 1 gomb ✔
- 1 nem látható hibaüzenet objektum (egységesítés esetén) ✔
- + 1 üzenet a sikerességről??? ✘ (Ez az objektum nem létezik az oldalon. A következő oldalon sem.)
Amennyiben eltekintünk a nem létező objektumtól, a megtalálási siker: 93,3%
Generált tesztek
Az alábbi tesztek lettek generálva:
- Verify that the user can successfully submit the registration form with valid inputs for all fields.(*)
- Check that the „Signing up is easy!” message is displayed prominently when the registration page loads.(*)
- Ensure that the form provides appropriate feedback (e.g., success message) after a successful registration.(*)
- Validate that the email confirmation link is sent to the user after registration.
- Confirm that all input fields accept valid data formats (e.g., correct character limits for names, valid phone number format).(*)
- Attempt to submit the form with empty fields and verify that appropriate error messages are displayed for each required field.(*)
- Input invalid data formats (e.g., letters in the Zip Code field) and check that the system rejects the submission with a clear error message.(*)
- Enter a password that does not meet security criteria (e.g., too short) and ensure that the form does not submit and provides feedback.
- Test the scenario where the „Confirm Password” field does not match the „Password” field and verify that an error message is shown.(*)
- Try to submit the form with an invalid SSN format and ensure that the system rejects it with a specific error.
- Simulate a user filling out the form using a screen reader and assess whether all fields are accessible and properly labeled.
- Test the form submission using a mix of valid and invalid data to see how the system handles partial submissions.(*)
- Check the behavior of the form when a user attempts to submit it multiple times rapidly (e.g., doubleclicking the submit button).
- Assess the responsiveness of the form on different devices (e.g., mobile, tablet) to ensure that all fields are usable and legible.
- Explore the scenario where a user navigates away from the form and then returns; verify if the previously entered data is retained (if applicable).
Színjelölések:
- piros: azon tesztek, melyeknek semmi értelmük nincs
- kék: valid tesztek lehetnének, de tartalmaznak félig fals információkat, vagy nem megértett működést
- zöld: megfelelőnek ítélt tesztek
Tesztek validsága: 80%
Minőségben való eltérés manuális tesztíráshoz viszonyítva:
- A tesztek 1-2 sorosak. Nem tartalmaznak lépéseket.
- A tesztekben írt információ nagyon kevés. Az AI valószínűleg a Front End HTML kódból próbálja kitalálni a működést, így ezek az információk teszteseteket eredményeznek, de látszik, hogy valójában nem tudja, hogy ezen elemek között milyen ügyféllogika húzódik meg.
pl.: Invalid adatmegadásra generált összevont tesztet, de nem tudja azt, hogy vajon mi számít invalid adatnak az egyes mezőknél. Ezt manuálisan kell pótolnia a szakembernek.
Lefedettség (szubjektív megítéléssel)
A generált tesztek közül 8 db az, amely
- valid
- értékelhető tesztesetként
- a tesztelt funkcionalitás tapasztalat alapján megfelelő kockázatú funkciót fed le
Átböngészve a generált teszteket, az alábbiakat hiányolom hasonló kontextusban:
- Minden kihagyott kötelező mezőre külön teszteset hibaüzenet ellenőrzéssel (10db)
- Oldalcím alatti szöveg ellenőrzése. (1db)
- Már létező felhasználóval történő sikertelen regisztráció (1db)
Ez azt jelenti, hogy a lefedettség 40%.
Befektetett idő
AI esetén nem kell külön magyarázni az idő rövidségét. A generálás kb. 3 másodpercig tartott.
Annak ellenére, hogy az esetek nincsenek lépésszinten kidolgozva, az emberi befektetett időt ugyanennyi tesztre kb. 2-3 órának saccolom egy tényleges projekten megszakítás nélküli munka esetén. (Abból kiindulva, hogy az ember próbálgat, specifikációt elemez, különböző eszközöket vesz igénybe közben, stb stb..)
Ha az AI által generált eseteket veszem alapul és megnézem, hogy azt egy szakember átnézi, valamint lépésszinten kidolgozza, akkor mint korrekciós idő, kb. 1-1,5 órára jön ki.
Röviden:
- AI: 3 másodperc
- Szakember: 2-3 óra
- AI+korrekció: 1-1,5 óra ✔
Félúton
Idáig jutottunk. Egyelőre azt láttuk, hogy a kiválasztott AI eszköz segítségével, ha rendes munkát akarunk végezni, a harmadára, felére csökkent a munkaidőnk. Ez jól hangzik, de egyrészt ez csak egy egyszerűbb oldalra vonatkozik, másrészt az automatizálási képességét még nem vizsgáltuk meg. A következő héten megnézzük ugyanezeket a bonyolultabb oldal esetében is és megvizsgáljuk az automatizálási képességeket és az eszközről az összefoglaló következtetésünket is ott tesszük majd közzé.
Addig is: Jó tesztelést! Hajrá! 🙂
