Az MI több tesztelői erőforrást követel

Minden felkapott téma sorsa, hogy hiába hangsúlyozzák az előnyöket, idővel a használat alatt egyre szaporábban felbukkanó negatívumok is előkerülnek vele kapcsolatban.

Rájár a rúd az AI-ra

Miközben már a legtöbb terméket és szolgáltatást a mesterséges intelligencia hívószavával próbálnak eladni a kereskedők, az idő előrehaladtával látszik, hogy még nagyon gyerekcipőben jár a technológia.

Egyik portálon arról olvashatunk, hogy a Google nálunk még nem elérhető MI-t és keresést egyesítő terméke, az AI Overview éppen ragasztót ajánl a pizzára, hogy a sajt stabilabban álljon rajta, illetve kőevést javasol, mivel az sok vitamint és ásványi anyagot tartalmaz, (LINK) majd a következő pillanatban szembe jön a hír, miszerint egyes szoftverfejlesztő társaságok szembefordultak az AI programozási felhasználásával, azzal indokolva a lépésüket, hogy az általában pontatlan kódot generál.

MI alkalmazásának ellenzése

Már több nyílt forráskódú projekt ellenzi az MI alkalmazását a kódgenerálás területén. A Gentoo és a NetBSD egyenesen megtiltotta, ugyanakkor a Debian egyelőre a kivárásos stratégiát alkalmazza a kérdésben. (LINK)

A Gentoo három fő problémát emel ki, amivel indokolja az NLP AI eszközök tiltását:

  • Első helyre sorolja a szerzői jogi aggályokat, miszerint jelenleg világszerte még kialakulóban vannak a létrehozott tartalmakra vonatkozó szerzői jogi szabályozások. Az így születő produktumok használata a szerzői jogok megsértésének veszélyét hordozza magában.
  • Megemlíti a minőségbeli aggályokat is, ugyanis a népszerű nagy nyelvi modellek (LLM, LINK) igazán jók abban, hogy hihetőnek tűnő, de valójában értelmetlen tartalmakat készítsenek. Ez egyrészt a projektek minőségromlásának kockázatát jelenti, másrészt azt, hogy a fejlesztőktől tisztességtelen emberi erőfeszítést követelnek meg az AI használatából eredő hibák feltárása érdekében.
  • Végül pedig etikai aggályokat hangsúlyoz a cég. Szerintük a kereskedelmi mesterséges intelligencia-projektek gyakran szembetűnő szerzői jogsértéseket követnek el modelljeik képzése érdekében, valamint az AI-modellek reklámozása és használata jelentős károkat okozott az alkalmazottaknak, és az LLM-ek megkönnyítették a spam- és átverési trükkök alkalmazását. (LINK)

A programozók idejük kétharmadát, nem kódolással töltik

Ugyanakkor egy hangzatos cikkben arról olvashatunk, hogy a fejlesztők idejük jelentős részét nem kódolással töltik. (LINK)

Az erősen PR szagú cikk interjúalanya, Jyoti Bansal, a Harness alapítója arra próbálja felhívni a figyelmet, hogy a kódolás utáni munka, mint a tesztelés, a telepítés, a biztonság kérdése, az irányítás és az egyezkedés mind a fejlesztői munka rovására megy. A cikkből nem egyértelműen vehető ki, hogy mire gondol, de a szakember cégének termékoldalán körülnézve egyértelműsödik mondandója, miszerint a fejlesztők rengeteg eszközzel dolgoznak egyszerre, ezért sok idő megy el a felületek közötti váltásokkal, meg kell tanulniuk a különböző munkafolyamatokat, és külön fiókokat és licenceket kell kezelniük. „Ez zavartsághoz, kognitív túlterheltséghez és a fejlesztési környezet következetesség hiányához vezethet.” (LINK) Jól kivehető, hogy valójában a saját – állítása szerint egyszerűbben kezelhető – termékét promótálja, de ettől függetlenül mindenképpen töprengésre késztető a gondolatmenete.

Az interjú egy pontján viszont egy nagyon érdekes kijelentést tesz a mesterséges intelligencia és a tesztelés vonatkozásában. Felhívja a figyelmet, hogy az AI segíthet például egy meghiúsult telepítés okainak feltárásában, ezzel levéve a fejlesztők válláról az időigényes problémakeresést, log-böngészést. Ugyanakkor az MI hibázási rátája miatt nagyobb teret kényszerülünk engedni a következő generációs ellenőrzéseknek. A mesterséges intelligencia segítségével megspórolt kódgenerálási és hibanyomozási idő egy részét, a tesztelés hangsúlyosabbá tételére kell fordítanunk.

„A minőségbiztosítás szerepe még fontosabbá válhat, mint a fejlesztő szerepe az AI világában. A mesterséges intelligencia meg tudja írni a kódot, de az embernek érvényesítenie kell és ellenőriznie kell, hogy működik-e.” – teszi hozzá Bansal. (LINK)

Láthatóan az AI tiltásával szemben ez is a lehetőségek között szerepel a fejlesztés számára. A több hibát tartalmazó generált kód kitesztelése valóban időigényesebb a megtalált hibák kezelése, majd javítás utáni újratesztelése miatt. Összességében elképzelhető, hogy kevesebb programozói munkát, de nagyobb tesztelői erőforrást jelent ennek a megoldásnak az alkalmazása. Ezen a ponton egy érdekes fordulatra lehetünk figyelmesek: míg ugyanis nem olyan régen még azt a kérdést hallhattuk, hogy az AI ki fogja-e váltani a tesztelői munkát, most már inkább arra a kérdésre szeretnénk választ kapni, hogy mennyivel nagyobb hangsúlyt kell helyeznünk a minőségbiztosításra az elkövetkező időkben.

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.

Töltse le tesztelőink szakmai profilját

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