Artikkelin on kirjoittanut Maaret Pyhäjärvi. Tämä teos on lisensoitu Creative Commons Nimeä-Epäkaupallinen 4.0 Kansainvälinen -käyttöluvalla.
Creative Commons -käyttölupa

Vuosien testauskokemus on tuonut mukanaan enemmän varovaisen kuin positiivisen asenteen testauksen automatisointiin. Kuitenkin lukiessani alkusyksyllä 2012 Cem Kanerin blogiartikkelia oraakkeleista luulen tajunneeni jotain, mitä olen menettänyt keskittäessäni uskoni ja voimavarani pääasiassa älylliseen tutkivaan testaukseen – olen tyytynyt lopettamaan liian aikaisin miettiessäni miten prosessiani voi tehostaa ja miten itse voin kokonaisuutta parhaiten auttaa. Sääntöjä, joilla virheitä tunnistetaan pitää voida konkretisoida tasolle, jossa ne tehostavat ja laajentavat testiautomaation käyttöä.

Arvioinnin haaste

Testaamisen keskeisiä haasteita on ohjelmiston toiminnan moniulotteinen arviointi ja mahdollisen virhetilanteen tunnistaminen. Kun virhetilanne ohjelmistoa testaustarkoituksessa käytettäessä tulee kohdalle, kuinka testaaja tunnistaa sen? Miltä osin ja millä mekanismeilla voidaan luoda testiautomaatiota, joka tunnistaa oleellisilta osin oikean käyttäytymisen? Automaatio vähintäänkin helpottaa ihmisvoimin tehtävää testausta säästäen aikaa kun voi rajata huomiotaan kaikesta mahdollisesta asioihin, joita konevoimin on jo voitu etsiä.

Toiminnan puutteiden tunnistamisen ongelmaa kutsutaan oraakkeliongelmaksi. Lähtökohtana on, että testauksen kohteella on moniulotteinen alkutila, testatessa luodaan jonkinlaisia syötteitä ja herätteitä ja moniulotteista lopputilaa tehtyjen toimenpiteiden jälkeen tarkastellaan vertaamalla toteutunutta odotettuun tilanteeseen. Ohjelmistotestauksen oraakkeli on työkalu, joka auttaa päättämään onko ohjelma läpäissyt testin tuottamalla jonkinlaisen odotetun tilanteen johon verrata. Työkalu voi olla ohjelmallinen toteutus, tai se voi olla joukko nyrkkisääntöjä. Oraakkelit ovat heuristisia, ja auttavat tekemään päätöksiä, mutta tuottavat joskus väärän päätöksen.

On harvinaista että yksittäinen oraakkeli, joka vastaa kysymyksiin odotetusta tuloksesta johon verrataan, on käytännössä saavutettavissa tai edes olemassa. Sen sijaan testaajat luottavat osittaisiin oraakkeleihin. Esimerkiksi testaaja saattaa tunnistaa laskennan tuloksen olevan väärä siltä pohjalta että se on suhteettoman suuri vaikka ei tiedäkään tarkkaa tulosta, tai testaaja saattaa tunnistaa ohjelman käyttäytymisen vääräksi vaikka ei tiedä tarkkaan kuinka ohjelman tulisi käyttäytyä.

Oraakkeliymmärryksen monipuolisuus vaikuttaa suoraan testaajan kykyyn tunnistaa ongelmia. Testaaja, joka suorittaa ohjelmiston käytön liikkeet mutta ei tuota tarvittavaa tietoa ei ole hyödyllinen. Toisaalta, eri ihmiset luontaisesti kiinnittävät huomiota eri asioihin eri järjestyksessä. Esimerkiksi monille on vaikeaa arvioida syvällisesti toiminnallisuutta kun käyttöliittymä on karkea ja täynnä kirjoitusvirheitä. Toiset taas eivät näe kirjoitusvirheitä kuin osoitettaessa. Kyky nähdä asioita monipuolisesti ja arvioida mitä asioita on voinut keskittyä katsomaan tehdyn testauksen puitteissa ovat testaajan perustavaa laatua olevaa osaamista.

Huteja ja vääriä hälytyksiä

Luottaen oraakkeliin saattaa syntyä huti – uskot että ohjelma läpäisi testin vaikka se tekikin jotain väärin – tai väärä hälytys – uskot että ohjelma ei läpäissyt testiä vaikka se toimi tarkoitetusti. Voit väärin perustein päättää että ohjelma läpäisi testin koska sen antamat tulokset vastasivat odotettuja tuloksia, mutta se käyttäytyi väärin jollain muulla tapaa. Esimerkiksi ohjelma joka laskee 2+2=4 on selvästi rikki jos tuloksen aikaansaamiseen kuluu päivä. Voit myös väärin päättää että ohjelma ei läpäissyt testiä koska sen tulokset eivät vastanneet odotettua tulosta, mutta tarkempi tarkastelu paljastaa että et vain tiennyt ohjelman tekevän oikeaa asiaa. Esimerkiksi testatessa tietyn tulosteen tulostamista minuutissa joku toinen lähettää samalle tulostimelle pitkän dokumentin eikä testauksen kohde pääsekään tulostukseen. Monet testaajat, jotka tekevät testausta ihmisvoimin, eivät luultavasti tekisi kumpaakaan virhettä. Mutta automatisoitu testi tekisi molemmat virheet. Samaten sellainen testaaja, joka noudattaa annettuja ohjeita sanasta sanaan eikä käytä harkintaa.

