Test Automation Results -tulosten oikea arviointi

Regressiotesti voi aamulla päättyä 98 prosentin onnistumisosuuteen eikä silti ole hyvä uutinen. Ehkä epäonnistunut testi on juuri suurasiakkaan kirjautuminen. Ehkä 40 testiä jätettiin väliin, koska testiympäristöön ei saatu yhteyttä. Tai ajo oli vihreä, mutta tarkisti vain, onko painikkeita olemassa, ei sitä, tallentuuko tilaus todella, syntyykö toimituskirja ja korjaantuuko varasto oikein. Test automation results eivät ole laatuväite, niin kauan kuin niiden konteksti puuttuu.

QA-johdolle, kehitykselle ja liiketoimintayksiköille varsinainen työ ei siksi ole pelkästään testien automatisointia. Ratkaisevaa on valmistella tulokset niin, että niistä syntyy luotettavia päätöksiä: voidaanko julkaisu viedä tuotantoon? Täytyykö virhe käsitellä heti? Onko virhe uusi, palannut vai vain testiympäristön ongelma? Ja onko olemassa todisteita, jotka myös liiketoimintayksikkö ilman testikoodia voi ymmärtää?

Mitä Test Automation Results todella kertovat

Yksinkertaisin tunnusluku on: läpi tai hylätty. Se on hyödyllinen, mutta harvoin riittävä. Korkea onnistumisosuus voi luoda luottamusta, jos testit kattavat kriittiset kulut, testidata on uskottavaa ja ympäristö muistuttaa myöhempää käyttöä. Jos yksi näistä tekijöistä puuttuu, luku jää ennen kaikkea merkiksi siitä, että automatisoitu ajo suoritettiin.

Liiketoimintakriittisissä sovelluksissa muut kysymykset painavat enemmän. Varastoratkaisussa jokainen näyttö ei ole yhtä tärkeä. Sisäisen ohjetekstin esitysvirhe voi odottaa. Virhe, joka kirjaa tavaran vastaanotossa väärän määrän tai luo lähetystarran ilman vastaanottajan osoitetta, ei voi. Hyvät testitulokset painottavat siksi riskejä sen sijaan, että kohtelisivat kaikkia tapauksia samoin.

Myöskään epäonnistunut testi ei ole automaattisesti tuotevirhe. Sen voivat aiheuttaa vanhentuneet tunnukset, lukittu testirooli, saavuttamattomat rajapinnat, muuttunut testidata tai hidas ympäristö. Joka ei erota näitä syitä, tuottaa kohinaa. Tiimi käyttää silloin aikaa vääriin hälytyksiin, kun todelliset virheet hukkuvat punaisten tilailmoitusten joukkoon.

Neljä tilatyyppiä yhden punaisen listan sijaan

Käytännössä selkeä jaottelu on osoittautunut toimivaksi: toiminnallinen virhe, tekninen testivirhe, ympäristöongelma ja odotettu muutos. Toiminnallinen virhe tarkoittaa, että sovellus rikkoo määritellyn vaatimuksen. Tekninen testivirhe viittaa pikemminkin itse testiin, esimerkiksi valitsimeen, joka ei enää sovi tarkoituksella muutetun käyttöliittymän jälkeen.

Ympäristöongelma on kyseessä, kun esimerkiksi testijärjestelmä tai liitetty rajapinta ei ole käytettävissä. Odotettuja muutoksia syntyy, kun prosessia on tietoisesti muutettu, mutta automaatio tarkistaa yhä vanhaa tavoitetilaa. Nämä luokat eivät estä jokaista keskustelua. Mutta ne varmistavat, että keskustelu alkaa oikeasta kohdasta.

Testiajoista päätöskelpoisiin raportteihin

Käyttökelpoinen raportti ei vastaa vain siihen, että jokin epäonnistui, vaan siihen mitä tapahtui, kuinka vakavaa se on ja vaikuttaako virhe toistettavalta. Siihen tarvitaan enemmän kuin luettelo testien nimistä ja aikaleimoista.

Jokaiseen olennaiseen ajoon kuuluvat testattu build, testiympäristö, käytetty rooli, keskeinen testidata sekä alkamis- ja päättymisaika. Etenkin Windows-työpöytäsovelluksissa tai monimutkaisissa verkkoalustoissa nämä tiedot ovat tarpeen erojen rajaamiseksi. Virhe, joka ilmenee vain rajoitetulla varastoroolilla, on eri asia kuin virhe, joka estää jokaisen kirjautumisen.

Merkitykselliset tulokset sisältävät lisäksi jäljitettäviä todisteita: kuvakaappauksia, tallennettuja vaiheita, virheilmoituksia ja tarvittaessa teknisiä lokeja. Pelkkä kuvakaappaus voi kuitenkin harhauttaa. Se näyttää hetken, ei syytä. Vaiheiden järjestyksen, näkyvän tilan ja odotetun reaktion yhdistelmä on huomattavasti hyödyllisempi.

Tekoälyavusteiset järjestelmät voivat muuttaa nämä todisteet ymmärrettäviksi arvioiksi. COCOssa esimerkiksi testit ajetaan omalla, itse isännöidyllä tekoälypalvelimella. Arviointi voi selittää, että tilaus kyllä luotiin, mutta odotettu tilanmuutos jäi tapahtumatta, ja liittää ajon tallenteen suoraan. Turvallisuustietoisille tiimeille on olennaista, missä kuvakaappauksia, sovellusdataa ja testiliikennettä käsitellään. Paikallinen hallinta ei ole automaattisesti välttämätöntä, mutta sisäisissä sovelluksissa ja arkaluonteisessa datassa se voi olla järkevämpi tie kuin ulkoinen pilvipalvelu.

