Amodo je hrvatski IT scaleup iz sfere InsurTecha. Glavni proizvod Amoda je Connected Insurance Platforma koja prikuplja podatke iz različitih izvora, objedinjuje ih i analizira u realnom vremenu. Amodova napredna tehnologija omogućuje osiguravajućim društvima da razviju nove kategorije proizvoda temeljene na bihevioralnim podacima, te svakom korisniku ponudi uslugu prilagođenu njegovom stilu vožnje.

Amodo je 2013. godine počeo kao startup, a danas broji oko 50-ak zaposlenika. Kroz godine su razvili veliku bazu klijenata, isporučili su više od 35 projekata na 6 kontinenata. Neki od Amodovih najpoznatijih klijenata su AIG, Porsche, BNP Paribas, a od nedavno i Croatia Osiguranje čiji je Amodo tehnološki partner na najnovijem produktu – LaqoPrevent.

.debug: Koji dio Amodo ekosustava je Analiza?

Budući da se nalazimo u vremenu bogatom podacima, razumijevanje kako analizirati i interpretirati podatke je jedan od ključnih procesa u Amodu. Potencijal analize je beskonačan, u Amodu primjerice analizom podataka možemo dobiti 360° viziju aspekata povezanih s našim krajnjim korisnicima, možemo razumjeti njihove demografske podatke, interese, navike, ponašanje u vožnji i još mnogo toga.

Dugoročno će to potaknuti uspjeh marketinških strategija, kao što su npr. prepoznavanje proizvoda koji se mogu nuditi pojedinim korisnicima. Iz perspektive upravljanja, analiza podataka pomaže našim klijentima pri donošenju važnih odluka temeljenih na činjenicama, mogu razumjeti kao uložiti kapital, predvidjeti prihode i rashode, utjecati na promjene ponašanja vozača na bolje, povećati sigurnost na cestama. Iz svega navedenog, očito je da je Analiza ključan dio Amodo ekosustava.

Na slici niže je prikaz geografskih lokacija testnih vožnji unutar jednog dana. Takve podatke koristimo za naš razvoj i testove.

.debug: Zašto je posebno izazovno testiranje analize?

Unatoč tome što su funkcionalnosti Analize pokrivene unit testovima posebno je izazovno testiranje njenog cjelokupnog ponašanja zbog toga što se između dviju verzija Analize mogu primijeniti vanjski faktori koji utječu na njene rezultate.

Značajni čimbenici na rezultate Analize su:

• Geografsko područje u kojem se skupljaju podaci
• Razlike u hardware-u i software-u na smartphone uređajima
• Kvaliteta kartografskih podataka – neke dionice puta mogu biti osvježene novim podacima
• Različiti izvori karata (map providers: HERE, OSM, Google Maps, Yandex Maps…)
• Radovi na cestama zbog kojih se mijenja ruta vožnje iako se izvorni podaci nisu promijenili
• Promjena ograničenja brzine na pojedinim dionicama
• Cestovna infrastruktura i razvijenost samog područja
• Pokrivenost internetom / GPS sustavom

Zbog svega toga postoji znatna varijabilnost u samim podacima o vožnji, pa je teško unaprijed znati kako će neka funkcionalnost utjecati na analiziranu vožnju ovisno o tim utjecajima.

.debug: Na koji način se Analiza prilagođava vanjskim utjecajima?

Zbog prethodno navedenih čimbenika koji utječu na njen konačan rezultat, ponašanje Analize mora biti vrlo fleksibilno i konfigurabilno. Postoji mnoštvo konfiguracijski opcija koje kontroliraju paljenje/gašenja nekih funkcionalnosti, promjenu redoslijeda obrade, definiranje korištenih izvora podataka, te izmjenu parametara korištenih u samim algoritmima obrade.

Velika količina mogućih konfiguracija dodatno otežava praćenje utjecaja promjena na nekoj od funkcionalnost i na sve potencijalne međuovisnosti. Stoga unit testovi ne mogu samostalno otkriti utjecaj neke izmjene na ponašanje cjelokupnog sustava, već je Analizu potrebno konstantno nadograđivati i ponovno testirati.

.debug: Koji dio Analize je najzahtjevniji za testirati?

Jedan od najzahtjevnijih dijelova za testiranje je izračun udaljenosti prijeđene u vožnji. Na taj izračun najviše utječe sustav koji sirove GPS podatke spaja sa stvarnim prometnicama. Sami GPS podaci podložni su raznim vrstama problema, od nepouzdanosti samog GPS senzora, različitih hardverskih komponenti (posebice u slučaju Android telefona), te neažurnih kartografskih podataka. Uz sve anomalije dobivene iz vanjskih izvora, taj dio sustav također mora bit agnostičan u dva bitna aspekta:

1. Izvora vožnji koji osim sa pametnih telefona, mogu biti prikupljeni od OBD uređaja ili dobiveni direktno od povezanih vozila koja ih prikupljaju sama
2. Izvor kartografskih podataka koji se mogu izmijeniti ovisno o željama klijenta