Kumpikaan virhetyypeistä ei ole vältettävissä, sillä kukaan ei pysty täysin määrittämään alkutilaa eikä lopputilaa. Lisäksi, jos lähdet tarkastelemaan tilaa jollain toiminnolla, ko. toiminto muuttaa tilaa, joten tiedät tilanteen vain diagnostiikan ajon jälkeen, et ennen sitä. Oraakkelit ovat siis osittaisia ja heuristisia.

Yhdenmukaisuusheuristiikkoja

Ohjelmien odotetaan käyttäytyvän yleisten sääntöjen puitteissa yhdenmukaisesti. James Bach ja Michael Bolton ovat keränneet joukon hyödyllisiä yhdenmukaisuuden nyrkkisääntöjä, joista poikkeava käyttäytyminen testatessa auttaa tunnistamaan mahdollisen virhetilanteen. Vertailu voi olla tietoista tai tiedostamatonta. Erityisesti ne auttavat selittämään itselle ja sitä kautta muille miksi jokin havainto on oleellinen.

  • Yhdenmukaisuus järjestelmän sisäisesti. Toiminto käyttäytyy yhdenmukaisesti muihin saman järjestelmän toimintoihin tai toimintamalleihin verraten. Jos termistö eroaa, vastaavat toiminnallisuudet toimivat eri tavoilla tai näyttävät erilaiselta, näiden erojen nostaminen on useinkin tärkeinä koettuja havaintoja.
  • Yhdenmukaisuus vertailtaviin järjestelmiin: Toiminto käyttäytyy yhdenmukaisesti vastaaviin toisten vertailukelpoisten järjestelmien vertailukelpoisten toimintojen kanssa. Jos järjestelmä toimii oleellisesti eri tavalla kuin vastaavat muut järjestelmät, asian tietäminen voi vaikuttaa käyttäjien järjestelmävalintaan. Vertailukohtia voivat olla vaihtoehtoisten järjestelmien lisäksi järjestelmät joissa on ominaisuuksia joita emme halua, tai tietyt vertailukelpoiset toiminnallisuudet aivan toisen tyyppisistä järjestelmistä.
  • Yhdenmukaisuus historiaan. Nykyinen käyttäytyminen vastaa aiempaa käyttäytymistä. Jos jotakin on muuttunut ja kukaan ei ole maininnut muutoksesta, saattaa olla että muutos ei ole tarkoitettu.
  • Yhdenmukaisuus imagoon. Käyttäytyminen on yhdenmukaista organisaation haluaman mielikuvan kanssa ulkoisen tai sisäisen asiakkaan ja erilaisten asiakassegmenttien suuntaan. Jos järjestelmässä on piirteitä tai rajoitteita, jotka eivät istu yhteen organisaation itsestään tavoitteleman mielikuvan kanssa, saattaa olla että asiaa halutaan oikaista.
  • Yhdenmukaisuus väitteisiin. Käyttäytyminen on yhdenmukaista suhteessa dokumentaatioon, määrittelyihin tai mainoksiin. Jos joku sanoo tai kirjoittaa järjestelmän tekevän jotakin ja se ei sitä tee, asiaan saatetaan kaivata muutosta.
  • Yhdenmukaisuus standardeihin ja säädöksiin: Käyttäytyminen on yhdenmukaista ulkoisesti asetettuihin vaatimuksiin.
  • Yhdenmukaisuus käyttäjän odotuksiin: Käyttäytyminen on yhdenmukaista suhteessa siihen mitä luulemme käyttäjien haluavan. Käyttäjiä on monenlaisia, ja eri näkökulmista on tarpeen olla tietoinen, esim. loppukäyttäjä ja ylläpitäjä odottavat erilaista toiminnallisuutta ja toimivuutta.
  • Yhdenmukaisuus tarkoitukseen: Käyttäytyminen on yhdenmukaista järjestelmän tai toiminnallisuuden käyttötarkoituksen kanssa. Jos ohjelmalla voi tehdä asioita, joita ei pitäisi tai ei voi tehdä asioita joita pitäisi sen tarkoituksen täyttämiseksi, näistä on hyvä tietää.

Englanninkielinen lista hieman eri järjestyksessä muodostaa muistettavan lyhenteen HICCUPPS: History, Image, Comparable products, Claims, User expectations, Purpose, Product, Statutes&Standards.

Ohjelmoitavia oraakkeleita

