Regressiojumppaa

Silloin tällöin peruslaiskalle iskee tarve kuntokuurille. Eihän kroppa pysy kunnossa, jollei siitä pidä vähän huolta. Silloin saattaa löytää itsensä surffaamasta kuntokeskusten tarjontaa tai ohjeita treeniohjelman rakentamiseen itse. Yksi vaihtoehto on miettiä, mitkä osat kehosta kipeimmin kaipaavat kohennusta, ja rakentaa sitten joogaohjelma, joka parhaiten tukee juuri näiden alueiden ylläpitoa.

Hathajooga tarjoaa runsaan valikoiman erilaisia liikkeitä, joilla jokaisella on omat positiiviset vaikutuksensa. Ohjelma koostetaan keräämällä joukko liikkeitä ja laittamalla ne sopivaan järjestykseen. Suunnittelussa huomioon otettavia asioita ovat ainakin:

• Mikä on treenauksen tavoite, eli millaisia asioita on tarpeen sisällyttää treeniin.
• Mitkä liikkeet sopivat lämmittelyyn, mitkä taas vaativat lämmittelyä ennen kuin niitä voi tehdä.
• Vastaliikkeet. Monien voimakkaiden venytysten jälkeen on hyvä tehdä vastaliike, jotta keho saa optimaalisella tavalla kuormitusta.
• Flow, missä järjestyksessä liikkeiden suorittaminen tuntuu mahdollisimman luontevalta.
• Harjoitukseen kerralla käytettävissä oleva aika, sekä kuinka usein se on tarkoitus suorittaa.
• Harjoitukseen käytettävissä oleva tila.
• Henkilökohtaiset mieltymykset, eli mikä on kivaa.

Kun ohjelma sitten on rakennettu, sitä suoritetaan suunnitelman mukaisella tahdilla. Jos käy niin hyvin, että kunto pääsee kohenemaan, tai tavoitteita on jostain muusta syystä tarpeen tarkastella uudelleen, ohjelmaa kehitetään lisäämällä, poistamalla tai muokkaamalla siihen kuuluvia liikkeitä.

Prosessi on yllättävän lähellä regressiotestauksen suunnittelua. Myös siinä mietitään tavoitteet, eli mitkä ovat ne asiat, joiden toimivuus on tarpeen varmistaa. Lisäksi on tarpeen pohtia, missä vaiheissa regressiotestit suoritetaan. Ylläpitovaiheessa pitäisi olla selvää, että regressiotestikierros tehdään ennen jokaista julkaisua. Testattavan järjestelmän muuttuessa myös regressiotestien sisältöä voi joutua tarkastelemaan kriittisesti. Regressiotestaukseen sisällytettävien testien laajuuteen vaikuttaa testaukseen käytettävissä oleva aika sekä budjetti. Nämä asiat vaikuttavat myös silloin, kun regressiotestausta automatisoidaan, sillä myös automatisointi vie aikaa, ja automaattitestauksenkin tulokset on analysoitava. Jos taas testit suoritetaan käsityönä, tehtävän mielekkyyden ylläpitämisen kannalta on hyvä sisällyttää suunnitteluun myös ajatus siitä, miten siitä saisi jollain tapaa kiinnostavaa testaajalle. Tehokkuutta ja mielekkyyttä lisää myös testien järjestäminen tavalla, jolla edeltävät testitapaukset mahdollisimman luontevasti valmistelevat seuraavien testitapausten alkuehdot. Joskus voi olla tarkoituksenmukaista sisällyttää suunnitelmaan myös luodun testimateriaalin poistaminen.

Korkean tason tavoitteena joogaajalla on kehon toimintakunnon ylläpito, regressiotestaajalla taas testattavan järjestelmän toimivuuden ylläpito. Testi ei toki itsessään toimivuutta paranna, vaan se vain paljastaa ne paikat, jotka ovat ajan myötä päässeet rupsahtamaan ja kaipaavat nyt tarkempaa huomiota. Vähän niin kuin aloittelevan kuntoilijan lihaskipu paljastaa paikat, jotka ovat päässeet liian vähällä sohvaperunan elämässä.

Mitä bugille tapahtuu?

Kaikki tietävät, mitä ensin tapahtuu. Testaaja lähtee käymään läpi testitapauksia, hetken päästä prosessi katkeaa. Tilanne dokumentoidaan tekstein, kuvakaappauksin, nauhoittein, miten milloinkin, kuitenkin mahdollisimman yksityiskohtaisesti. Sitten se tallennetaan bugitietokantaan ja jäädään odottamaan korjausta.

