Mi van a folyamatos tesztelésen túl? MI

Minden feladatot kétféleképpen lehet megcsinálni. Az ember vagy belead mindent és szívvel-lélekkel áll hozzá, vagy “csak letudja”. Az elsõ esetnél általában nyitott, befogadó személyiséggel találkozunk aki érdeklõdik a feladat iránt és gondolkodik a megoldásokon. Lelkes és motivált a szakmája iránt. Számomra õk a “gondolkodó” tesztelõk

Az MI adatokat, számítási teljesítményt és ezeken túl algoritmusokat igényel. Algoritmusaink régóta vannak, de most, a nagy adathalmazok (big data) és a hatalmas számítási teljesítmények korában fordulóponthoz érkeztünk.

Az MI megvalósíthatósága nem jöhetett volna jobbkor. Ma a Digitális Zavar (Digital Disruption) arra készteti a vállalatokat, hogy villámgyorsan fejlesszenek. Szükségünk van erőforrásokat szentelni arra, hogy minél nagyobb fogyasztói értéket tudjunk előállítani, miközben folyamatosan növelnünk kell működésünk gyorsaságát, rugalmasságát. Ellenkező esetben egy napon arra ébredünk, hogy bár semmi „hibát” nem követtünk el, mégis valahogy vesztésre állunk – lásd Nokia.

Aki a szoftverkészítésért felelős, tudja, hogy a szoftverfejlesztés és -a sikeres szállítás hagyományos módszerei már nem elegendők az új igények kielégítéséhez. Nem sokkal ezelőtt, a legtöbb vállalat évente, kétévente vagy negyedévente adott ki új szoftver verziókat. Mostantól az iterációk általában legfeljebb 2 hétig tartanak. Miközben a szállítási ciklusidő csökken, a pozitív felhasználói élmény biztosításához és a versenyelőny fenntartásához szükséges technikai összetettség növekszik – ahogyan az a sebesség is, amivel ezeket az újításokat kell bevezetnünk.

A szoftvertesztelés terén ezek a versengő erők szakadékot hoznak létre. Ma azzal szembesülünk, hogy a szakadék áthidalásához a folyamatos tesztelést kezdtük el alkalmazni. De hogyan teszteljük, amikor ezek a trendek idővel folytatódnak és a szakadék egyre csak tágul? Elkerülhetetlenül szükséges túllépni a folyamatos tesztelésen.

A pozitív felhasználói élmény növeléséhez olyan további segítségre lesz szükségünk, mint a gyors szállítási sebesség és a magas technikai összetettség.

Jó úton haladunk, hogy elérjük a folyamatos tesztelést. A klasszikus tesztelés havonkénti (vagy néha éves) szoftverszállítási ciklusra volt tervezve. Az Agilis kéthetes norma szerinti fejlesztési iterációkat adott ki – de most még többre van szükség ahhoz, hogy megfeleljen a mai gyorsan változó szoftver iránti igényeknek. A folyamat további felgyorsítására irányuló kísérletek ki vannak téve a fejlesztés, teszt és műveletek közötti szakadéknak. A gyorsítás érdekében ezt a szakadékot a DevOps és a Folyamatos tesztelés bevonásával kellett áthidalni. Ma a szervezetek túlnyomó többsége a folyamatostesztelés mellett voksol, és megpróbálja azt megvalósítani.

Mindazonáltal világosan látszik már most, hogy a folyamatos tesztelés sem lesz elegendő. Segítségre van szükségünk.

Digitális Tesztelésre van szükség a nagyobb gyorsaság elérése és a jövő minőségi igényeinek kielégítése érdekében, az IoT, a robotika és a kvantumszámítás bevezetésével. Az MI, amely az intelligens emberi viselkedést imitálja a gépi tanuláshoz és a prediktív elemzéshez, segítségünkre lehet célunk elérésében.

Mi az MI?

Mielőtt alaposabban megvizsgálnánk az MI szerepét a szoftvertesztelés szintlépésében, térjünk vissza és vizsgáljuk meg, mi az MI valójában?

Forrester definíciója szerint az MI:

Egy kódolással, üzleti szabályokkal és egyre inkább öntanuló képességekkel rendelkező rendszer, amely képes kiegészíteni az emberi megismerést és tevékenységeket, természetes módon kommunikál az emberekkel, de megérti a környezetet is, megoldja az emberi problémákat és emberi feladatokat lát el.”

Más érdekes definíciója az MI-nek:

Egy olyan tanulmányi terület, amely lehetővé teszi a számítógépek számára a tanulást anélkül, hogy kifejezetten programozva lennének.