Oikea yksityiskohtaisuus eri vastaanottajille

Kehitystiimit tarvitsevat virheilmoituksia, teknisiä vaiheita ja mahdollisimman tarkkoja ohjeita toistamiseen. Operations managerille taas tärkeintä on ensin kyseessä oleva toiminto, liiketoimintariski ja selkeä lausuma toimintakyvystä. Molempien näkökulmien täytyy voida syntyä samasta suorituksesta, ilman että kenenkään tarvitsee siirtää tuloksia käsin esityksiin.

Hyvä raportti alkaa siksi lyhyellä päätöstasolla: julkaisu suositeltu, julkaisu tunnetuin rajoituksin tai julkaisu pysäytetään. Sen alla ovat kriittiset poikkeamat prioriteetteineen ja todisteineen. Tekniset yksityiskohdat seuraavat vasta sen jälkeen. Se ei ole yksinkertaistus tarkkuuden kustannuksella, vaan tiedontarpeiden siisti erottelu.

Kattavuuden mittaaminen ilman näennäisturvaa

Testikattavuus esitetään usein prosenttilukuna. Tämä arvo on hyödyllinen, kun on selvää, mitä se mittaa. Koodikattavuus näyttää esimerkiksi, mitkä ohjelmakoodin osat suoritettiin testien aikana. Se ei todista, että liiketoimintaprosessi toimii oikein. Testi voi koskettaa monia koodirivejä eikä silti koskaan tarkista, näkyykö väärä toimitusosoite asiakirjassa.

Liiketoimintayksiköille prosessikattavuus on usein kuvaavampi. Se kuvaa, mitkä todelliset kulut on suojattu: tilauksen tallennus, varaston varaus, osatoimituksen kirjaus, palautuksen vastaanotto tai laskun hyväksyntä. Erityisen arvokkaita ovat siirtymät järjestelmien ja roolien välillä, sillä siellä virheitä syntyy usein: tilauksen tuonnissa, tarran tulostuksessa tai siirryttäessä toimistosta varastopäätteelle.

Älä priorisoi mahdollisten testien määrän mukaan, vaan vahingon vaikutuksen ja muutostiheyden mukaan. Harvoin käytetty prosessi, jolla on suuri taloudellinen tai oikeudellinen riski, ansaitsee usein automatisoinnin aiemmin kuin usein käytetty mutta vaaraton näkymä. Toisaalta vakaa, vähän kriittinen kulku voi yhä tulla toimeen lyhyellä manuaalisella tarkistuksella. Kaikkea ei tarvitse automatisoida vain siksi, että se on automatisoitavissa.

Epävakaat testit ovat oma laatuongelmansa

Testejä, jotka ilman tunnistettavaa tuotemuutosta välillä läpäisevät ja välillä epäonnistuvat, kutsutaan usein flaky-testeiksi. Ne vahingoittavat luottamusta nopeammin kuin pysyvästi punainen testi. Heti kun tiimit käynnistävät punaiset tulokset refleksinomaisesti uudelleen, automaatio menettää varoitustoimintonsa.

Syyt ovat yleensä konkreettisia: kovakoodatut odotukset, yhteiskäyttöinen testidata, rinnakkaiset käytöt, asynkroninen käsittely tai ympäristö, jota ei palauteta. Lyhyt kolmen sekunnin tauko testissä voi sattumalta auttaa, mutta se ei ole ratkaisu. Parempi on odottaa todennettavaa tilaa, tehdä testidata yksiselitteiseksi ja eristää kulut toisistaan.

Kaikkea epävakautta ei voi välttää kokonaan. Ulkoiset rajapinnat voivat vaihdella, ja todellisessa infrastruktuurissa on katkoja. Silloin raportin tulisi selvästi merkitä, ettei testiä voitu arvioida ulkoisen riippuvuuden vuoksi. Toistettu ajo voi olla järkevä diagnoosiin, mutta ei saa tehdä ensimmäistä löydöstä näkymättömäksi.

Järkevä kulku jokaisen testiajon jälkeen

Automatisoidun ajon jälkeen ei kaikkia tuloksia pitäisi heti kohdella samoin. Ensin tarkistetaan estävät virheet ja arvioimattomat kriittiset testit. Sen jälkeen uudet poikkeamat luokitellaan tunnettuihin, hyväksyttyihin ongelmiin nähden. Vasta sitten julkaisupäätös on kestävä.

Määritellyt kynnysarvot auttavat, mutta niiden täytyy sopia prosessiin. Esimerkiksi epäonnistunut testi maksu- tai käyttöoikeusvirrassa voi laukaista välittömän pysäytyksen. Puhtaasti kosmeettisessa poikkeamassa dokumentoitu poikkeus voi olla perusteltu. Tällaisia sääntöjä ei pitäisi luoda vasta aikapaineessa ennen julkaisua.

Yhtä tärkeää on palaute: jokainen tuotantovirhe, jota testit eivät havainneet, on syy tarkistaa, puuttuuko skenaario, testidatavariantti tai tarkistuspiste. Tavoite ei ole kasata mahdollisimman monta testiä. Se on rakentaa todellisista virheistä kohdennetusti parempaa suojaa.

Hyödyllisimmät testitulokset eivät lopulta ole niitä, joiden yleiskuva on vihrein. Ne ovat niitä, joiden perusteella vastuuhenkilö voi maanantaiaamuna ymmärtää, mitä tarkistettiin, mikä riski jää ja mikä toimenpide on nyt järkevä.