Muistatko kun opettelit ajamaan autoa? Alkuun se oli haastavaa, monta pientä huomioitavaa samanaikaisesti. Oli turvallisempaa liikkua rauhallisemmin, ettei huomaamattaan kääntäisi rattia naapurikaistaa silmäillessä. Mäkilähtöön oli hyvä varautua ja valmistautua. Hengitellä, tunnustella kytkintä, painaa kevyesti kaasua, mahdollisesti jopa asetella jo vaihdetta silmään. Töksähtävä lähtö tai auton sammuminen saattoi muodostua muovaavaksi kokemukseksi.
Testaaminen on monen pienen asian oikeanlaista yhdistelyä. Tarkoituksena on tuottaa tietoa ja aiemman sovelluksiin ja järjestelmiin keskittyvän testauksen lisäksi nykyään testataan myös organisaatioita.
Useita pieniä asioita oppii yhdistelemään opettelemalla pala kerrallaan ja laajentamalla kokonaisymmärrystä pikkuhiljaa. Ajatus siitä, missä järjestyksessä asioita kannattaa oppia mahdollisimman hyvän pohjan rakentamiseksi on muuttunut viime vuosina. Sertifiointiin pohjautuva perusopetus ei välttämättä olekaan paras mahdollinen suunta.
Tutkiva testaus, erittäin lyhyt historia
Nykyään jo eläköitynyt testausprofessori Cem Kaner mainitsi ilmaisun “tutkiva testaus” (exploratory testing) kirjassaan “Testing Computer, Software 1st edition”
Kaner kuvasi tutkivaa testausta Piilaakson havaintojen perusteella yleistä tasoa onnistuneemmaksi testaukseksi.
Tutkiva testaus on tyylisuunta, jossa keskeisessä roolissa on monialainen käsitys testauksesta – yhdistelmä liiketoimintaa, sovellusaluetietämystä, lakia ja tekniikkaa. Sekä osaamista. Tyyliä luonnehtii erityisesti tuloksellisuus ja tehokkuus.
Amerikan julkaisuja varhaisempia referenssejä löytyy esimerkiksi tutustumalla kotimaisen Kelan eläköityneen Mervi Hyvösen oppeihin vuodelta 1973. Maaretin muistilokeroista kaivelimme Mervin tulkintoja siitä, ettei pienellä maalla ollut varaa tehdä tehotonta testausta ensimmäisen maahan hankitun tietokoneen kanssa.
Tutkiva testaus ei kuitenkaan tarkoita kaikille samaa. Mervin ja Cemin opeista ja Maaretin hieman pidemmästä testausurasta ponnistaen olemme vertailemalla testauskokemuksiamme päätyneet tyyliin, jota kutsumme tutkivaksi nykytestaukseksi (contemporary exploratory testing) ja toteutamme omissa organisaatioissamme.
Vähän kuten kitaran aiemmin tulkittiin olevan aina akustinen, löydettiin sähkökitaran myötä tarve etuliitteille, jotka tarkentavat kuvattuja samankaltaisia asioita.
Erilaisiin määritelmiin ja käsityksiin törmää selittäessään muille testaustapaansa. Esimerkiksi tutkiva testaus 3.0 haluaa kutsua tätä vain testaukseksi, sillä onhan selvää, että kaiken testauksen kuuluu olla tutkivaa. Käsin tehtävään tutkivaan testaukseen törmää usein ihmisten miettiessä, miten saisivat tehdä testausta mielekkäämmällä tavalla ilman automaatiota. Sessioperusteinen tutkiva testaus on erityisesti testauksen hallinnan keino testitapausten kirjoittamisen vastineeksi. Tutkiva testaus nähdään tekniikkana, jonka selkeän oloinen muoto täydentää testausta.
Miten niin nykyaikainen?
Otetaan 80-luvun Piilaakson vaihtoehtoiskustannustietoisuus pohjaksi ja lisätään nykypäivän faktat:
- automaatio kuuluu testaukseen ja ei ole erillinen tehtävä
- testaus kuuluu koko kehitystiimille, ei vain testausammattilaisille
- testiohjattu kehitystapa on yksikkötestaustason tutkivaa testausta
- ihmisten tehtävien ja osaamisten rajoja pitää aktiivisesti muuttaa
- yhteistyö ja nykyosaamisesta kasvaminen ovat välttämättömiä
- palaute on arvokasta pian ja täsmällisesti
- tehtävien jäsentely itsemääräämisoikeutta kunnioittaen on tarpeen hyviin tuloksiin
- vaihtoehtoiskustannus ohjaa jatkuvaa innovointia
Tiivistämme näistä kolme perusteesiä: testaus, ei testaaja, automatisoijan pelinavaus ja ajoittaminen yhteistoimintaan.
Testaus, ei testaaja
Testaus on liian tärkeää jätettäväksi vain testaajille. Testaus on myös liian tärkeää jätettäväksi ilman selkeää omistajuutta. Näiden välillä tasapainotellaan.
Monet nykyaikaisista kehittäjistä ovat erittäin taitavia testaajia; he välittävät kokonaisvaltaisesti toimivuudesta ja varmistavat sitä erittäin monipuolisesti. Kaikki organisaatiot eivät kuitenkaan tee tälle tilaa. Tätä teesiä voisi kutsua testaajan paradoksiksi – tulokset paranevat testaajan jakaessa testauksen. Kokemuksena on havaittu, että usein laatu heikkenee, kun tiimissä on enemmän testaajia. Työ on osattava jakaa kaikille tiimissä.
Laatutieto ei muuta laatua, vain tietoon reagointi vaikuttaa. Kehittäjät voivat reagoida oman testauksensa tuloksiin jatkuvasti tuomatta siihen muiden osapuolten osallistumisen kautta syntyvää kommunikointikustannusta.
Tutkivan nykytestauksen puitteissa ajattelemme asiaa elinkaarinäkökulmasta. Meillä jokaisella on eri mittainen ja muotoinen urapolku. Alan merkittävä kasvu vaatii porukan koon kasvattamista uusilla vielä kokemattomilla tekijöillä. Jokainen aloittaa oppimisen jostakin kulmasta ja yhdistelykyky kasvaa kokemusvuosien kertyessä.
Automatisoijan pelinavaus
Automatisoijan pelinavaus on shakkipelin aloitustilanteesta inspiroitunut teesi. Shakin avauksessa joutuu uhraamaan jotain voittaakseen lopussa. Vastaavasti käsin tehtävää testausta korostavassa testauskentässä automaatio koetaan uhrauksena. Automaation rajoitteista varoittamiseen käytetty aika on kuitenkin pois automaation onnistumiseen panostetusta ajasta.
Tutkiva nykytestaus lähtee siitä että automaatio on osa tutkivaa testausta. Osa tehdään läsnäolevalla (attended) tavalla, osa taas poissaolevalla (unattended). Tietokoneen voi jättää tutkimaan viimeisimpiä muutoksia herättäen tutkimaan tuloksia hälytysten perusteella. Sillä voi helposti tehdä koko viikon 30 minuutin välein toistuvaa tarkistelua raporttien oikeellisuudesta ja oikea-aikaisuudesta. Se on myös dokumentointia, joka antaa hälytyksen dokumentaation päivitystarpeesta. Automaation kirjoittaminen pakottaa yksityiskohtaiseen tekniseen tarkasteluun, jolloin löytää hienovaraisia virheitä, joita suurpiirteisemmässä tarkastelussa ohittaa.
Ajoittaminen yhteistoimintaan tiimin kanssa
Kolmas teesi korostaa toimivan palautteen luonnetta. Ajoituksen pitää olla oikea, reagointi testaamalla heti muutosten jälkeen. Tarvitaan hyvää yhteistoimintaa ja roolirajojen rikkomista. Testausta tekevä tekee päätöksiä siitä, mitä asioita nostaa keskusteltavaksi. Riittävä laatu on eri organisaatioissa ja eri ajankohtina erilainen.
Mikäli näet kirjoitusvirheen, sen saa varmimmin korjattua itse muuttamalla. Mikään ei estä testausta tekevää ottamaan ensiaskeleitaan koodipohjan muokkaamiseen harjoittelemalla versionhallintaa ja muuttamisen perusteita pikkukorjauksilla. Jos näet tärkeän virheen, jota et osaa korjata, voit valita raportoinnin sijaan pariohjelmoinnin ainakin osalle virheistä. Samalla kun virhe korjataan, saattaa myös virheen lähde (tiedon/huomion puute toteutuksessa) korjaantua. Ja samalla kasvatat omia taitojasi. Jos näet virheen, jota pidät tärkeänä, mutta joka hautautuu raportointijärjestelmään voi yhteistestaus (ensemble testing) saada vertaispaineen kautta ihmisiä reagoimaan eri tavalla samaan palautteeseen
Lopuksi
Pyydettäessä samalta ihmiseltä testien suunnittelua, testien suorittamista ilman automaatiota ja testien dokumentoimista ohjelmoimalla, kuulee usein työn sisältävän liikaa kontekstinvaihtoja. Meidät on opetettu ajattelemaan näitä mahdollisesti kolmen eri henkilön työnä. Eri henkilöiden työnä kussakin työssä opittujen asioiden soveltaminen yhteen erinomaisiksi testaustuloksiksi kärsii.
Sen sijaan että yksi suunnittelee, toinen testaa käsin ja kolmas ohjelmoimalla, kaikkien kolmen on hyvä opetella suunnittelua, käsin testaamista ja ohjelmointia. Lisäksi kannattaa tehdä testausta yhdessä ja oppia toisten tyyleistä. Testiautomaatiossa ei ohjelmoida käsin tehtyjä testejä, vaan luodaan ohjelmaa joka tuottaa merkittäviltä osin vastaavaa ja laajentavaa tietoa mahdollisimman ylläpidettävällä koodipohjalla. Mikäli ymmärrys tarvittavasta tiedosta perustuu toisen käden tietoon, automaatio on usein tuloksien puolesta heikkoa.
Perinteinen tutkiva testaus korosti että tiedot eivät välity testisuunnittelijalta toiselle kirjoitettujen testitapausten kautta, vaan testitapausten luomiseen liittyvän oppimisen kautta. Sama laajenee koskemaan automaatiota tutkivassa nykytestauksessa.
Aloitteleva testaaja voi aloittaa taitojen kerryttämisen monella tapaa. Taitojen yhdistäminen tuottaa erinomaista testausta, eristäminen tuottaa oppimisalustan. Pyydettäessä aloittelijalta yhdisteltyä testaamista ja dokumentointia automaatiolla on kokemus kontekstin vaihdosta todellinen. Tämän hyväksyminen pysyväksi tilaksi ei kuitenkaan nähdäkseni tuota erinomaista testausta. Etsin kolmea taitoa erinomaisessa testaukseen keskittyvässä ohjelmistokehittäjässä: sovellusalueeseen sitoutuvaa tuloksellista testaustaitoa; ohjelmoinnin matalasta päästä aloittavaa ohjelmallisten testien tekotaitoa; sekä tiimiyhteistyötaitoa, jossa sopivalla viestinnällä vältetään virheiden syntyä.
Maaret Pyhäjärvi toimii ohjelmistokehitystiimin vetäjänä Vaisalassa. Hän on testaaja, ohjelmoija, viisinkertainen TIVI ICT-100 vaikuttajaa -listalainen ja toistaiseksi ainoa maailmassa, joka on palkittu sekä ’EuroSTAR Testing Excellence Award’ että ’Most Influential Agile Testing Professional Person’ -palkinnolla. Oman toimen ohella Maaret vaikuttaa Tivia-yhteisössä Sytyke ry:n hallituksessa sekä Selenium-projektin johtoryhmässä.
Mirja Pyhäjärvi toimii johtavana testaajana Mezzoforte Oy:llä, testaten huutokaupat.com -palvelua. Mirja vaihtoi palvelualan ohjelmointia sisältävään testaustyöhön Python-ohjelmointikieltä hyödyntäen ja edennyt nopeasti urallaan siirtyen juniorista johtavaksi testaajaksi neljän vuoden aikavälillä.