Az MI egyik legfontosabb pontja az, hogy nem szükséges explicit módon programozni az algoritmusokat. Algoritmusokat minden bizonnyal használnak, de ezeket nem egy külön probléma explicit megoldására tervezték. A gépek képesek tanulni és ehhez adatokat használnak.

MI alkalmazása a szoftver tesztelésre

A növekvő műszaki bonyolultsággal történő, gyorsuló szállítási sebességgel felmerülő kihívásoknak való megfelelés érdekében egy nagyon egyszerű felhívást kell követnünk:

Tesztelj okosabban, ne keményebben

Például, fontoljuk meg, hogy egy következő szinten a képfelismerés hogyan lenne használható az UI-teszteléshez úgy, hogy a dinamikus UI vezérlők (pl. reszponzív weboldalak) automatikusan felismerhetők legyenek minden különböző alakzatra és űrlapra vonatkozóan.

Az UI-vezérlőket már emberi nézőpontból is felismerhetjük, az egyszerű sablon-egyezésen túl. Az UI pixelszerkezetei értelmezhetők képminták azonosságainak megtalálásával és információ azonosítással, úgymint szöveg (text). Például, az él érzékelése használható gomb (button) vezérlőelem azonosítására és az OCR / GDI rétegek használhatók gomb szöveg (button text) azonosítására.

Az MI használatával a szoftvertesztelő eszköz megtanulhatja, hogyan azonosítson be vezérlőelemeket a szkennelés és a teszt végrehajtása során, függetlenül a vezérlő méretétől, színétől, szöveg elrendezésétől stb. A tanulási megközelítés egy fajtáját alkalmazza: általánosított képeket új képminták hozzáadásával, valamint már meglévők adaptálásával hoz létre a szkennelés és a teszt végrehajtása során.

Minden vezérlő gomb ismeri a saját helyét a grafikus interfészen, a rögzítő azonosítón (anchor ID) keresztül. A vezérlő tulajdonságokra a képminták utalnak, továbbá ezeket a vezérlő tulajdonságokat bizonyos vezérlők (pl. görgetősáv – scrollbar) automatizálásának a korlátozására is fel lehet használni a teszt végrehajtása közben. Ez kiküszöböli annak a szükségességét, hogy a vezérlői tulajdonságokat a technikai implementációjukból kelljen felismerni.

A tanulás végeredményeképpen lehetővé válik az ismételhető és stabil tesztfuttatás még a reszponzív felhasználói felületeken is. Ez lesz az UI tesztautomatizálás következő lépcsőfoka.

Nem MI – De vajon ez mit jelent?

Az MI hívószót, státuszának köszönhetően, túl gyakran alkalmazzák a hihetetlenül izgalmas és értékes újításokban, de ez nem igazi MI, mert az önképzés tulajdonsága hiányzik. Az öngyógyító (Self-healing) technológiák például ebbe a kategóriába tartoznak.

Ennek egyik legérdekesebb példája az a technológia, amely futási idő alatt módosítja (out-of-sync) a hibára futott teszteseteket. Általában többféleképpen lehet azonosítani azt a vezérlőt (például egy gombot), amit automatizálni szeretnénk. Minden vezérlő rendszerint azonosítható egy technikai tulajdonság által, például azonosító (ID), név (name) stb. Sok esetben a tulajdonságok többszörös beállításai redundánsan egyediek egy vezérlőnek. Például, feltételezzük, hogy 3 azonosítóból 2 régebben azonosított egy adott vezérlőt, amit nem tud többé azonosítani. Ha a 3 azonosító közül csak 1 a még mindig aktuális, az öngyógyító technológiát használhatjuk a vezérlő azonosítására, valamint módosíthatjuk a másik 2 azonosítót.

Nem vitatom e technológia értékét. Valójában ez egy olyan dolog, amit a Tricentis cégnél fejlesztettek ki, és saját szemükkel látták, hogyan szabadítja meg a tesztelőket változó alkalmazások esetén a folyamatos teszteset frissítések nyűgétől. Mégis, annak ellenére, hogy a nevében az “ön” szócska szerepel, az öngyógyító technológiát fejlett algoritmusok vezérlik, ezért ez nem öntanulás. Ez nem MI. Ez az, amit kognitív tesztelésnek lehet nevezni. Ennek ellenére elsődleges példája annak a fajta innovációnak, amelyet a digitális tesztelés követelményeinek ki kell elégíteni a folyamatos tesztelésen túl.

Forrás: https://sdtimes.com/ai/whats-beyond-continuous-testing-ai/ 
Szerző: Wolfgang Platz