Mutta mitä sitten tapahtuu?

Testaaminen on välttämätöntä toimintavarman ohjelmiston rakentamiseksi. Joskus voi kuitenkin käydä niin, että testaus tuottaa bugeja paljon nopeammin kuin niitä ehditään korjaamaan. Yksikin testaaja saattaa raportoida kymmeniäkin bugeja päivässä, ja samaan aikaan kehittäjät ovat ehkä kiinni uusien ominaisuuksien kehittämisessä tai jopa muissa projekteissa. Tai jos bugeja korjataankin, yksittäinen korjaus saattaa avata testaajalle tien löytää monta uutta bugia. Muutamassa päivässä bugitietokanta saadaan niin täyteen, että sen perkaaminen käy työstä. Ja todella se perkaaminen vie myös aikaa. Bugien korjaamista ohjataan käymällä listaa läpi, delegoimalla ja priorisoimalla. Kehittäjät etsivät itselleen mielekkäitä kokonaisuuksia korjattaviksi. Testaaja kahlaa läpi aktiivisten bugiraporttien listaa tarkistaakseen, muistiko eilen raportoida sen yhden kummallisen bugin, jonka selvittely jäi kesken, tai etsii viime viikolla löytyneen bugin täydentääkseen sen kuvausta uudella tilanteella, jossa sama ongelma toistuu. Kenties muukin projektihenkilöstö raportoi löytämiään bugeja joko suoraan samaan tietokantaan luoden duplikaatteja, tai kyselemällä sähköpostitse testaajalta, joko olet huomannut tämän ja tämän asian. Kehittäjien tehdessä uutta toiminnallisuudet saattavat myös muuttua tavalla, jonka myötä vaivalla dokumentoituja bugeja ei enää saada toistumaan, ja niiden moniportainen käsittely vie turhaan aikaa niin kehittäjiltä kuin testaajilta.

Ei kuulosta ihan hirveän tehokkaalta.

Soppa saadaan kasvamaan entisestään, kun kirjataan bugeina kaikki testaushavainnot, ja oletetaan, että ne hoituvat kehittäjien ja testaajien välisellä pingiksellä.

Testaaja ei kuitenkaan yleensä ole projektipäällikkö, ei suorassa yhteydessä asiakkaaseen eikä vastuussa määrityksestä tai vaikkapa käyttöliittymäsuunnittelusta. Tarkentavat kysymykset, joiden oleellinen sisältö on "pitääks tää oikeesti tehdä?" tai "mitä tää määrityksen kohta oikeesti tarkoittaa?" pitäisi ohjata jonnekin muualle. Esimerkiksi suoraan asiakkaalle. Testaaja kun ei voi yksinään antaa kehittäjälle lupaa oikaista.

Miten tilanteen sitten saisi pysymään hanskassa?

Bugien löydettävyyttä parannetaan paitsi hyvällä nimeämisellä myös linkityksillä (esim. käyttötapauksiin) ja luokitteluilla (esim. mihin toiminnallisuuteen liittyy). Sotkun syntymistä voi vähentää myös niin, että sovitaan tarkkaan testauksen tavoitteet, ja vain niihin liittyviä bugeja raportoidaan. Jätetään se kaikesta jännästä nipottaminen vähän myöhempään, kun keskeisimmät asiat toimivat. (Tämä toki tarkoittaa, että testaukseen on oltava käytettävissä riittävästi kalenteriaikaa, eli testaus on aloitettava heti kun toteutus on siinä vaiheessa, että testaaminen on mielekästä.) Voidaan myös jakaa testaushavainnot esim. bugeihin, keskeneräisiin toiminnallisuuksiin ja lähdemateriaalien ongelmiin, ja sopia näille toisistaan poikkeavat käsittelytavat. Kunhan projektissa mietitään, mitä testaukselta aikuisten oikeasti halutaan, ja miten organisoimalla se saadaan mahdollisimman hyvin tukemaan ja mahdollisimman vähän tukkimaan kehitystä.

Jos kaikki oikeasti tietävät, ettei olla vielä stabilointivaiheessa, on hyvä jos testaaja voi työskennellä kehittäjien lähellä, jolloin tieto kulkee myös ilman bugitietokantaa. Kysymyksiä on silloin helppo pallotella suullisesti, ja arvioida yhdessä, miten paljon testauspanoksia kannattaa laittaa mihinkin toiminnallisuuteen juuri nyt. Tätä keskustelua on toki mahdollista käydä sähköisestikin, jos vain kaikki osapuolet ymmärtävät sen olevan yhteinen etu.

