Tekoäly on muuttanut ohjelmistokehitystä ja -testausta lopullisesti. AI-työkaluilla koodia syntyy moninkertaisesti enemmän ja nopeammin, jonka ohella AI voi lisäksi kirjoittaa unit-testejä, rakentaa testiautomaatiota, testausympäristöjä, korjata virheitä ja tehdä jopa koodikatselmointia.
Testit vihreänä – mutta rakennettiinko asia oikein?
Ajatellaan yksinkertaista tilannetta:
- Kehittäjä antaa AI:lle tehtäväksi toteuttaa uuden ominaisuuden.
- AI tulkitsee vaatimuksen, kirjoittaa toteutuksen ja generoi sille unit-testit.
- Testit menevät läpi ja CI näyttää vihreää.
- Kaikki näyttää hyvältä kohti tuotantoa!
Vihreä testitulos kertoo silloin, että ohjelmisto toimii testille määritellyn tarkistuksen mukaisesti, mutta se ei vielä kerro, oliko oletus oikea.
Silloin meillä voi olla täysin toimiva toteutus ja kattava joukko läpäiseviä testejä, jotka molemmat perustuvat samaan väärään oletukseen.
- Entä jos AI ymmärsi alkuperäisen vaatimuksen väärin?
- Entä jos kehittäjä promptasi ylimalkaisesti?
- Entä jos AI:lle syötettiin lisätietona virheellinen speksi?
Kuka siis testaa tämän oletuksen ja antaa palautteen, että toteutus toimii oikein?
Historiaa: Testaaminen on muutakin kuin tarkistamista
Ohjelmistotestausalan luultavasti tunnetuimmat gurut, James Bach ja Michael Bolton, ovat jo pitkään tehneet eroa checking– ja testing-käsitteiden välillä. Yksinkertaistettuna checking tarkoittaa ennalta määritellyn asian tarkistamista: kun tapahtuu X, saammeko tuloksen Y? Tällaiseen tietokone on erinomainen.
Testing on laajempi prosessi. Siihen kuuluu tuotteen tutkimista, oppimista, riskien arviointia ja uusien kysymysten muodostamista sen perusteella, mitä testaaja havaitsee.
Bachin ja Aaron Hodderin vuosia sitten kirjoittamassa Test Cases Are Not Testing -artikkelissa asiaa verrataan osuvasti työkalun ja varsinaisen työn suhteeseen: automatisoitava tarkistus on osa testausta, mutta se ei yksin ole testaamista.
Bach ja Hodder korostavatkin testaamisessa vaikeasti mekanisoitavia taitoja, kuten kysymistä, yhteistyötä ja systeemiajattelua. Testaaminen ei heidän ajattelussaan ole ennalta kirjoitetun testitapauksen mekaanista suorittamista, vaan tutkivaa ja arvioivaa toimintaa, jossa seuraava kysymys voi syntyä vasta edellisen vastauksesta.
Vaikka artikkeli on julkaistu kauan ennen ”AI-hypeä”, tuo erottelu tuntuu juuri nyt erittäin ajankohtaiselta.
Automatisoidulla tarkistamisella voidaan tehokkaasti selvittää, käyttäytyykö ohjelmisto kuten ennalta määriteltiin. Laajempi testaaminen kysyy lisäksi, oliko määrittely oikea, mitä siitä jäi puuttumaan ja mitä muuta ohjelmisto voi tehdä.
Testaaja testaa siis myös oletuksia!
Mutta tekeehän AI myös checkingistä aiempaa tehokkaampaa?
Aivan oikein! AI pystyy tuottamaan valtavia määriä testejä murto-osassa siitä ajasta, joka niiden tekemiseen aikaisemmin kului.
Mutta kaiken AI-kohinan keskellä unohdamme helposti, ettei testien määrä ole sama asia kuin testauksen laatu. Ajettujen testien suuri lukumäärä ei ole myöskään laadukkaan lopputuloksen synonyymi.
James Bach varoitti jo Test Automation Snake Oil -artikkelissaan tilanteesta, jossa automaatiotestien määrä kasvaa niin suureksi, ettei lopulta kukaan enää kunnolla tiedä, mitä testikokonaisuus tosiasiassa testaa – tai mitä tuotteen “testien läpäiseminen” oikeastaan kertoo sen laadusta.
Bachin mukaan automaation arvoa ei siksi pitäisi arvioida ensisijaisesti testien määrällä. Oleellisempaa on ymmärtää, mitä testit kattavat, mitä ne eivät kata ja millaista tietoa niiden tulokset todella antavat tuotteesta.
Hänen loppupäätelmänsä on yksinkertainen: “think about testing first and automation second.”
Generatiivinen AI poistaa nyt yhden aikaisemman luonnollisen rajoitteen: testien tekemisen kustannuksen. Jos aikaisemmin sadan automaatiotestin rakentaminen vaati paljon työtä, AI voi generoida niitä tuhansia, jolloin testien tuottamisesta tulee myös halpaa.
Sen sijaan sen ymmärtämisestä, ovatko ne oikeita testejä oikeille riskeille, voi tulla entistä arvokkaampaa.
Siksi olennaisempi kysymys ei välttämättä enää ole:
”Kuinka paljon meillä on automatisoituja testejä?”
vaan
”Kuinka tehokkaasti testaamme oikeita asioita?
Helppo homma! AI myös tarkistaa AI:n luoman työn?
Agenttipohjainen kehitys vie tätä otsikkoa jatkuvasti pidemmälle.
OpenAI kirjoitti omista kokeiluistaan, jossa pieni insinööritiiminsä rakensi Codexilla viidessä kuukaudessa noin miljoonan rivin ohjelmistokokonaisuuden ilman ihmisen käsin kirjoittamaa koodia. Codex tuotti sovelluskoodin lisäksi testit, CI-konfiguraatiot, dokumentaation, observability-ratkaisut ja sisäisiä työkaluja.
Kehitysnopeuden kasvaessa vastaan tuli kuitenkin kiinnostava ongelma: ihmisten QA-kapasiteetista tuli pullonkaula. Ratkaisuksi OpenAI alkoi tehdä itse sovelluksesta ja sen ympäristöstä AI:lle paremmin tutkittavan. Codexille annettiin mahdollisuus käynnistää ja käyttää sovellusta, navigoida käyttöliittymässä, tutkia DOM-rakennetta ja kuvakaappauksia sekä analysoida lokeja, metriikoita ja traceja. Näin agentti pystyy esimerkiksi reprodusoimaan bugin, tekemään korjauksen ja validoimaan korjauksen itse.
Myös katselmointi vietiin pitkälle: Codex katselmoi omat muutoksensa, pyytää erillisiltä agenteilta lisäkatselmointeja ja korjaa työtään palautteen perusteella, kunnes agenttikatselmoijat ovat tyytyväisiä. OpenAI kertoo siirtäneensä ajan myötä lähes kaiken katselmointityön agenttien väliseksi.
Tämä näyttää todennäköisesti suuntaa sille, mihin ohjelmistokehitys laajemminkin menee.
Palautesilmukat nopeutuvat ja automatisoituvat jatkuvasti: AI havaitsee ongelman, tekee muutoksen, tarkistaa lopputuloksen, saa palautetta ja korjaa toimintaansa.
Mutta yksi kysymys jää edelleen jäljelle:
Kuka haastaa AI:n tekemät oletukset, jos sama AI tulkitsee tehtävän, rakentaa ratkaisun ja arvioi lopputuloksen?
Mikäli sama AI-vetoinen kehitysketju tulkitsee vaatimuksen, tekee toteutuksen, generoi testit ja arvioi lopputuloksen, riippumattoman näkökulman merkitys ei välttämättä vähene.
Se saattaa päinvastoin kasvaa.
Tässä tutkiva testaus tulee kuvaan
Tutkiva testaus ei tarkoita ihmistestaajaa, joka suorittaa valmiiksi kirjoitettua testitapauslistaa. Sellaisen suorittavan työn automatisointi on jo pitkällä – ja AI pystyy yhä enemmän myös mukauttamaan testaamistaan havaintojensa perusteella.
Tutkivan testaajan tehtävä on kuitenkin tätä laajempi. Hän muodostaa käsitystä tuotteesta ja sen riskeistä, kyseenalaistaa omia ja muiden oletuksia, tulkitsee havaintojen merkitystä ja päättää jatkuvasti, mikä olisi arvokkain seuraava kysymys tuotteelle.
- Mitä tapahtuu, jos käyttäjä toimii tavalla, jota speksissä ei ajateltu?
- Mitä tapahtuu väärässä järjestyksessä?
- Mitä tapahtuu poikkeavalla datalla?
- Mikä näyttää teknisesti toimivalta mutta on käyttäjän näkökulmasta täysin järjetöntä?
- Miksi sisältö näyttää tältä?
- Onko loppukäytön kannalta keskeiset ominaisuudet ja oikeudet toteutettu oikein?
- Mitä jos…näissä olosuhteissa…tällä käyttötyylillä…näillä poikkeuksilla…?
Mitä pidemmälle AI automatisoi toteuttamisen ja tarkistamisen, sitä enemmän ihmisen arvo siirtyy suorittamisesta intentioon, riskiin, arviointiin ja riippumattomaan harkintaan.
Juuri siksi ihmisen tutkivalle ajattelulle, riippumattomalle harkinnalle ja mielikuvituksen käytölle jää edelleen tärkeä rooli – vaikka yhä suurempi osa ohjelmiston laadunvarmistusprosessista automatisoituisikin AI:n johdolla.
Summa summarum: AI ei poista tutkivan testauksen tarvetta.
Uskomme, että AI tulee vähentämään merkittävästi perinteistä manuaalista testien suorittamista. Se on hyvä kehityssuunta. Ihmisen aikaa ei kannata käyttää sellaiseen, minkä kone pystyy tekemään nopeammin ja toistettavammin.
Mutta samalla ohjelmistoa pystytään tuottamaan enemmän ja nopeammin kuin koskaan aikaisemmin.
Siksi ihmisen rajallinen testausaika kannattaa käyttää siellä, missä siitä saadaan eniten arvoa: riskien tutkimiseen, oletusten haastamiseen ja sellaisten ongelmien etsimiseen, joita kehitysprosessi ei itse osannut ennakoida. Tulevaisuuden laadunvarmistuksessa ei ehkä olekaan tärkeintä se, kuinka monta testiä pystymme suorittamaan.
Yhteenveto
Automaatiolla tarkistamme tehokkaasti sen, mitä osaamme odottaa.
Tutkivalla testauksella etsimme sitä, mitä emme osanneet odottaa.
AI:n aikakaudella tarvitsemme molempia – ensimmäistä enemmän kuin koskaan ja jälkimmäistä ehkä juuri siksi.
Janne Lepistö,
Test specialist & CEO, Qubilea Oy
+358 50 487 3265 / janne.lepisto@qubilea.fi
Lue lisää testauspalveluistamme >>
Tutustu myös muihin artikkeleihimme:
