Ad hoc -testauksen suunnittelu

Tässä artikkelissa käsittelemme ad hoc -testausta, sen tyyppejä, etuja ja haittoja sekä parhaita käytäntöjä ad hoc -testauksen suorittamiseen.

Mitä on ad hoc -testaaminen?

Ad hoc -testausta kutsutaan toisinaan satunnaistestaukseksi tai apinatestaukseksi, ja se määritellään epäviralliseksi testaustavaksi. Sen tavoitteena on rikkoa järjestelmä epätavanomaisilla menetelmillä. Tämäntyyppinen ohjelmistotestaus on yleensä suunnittelematonta eikä siinä noudateta mitään erityisiä testisuunnittelutekniikoita testitapausten luomiseksi.

Ad hoc -testauksen päätavoitteena on löytää mahdolliset viat satunnaisten tarkistusten avulla. Testaaja improvisoi vaiheita suorittamalla niitä mielivaltaisesti. Näin voidaan paljastaa hyvin spesifisiä ja mielenkiintoisia vikoja, jotka jäävät helposti huomaamatta muita menetelmiä käytettäessä.

Yllättävintä ad hoc -testauksessa on se, että se ei sisällä mitään testien suunnittelutekniikoita. Tämä tarkoittaa sitä, että vaikka tällä menetelmällä löydetään virheitä, joita ei ehkä tavallisesti löydetä, sitä on vaikeampi toistaa, koska kirjallisia testitapauksia tai dokumentaatiota ei ole.

Ad hoc -testauksen onnistuminen riippuu oikeastaan testaajan luovuudesta ja sinnikkyydestä, ja toisinaan se on pelkkää tuuria. Ad hoc -testaustekniikka kuuluu suoraan ”strukturoimattoman testauksen” luokkaan.

Strukturoitu vs. strukturoimaton testaus

Strukturoitu testaus

Tällä lähestymistavalla varmistetaan, että jokainen testausmenettelyn aikana tapahtuva toiminto on käsikirjoitettu testitapausten luomisesta peräkkäiseen suorittamiseen asti. Testaaja noudattaa käsikirjoitusta suorittaakseen testit menestyksekkäästi.

Rakenteeton testaus

Tässä lähestymistavassa testaus tapahtuu virheitä arvaamalla. Testaaja luo testitapauksia testausprosessin aikana.

Tyyppiset ad hoc -testausmenetelmät

Kaveritestaus

Tässä ad hoc -testausmenetelmässä testaukseen osallistuu vähintään kaksi henkilöä. Se tapahtuu sen jälkeen, kun moduulin yksikkötestaus on suoritettu ja saatettu loppuun. Tämäntyyppistä testausta voidaan myös pitää sekä järjestelmä- että yksikkötestauksen yhdistelmänä.

Päätavoitteena on, että kaksi ”kaveria” työskentelee samaan aikaan saman moduulin vikojen tai virheiden tunnistamiseksi. Tämä tiimi koostuu yleensä yhdestä ohjelmistokehittäjästä ja yhdestä ohjelmistotestaajasta.

Kaksi ’kaveria’ työskentelevät yhdessä kyseisen moduulin parissa luodakseen päteviä testitapauksia. Tällä prosessilla varmistetaan, että testaaja ei raportoi virheistä, joita virheelliset testitapaukset ovat saattaneet tuottaa.

Buddy-testaus on osoittautunut menestyksekkääksi, koska se auttaa testaajaa kehittämään parempia testitapauksia ja antaa kehitystiimille mahdollisuuden tehdä suunnittelumuutoksia mahdollisimman varhaisessa vaiheessa.

Apinatestaus

Testauksen sattumanvaraisen luonteen vuoksi tämä menetelmä on ansainnut nimen ”apinatestaus”. Apinatestausta tehdään yleisimmin yksikkötestauksen tasolla. Tässä testaajat testaavat satunnaisesti sovelluksen tai tuotteen ilman testitapauksia. Testaajan päätavoitteena on analysoida tietoja tai testejä täysin satunnaisilla tavoilla varmistaen, että järjestelmä kestää minkä tahansa kaatumisen.