Lopulta tärkeää on myös se, ettei pelätä nostaa kissaa pöydälle. Jos toteutuksen ja testauksen lähdemateriaaleissa kuten määrityksessä on ongelmia, joiden takia ei ole mielekästä jatkaa, tieto tästä pitää saada mahdollisimman pian etenemään sinne, missä asioista päätetään. Ongelmien raportoiminen ei koskaan saa hilpeää vastaanottoa, mutta tämä asia ei yleensä odottamalla parane.Näiden maton alle lakaistujen asioiden esiin nostaminen on yksi testauksen tärkeimmistä tehtävistä, ja niiden edistämiseen onkin löydyttävä kanavat, joita käyttäen ongelmat myös ratkotaan. 

Elämäni mutteriapinana ja muita motivaatiokokemuksia

Kenties turhauttavinta testaustyössä on säätäminen.

Siis se, miten pahimmillaan parikin kertaa päivässä joutuu kyselemään projektien vastuuhenkilöiltä, joko olisi testattavaa, miten aikataulu elää, missä testataan, milloin ympäristö päivitetään, mitä ja miten on testattavissa. Mitkä ovat juuri nyt testauksen prioriteetit ja tavoitteet.

Miten viime hetken kiireellisen tilauksen vuoksi joutuu keskeyttämään juuri vauhtiin päässeen työskentelyn tehdäkseen taas uuden syöksyn tuntemattomaan. Tai kyselemään, voisiko jonossa seuraavan projektin aloittaa sovittua aikaisemmin, kun se ensimmäinen ei olekaan vielä testattavissa. Järjestelemään testauksen jakamista tai siirtämistä toiselle testaajalle, kun projektien toteutuvat aikataulut vaativat suurempaa työpanosta kuin mihin on kohtuullista yksin venyä.

Kysymään useampaan otteeseen, ennen kuin saa riittävät tiedot jonkin asian testaamiseen, vain löytääkseen itsensä tilanteesta, jossa joku tuhoaa varoittamatta vaivalla rakennetun testiaineiston, tai selviää että sovittua päivitystä ei sitten ollutkaan tehty. Tai päivitettiin epästabiiliksi tiedettyyn versioon, ja nyt päästään testaamaan samoja bugeja useammassa ympäristössä yhtäaikaa.

Tähän kaikkeen liittyy piinallinen tuntuma siitä, ettei saa mahdollisuutta tehdä työtään niin hyvin kuin haluaisi, olla niin hyödyllinen kuin omasta mielestään osaisi olla.

Jonkin verran epävarmuutta, inhimillisiä erehdyksiä ja niihin liittyvää säätämistä on pakko hyväksyä. Testaajan työn aikataulu ja työmäärä riippuvat siitä, miten kehittäjät tekevät työnsä, eikä sitä ole täysin mahdollista ennakoida. Kun vielä testaajan työn idea on enemmän tai vähemmän keskeneräisen kanssa työskentely - sen tarkistaminen, miten tukeva rakennelmasta tulikaan - virheisiin törmääminen vähän niin kuin kuuluu toimenkuvaan.

Siksi välillä on pakko joustaa ja järjestellä. Joskus on myös pakko hyväksyä se, että juuri nyt ei ole tarjolla mielekästä testaustyötä. Tai että aika ei riitä tekemään asioita oikeasti perusteellisesti. Työ on lopulta vain työtä, ei sen takia kannata yöuniaan menettää, eikä sen tarvitse olla tärkein elämään sisältöä tuova asia.

Joskus kuitenkin on vaikea välttää ajatusta, olisiko asiat kuitenkin mahdollista tehdä edes vähän paremmin.

Yksi vaihtoehto olisi tehdä projekteja ketterämmin, jolloin testattavaa syntyisi tasaisempaa tahtia ja pienempiä määriä kerrallaan. Tämäkään vaihtoehto ei kuitenkaan yksin tuo pelastusta, sillä monia vesiputousmallia rampauttavia toimintatapoja (tai tapoja olla toimimatta) on mahdollista käyttää myös projekteissa, joita periaatteessa edistetään ketterästi - häröilyhän ei sellaisenaan kuulu mihinkään prosessimalliin. Eikä järjesteltävien palikoiden pienentäminen itsessään poista järjestelyn tarvetta, vaan lopputulos voi olla jopa päinvastainen.

