Sunday 19 June 2011

Testausheuristiikat 3/7

HICCUPPS
Tämä viittaa tuotteen testauksessa oraakkeleihin. Eli mihin voit perustaa havaintojen oikeellisuuden. Oraakkeli on kuten heuristiikan yleensä "ehkä päteviä omassa kontekstissaan". Oraakkeli siis kertoo /mielipiteen/, joka ohjaa toimintaa tavalla tai toisella. Oraakkelit koostuvat seuraavista: H = History, I = Image, C = Comparable products, C = Claims, U = User expectations, P = Purpose, P = Product itsef, S = Standards. Nämä ovat ylseensä jo testauksen aikana tapahtuvia heuristisia ajatusmalleja. Näillä voidaan mitata tuotteen yhteneväisyyttä jonkin oraakkein kanssa. Onko se yhteneväinen asiakkaan esittämien lupausten kanssa? Onko se yhteneväinen itsensä kanssa?

Historia antaa aina ideoita testaukseen. Miten tuote käyttäytyi edellisissä versioissa, eilen, jne. Tämä osittain sisältää myös bugilistat.

Yrityksen antama kuva toimii heuristiikkana silloin, kun testauksen kohde on räikeästi tai hienovaraisesti pois yrityksen antamasta linjasta. Esimerkiksi Officetuotteissa on samantyyppinen ulkoasu, joten linjasta poikkavien asioiden huomaaminen on helppoa. Toisaalta esimerkiksi vakavarainen vakuutustoimija saattaa haluta ilmaista järjestelmillään luotettavuutta, jota kirjoitusvirheet sivuilla eivät edusta.

Verrokkituotteet ovat äärimmäisen hyvä oraakkeli. Jos on olemassa esimerkiksi tuotantoversio, johon tehdään päivitys, voidaan alkuperäisestä varmistaa toimintojen käyttäytymistä. Jos kilpailijalla on saman tyyppinen tuote, sitä voidaan käyttää vertailuun.

Lupaukset ja julkaisut ovat omiaan tuottamaan testausideoita. Manuaalit, helppi-tiedostot, mainokset, jne. voivat tarjota ideoita, jotka käyttäjän näkökulmasta sotisivat lupauksia vastaan. Lisäksi käyttöohjeiden testaaminen sovellusta vasten voi olla hyödyllistä myös käyttöohjeen itsensä kannalta.

Käyttäjän odotuksien kanssa yhteneväisyydessä saatta olla ongelmia. Jos olettaa esimerkiksi, että ohjelma käynnistyy automaattisesti ja se vaatiikin pääkäyttäjäoikeudet, saattaa virheilmoitus aiheuttaa närää käyttäjällä. Odotukset ylipäänsä ovat vahva oraakkeli, koska ne viittaavat siihen miten oikeasti tuotetta käytetään.

Tarkoituksen vastaan sotivien asioiden testaus saattaa herättää mielenkiintoisia kysymyksiä. Onko tarkoitus, että sääennustussovellus täyttää veroilmoituksesi? Onko tarkoituksenmukaista kaksoisklikata linkkiä, jos yksi painallus selvästi riittää?

Tuote itsessään voi olla ristiriidassa itsensä kanssa. Esimerkiksi saman tiedon näyttäminen samassa järjestelmässä eri tavalla. Tämä saattaa horjuttaa luottamusta tietojen oikeellisuuteen ("Älä pidä kahta kelloa laivassa. Jos toinen on väärässä, niin mistä tietää kumpi on oikeassa."). Ongelmia voi tulla eri näkymien erilaisuudesta tai vaikkapa virheilmoitusten yhteneväisyydestä.

Lait, asetukset, standardit tuovat oman mausteensa testaukseen ja yhtenevyys lakeihin esimerkiksi vakuutus- tai ilmailuhallintajärjestelmissä voi aiheuttaa jopa vaaratilanteita. (Se että turvallisuuskriittisten järjestelmien testaus ei aina ole viisasta pelkästää heuristiikkoja hyväksikäyttäen, on aivan toinen lukunsa.)

No comments:

Post a Comment