Susanna Kekkonen
Sähköautot ovat erinomainen esimerkki ohjelmistojen ulottumisesta paikkoihin, joissa ne eivät ennen olleet. Ohjelmistot niissä ovat lisäksi niin monimutkaisia, että niiden testaus aiheuttaa uudenlaisia haasteita. Autoilukin on nykyään ohjelmistojen käyttämistä. Pääsin sukeltamaan kunnolla sähköautojen maailmaan saatuani lopulta oman ensimmäisen sähköautoni.
Tilasin sähköauton vuonna 2021 syksyllä. En tässä mainitse merkkiä; asiat pätevät kyllä kaikkiin merkkeihin. Puolitoista vuotta myöhemmin sähköauto lopulta saapui. Sitä oli hidastanut Ukrainan sota, koronapandemian sivutuotteena syntynyt komponenttipula ja yleinen sähköautobuumi ja lopulta vielä erinäiset lakot.
Epäonninen toimitusketju kuitenkin kannatti – sähköauto on erinomainen peli. Se mullistaa käyttökokemuksen ja käyttökustannukset. Ikävä kyllä se myös tuo bugeja käyttäjän elämään. Onneksi niistä kuitenkin pääsee yleensä yli ”Microsoft-korjauksella” eli buuttaamalla auto tai sen osajärjestelmä (vaikkapa infotainment). Eikä bugeja ole paljon: 99 prosenttia ajasta homma kyllä toimii.
Sähköauton käyttäjälle näkyvät bugit tuntuvat isoilta, koska niihin hukkuu silloin omaa aikaa. Kuitenkin kuin testaajana suhteuttaa ne kokonaisuuteen, niin pikkuvikojana ne yleensä ovat. Kerran itselläni kaikki äänet hävisivät, niin radiosta kuin puhelimen yhteydestä autoon. Infotainment-järjestelmän uudelleenkäynnistys auttoi.
Testaajana luokittelisin tällaisen bugin pikkuviaksi. Kaksi kertaa hätäyhteysjärjestelmä on tipahtanut päältä, nähtävästi GPS:n hävitessä, jolloin auto on käskenyt menemään huoltoon. Kuitenkin auton uudelleen käynnistys auttoi heti.
Testaajana luokittelisin tämänkin bugin pikkuviaksi, enhän ole moneen kymmeneen vuoteen tarvinnut mitään hätäyhteysjärjestelmää. Auton valmistaja kuitenkin luokittelee asian turvallisuuskriittiseksi ja suosittelee huollossa käyttämistä. Kuukauden päästä vienkin auton huoltoon.
Ohjelmistot yleensäkin ovat siirtyneet DevOpsin myötä yhä enemmän jatkuvaan julkaisuun. Sähköautojen kohdalla, myös omani, käyttöön on tätä varten otettu OTA-päivitykset (over-the-air). Selvästi tosin vain pienempiä päivityksiä tehdään OTA:n kautta. Tällöin auto kertoo, että pienen päivityksen kohdalla voit kuitata sen tehtäväksi ajaessa ja vähän isomman kohdalla sinun pitää pysäköidä auto ensin. Vielä isompiin, riskipitoisiin päivityksiin auto halutaan huoltoon, jotta ongelmien sattuessa huolto voi tehdä toimenpiteitä. Riskipohjaista julkaisustrategiaa – testaaja sisälläni tykkää!
Sähköautojen testauksessa käyttäjille jää osa testauksesta. Harkittua tai ei, pikkuvikoja valuu käyttäjien raportoivaksi. Tämä vaikuttaa jatkuvalta beetatestausvaiheessa olemiselta. Toisaalta kyse voi olla jatkuvan julkaisun periaatteiden käyttämisestä sopivaksi tulkitulla kynnyksellä – ihan kaikkea testikattavuutta erilaisiin käyttötilanteiden kombinaatioihin ei tehdä ennen julkaisua tuotantoon. Kombinaatioita on niin paljon, että kaikkea ei vain voi simuloida vähemmän kriittisten järjestelmien kohdalla.
Autoteollisuuden testaus (automotive testing) on toki hyvin pitkälle säädeltyä ja suunniteltua joka tapauksessa. On tapahtumia, on julkaisuja, on asiaan erikoistuneita yrityksiä, on standardeja, kursseja ja sertifikaatteja.
Esimerkiksi ISTQB:n Automotive Tester syllabus kuvaa, että autojen ohjelmistoille täytyy tehdä komponenttitestit, komponentti-integrointitestit, järjestelmätestit, järjestelmäintegraatiotestit, järjestelmien järjestelmä -testit ja hyväksymistestit.
Kaikki tämä testi tehdään vielä eri turvallisuuskriittisyysasteilla riippuen järjestelmän osasta. Silloin käytetään erilaisia testitapaustekniikoita, kattavuusmittareita, virtuaalisia ja todellisia ympäristöjä, sekä suunnittelun tasoja.
Esimerkiksi suljetun-kierron (closed-loop) järjestelmiä kuten abs-jarrut testataan aiempien testien tulokset huomioiden, koska jarrutuksen tilanne vaikuttaa jatkojarrutukseen. Vastaavasti avoimen kierron järjestelmiä kuten valojen käyttö voi testata yksinkertaisemmin – menevätkö valot käskystä päälle.
Oma lukunsa ovat itseohjautuvuuteen liittyvät järjestelmät, joissa käytetään vähintäänkin kuvantunnistuksen puitteissa tekoälyä. Tällöin monimutkaisuus kasvaa, kun tekoälyalgoritmit ja niiden tuottamat mallit täytyy testata ja sen jälkeen näiden mallien toiminta tulee testata erilaisissa tilanteissa, joita jälleen löytyy lukemattomia kombinaatiota. Tyypillisesti ympäristöä laajennetaan tässäkin testauksessa asteittain, eli ensin tehdään testit simulaattorissa, sitten hallitussa ympäristössä (vaikkapa suljettu parkkipaikka) ja lopulta kadulla.
Sähköautot tuovat testaajalle vastaavaa arjen testaushuumaa kuin mobiilisovellukset. Vaikka turvallisuuskriittisyystasot ovat ihan erilaisia, molemmissa pääsee omassa arjessa havainnoimaan vähintäänkin käytettävyysongelmia. Ja toisaalta pääsee pohtimaan, miten paljon tai vähän testausta on taustalla. Testausta vain on kaikkialla! Kuten kohta sähköautojakin.
Kirjoittaja on Vuoden Testaaja 2021, EuroSTAR Testing Excellence Award 2021 voittaja, lasten testauskirjailija Dragons Out Oy:ssä, Knowitin konsultti, Finnish Software Testing Boardin varainhoitaja, ISTQB:n aktiivi, TMMi:n hallituksen jäsen, ja innokas meloja.