Įžvalgomis apie svarbiausias testavimo tendencijas ir iššūkius, kurie technologijų sektoriaus laukia kitais metais, pranešime žiniasklaidai dalijasi IT įmonės „Devbridge“ (priklausančios „Cognizant Softvision“ kompanijai) naujasis Testavimo praktikų vadovas Justas Laužadis, kuris bus atsakingas už kompanijos testavimo praktiką ir modernių testavimo principų taikymą, kuriant pažangius IT sprendimus.
1 tendencija. Augantys lūkesčiai programinių sprendimų kokybei
J. Laužadis pabrėžia, kad skaitmeniniai sprendimai vis dažniau ne tik nukonkuruoja, tačiau ir priverčia verslus visiškai atsisakyti analogiško fizinio sprendimo, tad daugėja skaitmeninių paslaugų poreikis, o kartu su juo auga ir vartotojų lūkesčiai programinės įrangos sprendimų kokybei.
„Skaitmeniniai sprendimai genda, kartais klaidų nepavyksta išvengti tiesiog dėl kompleksiškos prigimties, sudėtingų procesų ar skubėjimo, o kartais koją gali pakišti trečiosios šalies programinės įrangos atnaujinimas ar tiesiog blogas oras. Priežasčių gali būti labai įvairių, tačiau kai gedimas įvyksta ir yra pastebimas, pirmiausia siekiama jį pašalinti, kad sistema vėl galėtų funkcionuoti ir sklandžiai tiekti paslaugą. Čia pasidaro labai svarbus sistemos atstatymo laikas, nes būtent tiek laiko verslas ar institucija praranda savo funkciją, o naudotojai negali pasiekti paslaugos.
2 tendencija. Automatizavimo taikymas
Anot J. Laužadžio, testų automatizavimas ir automatinis verifikavimas tikrai nėra naujiena programinės įrangos inžinerijos pasaulyje. Stebint Lietuvos testuotojų rinką, per pastarąjį dešimtmetį automatizavimo įgūdžiai smarkiai sustiprėjo.
„Jei prieš dešimtį metų vos vienas, kitas testuotojas gebėjo automatizuoti, dabar tai sugeba daryti dauguma specialistų. Prie to prisidėjo ne tik auganti rinka, tačiau ir nauji bei tobulėjantys įrankiai. Tačiau sėkmingam automatizavimo procesui reikia ir daugiau komponentų. Moderniuose programinės įrangos vystymo procesuose kodo pakeitimai atkeliauja sąlyginai nedideliais gabaliukais, bet dažnai. Kadangi automatinių testų paskirtis – patikrinti, ar kodo pakeitimai nesugadino svarbiausių programos savybių ir funkcijų, todėl automatiniai testai taip pat turi būti pritaikyti dažnam naudojimui.
Tikruose projektuose tam tikra automatinių testų imtis gali būti vykdoma ir šimtus ar daugiau kartų per dieną. Tam, kad galėtų būti dažnai vykdomi, jie turi būti greiti, stabilūs ir patikimi. Stabilumas dažniausiai nepasiekiamas nuo pirmosios dienos, tačiau jeigu testai leidžiami dažnai, per laiką pavyksta „išgaudyti“ net ir retai pasikartojančias klaidas.
Kalbant apie greitį ir patikimumą – tai jau priklauso nuo paties techninio sprendimo. Yra daug skirtingų technikų, kaip tai pasiekti, tačiau dažnai pati testuojamoji sistema diktuoja, kas tinka, o kas ne. Sėkmingi automatizavimo taikymo pavyzdžiai formuoja specialisto gebėjimų lūkesčius. Tačiau itin svarbu, kad tie testai būtų kuo plačiau naudojami, kad duotų greitą ir patikimą vertinimą apie svarbiausias programos dalis“, – akcentuoja IT įmonės atstovas.
3 tendencija. Nykstanti riba tarp testavimo ir programavimo
J. Laužadžio teigimu, kartu su programinių sistemų modernizavimu, sistemos dalių skaidymu į atskirus modulius, servisus ir kitus komponentus, dažnai auga ir automatizuotų testų sprendimų sudėtingumas. Norint išleisti atskirus servisus nepriklausomai nuo kitų, reikia sugebėti juos testuoti tiek izoliacijoje, tiek integracijoje, tada tenka galvoti apie įvairių priklausomybių ir testavimo duomenų valdymą.
„Negana to, kiekvienam servisui (kurių gali būti 10 ir daugiau) reikia atskirų automatizuotų testų sprendimų, o šie neretai gali skirtis savo konfigūracija. Dar prie viso paveikslo pridėkime pasakymą, kad „testų kodas yra lygus programos kodui, tad tikimės aukščiausios kodo kokybės“ ir jau galima įsivaizduoti techninių įgūdžių lūkesčius. Tačiau testuotojai nepaliekami vieni – programuotojai aktyviai padeda arba patys rašydami kodą, arba peržiūrėdami testuotojų kodą, palikdami atitinkamus komentarus, patardami, kaip ką nors aprašyti tiksliau, paprasčiau. Kaip ir programuotojai peržiūri testuotojų kodą, lygiai taip pat ir testuotojai peržiūri programuotojų kodą.
Kartais klaidas programos kode galima atlikti tiesiog patikrinus naują logiką kode, ypač, kai pakeitimų nėra daug. Taip pat, galima atkreipti dėmesį į parašytus automatinius testus. Ar jie apskritai parašyti? Ar užtenka padengimo? Ar visi svarbiausi atvejai paminėti? Net ir iki šiol testuotojai kiek ilgiau padirbėję komandoje gana aiškiai pajusdavo, kuris programuotojas pateikia kokybiškesnį kodą, o kuris palieka daugiau defektų, o dabar, testuotojams vis geriau suprantant kodą ir programavimo niuansus, dažnai net galima parodyti konkrečius trūkumus kode. Manau, gana aiškiai juntama, kad iš testuotojų, ypač dirbančių su automatiniais testais, ir ateityje bus tikimasi vis gilesnių programavimo žinių, o iš programuotojų – testavimo“, – akcentuoja J. Laužadis.
4 tendencija. Nefunkcinių sistemos savybių testavimas
Anot J. Laužadžio, vis dar pasitaiko atvejų, kai programinės įrangos saugumo biudžetas yra peržiūrimas tik po saugumo incidento. Saugumas, greitaveika, prieinamumas ir kiti nefunkciniai reikalavimai dažnu atveju vis dar gauna gerokai mažiau dėmesio nei naujos funkcijos ar esamų patobulinimai. Arba yra pavedami atskiram skyriui ar išorinei kompanijai, kad šie atliktų atitinkamą auditą.
„Dažnu atveju tokio audito rezultatai programinės įrangos komandai atrodo paviršutiniški, nes auditorius tiesiog neturi tiek resursų, kad įsigilintų į sistemos logiką tiek, kiek tai galėtų atlikti pati programinės įrangos komanda. Paradoksalu, tačiau funkciniai ir nefunkciniai reikalavimai yra glaudžiai susiję – funkciniai reikalavimai savyje dažnai neša daug nefunkcinių rizikų. Ar sistemos dizainas saugus? Ar sistemos naudotojas negali pasiekti svetimų duomenų? Ar sistema veiks sklandžiai, jei duomenų bus (daug) daugiau? Ar skirtingi naudotojai galės pasiekti sistemos dalis, kurias turėtų galėti pasiekti? Šie ir kiti panašūs klausimai apie nefunkcines sistemos savybes egzistuoja ir dažnai yra aktualūs nepriklausomai nuo to, ar kas nors juos įgarsina. Įgudęs specialistas jau nagrinėdamas reikalavimus, kai sistema dar nėra sukurta, bet vien žiūrėdamas į prototipą jau galės pasakyti, kad tam tikru atveju gali kilti problemos. Manau, viena iš testuotojo užuočių – užduoti šiuos ir panašius klausimus, ieškoti atsakymų, eksperimentuoti, tyrinėti produktą ir, sukaupus daugiau žinių apie sistemą, užduoti naujus klausimus.
Jau dabar juntama tendencija, kad norėdamos dažnesnės ir labiau su produkto logika susijusios informacijos komandos investuoja į automatinio audito įrankius bei tikisi nefunkcinių sistemos savybių testavimo iš savo testuotojų. Išoriniai auditai išlieka, bet kadangi jie vyksta rečiau (dažniausiai net rečiau nei leidžiamos naujos versijos), didžiąją dalį problemų ar bent kritiškiausias problemas siekiama rasti ir išsispręsti savarankiškai dar iki kito audito“, – pabrėžė IT specialistas.
5 tendencija. Pritaikymas mobiliesiems įrenginiams
J. Laužadis akcentuoja, kad interneto naudojimas mobiliuosiuose įrenginiuose jau penkerius pastaruosius metus viršija naudojimą kompiuteriais ir ši tendencija turėtų išlikti ir ateityje. Todėl atsižvelgiant į tai, reikėtų jau dabar vis daugiau fokusuotis į programinės įrangos pritaikymą mobiliesiems įrenginiams.
„Jeigu iki šiol pritaikymas mobiliesiems eidavo iš paskos, t.y. pirmiausiai sukuriamas prototipas kompiuterio ekranui, o tik po to pritaikoma siauresniems mobiliems ekranams, tai tikėtina, kad atkreipus dėmesį į mobiliųjų vartotojų auditoriją šis procesas gali apsiversti. Analogiškai, daugiau dėmesio turėtų būti skiriama programos mobilios versijos testavimui ir įvairių mobiliųjų įrenginių testavimui. Tiesa, dažniausiai kalbėdami apie mobiliuosius įrenginius mes pirmiausia pagalvojame apie mobiliuosius telefonus, tačiau kuriant, vystant ir testuojant produktą siūlyčiau nepamiršti ir kitų išmaniųjų įrenginių – planšečių, išmaniųjų laikrodžių, televizorių ir kitų įrenginių, kurie dažnai gali praplėsti vartotojo patirtį“, – įžvalgomis dalijosi Testavimo praktikų vadovas.
6 tendencija. Dirbtinio intelekto pasitelkimas
Pasak J. Laužadžio, dažnai dirbtinis intelektas ar mašininio mokymo algoritmai profesinėse srityse vertinami gana skeptiškai ir su baime būti pakeistiems ir išstumtiems. Kartais jie tikrai gali būti naudojami vietoje kažko ir pilnai pakeisti tam tikrą sistemos ar proceso dalį, tačiau kartais geriau dirbtinį intelektą naudoti tik kaip asistentą ir galutinį sprendimą palikti specialistui.
„Testavimo srityje šie algoritmai naudojami jau seniai, tačiau pritaikymas vis dar nėra platus. Paprastai testavimo cikle randama kokia nors pasikartojanti problema, kurią mašininio mokymo algoritmas galėtų išspręsti, na, ir ji išsprendžiama. Vienas iš pavyzdžių – automatizavimo įrankiai su automatiškai pasitaisančiais lokatoriais – kas gana sėkmingai komerciniuose įrankiuose išsprendė siaurą, bet pasikartojančią problemą. Platesnėms testavimo problemoms svarbu giliai suprasti produkto kontekstą ir šis įsigilinimas į produkto kontekstą (ar produktą pasaulio kontekste) ir yra žmogaus pranašumas prieš mašininio mokymo algoritmus.
Vis dėlto, neseniai mane nustebino keletas ChatGPT taikymo atvejų, kai šis įrankis pakankamai sėkmingai sugeneravo gana logišką testavimo scenarijų sąrašą, prieš tai šiek tiek nupasakojus algoritmui produkto kontekstą. Plačiame kontekste šis įrankis tikrai gali duoti naujų idėjų ir padėti išeiti iš mąstymo aklavietės, tačiau siaurinant ir detalizuojant užduotį, vis dar įveliama daug logikos ar net matematinių klaidų. Taigi, sakyčiau, iki testuotojo pakeitimo dar toli, bet kaip asistentas kartais gali būti naudingas jau dabar.
Kita vertus, mašininio mokymo algoritmai kaip ir bet kurie kiti vertinimą ar konkretų atsakymą grąžinantys įrankiai (taip pat ir automatiniai testai) visada reikalaus priežiūros ir tikrinimo, ar jų grąžinamas rezultatas esamame kontekste vis dar logiškas. Tad prieš paliekant bet kokį algoritmą veikti savarankiškai reikėtų labai gerai apgalvoti, kaip jis bus tikrinamas – ar tai atliks koks kitas automatinis procesas, ar visgi prireiks periodiško specialisto įsikišimo. Akivaizdu, kad panašių dirbtinio intelekto pritaikymo atvejų tik daugės ir specialistai su mielu noru naudos tuos, kurie nereikalaudami daug laiko ar kitų resursų sukurs jiems bent kažkokią apčiuopiamą vertę. Po kurio laiko jau nebeišskirsime to kaip dirbtinio intelekto algoritmų, kadangi tai taps tiesiog automatizavimo dalimi“, – prognozuoja specialistas.
7 tendencija. Nuo kokybės prie vertės
J. Laužadis pabrėžia, kad kokybės užtikrinimo srityje labai svarbu mokėti pamatuoti kokybę, kai įvedant naujas funkcijas ar kitus pakeitimus kokybinės metrikos išlieka atitinkame lygyje arba yra gerinamos.
„Kiek tenka pastebėti, testuotojai Lietuvoje jau kuris laikas vengia arba labai atsargiai vertina „tuštybės metrikas“ ( angl. „vanity metrics“), tokias kaip atliktų testų kiekis, atitinkame procese rastų defektų kiekis, sistemos padengimas testais, ir t.t., kas gal ir apibūdina įdėta darbą, tačiau iš principo nėra tiesiogiai susiję su galutine produkto kokybe. Kalbant apie patį produktą iš inžinerinės pusės, komandos dažniausiai seka ir produkto technines metrikas – servisų pasiekiamumą, atsakų trukmes, resursų naudojimo metrikas, kadangi tai yra pirmieji indikatoriai, jei kuri nors sistemos dalis jau dabar neveikia ar veikia neteisingai.
Tačiau pačios sistemos dažniausiai yra kuriamos žmogui. Pagrindinis tikslas, kad vartotojas lengvai įsitrauktų, rastų reikalingą informaciją ar prekę, intuityviai atliktų norimus veiksmus ir visos veiksmų sekos metu nejaustų diskomforto dėl nesklandaus sistemos veikimo. Pamažu inžinerinės komandos supranta, kad verslo rodikliai ir su tuo susijusios vartotojo patirties bei įsitraukimo metrikos turi būti esminė programinės įrangos kūrimo proceso ašis. Kurti vertę verslui, tuo pačiu saugant kokybę, techninio sprendimo lygyje.
Taip pat vis plačiau taikomas eksperimentinis metodas – turint aiškias metrikas, ką norima pagerinti, keliama hipotezė, kad vienoks ar kitoks pakeitimas turėtų pagerinti atitinkamą rodiklį. Pavyzdžiui, vis daugiau specialistų pradeda taikyti A/B testavimą, kuris reikalauja šiek tiek investicijų į inžinerinius sprendimus, gana didelės auditorijos ir valios, nes tikrai neretai hipotezės nepasiteisina ir tenka atmesti naujus sprendimus. Vis dėlto džiugu, kad vis daugiau programinės įrangos komandų atsigręžia ir į verslo rodiklius bei vartotojų įsitraukimo metrikas, prašo prieigos prie šių rodiklių, siekia remti ir pagrįsti inžinierinius sprendimus atitinkamais duomenimis“, – teigė Testavimo praktikų vadovas.