Sanapari Ad hoc tulee latinan kielestä ja se tarkoittaa "for this" - tätä varten. Sanaparia käytetään yleisesti etuliitteenä tapauksissa, joissa pitää nopeasti keksiä ratkaisu jotain tiettyä, usein yllättäen esiintynyttä, tapausta varten. Sama pätee myös Ad hoc -testauksessa.

Määritelmänsä mukaisesti Ad hoc -testaus on siis epäformaali prosessi, joka tehdään ilman suunnittelua tai dokumentointia. Sitä käytetään tyypillisesti, kun formaali, strukturoitu testaus on päättynyt, mutta järjestelmästä on silti löytynyt jokin bugi ja siitä pitäisi päästä nopeasti eroon ennen tuotantoon vientiä. Tällöin vian syy pitää löytää nopeasti, eikä testisuunnitteluun jää aikaa.

ISTQB Exam Certificationin (2016) artikkeli nostaa esiin viisi parasta käytäntöä (best practices) Ad hoc -testauksessa:

• Testaajalla on syvä tuntemus testattavasta järjestelmästä
• Testaus priorisoidaan koskemaan järjestelmän tärkeimpiä osia
• Voidaan tehdä kevyt, karkea testaussuunnitelma
• Testaaja hyödyntää työkaluja järjestelmän tehokkaassa tutkimisessa
• Havainnot dokumentoidaan, vaikka prosessia ei dokumentoitasi

Ad hoc -testauksen ehdottomana etuna ja ehkä ainoana syynä, jolla sen käyttöä voi hyväksytysti perustella, on sen kyky löytää vakavia virheitä nopeasti. Järjestelmän hyvin tunteva testaaja osaa tunnistaa järjestelmän vikaherkimmät osat ja kohdistaa testauksensa niihin osiin tehokkaasti. Ad hoc -testaus voi siten löytää virheitä, joita ei havaittu, eli ei siis testattu, formaalissa testausprosessissa. Tämä voi paljastaa mahdollisia virheitä itse testausprosessissa.

Kuitenkin Ad hoc -testausta pitäisi tehdä mahdollisimman vähän, sillä sen liiallinen käyttö kertoo strukturoimattomasta ja toimimattomasta testausprosessista, joka itsessään antaa syytä huoleen testauksen laadusta. Ammattimaisen ohjelmistotestauksen pitäisi olla aina formaalia, strukturoitua ja jäljitettävää. Siksi Ad hoc -testausta pitäisikin käyttää mahdollisimman vähän, tapauskohtaisesti, ad hoc.

Lähteet:
Ad hoc -testing, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Ad_hoc_testing
"What is Ad hoc testing? Types, advantages and disadvantages". ISTQB Exam Certification, Saatavilla: http://istqbexamcertification.com/what-is-ad-hoc-testing/

Ei savua ilman tulta (Mitä on smoke testing?)

Smoke testing, joka tunnetaan myös nimillä confidence testing, sanity testing, build verification test (BVT) ja build acceptance test, tarkoittaa ohjelmiston valmistavaa testausta ennen julkaisua, jonka tarkoituksena on varmistua siitä, että ohjelmiston tärkeimmät ominaisuudet toimivat. Smoke-testaus suunnitellaan siten, että testicaset kattavat järjestelmän tai sen moduulin kriittisimmän toiminnallisuuden. Mutta mikä on se syy, miksi smoke-testausta tehdään?

Nykyaikaisten ohjelmistojen arkkitehtuuri perustuu yksittäisiin moduuleihin, jotka toteuttavat tietyn toiminallisuuden ja siihen, että moduulit viestivät ja toimivat keskenään yhteen. Useiden eri moduulien muodostamat kokonaisuudet ovat usein hyvin monimutkaisia, jolloin vain harvalla on kokonaiskuva järjestelmän täydellisestä toiminnasta ja siitä, miten yksittäisten moduulien toiminta vaikuttaa koko järjestelmään. Usein esimerkiksi alimman tason moduulin toteutus on hämärretty, eikä ohjelmistokehittäjää edes kiinnosta, miten sen sisäinen logiikka on toteutettu, kunhan moduulin tuottama output-data on oikeanlaista muiden moduulien käyttöön.