Testaajat antavat ohjelmistolle satunnaisia syötteitä ja tarkkailevat niiden vastaavia tuotoksia. Lähtötietojen perusteella he voivat määrittää paremmin mahdolliset virheet, epäjohdonmukaisuudet tai järjestelmän kaatumisen.

Paritestaus

Paritestauksessa, joka muistuttaa jossain määrin ”kaveritestausta”, testaajapari työskentelee yhdessä testattavien moduulien parissa. Molemmat testaajat jakavat ajatuksiaan, tietämystään ja mielipiteitään samasta koneesta vikojen tai virheiden havaitsemiseksi.

Tässä testausmenetelmässä käytetään testaajia, jotka on asetettu pariksi heidän asiantuntemuksensa ja tietämystasonsa mukaan, mikä mahdollistaa erilaiset näkemykset kaikkiin havaittuihin ongelmiin. Molemmat testaajat jakavat saman asetelman, ja he jakavat myös testaustyön ja dokumentoivat kaikki havainnot keskenään. Tämä testausmenetelmä mahdollistaa myös sen, että toinen testaaja suorittaa testit, kun taas toinen voi tehdä muistiinpanoja havainnoista.

Lue myös: Käytä paritestausta parempaan hyväksymistestaukseen

Kaveritestaus vs. paritestaus

Kaveritestauksen ja paritestauksen tärkein ero on, että kaveritestaus on yhdistelmä yksikkö- ja järjestelmätestausta. Toinen keskeinen ero on se, että kaveritestauksen suorittavat kehittäjät ja testaajat yhdessä. Paritestauksen sen sijaan suorittavat vain testaajat, joilla on eritasoinen tietämys.

Milloin ja milloin ei kannata suorittaa ad hoc -testausta

Ad hoc -testausta suoritetaan yleisesti silloin, kun ei ole aikaa suorittaa pidempiä ja perusteellisempia testausprosesseja. Perusteellisempaan testausmenetelmään kuuluu testivaatimusasiakirjojen, testitapausten ja testitapaussuunnitelmien laatiminen.

Ihanteellinen aika ad hoc -testauksen suorittamiseen on kaikkien virallisten testaustekniikoiden suorittamisen jälkeen. Ad hoc -testausta voidaan kuitenkin suorittaa myös kesken ohjelmistokehityksen, ohjelmiston täydellisen kehittämisen jälkeen tai sen jälkeen, kun muutama moduuli on jo kehitetty.

On tärkeää huomioida ne muutamat skenaariot, jolloin ad hoc -testausta ei suositella. Muutamia olosuhteita, joissa ad hoc -testausta ei tulisi suorittaa, ovat:

Kun suoritetaan beta-testausta

Testitapauksissa, joissa on jo olemassa olevia virheitä

Ad hoc -testauksen edut

Yksi ad hoc -testauksen tärkeimmistä eduista on se, että sillä pystytään havaitsemaan kaikki virheet, jotka tavallisesti jäisivät huomaamatta muodollisissa testausmenetelmissä. Tämä voi säästää paljon aikaa, koska se ei vaadi mitään strukturoidun testauksen kaltaista suunnittelua.

Toisena etuna on, että testaajat pääsevät tutkimaan sovellusta vapaasti oman tietämyksensä ja ymmärryksensä mukaan. He voivat sitten suorittaa erilaisia testejä matkan varrella, mikä auttaa virheiden tunnistamisessa koko prosessin ajan.

Kolmanneksi, testaajat ja sovelluksen kehittäjät voivat testata sovellusta helposti itse, koska se ei vaadi testitapauksia. Näin kehittäjät voivat helposti luoda tehokkaampaa ja virheettömämpää koodia.

Ad hoc -testaus voidaan myös yhdistää muihin testaustekniikoihin ja suorittaa sen jälkeen, jolloin saadaan kaiken kaikkiaan tehokkaampia ja informatiivisempia tuloksia.

Ad hoc -testauksen haitat

Yksi ad hoc -testauksen suurimmista haitoista on se, että varsinaista testausprosessia ei dokumentoida, koska se ei noudata tiettyä testitapausta. Tämä vaikeuttaa sitä, että testit uusintavat virheen. Koska saadakseen kyseisen virheen, testaajan on muistettava tarkat vaiheet, joita hän teki päästäkseen virheeseen, mikä ei aina ole mahdollista.

