Sinoć je održan još jedan meetup u seriji Cortex academy meetup-ova koji su prvenstvno namijenjeni polaznicima Cortex akademije, ali i svima onima koji žele da direktno od najboljih stručnjaka dobiju odgovore na sva pitanja i riješe nedoumice u vezi ICT zanimanja. 

Tema 4. Cortex Academy meetup-a bila je softversko testiranje, a o istoj je moderator Jovan Kovačević (CTO Coinis) razgovarao sa Markom Dragovićem (Testing Expert Amdocs) i Branom Bukilićem (CEO Data Design). 

Ukoliko nijeste bili u prilici da nam se pridružite na meetup-u, snimak istog možete pogledati na našem YouTube kanalu. https://www.youtube.com/watch?v=L9RgaGEPTJA

Ovaj meetup je obilježilo veliko interesovanje za kvalitetnu stručnu diskusiju i brojna pitanja. Zbog vremenskog ograničenja, nijesmo mogli dobiti odgovore na sva pitanja, ali naši gosti su na ista odgovorili u pisanoj formi, pa ih možete pronaći u nastavku blog posta: 

 QA Meetup – odgovori na postavljena pitanja

Marko: Dolje se može naći komparitivna tabela za sva 3 alata (Playwright, Cypress, Selenium).

Appium je popularan alat otvorenog koda koji se koristi za automatsko testiranje mobilnih aplikacija. Omogućava programerima da automatizuju testiranje izvornih ili hibridnih iOS i Android aplikacija. Appium ne radi sam. Pokreće test slučajeve koristeći interfejs WebDriver-a. Slično kao i Selenium, Appium omogućava testerima da kreiraju test skripte u više programskih jezika – Java, JavaScript, PHP, Rubi, Pithon i C#.

Appium je posebno omiljen zbog toga što je fleksibilan, višeplatformski okvir kojim se testeri mogu koristiti za kreiranje testnih skripti primjenljivih na više platformi (Windows, iOS i Android) – koristeći isti API. U suštini, korisnici Appium-a mogu ponovo da koriste svoj izvorni kod za Android kao i za iOS, čime se smanjuju vrijeme i trud.

CriteriaPlaywrightCypressSelenium
LanguageSupports multiple languages such as JavaScript, Java, Python, and .NET C#Supports JavaScriptSupports multiple languages such as Java, Python, C#, Ruby, Perl, PHP, and JavaScript
Test Runner Frameworks SupportedMocha, Jest, JasmineMochaMocha, Jest, Jasmine, Protractor, and WebDriverIO
Operating Systems SupportedWindows, Linux, and macOSWindows, Linux, and macOS 10.9 and aboveWindows, Linux, Solaris, and Mac OS
Open SourceOpen Source and FreeOpen Source and FreeOpen Source and Free
ArchitectureHeadless Browser with event-driven architectureExecutes test cases directly inside the browserLayered Architecture based on JSON Wire Protocol
Browsers SupportedChromium, Firefox, and WebKitChrome, Firefox, and EdgeChrome, Firefox, IE, Edge, Opera, Safari, and more
SupportSince Playwright is fairly new, the support from the community is limited as compared to SeleniumStrong community support from professionals across the world Provides commercial support for its users via its sponsors in Selenium Ecosystem along with self-support documents. Strong community support from professionals across the world 
Real Devices SupportDoes not support real devices for Mobile Browser Tests but supports emulatorsSupports real device clouds and remote serversSupports real device clouds and remote servers

Marko: Naravno. Programi za testiranje su svakodnevna potreba inženjera za testiranje. Neki od potrebnih alata za testiranje su : FileZill-a, Putty, Oxygen XML editor, Toad for Oracle, Testing Studio, HP ALM QC, Jira, Selenium kao i strogo interno razvijene alate koje kompanija interno razvija za potrebe testing tima uz pomoć testing tools developer-a.

Marko: Odgovor na ovo pitanje smo mogli čuti tokom prezentacije. Automatizovano testiranje se može u praksi sresti i primijeniti najviše u onim sistemima, djelovima sistema i funkcionalnostima gdje je u jedinici vremena nema puno zahtjeva za novim promjenama na istoimenim funkcionalnostima, odnosno, gdje je postignuta željena svrha i slijedi period stagnacije. Shodno tome automatizacija se može uraditi u punom mahu, mahom radi ispitivanja regresionih testova i izvještavanja da bi se utvrdilo da neke novo razvijene funkcionalnosti neće uticati regresiono na promjene već postojećih. Predložio bih korišćenje Selenium-a na bazi Python-a ili Jave, u zavisnosti od dalje potrebe/primjene.

