Oni su stručnjaci za kvalitetu robota, a ovako se njihov posao razlikuje od “klasičnog” QA

U razvoju robota nemoguće je spriječiti baš sve greške – kako smo saznali u prethodnom intervjuu s Gideonovim stručnjacima, pitanje je samo na kojem će se sustavu pojaviti, u kojoj fazi i koliko će biti skupe. Briga o kvaliteti tijekom nastanka jednog robota zato im je neizmjerno bitna. Jedino održavanjem kvalitete na svakom dijelu tog procesa mogu utjecati da neminovne greške što manje kompromitiraju razvojni ciklus.

Osim toga, nova tehnologija poput Gideonovih robota mora zadovoljiti najviše kriterije sigurnosti i pouzdanosti kako bi bila razmotrena kao alternativa postojećim poslovnim modelima.

U Gideonu zato svi usko surađuju s Quality Assurance timom koji je zadužen za osiguranje kvalitete softverskog stacka na robotu odnosno Quality Control timom koji je zadužen za kontrolu kvalitete robotskog hardvera i hardverskih komponenti. Oni su ljepilo koje spaja i osigurava da svaki dio u procesu razvoja jednog od njihovih robota bude na visokoj razini različitih zahtjeva.

Kvaliteta nije samo set kriterija koji treba zadovoljiti…

U Gideonu intenzivno rade na novim tehnologijama koje će omogućiti povećanje efikasnosti i ukupnog kapaciteta poslovanja modernih lanaca opskrbe, stoga su ulagali posebnu pažnju da procese osiguranja kvalitete integriraju u razvojni proces, pojašnjava Petar Mateljak, njihov Senior Product Operations Manager:

Odavno ne razmišljamo o kvaliteti kao setu kriterija koje je potrebno zadovoljiti na kraju razvojnog ciklusa nego nastojimo unaprijed promišljati sve njene aspekte i ugraditi ih u tehničke zahtjeve na kojima rade naši timovi.

Gideon trenutno ima dva robota oko kojih grade cjelokupna robotska rješenja za prijevoz materijala u skladištima i industrijskim okruženjima. To su Casey koji automatizira i optimizira proces komisioniranja robe i Trey, robot čiji je zadatak automatsko istovarivanje i utovarivanje kamionskih prikolica. Casey i Trey se konstantno poboljšavaju i unaprjeđuju što uključuje niz testiranja kako u simuliranom, tako i u stvarnom okruženju.

Iako su oba robota namijenjena radu u skladištu, njihova funkcija je drugačija – a time je i proces testiranja veoma različit pojašnjava Ivana Trstenjak, Senior Quality Control Engineer u Manufacturing odjelu Gideona.

Osim sigurnosnih testova – te testova sučelja koje koriste krajnji korisnici – koji su dobrim dijelom isti, svi ostali testovi su drugačiji. Dok će Casey tijekom testiranja proći kroz mnogo krugova komisioniranja (picking process) koji će simulirati stvarnu interakciju robota i ljudi i procese prikupljanja robe u skladištu, kod Treya je bitno da se puno puta prođe kroz testove u kojima robot autonomno istovaruje i utovaruje prikolicu, uz razne izmjene scenarija kod svakog testa.

“Klasični” vs robotički QA

Osim razlika u testiranju pojedinih proizvoda, tu je niz specifičnosti koje obilježavaju ispitivanje i kontrolu kvalitete u robotici. Iako je sam proces vrlo sličan “klasičnom” Quality Assuranceu, znanja i tehnologije su vrlo različite. Uz to, Petar dodaje kako roboti moraju funkcionirati u stvarnom, kaotičnom svijetu, u skladištima i industrijskim okruženjima u kojima se paralelno odvijaju različiti procesi u kojima sudjeluju ljudi.

Dok se u “klasičnom” QA-u testiranje gotovo u potpunosti može provesti u simuliranim uvjetima, za robote je zadnji test uvijek u stvarnom svijetu. Razlog tome je što kaotičnost stvarnosti često uzrokuje situacije koje nije moguće simulirati ili je trud potreban da se simuliraju veći od rada potrebnog da se test provede u stvarnosti.

Osim razlika, neke stvari vrijede u oba svijeta. Poput činjenice da je kvaliteta krajnji cilj i odgovornost svih uključenih u razvoj proizvoda te da je važna kvalitetna komunikacija koja to treba omogućiti. A identični su i QA principi…

Definicija kvalitete, gotovosti, testna strategija, testni plan i izvještaji su isti kao i u “klasičnom” QA-u.

Kako to izgleda u praksi?

Kao i u softverskom svijetu, kad su u pitanju softverske značajke robota, u Gideonu se oslanjaju na preporuke agilnog načina rada odnosno na Scrum metodologiju. Prema tome, QA tim je uključen u proces razvoja robota od samog početka – definiranja novih funkcionalnosti. Quality Assurance Team Lead Matija Bosnić navodi kako im to pomaže da kreiraju preciznije zahtjeve za razvojni tim i unaprijed povećaju vjerojatnost uspješnosti u zadovoljavanju izlaznih testova.