Tässä kuitenkin piilee inhimillisen virheen mahdollisuus. Nykyaikainen ketterä, agile, ohjelmistokehitys on nimensä mukaisesti nopeatahtista ja yksittäisiä moduuleja päivitetään tai muutetaan päivittäin. Koska nämä moduulit ovat tiivisti yhteydessä muihin moduuleihin, pienikin, harmittomalta vaikuttanut muutos yhden moduulin toiminnassa voi rikkoa koko järjestelmän yhteistoiminnan, odottamattomasti.

Tämän takia päivittäistä kääntämistä (daily build) ja sen automatisoitua smoke-testausta pidetään yhtenä ohjelmistokehityksen "hyvistä käytännöistä", best practices. Päivittäisellä automatisoidulla smoke-testauksella saadaan kiinni kaikki  ne odottamattomat bugit, jotka syntyivät kehittäjän eilen tekemästä muutoksesta. Bugit havaitaan siten ajoissa ja toimiva ohjelmistoversio voidaan palauttaa ennen kuin epätoimivaa ohjelmistoversiota ehditään kehittää pidemmälle. Testaajina tiedämme, että tämä tarkoittaa mahdollisesti suuria säästöjä niin ajassa, rahassa kuin miestyövuosissakin.

Smoke-testauksella voidaan siis saada nopea vastaus ohjelmiston yleisen tason toimivuudesta. Sen tehtävänä, kuten testauksella yleisestikin, on luoda luottamusta ohjelmiston laatuun. Smoke-testauksella voimme olla varma, että meidän jokapäiväinen buildimme toimii huomennakin.

Lähde:
Smoke testing (software), Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Smoke_testing_(software) 

Mitä on apinatestaus? (Monkey testing)

Jos apinalle antaisi tietokoneohjelman testattavaksi, miten apina suorittaisi tehtävän? Lopputuloksena olisi todennäköisesti jono satunnaisia näppäinpainalluksia ja hajonnut tietokoneen näppäimistö. Oliko apinasta siis mitään hyötyä vai ei?

Apinatestauksella (Monkey testing) tarkoitetaan testausta, jossa järjestelmälle annetaan satunnaisia syötteitä ja tutkitaan, miten järjestelmä selviytyy niiden käsittelystä. Usein juuri virheelliset syötteet, joiden käsittelyyn kehittäjät eivät ole osanneet varautua, johtavat järjestelmän vika- tai virhetilanteisiin. Apinatestaus onkin tärkeä työkalu järjestelmän häiriökestävyyden arvioinnissa (robustness). Satunnainen syöte voi myös tuoda uusia out-of-the-box ideoita järjestelmän koettelemiseen ja sillä tavoin antaa uusia keinoja löytää järjestelmän rikkovia bugeja.

On olemassa myös termi fuzz testing (sumea testaus), joka usein esiintyy apinatestauksen yhteydessä. Osa määrittelee termien eroksi sen, että apinatestaus viittaa nimenomaan satunnaisiin toimiin (random actions), kun taas sumea testaus viittaa syötetyn datan satunnaisuuteen (random input data). Toisin sanoen, sumeaa testausta on esimerkiksi se, että syöttää ohjelmalle Excel-taulukon, jonka dataa on muokattu tai rikottu määritelmien vastaiseksi. Apinatestauksen esimerkki voisi puolestaan olla ohjelman käyttäminen painamalla satunnaisesti jokaista käytettävissä olevaa nappia.

Apinat voidaan jakaa älykkäisiin (smart) ja tyhmiin (dumb). Sama pätee myös apinatestauksessa.

Älykkäillä apinoilla on suppea idea järjestelmän toiminnasta, älykkäät apinat tietävät oman paikkansa ja kykynsä ja järjestelmän kyvyt, älykkäät apinat ovat fokusoituneet järjestelmän rikkomiseen ja osaavat raportoida niistä. Tyhmät apinat eivät tiedä mitään järjestelmän toiminnasta, tyhmät apinat eivät osaa syöttää oikeanlaista syötettä, tyhmät apinat eivät tiedä omia tai järjestelmän kykyjä, eivätkä ne toimi suunnitelmallisesti.

Testaamisen ei pitäisi olla päämäärätöntä näppäimistön hakkaamista, mutta silti siitä näyttää aina silloin tällöin olevan hyötyä. Arvelisin kuitenkin, että koulutettu testaaja tulee silti halvemmaksi kuin lennättää simpanssi Espooseen ja opettaa sille koodaamista. Banaanejakaan ei tarvitse ostaa.

Lähteet:
Monkey Testing, Wikipedia. Saatavilla: https://en.wikipedia.org/wiki/Monkey_testing