Evo 5 najboljih praksi kako bi UAT proces bio efikasan:

Ključno je identifikovati ciljnu publiku i detaljno je poznavati i razumjeti koji su njeni problemi i potrebe. Na ovaj način neće biti gubljenja vremena na nešto što neće raditi. U vezi sa korisnicima, važno je odabrati stvarne i potencijalne korisnike za UAT. Razvojni tim ne bi trebalo da učestvuje u korisničkom testu. Povratne informacije koje se dobijaju od korisnika su veoma obogaćujuće jer im omogućavaju da vide greške i kreiraju buduća poboljšanja.

Plan testiranja (ponekad se naziva i QA test plan) može se posmatrati kao uputstvo za upotrebu ili vodič za napore testiranja. Opisuje ciljeve testiranja (šta planirate da verifikujete i/ili validirate), obim testiranja (šta će, a šta neće biti testirano), zajedno sa opštim i ponekad detaljnim rasporedom aktivnosti koje želite da izvršite. Kad god korisnici imaju problema ili pitanja, treba ih saslušati i pomoći im što je prije moguće. Takođe se preporučuje prisustvo tehnoloških partnera kako bi se problemi i ažuriranja rešavali kada se pojave.

Testni slučaj precizira radnu proceduru, očekivane rezultate i uslove koje tester treba da provjeri. To je osnovna dokumentacija potrebna da se utvrdi da li aplikacija ili jedna od njenih karakteristika funkcioniše kako je prvobitno planirano i željeno. Potreban je plan korak po korak. Ovo će služiti kao vodič za ljude tokom testiranja. Tako će biti koncentrisani na pravim mjestima. Važno je kreirati test slučajeve koji su dobro detaljni i koji daju jasnoću procesu. 

Važno je znati kako postupiti kada se pojavi greška. Kada se prijavi greška, potrebno je zabilježiti što je moguće više informacija, kako bi kasnije bilo lakše ponovo reprodukovati problem i riješiti ga.

Marko: SDET (Software Development Engineer in Test) u testiranju je IT profesionalac koji može da radi podjednako i efikasno i u ulozi razvoja i testiranja. SDET učestvuju u kompletnom procesu razvoja softvera kao i u procesu testiranja softvera. Znanje SDET profesionalaca je u potpunosti fokusirano na testiranje, robusnost i performanse procesa testiranja i razvoja softvera ujedno. Nisam primijetio da kod nas u CG postoji potreba za ovakvim kadrom. I da postoji, postavlja se pitanje o kome smo već razlučivali na sastanku, koliko bi on bio uspješan da pokriva i testiranje i development ujedno. Na duže staze mislim da ne.

5-a. Predlog za materijal (neformalnu edukaciju) kada je u pitanju usavršavanje u ovoj oblasti(za one koji nemaju značajnog iskustva)?

5-b. Imate li da predlozite neki materijal za edukaciju u oblasti testiranja? – naknadno (pitanje je došlo od senior full stack developera)

https://www.udemy.com/

The Complete 2022 Software Testing Bootcamp | Udemy 

ISTQB Foundation Level 2022 Complete Training | Udemy

Udemy pruža širok spektar kurseva iz oblasti osnova QA-a, manualnog testiranja kao i automatizacije. S’obzirom da su u periodima praznika cijene kurseva svega par eura, smatram da su i te kako povoljni za početak samostalnog učenja i usvajanja znanja. Mogu se naći takođe i kursevi vezani za Unix i DB koje smatram da svaki tester treba proći.

Marko: Da bi se vršila automatizacija testiranja moraju se znati Python ili Java za početak. U zavisnosti od problematike koja se automatizuje nivo programiranja može biti nizak pa i vrlo komplikovan. Tako da, osoba koja se odluči za automatizaciju, poželjno je da bude dobar programer. Često alati za automatizaciju koriste svoje template i možete djelove koda više puta koristiti uz minimalne prepravke ali opet treba znati kad i gdje se mogu koristiti i šta se mora prepraviti.