Postoje razni drugi dijelovi sustava koji pokušavaju popraviti te podatke poput detekcije lošeg spajanja na prometnice ili filtriranja GPS točaka koje imaju izrazito lošu preciznost. Naš zadatak je proračunati najtočniju moguću udaljenost krajnjem korisniku neovisno o ovim problemima. Svi ti problemi utječu na proračun ukupne prijeđene udaljenost, pa je stoga izrazito komplicirano za testiranje.

.debug: Na koji način testirati sustav?

Način na koji smo odlučili testirati sustav je pokrivanje pojedinih logičkih funkcionalnosti unit testovima kako bi osigurali da pojedine komponente rade potpuno isprave te statističkim integracijskim testom koji uzima u obzir sve kompleksnosti opisane u prethodnim poglavljima.

Skup testnih vožnji korištenih za integracijsko testiranje inicijalno smo stvorili odabirom onih vožnji za koje pouzdano znamo očekivano ponašanje, primjerice vožnje snimane od strane Amodo QA tima za koje imamo zabilježeno stanje odometra ili one vožnje za koje sigurno znamo da su snimljene drugim prijevoznim sredstvom.

Također set testnih podataka se konstantno nadopunjuje onim vožnjama za koje dobijemo prijavu od klijenata da su imale određeni problem, kako bismo bili sigurni da se isti problem neće pojaviti i u nekoj kasnijoj verziji Analize. Kako bi propisno testirali regresiju skup vožnji sadrži i neke slučajno odabrane vožnje bez problema za koje znamo da se ne smiju promijeniti između verzija Analize.

Kako bismo pojednostavili kreiranje skupa vožnji i njegovo konstantno nadopunjavanje, kreiran je sustav koji na jednostavan način omogućava Amodo administratorima dodavanje bilo koje vožnje u set za integracijsko testiranje.

Sami integracijski test Analize provodi se unutar CI/CD pipelinea. Inicijalni korak je stvaranje kopije produkcijske okoline sa njenom cjelokupnom konfiguracijom. Nakon toga se na u njemu procesira skup testnih vožnji. Svi dobiveni analizirani podaci o vožnjama se zatim spremaju u verzionirane tablice kako bismo znali koja verzija Analize ih je kreirale te kako bismo na jednostavan način mogli usporediti rezultate između dvije verzije Analize. Prije stvaranja nove inačice Analize, ovaj proces se ponavlja za svaku od produkcijskih konfiguracija. Time osiguravamo da će u svim mogućim instancama Amodo sustava Analiza i u novoj inačici raditi ispravno.

.debug: Kako se interpretiraju rezultati testa?

Nakon testiranja rezultati testiranja se mogu izvesti iz baze podataka. Standardni način za provjeru testa je statistička te potom vizualna usporedba zadnje dvije verzije Analize na istoj platformi. Sve razlike među podacima su vizualno označene nakon statističke analize, kako bi bile lako uočljive. Statistička usporedba se odnosi na pokretanja uparenog t-testa ili z-testa s ciljem testiranja neke hipoteze. Sustav će sam testirati hipotezu kako bi se uvjerili da nema promjene među verzijama Analize, dok se neke kompliciranije hipoteze mogu jednostavno dodati kroz vanjske skripte.

Testiranje hipoteza koristimo ponajprije za efikasno detektiranje regresija. Karte svijeta se mijenjaju na dnevnoj bazi, pa je standardna pojava da se proračunate udaljenosti mijenjaju među verzijama analize zbog promjena na kartografskim podacima unatoč tome što se analiziraju iste vožnje. Usporedni test hipoteze promjene omogućuje da s jednim brojem vidimo da li se razlike mogu pripisati šumu u podacima iz kartografskih podataka ili zaista postoji značajna razlika koju jedino možemo objasniti bugom ili promjenom u novoj inačici Analize.

.debug: Koliko vremena traje testiranje? Koje su najčešće greške koje otkriva?

Testiranje cijelog sustava traje nešto više od 2 sata uz dodatno vrijeme potrebno za pregled i analizu dobivenih rezultata. Testiranje se pokreće pri izdavanju svake pojedine verzije Analize.

Najčešće otkrivene greške su:

• Analiza i neki drugi dio sustava više nisu dobro integrirani na nekoj od platformi
• Konfiguracija analize na nekoj platformi s novom funkcionalnošću uzrokuje neočekivano ponašanje
• Dogodila se regresija među verzijama

Bez ovakvog sustava testiranja sve ove greške vjerojatno ne bi bile primijećene na vrijeme, odnosno bile bi primijećene tek od strane krajnjih korisnika – što je najskuplja moguća greška. Ovim sustavom osiguravamo da su zadovoljni naši krajnji korisnici, ali istovremeno osiguravamo lagodno stanje uma našim developerima koji znaju da imaju sustav koji će uloviti eventualne pogreške koje se neminovno događaju pri razvoju softvera.

Više o Amodu poslušajte na .debugu…