X
Loading...
Ei hakutuloksia
Sisältö
Henkilöt
{ page.post_title }
{ page.titteli }
{ page.sahkoposti }
{ page.puhelinnumero }

Testauspäivät 2.6.2016

Testauspäivä on joka toinen vuosi järjestettävä tapahtuma Tampereen teknillisellä yliopistolla. Tämän vuoden teemana oli teknologia ja testaus: mitä teknologioita on tulossa käyttöön ja mitä teknologioilla testataan. Tämä blogikirjoitus käsittelee muutamaa testauspäivän luentojen mielenkiintoisista aiheista.

Mitä jokaisen testaajan pitäisi tietää pilvestä?

Qentinelin Mika Katara ja Teemu Vesala kävivät läpi historiaa reikäkorteista ja PC:stä virtualisaatioon sekä pilvipalveluihin.

Sitten käsiteltiin projektien kannalta tärkeää aihetta, eli mitä jokaisen testaajan tulisi tietää pilvestä. Pilvitarjoajasta tulisi selvittää ainakin seuraavat asiat:

  1. Missä resurssit sijaitsevat, asiakkailta tulevat vaatimukset ja rajoitukset tämän suhteen
  2. Latenssi, jos pilvipalvelut sijaitsevat Atlantin takana, niin tämä voi hidastaa palveluita huomattavasti
  3. Privaattiratkaisut (oma palomuuri) vai hybridipilvi
  4. Siirrettävyys (Vagrant, Docker)
  5. Palvelun tarjoajaan lukittautumisen välttäminen
  6. Pilvipalveluiden monitorointi, varmuuskopiointi (jos pilvi on alhaalla)
  7. Pilvipalveluiden laskutus ja hinta

Pilvityökalut, kuten Vagrant ja Docker, perustuvat open coreen. Peruspalvelut ovat ilmaisia, mutta lisäpalvelut maksavat.

Vagrant on työkalu paikallisten ja pilvipalveluiden hallintaan. Vagrantilla saadaan nopeasti uusi testikone käyttöön ja päästään nopeasti alkuun, esimerkiksi Robot Framework työkalun kanssa. Docker taas tarjoaa kevyttä virtualisaatiota säiliöillä (konteilla) ja mikropalveluita. Tämän jälkeen käsiteltiin nopeasti provisointia ja mitä työkaluja siihen voi käyttää: Shell, Puppet, Chef.

Luennon lopuksi käsiteltiin continious deliveryä, continious developmenttia ja laatuputkea, joissa tavoitteena on saada nopeasti ensimmäinen laatupalaute (alle viisi sekuntia). Tällaisissa järjestelmissä staattiset analysaattorit, Jenkins ja Git-versonhallinta toimivat selkärankana, mutta järjestelmä pitää osata itse Jenkinsillä rakentaa.

Skaalautuva testausautomaatio

Toinen päivän mielenkiintoinen aihe oli skaalautuva testausautomaatio, eli miten käyttöliittymätestausta voidaan ajaa kontissa (Docker), missä testaajalle jää työksi vain testausjärjestelmän huoltaminen ja keskittyminen palvelevaan softaan. Esimerkkinä työkaluista Symbion Sakari Hoiskolla oli Docker ja Robot Framework (joka on käyttöliittymä testausautomaatiotyökalu, joka pohjautuu avainsanoihin). Robot Frameworkin ja Dockerin käytöstä käytiin läpi demo, joka on nähtävissä täällä.

Automaattitestien suunnitellussa on tärkeä huomioida, että automaattitestit ovat uniikkeja, eli käyttöliittymätestit eivät saisi olla riippuvaisi toisista testeistä (ei saa jatkaa tietystä kohdasta mihin edellinen testi jäi) eikä samasta testidatasta. Lisäksi testeissä pitää ottaa huomioon ajoitus, eli testit eivät saisi käsitellä samaan aikaan samaa tietokannan taulua (toinen testitapaus lisää taulun, kun toinen poistaa sen). Automaattitesteissä tulisi välttää sleeppejä ja käyttää tilalla wait until luuppeja tai triggreitä.

Oppimiskokemuksia testausautomaatiossa

Testauspäivillä pääsimme kuulemaan myös aitoja esimerkkejä, kun Solitan Samuli Lahnamäki kertoi yrityksen testauskokemuksista. Samuli taustoitti, että Solita on projektitalo, jossa on erilaisia kulttuureita. Joissain projekteissa on pieni riskitaso, kuten esimerkiksi pienet Intraan liittyvät projektit ja sitten on projekteja, joissa on suuri riskitaso, kuten esimerkiksi toimintakriittiset järjestelmät. Niissä täytyy miettiä, kuinka nopeasti ollaan lehtien otsikoissa, jos jokin menee testauksessa pieleen.

”Kuka osaa korjata testit?” on tärkeä sisäpelillinen kysymys, kun testit kasvoivat eikä testaukseen liittyvä osaaminen liiku projektien välillä.

Ulkopelien suunnilla taas on tärkeä tarkastella, miten verifioidaan mitä ollaan testattu ja ollaanko testattu yhtään mitään. Eli tekeekö ohjelmisto mitä asiakas haluaa? Samuli nosti esiin myös integraatioiden testaamisen vaikeuden: tuskaa siinä tuottavat lyhyt kalenteriaika sekä kommunikointi sidosryhmien välillä.

Sitten ne vaikeat kopit, eli miten testataan esimerkiksi Office-dokumenttien muokkausta julkaisujärjestelmässä? Toinen vaikeuksia tuottava testauksen osa-alue on karttakäyttöliittymän testaus. Lisäksi ongelmia tuottaa kunnollisen testidatan hankkiminen. Onko tuotantoympäristöstä kopiota testausta varten vai voiko siinä käyttää anonyymiä dataa?

Nykypäivänä keskeinen kysymys on myös ROI, eli tehdyn työtunnin hyödyllisyys. Saiko asiakas sen minkä osti? Entä miksi testaamiseen menee niin paljon aikaa?

Lopuksi mietittiin oppimispolkuja, joissa Solitalla oli päädytty katselmointiradiaattoreihin. Lisäksi on havaittu ketteröitymistä, eli testaaminen on kuollut erillisenä vaiheena (paitsi verifioiva testaaminen). Projektin aikajanalla ei ole aikaa pitkäaikaisen testiympäristön pystyttämiseen, vaan tehdään joku versio hetkeksi aikaa.

Antoisa testauspäivä kokosi TTY:lle taas suuren määrän kollegoita eri yrityksistä. Suuret kiitokset järjestäjille!

Jos sinua jäi kiinnostamaan muiden luentojen aiheet, löydät kalvot täältä.

Panu Kukkasniemi

KIRJOITTANUT

Panu Kukkasniemi

Test Engineer

Panu Kukkasniemi on työskennellyt Eatechilla ohjelmistotestaajana ja on suuntautunut erityisesti testausautomaatioon. Hän on laadusta tinkimätön vastuunkantaja, joka pitää huolen siitä, että järjestelmät toimivat, kuten pitääkin.

Panu Kukkasniemi