Marko: End To End Testing je metoda testiranja softvera koja potvrđuje cijeli softver od početka do kraja zajedno sa njegovom integracijom sa spoljnim interfejsima. Svrha end-to-end testiranja je testiranje čitavog softvera i njegovih zavisnosti, integritet podataka i komunikaciju sa drugim sistemima, interfejsima i bazama podataka kako bi se izvršio kompletan scenario sličan produkciji. Otuda i naziv „od kraja do kraja“. End to End testiranje se obično izvršava nakon funkcionalnog i sistemskog testiranja. Koristi stvarnu proizvodnju kao što su podaci i testno okruženje za simulaciju podešavanja u realnom vremenu. Ono je zastupljeno u potpunosti i predstavlja jednu od finalnih faza testiranja. Cypress i Selenium su open source alati za automatizaciju i u širokoj su upotrebi. Mislim da predstavljaju korektne alate za nekog ko želi da se počne baviti čistom automatizacijom. Na primjer, predložio bih učenje Selenium-a na bazi Pythona za početak. Na Udemy se mogu naći odgovarajući kursevi.

Marko: Plate testera su u glavnom manje od plata developera. Razlog je razumljiv. Developeri imaju veoma težak posao da razviju kompletan sistem od nule do pune funkcionalnosti i pri tome odrade integrativne modularne testove takođe. Shodno tome ne treba puno dalje pojašnjavati. Međutim, plate inženjera za testiranje koji su profesionalci/eksperti mogu se ponekad kretati u rangu višem od plata developera u zavisnosti od kompanije u kojoj ste pozicionirani i u zavisnosti koliko vi kao tester značite/doprinosti firmi. Postoje kompanije koje se bave samo testiranjem i u njima je moguće vrlo brzo napredovati i sa pozicijom kao i sa platama. Mogućnost napredovanja uvijek postoji i na vama je koliko ćete brzo to i ostvariti. Jedan savjet mogu dati na ovu temu a to jeste da kada mislite da zaslužujete unapređenje, morate to objelodaniti i boriti se za njega !

Marko: Bilježenje nepravilnosti se vrši u nekim od profesionalnih alata za praćenje i monitoring testnog izvršavanja kao što su to Jira ili QC. Ti alati u sebi posjeduju funkcionalnosti potpunog testnog životnog ciklusa problema od trenutka kad su oni prijavljeni do trenutka kad su riješeni i kada budu zatvoreni. Svaki problem se prijavljuje uz tačno definisana pravila i otvara se sa tačno definisanim komentarima/koracima. Neki od elemenata koje problem mora da ima u sebi kada se prijavljuje jeste tačno opisani koraci koji vode do problema, opis testnog okruženja, konekcioni detalji vezani za unix i DB, slike problematičnih djelova sistema kao dokaz problema. Definišu se očekivani rezultati kao i aktuelni rezultati. Takođe se postavlja i takozvani „severity“ vs „priority“ greške. Na kraju se problem alocira kroz sistem odgovarajućem odjeljenju za razvoj koji će ga riješiti. Testovi se izvršavaju manualno uz pomoć alata za testiranje.

Marko: Pisanje testova i testiranje je obaveza obije strane ali u različitim fazama testiranja. U modularnim (jediničnim testovima) kao i integracionim i ST-System Test fazama to je dužnost izvođača projekta i njegovog tima za testiranje. U fazi UAT-User Acceptance Test-a, klijent ima već spremne svoje testove i angažuje svoje testere za ispitivanje sistema. Često i sam izvođač vrši paralelne UAT testove kako bi preduprijedio nalaženje problema. Sve zavisi od međusobnog dogovora na kraju između klijenta i izvođača radova.

Marko: Testiranje od strane izvođača radova se ne smije vršiti direktno na produkcionom okruženju. Rad na produkcionom okruženju je isključivo nadležnost klijenta. Ukoliko je neophodan takav rad, priprema se okruženje koje je slično produkcionom sa kopiranim podacima iz originalnog produkcionog okruženja i na njemu se mogu vršiti testovi kako od strane izvođača radova tako i od strane klijenta.

Marko: Ovo pitanje smo razmatrali na meetup-u. Moguća su oba prelaza i uspješnost upravo zavisi od pojedinca i njegove sposobnosti prilagođavanja. Važi mišljenje da dobar tester može biti dobar developer jer zna kako da testira i pravi testne kalendare, poznaje cijeli sistem E2E i njegove slabosti i mane. Međutim, treba shvatiti jednu stvar, da kratkoročno ovo može dati dobre rezultate dok dugoročno tester kad postane developer on gubi vremenom sluh i hands-on iskustvo testiranja i onda gubi na samom kvalitetu testiranja. Na kraju bismo opet došli u početnu situaciju. Više sam za pravilo da tester treba biti tester do kraja, kao i developer da ostane developer.

