Sisun korkea laatu vaatii kokeilunhaluista ja rohkeaa testaamista

Testaamme päätuotettamme Sisua monipuolisesti. Pääasiassa testaus on manuaalista, mutta automaatiotestaus on myös merkittävässä osassa, sillä monipuolinen testaaminen varmistaa Sisun korkean laadun. Saavutettavuuden testaaminen nousee myös koko ajan tärkeämmäksi osaksi Sisun testausta. Etsimme meille parhaillaan kokeilunhaluista ja rohkeaa ohjelmistotestaajaa “rikkomaan Sisua” eli huolehtimaan järjestelmän toimivuudesta. Käännyimme testaajamme Saran puoleen selvittääksemme paremmin, millaista on ohjelmistotestaajan arki Funidatalla. […]

Takaisin

Testaamme päätuotettamme Sisua monipuolisesti. Pääasiassa testaus on manuaalista, mutta automaatiotestaus on myös merkittävässä osassa, sillä monipuolinen testaaminen varmistaa Sisun korkean laadun. Saavutettavuuden testaaminen nousee myös koko ajan tärkeämmäksi osaksi Sisun testausta. Etsimme meille parhaillaan kokeilunhaluista ja rohkeaa ohjelmistotestaajaa “rikkomaan Sisua” eli huolehtimaan järjestelmän toimivuudesta. Käännyimme testaajamme Saran puoleen selvittääksemme paremmin, millaista on ohjelmistotestaajan arki Funidatalla.

Moi Sara, kertoisitko yleisesti testausprosessistamme?

Tietty! Jospa lähdetään ihan siitä liikkeelle, miten tiketti päätyy testaukseen. Devaajilla on omat tikettinsä, jotka katselmoinnin jälkeen siirretään kanban-taulussa “waiting for verify” -tilaan. Nappaan sieltä itselleni tikettejä verifioitavaksi eli testattavaksi. Testattavana voi olla uusia toiminnallisuuksia tai bugikorjauksia eli jo olemassa olevien toiminnallisuuksien muokkausta tai korjausta.

Me testaajat keskustelemme tarvittaessa kehittäjien kanssa työn alla olevista tiketeistä. Mikäli löydän bugin, otan yhteyttä kyseisen tiketin koodanneeseen devaajaan. Keskustelemme yhdessä, mitä asian kanssa tehdään, eli liittyykö löytynyt bugi kyseiseen tikettiin vai pitääkö tehdä uusi bugitiketti. Mikäli bugi liittyy kyseiseen tikettiin, palautan tiketin devaajalle, jonka jälkeen tiketti matkaa läpi saman prosessin, eli korjauksen jälkeen tiketti taas katselmoidaan ja testataan. Testaajana toimii yleensä sama henkilö kuin ensimmäiselläkin kerralla. Mikäli löytynyt bugi ei liitykään kyseiseen tikettiin, testaaja voi kirjoittaa siitä itse bugitiketin toisto-ohjeineen ja laittaa sen seuraavaan sprinttiin sille tiimille, jolle kyseinen toiminnallisuus kuuluu.

Sisua testataan myös automaatiotesteillä, kertoisitko hieman niistä?

Automaatiotestauksessa robotti raksuttaa testit läpi. Automaatio- eli E2E-testejä on satoja, joten robotti säästää todella paljon työaikaamme. Manuaalisesti niin suuren testimäärän läpikäyminen olisi liian iso työ.

E2E-testit käyvät järjestelmän läpi aina jokaisen pull requestin yhteydessä eli aina kun masteriin tulee uutta koodia. Jos E2E-testit eivät mene läpi, täytyy testejä tai koodia muokata. Kun masteriin lisätään uutta tavaraa, on vaarana, että jotain menee rikki. Uusi koodi voi muuttaa asioita jostain toisesta paikasta, jos siellä on käytetty samaa koodia. E2E-testien avulla on mahdollista varmistaa, ettei synny regressiota eli etteivät ennestään toimivat toiminnallisuudet mene rikki.

Testaajien lisäksi E2E-testit ovat erittäin hyödyllisiä myös kehittäjille, sillä niiden avulla näkee suoraan, mikä on mennyt pieleen. Automaatiotestaus nostaa Sisun laatua ja testikattavuus nousee. E2E-testit ovat tärkeitä, sillä niiden tarkoituksena on suojella järjestelmää ja varmistaa, että uudesta koodista huolimatta kaikki toimii kuten pitääkin.

