Adhoc-testaus suoritetaan yleensä järjestelmän rikkomiseksi ja epätavallisin keinoin. Adhoc-testauksen hämmästyttävin piirre on se, että siinä ei ole mitään testisuunnittelutekniikkaa testitapausten luomiseksi.

Prosessi suoritetaan yleensä ohjelmiston porsaanreikien löytämiseksi. Koska Adhoc-testauksessa ei ole testitapauksia, se suoritetaan usein ilman minkäänlaista dokumentaatiota.

Katso prosessi yksityiskohtaisesti

Adhoc-testaus on tekniikka, joka kuuluu ’Strukturoimaton testaus’ -luokkaan.

Mitä on strukturoitu ja strukturoimaton testaus?

Srukturoitu testaus

Tässä lähestymistavassa jokainen testausmenettelyn aikana tapahtuva toiminto testitapausten luomisesta niiden peräkkäiseen suorittamiseen asti, kaikki on käsikirjoitettu. Testaajat noudattavat tätä käsikirjoitusta ja suorittavat testit sen mukaisesti.

Epästrukturoitu testaus

Tässä lähestymistavassa testaus suoritetaan yleisesti virheitä arvaamalla, jolloin testaajat luovat testitapaukset, itse testausprosessin aikana.

Mitä on ad hoc -testaus?

Kuten edellä käsiteltiin, kyseessä on eräänlainen strukturoimaton testauslähestymistapa, jossa ei luoda mitään organisoitua suunnitelmaa ennen testausprosessin aloittamista.

Siten ennen testausta ei tehdä vaatimusdokumentaatiota tai testitapausten suunnittelua ja muotoilua.

Ad-hoc-testauksen suorittaa yleensä testaaja, jolla on vahva tietämys testattavasta ohjelmistosta siitä, mitä se tekee ja miten se toimii.

Tässä testauksessa luodaan testitapauksia sattumanvaraisesti virheitä arvailemalla ja suoritetaan niitä noudattamatta mitään testin vaatimuksia.

Tärkeä osa tätä testausta on selvittää ohjelmiston mahdolliset alueet, joissa voi esiintyä virheitä.

Sen vuoksi se tunnetaan joskus myös nimellä Monkey Testing tai Random Testing. Siksi on tärkeää, että tämän testauksen suorittavat vain ne testaajat, jotka tuntevat ohjelmiston hyvin.

Ad-Hoc-testaus on siitä eduksi, että se säästää melko paljon aikaa, joka muutoin kuluu asiakirjojen, kuten testivaatimusten, testitapausten suunnittelun, suunnittelun jne. laatimiseen.

Testaus suoritetaan yleensä myös sen jälkeen, kun strukturoitu testaus on jo suoritettu. Tämä tehdään, jotta voidaan löytää ohjelmistosta harvinaisia puutteita, joita ei voitu havaita noudattamalla etukäteen kirjoitettuja testitapauksia.

Adhoc-testauksen tyypit

1) Buddy-testaus

Tässä Ad-Hoc-testausmuodossa testit suoritetaan vähintään kahden henkilön ryhmätyönä. Tämä tiimi koostuu yleensä vähintään yhdestä ohjelmistotestaajasta ja yhdestä ohjelmistokehittäjästä.

Tätyyppinen testaus tapahtuu sen jälkeen, kun moduulin yksikkötestauksen suorittaminen on saatu päätökseen.

Kahden ”kaverin” tiimi työskentelee yhdessä kyseisen moduulin parissa luodakseen kelvollisia testitapauksia.

Tämähän tehdään siksi, että testaaja ei päädy raportoimaan virheistä, jotka on tuotettu epäkelvollisten testitapausten avulla. Tämäntyyppistä testausta voidaan pitää myös sekä yksikkö- että järjestelmätestauksen yhdistelmänä.

2) Apinatestaus

Tässä testauksessa käytetyn lähestymistavan satunnaisuuden vuoksi sitä kutsutaan ”apinatestaukseksi”.