Tijekom svakog sprinta, QA testira nove funkcionalnosti, potvrđuje njihovu kvalitetu (feature testing) te ukazuje na probleme koji su nastali, ako ih ima. To testiranje može i ne mora uključivati: feature, security, safety, API i integration testiranje. Nakon završetka razvoja, funkcionalnost se dodaje u već gotovi proizvod te se još jednom detaljno testira kroz regresijsko testiranje koje mi nazivamo “System Level Testing”. Cilj tog testiranja je potvrditi potpunu funkcionalnost cijelog proizvoda nakon nadogradnje.

Posljednji korak je tzv. “User Acceptance Testing” (UAT) koji odrađuju s nekim od njihovih partnera gdje žele potvrditi funkcionalnost u korisničkom okruženju, što im je iznimno važan korak. Naravno, prilikom UAT-a osigurava se minimalno remećenje produkcije kod korisnika.

Na lokaciji kupca QA ima “nadzornu” ulogu. Bilježimo statistike, greške, nelogičnosti i situacije koje do tada nismo vidjeli ili predvidjeli. Iznimno, pomažemo ekipi na terenu za što glađe puštanje u rad nove funkcionalnosti edukacijom korisnika tijekom rada.

Uz Quality Assurance softvera tu je i Quality Control hardvera

Proces ispitivanja kvalitete s hardverske strane u Gideonu se odvija pod jurisdikcijom Quality Control odjela. Razvoj hardverskih funkcionalnosti također vode kroz sprinteve, a tijekom svakog sprinta vrše se detaljna testiranja i mjerenja kako bi se vidjelo zadovoljava li funkcionalnost potrebne zahtjeve. Ivana pojašnjava kako kod malo kompleksnijih hardverskih komponenti, primjerice baterije, ili vision modula (stereo kamere), testiranja u pravilu traju duže i prati se njihovo stanje tijekom određenog vremena i određenih uvjeta (tvz. endurance testing).

Sam tijek procesa kontrole kvalitete u Gideonu odvija se kroz tri faze, pojašnjava Ivana:

Prvo se obavlja ulazna kontrola komponenti, provjera jesu li dostavljene prema dizajnu koji su napravili razvojni timovi te komunikacija ili prema dobavljačima ili prema hardverskim dizajn timovima (Mechanical Design, Electrical System Design i Embedded Systems Design) oko kvalitete dizajna i dostavljenih komponenti poput matične ploče, powerboarda, harnessa, žica i ostalih komponenti.

Nakon ulazne kontrole, slijedi nam međufazna kontrola, odnosno provjera kvalitete proizvodnje proizvoda i nadzor proizvodnje. Kad je određeni broj hardverskih komponenti sklopljen, vrši se kontrola tog dijela proizvoda.

I na kraju imamo završnu fazu kontrole kvalitete hardvera koja se radi kad je robot u potpunosti hardverski sklopljen. Nakon toga se radi komisioniranje – upload softverskog stacka, završne hardverske kontrole i osnovno funkcionalno testiranje, primjerice provjera vozi li robot ravno, funkcioniraju li mu kotači, daje li stereo kamera sliku i ostalo.

Suradnjom do kvalitete

Petar dodaje kako inženjerske razvojne timove i QA tim promatraju kao samostalne cjeline koje mogu isporučiti funkcionalnosti bez krutih formalizama primopredaje između različitih organizacijskih jedinica.

Kako sam već spomenuo, QA članovi tima su izuzetno važni sudionici razvojnog procesa jer svojim prisustvom i aktivnim sudjelovanjem u definiranju funkcionalnosti osiguravaju potpuno razumijevanje očekivanja korisnika (koje donosi product management) i postavljanje metrika (kriterija kvalitete) koje će biti korištene u potvrdi funkcionalnosti.

S druge strane, Quality Control tim, surađuje s kolegama iz Manufacturing odjela, s timovima za sklapanje robota te s odjelom Nabave oko možebitnih reklamacija prema dobavljačima, popratnih informacija o kvaliteti dostavljenih komponenti i slično. Potom surađuju i s kolegama iz hardverskih razvojnih timova: Embedded System Design, Electrical Design i Mechanical Design – oko povratnih informacija o dizajnu hardvera. A na kraju, i sa samim QA timom.

Male (robotske) pobjede

Za kraj našeg razgovora, upitala sam Davida i Ivanu da mi kažu više o svojim iskustvima u Quality Assuranceu odnosno Quality Controlu. Davida kao QA inženjera najviše veseli uspješno puštanje u rad nove funkcionalnosti koja radi kako je očekivano. Samo nešto malo niže na ljestvici zadovoljstva, dodaje, je sreća kada pronađu kakvu “sočnu bubu” koju mogu prijaviti developerima na popravak.

Time znamo da smo upravo spriječili crvenjenje pred našim korisnicima i svima u procesu uštedjeli novac i, najvažnije, vrijeme… Iako naši proizvodi moraju zadovoljiti rigorozne sigurnosne standarde, stvarnost je da su naši roboti i dalje vrlo robusni komadi hardvera i zato je jako važno detaljno testirati one dijelove sustava koji bi mogli predstavljati sigurnosne izazove.

Nastavno na to, razumljivo je da i Ivanu u Quality Controlu najviše u njezinom poslu veseli kad sve faze kontrole kvalitete prođu bez greške – što je zbog kompleksnosti sustava prava mala pobjeda, zaključuje.

Da bi brže i lakše došli do tih pobjeda, Gideon je u potrazi za novim kolegama – o otvorenim pozicijama možete više saznati na njihovim stranicama karijera!