Marko: Test Driven Development je tehnika razvoja softvera koja podrazumeva često testiranje napisanog koda. Test se piše prije koda, a nakon toga se piše izvorni kod koji treba da zadovolji test. Refaktorisanjem se taj kod dalje prečišćava i pojednostavljuje, ali osnovno je da test koji se jednom verifikovao mora da se iznova verifikuje, pri svim sljedećim izmjenama. To je tzv. jedinično testiranja (unit test). Ima smisla pisati testove ukoliko je to definisano ugovorom između dvije strane da bi se isti ispoštovao. U suprotnom nema smisla. Međutim ako klijent ipak zahtijeva mi moramo ispisati sve unit testove kako bi pokazali da smo pratili šemu iako u praksi to nismo uradili. Nekad moramo biti agilni i vršiti modifikacije i snalaziti se jer klijent ne zna način i pravila koja mi primjenjujemo pa može doći upravo do ovakvih situacija. Ovakve situacije se izbjegavaju na taj način da se unit testovi pišu na vrijeme od strane developera koji opet nemaju vremena za takve stvari od svojih regularnih obaveza. Rješenje može biti u traženju pomoći od strane testera da se uključi i piše unit testove umjesto developera jer tester bi to morao znati zasigurno. Unit testovi ne moraju bit sveobuhvatni u ovoj fazi, već samo koncentrisani na glavne funkcionalnosti modula.

  1. Da li možete predloziti neke dobre alate kada je u pitanju automatizacija testiranja (CI/CD) ? 

Jovan: ovdje bih predložio Gitlab CI/CD sa kojim mi u Coinisu imamo odlično iskustvo. Vi možete dopuniti.  Marko: slažem se. Selenium Python i Java imaju integraciju sa Gitlab-om.

  1. Da li će biti priče o performance ili security testiranju ? Da li u vašim firmama primjenjujete to i u kojem obimu ?

Marko: Na sastanku nije bilo priče o navedenim topovima testiranja jer oni ponaosob nisu bili tema. Naravno da je neophodno izvršiti testove performansi sistema kada funkcionalnost to zahtijeva. Nisu sve funkcionalnosti podložne detaljnom testiranju performansi. Lijep primjer za ispitivanje performansi sistema jeste kad se pravi funkcionalnost fajla koji u sebi sadrži parametre kojima se vršit neko plaćanje i taj isti fajl može imati neograničeno mnogo redova. Performanse se testiraju tako što se fajl bombarduje ogromnim količinama podataka i onda se puštaju procesi koji taj fajl kupe i obrađuju i shodno tome se mjeri vrijeme obrade podataka i dolazi do odgovarajućih problema. Često je bezbjednosno testiranje (security) posebna tema i pripada posebnom odjeljenju unutar odjeljenja za testiranje. Na isključiv zahtjev klijenta ono se vrši ukoliko klijent nema svoj tim i ne zahtijeva drugačije jer za ovaj vid testiranja klijent treba otvoriti svoje sigurnosne protokole ka nama što je često u suprotnosti sa njihovom bezbjednosnom politikom. Takozvani penetracioni testeri prolaze posebne obuke i sertifikate.

  1. Da li se rade samo testovi za kranje korisnike, tačnije samo ono što se desava na frontu, ili se takođe rade i testovi na backend sistemima, i tako brže prepoznali izvori problema?

Marko: Svaki testni slučaj koji se dizajnira i kasnije izvršava u sebi ima korake koji provjeravaju front-end i back-end zajedno ujedno sa operativnim sistemima i bazom podataka. Tako da se sve ove provjere izvršavaju za svaki testni slučaj ponaosob jer svako izvršavanje testa u front end-u i back-endu pravi različiti uticaj, kreira različite logove i u bazi upisuje različite vrijednosti i shodno tome se moraju provjeriti svaki put u jednom istom testnom slučaju ponaosob. E2E (end-2-end) testiranje je jedna od faza testiranja kada se na ovaj način ispituje cjelokupna funkcionalnost za svaki slučaj ponaosob.

Ukoliko ste zainterosovani za pohađanje kursa iz oblasti softverskog testiranja, postanite dio Cortex akademije! Pošaljite mejl sa ličnim podacima i informacijom o zainteresovanosti na contact@ictcortex.me a mi ćemo vam sa zadodoljstvom obezbijediti pristup dostupnim online kursevima besplatno i pomoći vam u daljem usavršavanju iz ove oblasti.