Tässä testattavaan ohjelmistoon annetaan satunnaisia syötteitä, joita vastaavia tuotoksia tarkkaillaan.

Saatujen tuotosten perusteella määritetään mahdolliset virheet, epäjohdonmukaisuudet tai järjestelmän kaatumiset.

3) Apinatestaus

Tässä testauksessa muistutetaan paljolti kaveritestausta. Tässä kuitenkin vain pari testaajia työskentelee yhdessä testattavien moduulien parissa.

He työskentelevät yhdessä ja jakavat ideoita, mielipiteitä ja tietoa samasta koneesta virheiden ja puutteiden tunnistamiseksi.

Testaajat paritetaan heidän tietämystasonsa ja asiantuntemuksensa mukaan, jotta saadaan erilainen näkemys mistä tahansa ongelmasta.

Adhoc-testauksen ominaispiirteet

• Tää testausta tehdään sen jälkeen, kun viralliset testaustekniikat on jo suoritettu ohjelmistolle. Syynä tähän on se, että ad-hoc-testausta tehdään sovelluksen poikkeavuuksien selvittämiseksi, joita ei voida ennustaa ennen testausta.
• Tätä testausta voivat suorittaa vain ne testaajat, joilla on hyvä ja perusteellinen tietämys sovelluksen toiminnasta. Tämä johtuu siitä, että tehokasta ”virheiden arvaamista” voidaan tehdä vain silloin, kun testaaja tietää, mitä sovellus tekee ja miten se toimii.

Ad-hoc-testaustekniikka soveltuu parhaiten sellaisten virheiden ja epäjohdonmukaisuuksien löytämiseen, jotka synnyttävät kriittisiä aukkoja sovelluksessa. Tällaisia virheitä on yleensä hyvin vaikea paljastaa.

• Tämä testaus vie verrattain vähemmän aikaa kuin muut testaustekniikat. Tämä johtuu siitä, että se tehdään ilman etukäteissuunnittelua, -suunnittelua ja -rakentamista.
• Ad-hoc-testausta tehdään vain kerran, sillä kaikki löydetyt virheet on testattava uudelleen.

Esimerkkejä ad hoc -testauksesta

Testataan sovelluksen moitteetonta toimintaa selaimen asetusten ollessa erilaiset. Esimerkiksi sellaisten virheiden tunnistaminen, jotka ilmenevät, kun JavaScript-asetus on poistettu käytöstä eri selaimissa jne.
• Testataan sovellusta eri alustoilla. On tärkeää tarkistaa, toimiiko kehitetty sovellus sujuvasti eri käyttöjärjestelmissä tai selaimissa.
• Syötteiden antaminen järjestelmälle, jotka ovat valid-inputs-alueen ulkopuolella, sen tarkistamiseksi, onko sovelluksen tekemä tuloksena syntyvä toimenpide asianmukainen vai ei.
• Sovelluksen URL-osoitteen kopioiminen ja sen muokkaaminen siten, että se toimii eri selaimessa. Näin varmistetaan, etteivät luvattomat käyttäjät pääse kirjautumatta järjestelmään.
• Sarjan satunnaisten vaiheiden läpikäyminen tai satunnainen navigointi sovelluksen läpi, jotta voidaan tarkistaa tulokset, jotka saadaan käymällä läpi tietty yhdistelmä epätavallisia syötteitä.

Milloin suoritetaan ad hoc -testausta

Ad hoc -testausta suoritetaan yleensä silloin, kun ei ole riittävästi aikaa suorittaa tyhjentävää ja perusteellista testausta, johon sisältyy testausvaatimusasiakirjan, testitapausten ja testitapaussuunnitelmien laatiminen.

Täydellinen aika tämäntyyppisen testauksen suorittamiseen on muodollisten testaustekniikoiden suorittamisen jälkeen.

Mutta ad-hoc-testausta voidaan suorittaa myös kesken ohjelmiston kehittämisen.

