Kokemuksia EuroSTAR 2019 -konferenssista: “DevOps: Test Alone”

Kokemuksia EuroSTAR 2019 -konferenssista: “DevOps: Test Alone”

Marraskuussa 2019 EuroSTAR konferenssissa Prahassa Bjorn Boisschot piti puheenvuoron DevOpsista ja ohjelmistotestauksesta. Lähtöajatuksena Bjornin puheenvuorossa oli, että kuten vanhassa Home Alone -elokuvassa Dev ja Ops olisivat lähteneet matkalle ja jättäneet laadunvarmistuksen ja testauksen ”yksin kotiin”. Bjorn totesi, että hän kuulee jonkun verran tarinoita suurista yrityksistä, että testauksen tapahtuessa tuotannossa ja kehittäjien tehdessä testausautomaatiota, testaajien tarve yrityksessä olisi vähentynyt. Bjornin mukaan silti useimmille DevOps-ratkaisuille QA on ratkaisevan tärkeä olla olemassa. Kuitenkin DevOps on muuttanut dramaattisesti tapaa miten kannattaa tehdä laadunvarmistusta. Tässä tekstissä on referoitu Bjornin Prahassa pitämä puheenvuoro.

Ohjelmistotestauksen (erittäin) lyhyt historia

Alkuun Bjorn esitteli lyhyesti muutaman ohjelmistotestauksen historiaan liittyvän vuosiluvun. Ensimmäinen kirja, joka käsitteli pelkästään ohjelmistotestausta, on Glenford J. Myersin ”The Art of Software Testing” (1979). Ohjelmistokehitysprosessiin liittyvät testauksen vaiheet linkattiin yhteen 1986, kun Paul E. Rook esitteli V-mallin. Agile manifesto esiteltiin vuonna 2001 Utahissa, jolloin Agilen kaksitoista periaatetta julkaistiin. Tällöin alettiin arvostaa muun muassa yhteistyötä kehittäjien ja liiketoiminnan välillä, nopeaa toimitusketjua sekä toimivaa lopputuotetta. Vuonna 2009 pidettiin ensimmäinen DevOpsDays-konferenssi, jossa tuotiin esille DevOps-ohjelmistokehitysmenetelmää. Menetelmää, joka korostaa viestintää, yhteistyötä ja integrointia ohjelmistokehittäjien ja tietotekniikan (IT) ammattilaisten välillä. Googlen Test Automation konferenssissa 2011 Alberto Savoia sanoi avauspuheenvuorossaan testauksen olevan kuollut (”Testing is dead”). Tämä tapahtui siis vain vähän yli 30 vuotta sen jälkeen, kun ensimmäinen täysin ohjelmistotestaukseen keskittynyt kirja oli julkaistu. Oliko testaajien kehitys tullut tiensä päähän näin lyhyessä ajassa?

Pelot

Monessa tapauksessa testaajat pelkäävät DevOpsia ja sen käyttöönottamista. He pelkäävät, että testaajia ei tarvita enää, kun ohjelmistojen julkaisemisesta sekä testaamisesta tulee automaattisempaa. Mikäli testausautomaatio tekee kaiken työn, ja testaus hoidetaan tuotannossa, mihin ammattimaisia ohjelmistotestaajia enää tarvitaan? DevOps kuitenkin jo omassa manifestossaan julistaa, että DevOps on kulttuurinormeja ja teknologiakäytäntöjä, jotka mahdollistavat nopean virran aina työn suunnittelusta ja kehityksestä testauksen kautta IT-tiimeille säilyttäen samalla maailmanluokan luotettavuuden, toiminnan ja turvallisuuden. DevOps kaipaa myös testausta – samalla täytyy vain opetella hieman uudenlaisia tapoja tehdä sitä.

DevOps-organisaatio ja ohjelmistotestaajat

Ohjelmistotestaus on pitkälti säilynyt samanlaisena vuosien varrella, ja tämä ei ole ollut heikkous. Samoja taitoja tarvitaan edelleen. Kuinka sitten selvitä DevOpsin suuntaan muuttuvassa organisaatiossa? Bjornin mielestä ensimmäinen asia on tuottaa arvoa. Tietenkin asiakkaalle, mutta myös tiimille, jossa itse työskentelee. Testaus ei ole vain yksittäinen tehtävä, joka suoritetaan, vaan kokonaisstrategia, jolla varmistetaan toimiva lopputuote. Testaajat voivat sparrata kehittäjiä näkemään tuotteeseen liittyen laajemman kuvan yksikkötesteissä sekä yleisesti ottaen koko tuotteessa. Testaajat ovat merkittäviä myös liiketoiminnan kanssa keskustellessa, esimerkiksi vaatimuksien ja hyväksyntäkriteerien suunnittelussa sekä loppukäyttäjien roolien määrittämisessä.

Testaajat ovat myös osaamiseltaan usein liiketoimintaa sekä ohjelmistokehitystä molempia ymmärtäviä asiantuntijoita, jolloin he pystyvät toimimaan molempien välillä siltana. Tällöin ns. ”pehmeät taidot” (soft skills) ovat myös heidän vahvuutensa, jota he voivat tuoda tiimin toimintaan mukaan. Bjorn puhui erityisesti onnistumisien juhlistamisesta, empatiasta sekä sitten ihan kahvittelusta, tavasta oppia tuntemaan ihmiset, joiden kanssa työskentelee.

Myös ohjelmistotestaajien on silti hyödyllistä opetella hieman lisää teknisempiä taitoja. Tämä mahdollistaa kehittäjien kanssa ”saman kielen” puhumisen, mutta myös auttaa testaajien omassa työssä. Skriptauksen osaaminen, konttitekniikoiden (containerisation) käyttäminen testauksessa ja testausautomaatiossa sekä huomion kiinnittäminen teknisempiin asioihin kuten koodin laatuun, tekniseen velkaan sekä testien koodikattavuuteen edesauttavat kokonaisuuden eteenpäin viemistä. Kuitenkin pitää aina muistaa, että vaikka yksikkötestien koodikattavuus olisi 100%, tämä ei tarkoita, että kaikki olisi testattu! Testaajat keskittyvät nimenomaan tapauksiin, joita ei koodikattavuudesta huolimatta tulla yksikkötesteillä testaamaan.

DevOpsissa ”Ops”-tiimin kanssa keskustelu voi tuottaa testaajien käyttöön metriikoita, joita voi hyödyntää testauksen suunnittelussa. Käyttäjien maailmasta saadut bugiraportit sekä sovelluksien kaatumiset näyttävät testaajille millaisia asioita loppukäyttäjät hyödyntävät, ja näin testitapauksien suunnitteluun saadaan lisää näkökulmia. ”No user would ever do that.” – Tämä usein kuultu lause saa vasta-argumetin, kun voidaan ottaa malliksi elävän elämän käyttötapauksia, mikäli tällaisia on mahdollista saada käyttöön.

Automatisoitu testaus DevOpsissa on enemmänkin monitorointia, että julkaistu tuote on kunnossa. Itse toiminnallisuuksien testausta tarvitaan DevOpsista huolimatta, ja erilaisilla tavoilla kuin aikaisemmin. Koko tiimin tavoitteena tulee olla sisäänrakennetun laadun tekeminen, ja tätä tukevat Bjornin esittämät tavat, joilla ohjelmistotestaajat pystyvät kehittämään itseään sekä tekemistään DevOps-maailmassa toimiessaan.

”QA is not dead, it is evolving to a higher consciousness.” – Bjorn Boisschot