Työnkuvaani kuuluu E2E-testitapausten kirjoittaminen ja muokkaaminen. Tätä voi tehdä eri teknologioilla, mutta meillä on käytössä Cypress. Se on mielestäni hyvä valinta. Jos vähänkin osaa lukea koodia, on testin lukeminen Cypressissä todella suoraviivaista. Cypress-testien kirjoittamisessa tulee osata etsiä softasta oikeat elementit, jotta testi vastaa järjestelmän toiminnallisuutta.

Ohjelmistotestaaja Saran arki Funidatalla Sara on testannut Sisua reilut pari vuotta. Myös Saran koira Hugo osallistuu välillä testaushommiin.

Millaisia haasteita Sisu tarjoaa testaajalle?

Tikettejä on sekä helppoja että vaikeita. Helpon tiketin testaamiseen ei yleensä mene varttia kauempaa, kun tarkistaa, että se toimii joka puolella erilaisissa tilanteissa. Isompiin tapauksiin voi mennä useampi päivä. Testaamiseen menevään aikaan vaikuttaa moni asia, kuten testattavan asian laajuus, onko toiminnallisuus minulle entuudestaan tuttu tai onko devaaja tarvittaessa paikalla, jos tulee jotain kysyttävää. Silläkin on tietysti merkitystä, kuinka hyvin tiketin kuvaus on kirjoitettu.

Pääasiassa seikkailen käyttöliittymissä, mutta välillä joudun konepellin alle tutkimaan, menikö muutos tietokantaan oikein. On siis hyvä osata tehdä tietokantakyselyjä ja testata rajapintojen kautta. Myös koodinlukutaidosta on hyötyä. Tässä hommassa on mahdollista päätyä kunnon HC-järjestelmäasiantuntijaksi, joka osaa ajatella kokonaiskuvaa koko järjestelmästä ja jolta usein kysytään asiasta kuin asiasta.

Meillä tehdään paljon myös saavutettavuuden eteen töitä, miten se näkyy testaajalla?

Saavutettavuustestaus lisääntyy meillä koko ajan ja se tulee olemaan isompi juttu tulevaisuudessa, kun pääsemme saavutettavuustyössä pidemmälle. Saavutettavuustestaukseen kuuluu mm. ruudunlukijan käyttöä, näppäinkomentojen osaamista, kooditestausta sekä kontrastitestausta.

Tähän mennessä työpöydälleni on tullut tapauksia, jossa on parannettu joidenkin sivujen kontrasteja tai liikkumista tietyissä näkymissä näppäinkomennoilla. Suurin työ saavutettavuuden osalta on UI/UX-tiimillä, joka yhteistyössä yhteistyökumppanimme Eficoden saavutettavuusasiantuntijan kanssa käy läpi, mitä näkymiä parannellaan, missä järjestyksessä ja miten.

Saavutettavuustestauksessa saattaa joutua hyppimään selaimien ja eri käyttöjärjestelmien välillä. Käytän itse Macia, mutta minun on täytynyt asentaa koneelleni Windows-virtuaaliympäristö, jotta voin käyttää NVDA:ta, joka on yleisin käytössä oleva ruudunlukuohjelma.

Mikä on parasta testaajan roolissa Funidatalla?

Parasta on se, että teemme omaa tuotetta, johon saa paneutua täysin. Pidän myös siitä, että oma roolini on selkeä. Vaikka toimin nyt Karhu-tiimin toisena testaajana, voin tarvittaessa siirtyä myös johonkin muuhun tiimiin testaajaksi eli tiimien rajat eivät ole kiveen hakattuja. Asioita ei myöskään tarvitse miettiä yksin, vaan devaajilta ja muilta testaajilta saa aina apua. Testauksessa on kivaa se, että saa kokeilla järjestelmän sisällä kaikenlaista. On palkitsevaa löytää bugeja ja se myös auttaa koko järjestelmän kehittämisessä, jotta ongelmat eivät päätyisi loppukäyttäjälle. Meille kaikille on tärkeää, että loppukäyttäjällä on laadukas ja luotettava järjestelmä käytössään.

 

Oletko valmis sukeltamaan syvälle Sisuun? Kiinnostaako ohjelmistotestaajan hommat Funidatalla? Hae meille ohjelmistotestaajaksi! Tutustu myös työntekijäesittelyymme ohjelmistotestaajastamme Henristä.