Se voidaan suorittaa sen jälkeen, kun ohjelmisto on kehitetty kokonaan tai jopa sen jälkeen, kun muutama moduuli on kehitetty.

Se voidaan suorittaa myös virallisten testausmenetelmien aikana.

On kuitenkin muutamia tilanteita, joissa tällaista testausta ei saa suorittaa. Siksi jokaisen testaajan on tiedettävä, milloin tätä testausta on vältettävä.

Alhaalla on lueteltu muutamia tilanteita, joissa ad-hoc-testausta ei saa suorittaa:

• Ad-hoc-testausta ei saa suorittaa beta-testauksen aikana. Tämä johtuu siitä, että beta-testaukseen osallistuvat asiakkaat, jotka testaavat kehitettyä ohjelmistoa antaakseen ehdotuksia uusista ominaisuuksista, joita on lisättävä, tai muuttaakseen sen vaatimuksia.

Tätä testausta ei myöskään suositella suoritettavaksi testitapauksissa, joissa on jo olemassa olevia virheitä. Virheet on ensin dokumentoitava asianmukaisesti, ennen kuin ne poistetaan järjestelmästä. Kun ne on korjattu, testitapaukset on testattava uudelleen, jotta voidaan varmistaa niiden moitteeton toiminta.

Mitkä ovat ad hoc -testauksen edut?

• Yksi ad hoc -testauksen eduista on se, että monet virheet, jotka tavallisesti jäävät havaitsematta, kun käytetään vain muodollisia testausmenetelmiä, voidaan löytää testaamalla sovellusta satunnaisotannalla.
• Testaajat pääsevät tutkailemaan sovelluksen sisältöä vapaasti intuitionsa ja sovelluksen ymmärryksensä mukaan. Sen jälkeen he voivat suorittaa testejä matkan varrella, mikä auttaa heitä löytämään virheitä tämän prosessin aikana.
• Testaajat sekä sovelluksen kehittäjät voivat testata sovellusta helposti, koska testitapauksia ei tarvitse suunnitella ja suunnitella. Tämä auttaa kehittäjiä luomaan tehokkaampia ja virheettömämpiä koodeja helposti.
• Testaus voi myös auttaa luomaan ainutlaatuisia testitapauksia, jotka voivat havaita virheet tehottomasti. Siksi tällaiset testitapaukset voidaan lisätä muodolliseen testaukseen muiden suunniteltujen testitapausten kanssa.
• Ad-hoc-testausta voidaan suorittaa milloin tahansa ohjelmistokehityksen elinkaaren aikana, koska se ei noudata mitään muodollista prosessia.
• Se voidaan yhdistää muihin testaustekniikoihin ja suorittaa siten, että saadaan informatiivisempia ja tehokkaampia tuloksia.

Mitkä ovat ad hoc -testauksen haitat?

Koska testausprosessia ei dokumentoida eikä mitään tiettyä testitapausta noudateta, testaajan on hyvin vaikea elvyttää virhe. Tämä johtuu siitä, että testaajan on muistettava tarkat vaiheet, joita hän noudatti saadakseen kyseisen virheen, mikä ei ole mahdollista joka kerta.
• Joskus testaajan satunnaisesti kehittämien virheellisten testitapausten suorittamisen vuoksi raportoidaan virheellisiä virheitä, mistä tulee ongelma myöhemmissä virheenkorjausprosesseissa.
• Jos testaajilla ei ole etukäteistietämystä testattavan sovelluksen toiminnasta, niin ad hoc -testejä suorittaessa ei pystytä paljastamaan monia virheitä. Tämä johtuu siitä, että testaajien on työstettävä virheiden arvailua ja luotava ja suoritettava testitapauksia intuitiivisesti paikan päällä.
• Ad-hoc-testaus ei anna varmuutta siitä, että virheet löydetään. Proaktiivinen virheiden arvaaminen testausta varten on täysin riippuvainen testaajan taidoista ja tiedoista.
• Koska testaukseen ei ole aiemmin luotuja ja dokumentoituja testitapauksia, testaukseen kuluvan ajan ja työpanoksen määrä jää epävarmaksi. Joskus yhdenkin virheen löytäminen voi viedä valtavasti aikaa.

