Kun aloitin alalla, testaus oli ohjelmistoprojektien v-mallin mukaista manuaalitestausta, ja testiautomaatio oli ihan nurkan takana. Kymmenen vuotta myöhemmin se oli edelleen ihan nurkan takana.
Tässä kohtaa testiautomaatio oli yleensä pienimuotoista skriptien ajamista. Meni todella pitkään moneen muuhun tekniikkaan verrattuna, että Robot Framework, DevOps ja muut löivät kunnolla läpi. Silti manuaalitestaus on jäänyt taustalle, koska kaikkea ei kannata automatisoida. Nykyään mietitään testauksessa sitä, mitä automatisoidaan ja mitä ei.
Onko laatu parantunut? Nykyään ainakin testataan enemmän ja automaattisesti. Automaation ongelma on se, että jos siinä tekee virheen, sama virhe toistuu aina, ellei testejä ylläpidetä tai tarkasteta.
Manuaalitestauskaan ei ratkaise ongelmaa. Löysin esimerkiksi ensimmäisessä kesätyöpaikassani vuosia vanhan virheen puhelimen päänäkymästä. Tämä tuli esiin savutestissä, mutta tuossa isossa yrityksessä oli tapana laskea ajettuja testitapauksia ja ajoaikaa eikä löydettyjä virheitä. Saatiin siis sitä, mitä mitattiin.
Kesätyöläiselle ei kaikkea kerrottu, ja kuulin asiasta vasta vuosia myöhemmin. Silloin selvisi, miksi olin löytänyt tuon virheen, eikä kukaan muu. Muilla oli ollut kiire ajaa mahdollisimman paljon testejä läpi, eikä tavoitteena ollutkaan löytää mahdollisimman paljoa virheitä.
Käytännössä testaus on edelleen samanlaista eli tekniikat muuttuvat ja etsitään virheitä. Kun testaaja pääsee ohjelmaan sisään, hän saa tuntumaa siihen, mitä kannattaisi testata lisää ja miten yrittää rikkoa ohjelma.
Aiemmin testit suunniteltiin suoraan dokumenttien perustella, ja niitä käytettiin testaamisen tukena. Koodari testasi yleensä asiat jollain yleistapauksella, mitä testitkin olivat. Siksi parhaat bugit löytyivät, kun testejä ajoi kokeilemalla erilaisten syötekombinaatioiden lisäksi jotain ihan muuta. Kun virhe löytyi, siitä kohtaa kannatti testata enemmän.
Testiautomaation haasteena on se, että projekti koostuu ketterien menetelmien, kuten scrum-kehityksen mukaisesti käyttäjätarinoista (storyista). Speksin osat saattavat olla hajallaan, jolloin kokonaisuus saattaa isoissa projekteissa hämärtyä.
Joskus olen ollut projekteissa, joissa kaikkea ei ehditä suunnitella kunnolla, vaan lähdetään tekemään vauhdilla, kuten ketterään kehitykseen joskus kuuluu. Tämä saattaa kostautua myöhemmin. Kun keskitytään osatekijöihin, kokonaiskuva jää usein muodostumatta, vaikka juuri testiautomaatiossa sillä on isompi merkitys.
Muistan projektin, jossa oli testit, mutta niillä ei uutena projektiin tulleena tehnyt enää mitään, koska kaikki oli ehtinyt muuttua. Siksi unohdin ne ja tutustuin ohjelmaan kokeilemalla. Kun näkemystä alkoi olla, aloin vasta sitten kirjoittamaan testeille runkoa, jota tarkensin ajan mittaan. Vasta myöhemmin tarkistin tarkemmat tiedot. Näin sain aikaan varsin joustavat testit jatkoa varten.
Testiautomaation saaminen joustavaksi on haastavaa ketterissä projekteissa. Pienetkin koodimuutokset saattavat aiheuttaa suuria muutoksia testiautomaatioon. Testiautomaation suunnittelussa vaaditaan kokemusta, jotta isoja yllätyksiä ei synny.
Käytettävissä oleva rajallinen aika voi estää sen, että kaikkia testejä ei saada ajettua yön aikana tai tarvittavassa ajassa. Tuossa kohtaa hyvä suunnittelu korostuu entisestään. Olen yrittänyt kiertää näitä ongelmia ottamalla listasta ääriarvot, joista arvotaan käytetty arvo. Näin saadaan nopeammin käytyä läpi halutut arvot ja pidemmällä aikavälillä myös kombinaatiot.
Lisäkombinaatioita on mahdollista lisätä samalla tavoin erilaisille tilasiirtymille ja niistä palaamisille. Kun virheitä löytyy, lisää testitapauksia voi lisätä sinne tai muuhun kohtaan, missä odottaa virheitä olevan. Kaikkea ei siis edelleenkään ole mahdollista testata, mutta ainakin toistuvasti ajettavat manuaalitestit ovat vähenemään päin, vaikka testauksen määrä kasvaa.
Perinteisellä manuaalitestauksella on yhä puolensa DevOps:in laajetessa. Manuaalitestaus antaa paremmin tuntuman siihen, miten ohjelmaa käytetään. Testaaja löytää tätä kautta enemmän niitä hankalia virheitä, jotka vaativat monimutkaisen testitapauksen. Testiautomaation lisääntyessä virheet löytyvät nopeammin ja niitä löytyy enemmän, mutta oma näkemykseni on, että hankalimmat jäävät jäljelle. Kokonaisuuden kannalta tuo on varmasti parempi suunta.
Aiemmin testaus ja koodaaminen saattoivat olla erillään, jolloin syntyi vastakkainasettelua. Anarkistiset testaajat halusivat rikkoa sen, minkä koodarit tekivät. Testiautomaation ja alan kehittymisen myötä nykyään tehdään yhteistyötä jo alusta lähtien.
Vaikka testaaminen on muuttunut koko ajan teknisemmäksi, pelkällä osaamisella ei pitkälle pääse. Tuosta juontaa juurensa tuo otsikossa oleva työkaverin toteamus. Minulle kerrottiin joskus testaajan perversiosta: testaaja haluaa, ettei ohjelma toimi. Tämän vuoksi omasta koodista on vaikeampi löytää virheitä kuin toisten tuotoksista.