Yllättävän paljolta turhalta työltä ja mielipahalta säästyttäisiin ihan vain skarppaamalla projektien sisäisen tiedonkulun kanssa. Siis esimerkiksi sillä, että aina kun tapahtuu jotain aikatauluun tai sisältöön vaikuttavaa, myös testaaja saisi kuulla asiasta. Tai jos kehitetään ja testataan yhtäaikaisesti, saman projektin parissa painivilla olisi tieto siitä, mitä muut ovat tekemässä, ja keihin kaikkiin omat tekemiset voivat vaikuttaa. Että saisi senkin tiedon, jota ei ole helppoa keksiä itse kysyä. Monet näistä asioista varmaankin helpottaisivat myös kehittäjien työtä.

Pitäisikö testaajan istua kehittäjien luona jo toteutusvaiheessa? Pitäisikö hänen osallistua projektipalavereihin alusta alkaen? Ainakin osaan niistä? Pitäisikö projektien tiedotus hoitaa spämmäämällä aina sähköpostilistaa, jolle myös testaaja kuuluu?

Ratkaisuvaihtoehtoja voi olla useampia. Ehkä lopulta tärkeintä on, että projektin sisäinen viestintä ylipäätään nähdään panostamisen arvoisena, tapana ehkäistä ongelmia. Esimerkiksi, että palaverit suunnitellaan jollain tasolla, niistä jaetaan etukäteen jonkinlainen agenda, ja niihin pääsevät tavalla tai toisella osallistumaan kaikki, joita käsiteltävä asia jotenkin koskee, tietäen mitä heidän osallistumiseltaan odotetaan. Että niiden ensisijainen tarkoitus ei ole raportointi, vaan tiedon jakaminen kaikille niille jotka siitä hyötyvät.

Testaamisen mielekkyydestä

Joskus kuulee ihmettelyä, miten kukaan voi haluta olla ohjelmistotestaaja. Sellaiselle, joka on joutunut muun työn ohessa kliksuttelemaan läpi liudan jonkun muun naputtelemia testitapauksia testaus varmasti näyttäytyykin tylsänä ja aikaavievänä tehtävänä, josta on vaikea sanoa, turhauttaako enemmän jos kaikki menee läpi, vai jos mikään ei toimi kunnolla.

Tämä on kuitenkin hyvin kapea näkökulma testaukseen. Hyvin tehty ohjelmistotestaus saattaa alkaa jo myyntivaiheessa kun mietitään, kuinka työläitä asiakkaan toiveet ovat täyttää. Testausnäkökulma on avuksi myös luotaessa ohjelmistomääritystä, sillä yksi keskeisimpiä hyvän määrityksen ominaisuuksista on että sen perusteella voi testata, täyttääkö ohjelmisto sille asetetut vaatimukset. Testaussuunnittelua on mahdollista käyttää myös toteutuksen tukena, sillä testitapaukset saattavat tarjota paitsi konkreettisen ja selkeästi jäsennellyn tavan lähestyä määritystä, myös eräänlaisen muistilistan poikkeustilanteista, joista ohjelmiston on selviydyttävä vaikka määritys ei niitä käsittelekään.

Toki testaustehtävien suorittaminen on välillä myös suunnattoman tylsää. Mutta harva työnkuva on pelkkää hupia. Siksi kai meille työstä maksetaan, että olemme hetkittäin valmiita tinkimään omasta mukavuudestamme saadaksemme jonkin tärkeän tehtävän tehdyksi. Testauksen tehtävä on suojella liiketoimintaa niiltä katastrofeilta, joita bugit voivat aiheuttaa, eikä sankaritekojenkaan tekeminen ole pelkkää riemua.

Testaamisen mielekkyyteen voi myös vaikuttaa. Testitapauksia voi suunnitella niin, että niiden läpikäynti on ennemminkin uteliaisuutta herättelevä kuin uneliaisuutta aiheuttava kokemus. Automatisointi saattaa joskus pelastaa tekemästä niitä puuduttavimpia tehtäviä. Mielekkyyden luominen ja ylläpitäminen testauksessa lieneekin yksi niistä testauksen tehtävistä, joilla ammattilaiset erotellaan harrastelijoista, ja joissa kovimmallakin asiantuntijalla on aina mahdollisuuksia kehittyä vielä paremmaksi.