Testaajan kehittämien virheellisten testitapausten seurauksena raportoidaan toisinaan virheellisiä virheitä. Tästä voi tulla ongelma seuraavissa virheenkorjausprosesseissa. Jos testaajalla ei ole ennakkotietoa testattavan sovelluksen toiminnallisuudesta, ad hoc -testauksesta ei ole hyötyä, eikä se pysty tunnistamaan virheitä.

Ad hoc -testaus ei myöskään takaa, että kaikki virheet löydetään. Ad hoc -testauksen onnistuminen riippuu testaajan taidoista ja tiedoista. Koska etukäteen luotuja tai dokumentoituja testitapauksia ei ole, näihin testeihin kuluvan ajan, vaivannäön ja resurssien määrä jää määrittelemättä. Yhden virheen löytäminen voi kestää muutamasta minuutista muutamaan tuntiin tai pidempäänkin.

Parhaat käytännöt testausta suoritettaessa

Testit, joita ei suoriteta oikealla tavalla, voivat aiheuttaa tarpeetonta ajanhukkaa. Tämän vuoksi on ratkaisevan tärkeää tietää, miten prosessi voidaan optimoida, jotta ad hoc -testaus voidaan suorittaa tehokkaasti ja menestyksekkäästi.

Seuraavat parhaat käytännöt varmistavat, että prosessiin käytetty aika käytetään viisaasti ja että halutut tulokset saavutetaan parhaalla mahdollisella tavalla.

Ole perehtynyt ohjelmistoon

On ehdottoman tärkeää, että ad hoc -testausta suorittavalla testaajalla on vankka tietämys ja ote sovelluksesta. On tärkeää, että testaaja tuntee kaikki sovelluksen pääominaisuudet, jotta voidaan varmistaa parempi ”virheiden arvaaminen”. Oikealla tietämyksellä testaaja pystyy löytämään enemmän bugeja, virheitä ja yleisiä epäjohdonmukaisuuksia.

Identify Areas Likely To Have Errors

Jos testaajat eivät tunne sovellusta, on suositeltavaa, että he tunnistavat sovelluksen virhealttiit alueet ja aloittavat siitä. Valitsemalla herkät alueet ad hoc -testausta varten testaajat löytävät virheet helpommin.

Priorisoi alueet, joihin loppukäyttäjä pääsee helpoimmin käsiksi

Aloita testaamalla ne sovelluksen alueet, joita asiakkaat ja loppukäyttäjät käyttävät eniten. Näin he arvioivat tärkeät ominaisuudet ensin, minkä ansiosta he voivat raportoida mahdollisista virheistä etukäteen.

Testisuunnitelman löyhä muotoilu

Vaikka ad hoc -testaus ei vaadi minkäänlaista etukäteissuunnittelua tai dokumentointia, on hyödyllistä tehdä karkea suunnittelu etukäteen. Tärkeimpien testausta vaativien osa-alueiden muistiin merkitseminen auttaa testaajaa kattamaan mahdollisimman paljon mahdollisimman lyhyessä ajassa.

Tehokkuuden lisääminen oikeilla työkaluilla

Prosessin tehokkaan suorittamisen varmistamiseksi on ratkaisevan tärkeää käyttää oikeita työkaluja, kuten tehtävämonitoreja, virheenkorjausohjelmia (debuggereita) ja profilointiohjelmia. Ne täydentävät testaajien kykyä eristää virheitä, sillä voi olla tapauksia, joissa poikkeuksia ei tunnisteta testauksen aikana.

Johtopäätös

Ad hoc -testaus ei vaadi monimutkaista suunnittelua, dokumentointia ja testitapausten suunnittelua. Sen sijaan se säästää aikaa ad hoc -luonteensa ansiosta ja valitsemalla testaajia, jotka ovat luovia ja joilla on ennakkotietoa sovelluksen toiminnallisuudesta. Tällaisen testauksen avulla voidaan löytää enemmän virheitä kuin suunnitellun testauksen avulla.

Liity yli 60,000 tilaajan joukkoon

Saa uusimmat blogit, alan päivitykset ja eksklusiiviset vinkit.

*Sähköpostisi on turvassa meillä, vihaamme myös roskapostia