Programinės įrangos kokybės klausimas išlieka aktualus ne tik iš vartotojų, testavimo specialistų, bet ir iš kitų IT profesionalų, todėl ši sritis jau kelerius pastaruosius metus vis sparčiau juda į priekį. IT produktų kokybė tampa ne tik testuotojų, bet ir kitų IT specialistų atsakomybe, todėl testuotojams daugiau darbų tenka atlikti glaudžiai bendradarbiaujant su programuotojais.
Programinės įrangos kokybės klausimas išlieka aktualus ne tik iš vartotojų, testavimo specialistų, bet ir iš kitų IT profesionalų, todėl ši sritis jau kelerius pastaruosius metus vis sparčiau juda į priekį.
IT produktų kokybė tampa ne tik testuotojų, bet ir kitų IT specialistų atsakomybe, todėl testuotojams daugiau darbų tenka atlikti glaudžiai bendradarbiaujant su programuotojais.
Asociatyvi „Pixabay“ nuotr.
Dėl to nuolatinis specialistų tobulėjimas ir modernus testavimo principų taikymas taps neišvengiama testuotojų kasdienybe ir kitais metais, svariai prisidėsianti prie IT produktų kokybės gerinimo.
Esminėmis šių metų testavimo tendencijomis dalijasi IT įmonės „Devbridge“ (priklausančios „Cognizant“ kompanijai) testavimo praktikų vadovas Justas Laužadis.
Dirbtinio intelekto pasitelkimas
Anksčiau dirbtinis intelektas ar mašininio mokymo algoritmai profesinėse srityse vertinami gana skeptiškai ir su baime būti išstumtiems. Tačiau kiti metai taps dirbtinio intelekto proveržio metais.
Testavimo srityje dirbtinio intelekto pritaikymas, kaip ir visur tampa vis aktualesnis. Tačiau labai svarbu suprasti, kad dirbtinis intelektas negali veikti be žmogaus priežiūros.
Jis bent jau kol kas reikalaus priežiūros ir tikrinimo, ar jo sukuriamas rezultatas esamame kontekste vis dar logiškas. Dirbtinio intelekto veikimas ir su tuo susijusios problemos kelia aibę pasitikėjimo klausimų, kas gali tiesiogiai trukdyti suprasti kokybinius klausimus, o tai savo ruožtu trukdyti sprendimų priėmimui.
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 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.
Ką labai svarbu suprasti ir dėl ko specialistai sutaria yra tai, kad įvaldžius atitinkamus dirbtinio intelekto įrankius, galima pasiekti žymiai geresnių rezultatų beveik visose srityse, nei be jų.
Dėmesys mobiliesiems įrenginiams
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 apsiribodavo pirmiausiai sukuriamu prototipu kompiuterio ekranui, o tik po to pritaikoma siauresniems mobiliems ekranams, tai šis procesas pamažu vis labiau keičiasi. Dėl to daugiau dėmesio turėtų būti skiriama programos mobilios versijos ir įvairių mobiliųjų įrenginių testavimui.
Tiesa, dažniausiai kalbėdami apie mobiliuosius įrenginius pirmiausiai 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į.
Automatizavimo svarba
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. Tačiau itin svarbu, kad tie testai būtų kuo plačiau naudojami, kad duotų greitą ir patikimą vertinimą apie svarbiausias programos dalis. Sėkmingi automatizavimo taikymo pavyzdžiai formuoja ir toliau formuos specialistųo gebėjimų lūkesčius, o tuo pačiu ir diktuos tendencijas rinkoje.
Blunkanti riba tarp testavimo ir programavimo
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.
Išliekantys lūkesčiai programinių 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.
Taigi, toliau sparčiai plėtojamas paslaugų skaitmenizavimas skatins skirti vis daugiau dėmesio skaitmeniniams sprendimams, jų kokybei, ypač tų paslaugų, kurios nebeturi kitos alternatyvos. Visgi visų klaidų išvengti nepavyks – tad kritiškai svarbių paslaugų tiekėjams vis didesnę svarbą įgis atsistatymo strategija, o kartas nuo karto vis išlendantys gedimai toliau edukuos tiek specialistus, tiek naudotojus apie tai, kurios gi paslaugos mums kritiškai svarbios, o kurios ne.
