Testidatanhallinta: prosessi, ei työkalu

Jostain syystä useimmat edellämainittuihin asioihin liittyvät keskustelut päätyvät pyörimään käytettyjen teknologioiden ja työkalujen ympärillä. Mikä olisi oikea kieli verkkoselainautomaatioon? JavaScript? Python? TypeScript? Mitä testiautomaatiotyökaluja tällä kielellä löytyy? Mitä DevOps-työkaluja meillä on? Tai aihe, josta tänään puhumme: kenen toimittajan testimateriaalinhallintasovellus on meidän valintamme?

Olet testidatan käyttäjä – halusit tai et

Fakta on, että testidatan hallinta on väistämätön osa minkä tahansa ohjelmistokehitysprojektin sisältöä, oli käytössä erillistä työkalua tai ei. Valinta, että testaukseen käytetään vaikkapa suojaamatonta tuotantodataa on sekin testidatan hallintaan liittyvä päätös, vaikka varsin kehno – eritoten näin GDPR:n aikoina. Tulet  siis tehneeksi testidatan hallintaa, vaikket sitä ajattelisikaan. Siksi onkin ihan hyvä ajatus pohtia sitä, millainen oma testidatanhallintaprosessi on sen lisäksi, että pohtisi pelkkää työkalua.

Testidatanhallintaa käsitellään etenkin enterprise-kokoisissa hankkeissa hyvin eri tavalla kuin pienemmissä ketterissä projekteissa. Suuremmat hankkeet hyötyvät merkittävästi työkaluista, jotka osaavat käsitellä monenkaltaisia ja -kokoisia tietokantoja, ottaa osituksia tuotantodatasta ja sotkea ne sopivalla tavalla ja tiputtaa keskenään synkronissa olevat testidatat automaattisesti eri testipalvelimille.

Olennaisempaa kuin työkalu on kuitenkin hyvin tehty suunnitelma siihen, miten työkalua voitaisiin käyttää tehokkaasti. Hyvin suunniteltu testidatanhallintaprosessi mahdollistaa sen, että asiakas voi oikeasti valita juuri sellaisen työkalun, josta hyötyy sen sijaan että valitsee vain sen suosituimman.

Prosessin mukaiset työkalut

Markkinoiden johtavat testimateriaalinhallintasovellusten toimittajat eivät ole päätyneet tilanteeseensa vahingossa, vaan niillä on tarjota suunnaton määrä eri toiminnallisuuksia, jotka tukevat erittäin laajalla skaalalla työtapoja ja tietokantamalleja. Toki CA:n, Informatican ja IBM:n tuotteet siis hoitavat periaatteessa homman kuin homman, MUTTA….

On kuitenkin turhaa tilata paikalle maansiirtokone silloin kun lapiokin riittää. Testidatanhallinta tapahtuukin siksi pienemmissä projekteissa varsin käsityönä ja osana testauksen hallintaa.

Vaikka skaala on pienempi, ei suunnittelun tarve tai järkevyys katoa silti mihinkään. Moni tiimi voi hyötyä pelkästään siitä, että esittää kysymyksiä kuten

• millaista testidataa projektimme oikeastaan tarvitsee?
• mistä se otetaan?
• jos tuotannosta, miten sotkemme sen?
• voimmeko generoida sen jotenkin?
• miten varmistumme siitä, että generoitu testidata on kyllin hyvää?
• mitä tapahtuu, jos integroidumme toisiin järjestelmiin ja mitä se tarkoittaa testidatamme suhteen?

Jos tiimin prosessi on hyvä ja se toimii, niin mitään ei luonnollisesti kannatakaan muuttaa. Näihin kysymyksiin on silti hyvä olla olemassa vastaus, sillä yleensä ongelmat alkavat silloin, jos jotain asiaa ei ole otettu huomioon.

Asiantunteva testidatanhallinnan suunnittelu tukee kaikkea projektin kehitystä.