Yhdenmukaisuusheuristiikat ovat yleisiä ihmisen käyttämiä ongelmaluokitteluja, ja niistä automaatiota tukevien oraakkelien johtamiseen on hieman matkaa. Testiautomaatioon tarvitaan riittävän yksityiskohtaisia ja toteuttamiskelpoisia, silti monipuolisia sääntöjä.

Doug Hoffman ja Cem Kaner ovat keränneet joukon yksityiskohtaisempien ja toteuttamiskelpoisten laajentavaa testiautomaatiota tukevien oraakkelien osalta, jotka auttavat tunnistamaan mahdollisen virhetilanteen.

  • Rajoiteoraakkeli. Tarkistetaan mahdottomia arvoja tai suhteita, esim. sähköpostiosoitteen muoto joka ei noudata vakiintuneita rajoitteita ei luultavasti toimi oikein.
  • Regressio-oraakkeli. Tarkistetaan nykyisen testin tuloksia suhteessa aiempaan testikertaan samalla testillä järjestelmän aiemmalla versiolla.
  • Itsensä tarkistava aineisto. Oikean vastauksen upottaminen testiaineistoon, esim. tarkistussummat.
  • Fyysinen malli. Vertailukohta testatessa fyysisen prosessin ohjelmistosimulointia, esim. painovoiman lait pelihahmon liikkeissä.
  • Liiketoimintamalli. Vertailukohta testatessa liiketoimintaprosessia mallintavaa ohjelmistoa, ehdotettujen ratkaisujen ohjelmistossa tulisi vastata mallia.
  • Tilastollinen malli. Kertoo että jokin tietty käyttäytyminen tai käyttäytymisten sarja on hyvin epätodennäköinen suhteessa tiettyyn toimintoon. Käyttäytyminen ei ole mahdoton, mutta siihen pitää suhtautua epäillen. Usein hyödyllinen tapa arvioida oikeellisuutta etsiessä kaavoja suuremmista aineistojoukoista.
  • Syöte-vastausjoukon tilastollinen oraakkeli. Järjestelmille joissa syötteillä on tunnettuja tilastollisia ominaisuuksia ja näiden ominaisuuksien tulisi vaikuttaa vastaavin säännöin vastausten joukkoon.
  • Tilamallit. Määritellään mitä ohjelma tekee vastineena syötteeseen, joka tapahtuu sen ollessa tunnetussa tilassa.
  • Vuorovaikutusmallit. Auttavat testaamaan kahden ohjelman välistä vuorovaikutusta määritellen miten ohjelmat käyttäytyvät vastineena toisen tekemiin toimintoihin.
  • Laskentaoraakkelit. Auttavat tarkistamaan laskentatuloksia. Esim. vertaaminen toiseen ohjelmaan joka tekee saman laskennan tai laskennan osittaminen varmistaen että osien poistaminen laskennasta tuottaa edelleen johdonmukaisia tuloksia.
  • Käänteisoraakkelit. Erikoistapaus laskentaoraakkelista, esim. listan järjestäminen laskevasta kasvavaan ja takaisin laskevaan suuntaan, saadaanko sama lista kuin alkujaan.
  • Referenssiohjelma. Ohjelma luo samat vastaukset joukolle syötteitä kuin testattava ohjelmisto. Joiltain osin referenssiohjelman käyttäytyminen eroaa testattavasta tai ne olisivat sama ohjelma.

Tämän tyyppisiä oraakkeleita voi ohjelmoida, ja niitä voi käyttää automaatiossa. Monipuolisten automatisoitavien oraakkelien tarve nousee erityisesti modernissa testiautomaatiossa, jossa ei koiteta toistaa osaa ihmistestaajan aiemmin tekemistä liikkeistä, vaan laajentaa automaatiota etsimään tarkoituksella virheitä joita on työlästä tai mahdotonta etsiä ihmisvoimin. Eri osaoraakkelit tarkistavat eri käyttäytymisiä ja oireita. Tämä auttaa poistamaan tietyn tyyppisiä ongelmia ja suoraviivaistaa prosessia, jossa ihmistä tarvitaan tarkkailemaan ulottuvuuksia joita automaatio ei kata.

Lopuksi

Cem Kaner on huomannut tarkkaillessaan osaavia ja taitavia opiskelijoita kursseillaan, että jostain syystä kuilu yhdenmukaisuus-heuristiikkojen ja ohjelmoitavissa olevien oraakkelien välillä on erityisen haastava kurottava. Tämä tukee omaa havainnointia minun työstäni testaajana. On liian helppoa piiloutua sen taakse, että tunnistan virheitä erilaisiin heuristiikkoihin ja listoihin perustuen, ja jättää ottamatta se askel että testatessaan ajatus mukanaan syventää ajatustaan askeleen automatisoinnin suuntaan. Jää miettimään:

Miten voisin yksityiskohtaisemmin kuvata miten ongelman tunnistaa ja miten sen voisi opettaa tietokoneelle?