Parhaat käytännöt ad hoc -testauksen suorittamiseen

Ad hoc -testaustekniikan tehokkaan suorittamisen kannalta on tärkeää tietää, mitkä ovat tehokkaimmat ja toimivimmat tavat suorittaa ad hoc -testausta.

Tämä johtuu siitä, että jos testejä ei suoriteta oikealla tavalla, testeihin panostettu vaivannäkö ja käytetty aika valuvat hukkaan.

Sen vuoksi tämäntyyppisen testauksen suorittamiseksi on tunnettava parhaat käytännöt, jotka voivat auttaa kattavammassa lähestymistavassa testaukseen:

1) Hyvä ohjelmistotuntemus

Varmista, että sovelluksen testaamiseen ad-hoc-lähestymistavan avulla määrätyllä testaajalla on hyvä ote sovelluksesta.

Testaajan on tunnettava kaikki sovelluksen ominaisuudet, jotta sovelluksen ”virheiden arvaaminen” olisi helpompaa.

Kun testaajan testausprosessin tukena on riittävä tietämys, useampien virheiden, vikojen ja epäjohdonmukaisuuksien löytäminen helpottuu.

2) Selvitä virhealttiit alueet

Jos testaajat, miten eivät ole perehtyneet sovellukseen, paras tapa aloittaa testausprosessi on tarkistaa sovelluksen se osa, jossa suurin osa virheistä on.

Tällaisten herkkien alueiden valitseminen ad-hoc-testejä varten voi auttaa heitä löytämään virheet helpommin.

3) Testausalueiden priorisointi

Aina on parempi aloittaa testaaminen niistä sovelluksen alueista, joita loppukäyttäjät tai asiakkaat käyttävät eniten. Tämä auttaa varmistamaan tärkeät ominaisuudet ja ilmoittamaan mahdollisista virheistä etukäteen.

4) Suunnittele testaussuunnitelma karkeasti

Vaikka ad hoc -testaus ei vaadi ennakkosuunnittelua tai -dokumentaatiota, se osoittautuu erittäin hyödylliseksi ja tehokkaaksi, jos karkea suunnitelma luodaan etukäteen.

Vaikka pelkkä tärkeimpien osoittimien ja testausta vaativien alueiden muistiin merkitseminen voi auttaa testaajia kattamaan suurimman mahdollisen osan sovelluksesta lyhyessä ajassa.

5) Työkalut

Testauksen helpottamiseksi on tärkeää käyttää oikeanlaisia työkaluja, kuten debuggereita, tehtävämonitoreja ja profilointilaitteita.

Tämä johtuu siitä, että on tilanteita, joissa tietyt virheet ja poikkeukset jäävät testauksen aikana huomaamatta ja havaitsematta.

Oikeiden työkalujen käyttö voi kuitenkin auttaa eristämään virheen lyhyessä ajassa.

Adhoc-testaus vs. eksploratiivinen testaus

Adhoc-testaus	Exploratiivinen testaus
Testaajilla on oltava selkeä käsitys sovelluksen työnkulusta	Testaajat tutustuvat sovelluksesta matkan varrella
Lisäksi testauksen täydellistämisestä	Se on oppimismenetelmä, jolla oppii tuntemaan sovelluksen
Muoto positiivisesta testauksesta	Muoto negatiivisesta järjestelmästä
Ei ole suunnitelmaa	Käyttöön otetaan peruskirjaan perustuva suunnitelma
Ei ole ehdotettua aikarajaa	Aikalaatikkoon/merkkivektoriin perustuva suunnitelma
Voi suorittaa ohjelmistotestausinsinööri	Voi olla tehdä asiantuntija
Painopiste on sovellusprosessissa	Datan syöttöalueet ovat pääpaino
Testien monimutkaisuus ei juurikaan häiritse tätä prosessia	Testaukseen liittyvät haasteet