Monday 17 October 2011

Testausheuristiikat 6/7

FDSFSCURA
Tekniikkoihin ja lähestymistapoihin pureutuva FDSFSCURA tarjoaa on omiaan kertomaan MITEN ja MITÄ kannattaa testata. Tekniikoita ovat siis: F = Function Testing, D = Domain Testing, S = Stress Testing, F = Flow Testing, S = Scenario Testing, C = Claims Testing, U = User Testing, R = Risk Testing, A = Automatic Testing. Tällä pyritään valottamaan sitä, että on useampiakin tapoja tehdä testausta kyseiseen tuotteeseen.

Toiminnallinen testaus on käytännössä sitä, että testataan "mitä voi tehdä". Tunnistetaan funktioiden ja toiminnallisuuksien tarkoamat ominaisuudet ja testataan niihin liittyviä asioita. Hyvä mittaamaan kykyä luotettavuuden sijaan. Toiminnallinen testaus on yleensä mukana muissakin heuristiikoissa tavalla tai toisella, mutta tässä tarkoitetaan nimenomaan toiminnallisuuden tarkastamista, että "se toimii oikein".

Toimialakohtainen testaus liittyy yleensä dataan. Kattamalla erilaisia datakombinaatioilla voidaan löytää asioita, joita puhtaasti toiminnallinen testaus ei löydä. Esimerkiksi vakuutusalalla on useita testaustekniikoita, testi-ideoita ja variaatioita, jotka koskevat vain ko. alaa. Myös logistiikka-ala, pankkiala, jne. sisältävät oman toimialan erikoistapauksia.

Stressitestauksella pyritään kyykyttämään järjestelmää parhaalla mahdollisella tavalla. Näin saadaan esiin muistivuotoja, validointivirheitä ym. jotka nousevat esiin vain paineen alla. Tietokantatasolla saadaan massatestauksella aikaan mahdolliset lukkotilanteet sekä datan ylikirjautuminen tai kirjautumatta jääminen.

Ketjuttamisella voidaan testata toimintoja toisen perään. Voidaan myös testata prosessia niin, että jätetään pakollisia toimintoja välistä tai tullaan prosessiin keskeltä mukaan. Näin löydetään ongelmia, jotka eivät ole riippuvaisia yhden toiminnallisuuden asioista. Mallipohjaisessa testauksessa testausautomaatiolla voidaan toteuttaa helpostikin pitkiäkin ketjuja sekä niiden variaatioita.

Skenaariotestauksella testataan asioita tuotteen ympäriltä sekä liittymistä. Skenaario on eräänlainen käyttötapaus, mutta joka on lähemmin yhteydessä todelliseen käyttöön ja ympäröiviin asioihin. Käyttötapauksia hyväksikäyttäen voidaan luoda sellaisia skenaarioita, missä on muuttujina esimerkiksi alusta, käyttäjän taito, aika, data ja/tai muut muuttujat.

Väitetestauksella tarkoitetaan siis määrityksiä, lupauksia, vaateita. Niitä testataan sekä tuotetta vasten ja tuotetta testataan niitä vasten. Tarkoitus on sekä tarkentaa "väitettä" ja tuotetta. Väitteet voidaan myös poimia asiakkaan tai tuotteen omistajan puheesta ja testata, josko "luvataan liikoja".

Käyttäjätestaus liittyy usein käyttäjän kykyihin käyttää järjestelmää. Miten punavihersokea pystyy aistimaan dashboradin elementit? Miten ummikko pystyy käyttämään kompleksista toiminnanohjausjärjestelmää? Entä käyttäjät, jotka käyttävät suoraan ohjeesta? Entä käyttäjät, jotka kokeilevat ja testailevat tuotetta?

Riskitestauksella pyritään tunnistamaan riskejä ja yrittämään toteuttaa ne. Voiko riskin toteuttaa järjestelmällä? Voiko siitä seurata ongelmia? Tässä kannattaa käyttää hyväksi asiantuntemusta myös liiketoiminnasta ja kehittäjiltä, jotta voidaan löytää ne suurimmat rsikit omaavat osa-alueet. Riskitestauksella voidaan myös mitigoida riskejä tai nostaa esiin uusia riskejä.

Automaatiotestaus tarkoittaa käytännössä testi ajamista tuhanisa kertoja tai automatisoimalla testin muuttumaan hieman. Näin voidaan nopeasti kehittää suuri määrä testejä joilla voidaan löytää ongelmia, joita manuaalinen testaus ei löydä. Esimerkiksi Brute force -tietoturvatestaus löytää helpommin aukkoja tietoturvasta kuin manuaalisesta samojen testien ajaminen. Lisäksi tietoturvatestausta harvemmin kannattaa toteuttaa manuaalisesti, sillä usein tietoturva-aukkoja etsitään koneitse.

Wednesday 12 October 2011

Testaajat eivät ehdi testata

Oli taas yksi niistä päivistä eilen, että aloin miettimään ammattivalintaani. Rakastan testausta ja kaikkea siihen liittyvää, mutta erityisesti pidän testaamisesta (ei testauksesta). Meillä oli miesvajausta ja päätin heittää hallinnollisen viittani naulakkoon ja kääriä hihat.

Istuttuani testauspenkkiin ajattelin nopeasti ajaa savutestisetit läpi ja aloittaa kunnon testauksen. Kopeana ja ylpeänä aloin ajamaan rajapintatestejä, jotka kaikki napsahtivat punaiselle. "Pannahinen" sanoin. Oletin ensimmäisenä, että vika on järjestelmässä. Tarkistin tilanteen ja totesin, että systeemi käy ja kukkuu. Olin ampunut testit väärään endpointiin.

Korjasin testit ja ajoin ne uudelleen. Noin 40% meni punaiselle. "Pannahinen" sanoin. "Eipäs tämä järjestelmä toimi yhtään niinkuin pitäisi!" Sitten tarkistelin virheilmoituksia ja assertioita. Näemmä olin innostuksissani päivittänyt testejä niin, että testit sisälsivät tyhjiä elementtejä, jotka rikkoivat testit.

Korjasin taas testit ja nyt sain kaikki paitsi 10 vihreiksi. "Pannahinen" sanoin ja pyyrin toisen testaajan katsomaan tuloksia. Hän vain totesi, että "toimiihan tuo. Olen sitä käyttöliittymän läpi testannut jo puoli tuntia."

--

Kun on pidemmän aikaa tekemättä jotakin, niin taidot ruostuvat - faktahan se on. Ne vaan eivät ruostu meidän päässämme. Me olemme omasta mielestämme edelleen niitä "huipputestaajia" ja "buginmetsästäjiä", mitä olimme puoli vuotta sitten. Kun pääsee sorvin ääreen uudelleen, niin hetki siinä menee palautellessa niitä taitoja taas sormenpäihin.

Tämän aion välttää jatkossa tekemällä harjoitteita, joita itse annan testaajilleni. Esimerkiksi ParkCalc-tyyppisiä testausrupeamia (kiitos plyytinen), joilla pystytään harjoittamaan kriittistä ajattelua ja testi-ideoiden kehittämistä.