Ad-hoc-testaus:

Termi ad-hoc viittaa rakenteettomuuteen tai johonkin, joka ei ole suunnitelmallista. Kun puhutaan ad-hoc-testauksesta, se tarkoittaa, että se on eräänlaista mustan laatikon testausta tai käyttäytymistestausta, joka suoritetaan ilman mitään muodollista prosessia.

Muodollisella prosessilla tarkoitetaan tässä dokumentaatiota, kuten vaatimusdokumentteja, testaussuunnitelmia, testitapauksia ja asianmukaista testaussuunnittelua aikataulunsa ja suoritettujen testien järjestyksen osalta. Myöskään testauksen aikana suoritettuja toimenpiteitä ei tyypillisesti dokumentoida.

Tämä tehdään pääasiassa siksi, että yritetään paljastaa virheitä tai puutteita, joita ei pystytä havaitsemaan perinteisillä tai virallisilla prosesseilla, joita noudatetaan testaussyklin aikana.

Kuten jo on ymmärretty, tämän testauksen ydin on siinä, että testauksessa ei ole muodollista tai strukturoitua tapaa. Kun tällaista satunnaista testausta suoritetaan, on ilmeistä, että testaajat suorittavat sen ilman mitään tiettyä käyttötapausta mielessä tavoitteenaan rikkoa järjestelmä.

Siten on varmasti vieläkin ilmeisempää, että tällainen intuitiivinen tai luova testausmenetelmä edellyttää, että testaajalta vaaditaan äärimmäistä ammattitaitoa, kyvykkyyttä ja syvällistä tietotaitoa järjestelmästä. Ad-hoc-testaus varmistaa, että suoritettu testaus on täydellistä, ja se on erityisen hyvin käyttökelpoinen testikauhan tehokkuuden määrittämisessä.

Suositeltava lukeminen => Exploratory Testing – How to Think Beyond Traditional Testing Boundaries?

Aloitetaan Ad-hoc-testausesimerkillä

Tässä on esimerkki siitä, miten voimme suorittaa tämän testauksen, kun kyse on käyttöliittymävelhosta.

Esitettäköön, että sinun on luotava suunnitelma tai malli jostain tehtävästä, joka suoritetaan tämän käyttöliittymävelhon avulla. Ohjattu toiminto on sarja paneeleita, joissa on käyttäjän syöttötiedot, kuten nimi, kuvaus jne.

Kun ohjattu toiminto etenee: sanotaan, että johonkin paneeliin on syötettävä käyttäjän tietoja, mikä liittyy siihen, että UI-ohjattu toiminto heittää kontekstin ponnahdusikkunan, joka lisää siihen liittyvät tiedot ohjatun toiminnon loppuunsaattamiseksi ja ohjatun toiminnon käyttöönottamiseksi/aktivoimiseksi.

Testaamaan tätä testaaja tekee tavanomaisen testauksensa, kuten:

• Toteuta ohjattu käyttöliittymä onnistuneesti kaikilla kelvollisilla tiedoilla ja luo suunnitelman.
• Keskeytä ohjattu käyttöliittymä kesken matkan.
• Muokkaa luotua suunnitelmaa ohjatun toiminnon kautta.
• Poista luotu suunnitelma ja katso, että siitä ei ole jäämiä.
• Syötä negatiivinen arvo ohjatussa toiminnossa ja katso, että asianmukaiset virheilmoitukset näkyvät.

Nyt tässä on yllä olevaan esimerkkiin joitain testitapauksia ad-hoc-testejä varten, jotka voitaisiin suorittaa mahdollisimman monen vian paljastamiseksi:

• Yritäessäsi lisätä negatiivisia tietoja, lisää tiettyjä erikoismerkkejä, joita ei ole rajoitettu, ja katso, käsitelläänkö ne oikein. Esimerkiksi joskus ohjatut ohjelmat eivät rajoita {tai [ aaltosulkeita, mutta tietyissä tilanteissa tämä voi olla ristiriidassa koodin kanssa sen kielen perusteella, jolla se on kirjoitettu, ja aiheuttaa hyvin epäluotettavaa käyttäytymistä.
• Toinen testi liittyy nimenomaan ponnahdusikkunoihin. Käyttäjä voi aiheuttaa ponnahdusikkunan käynnistymisen ja yrittää sitten painaa näppäimistön backspace-näppäintä. Monta kertaa olen havainnut, että näin tehdessä taustaohjattu toiminto katoaa kokonaan ja kaikki käyttäjän tiedot, jotka oli syötetty ponnahdusikkunan käynnistymiseen asti, menetetään!

Ad-hoc-testauksen ominaispiirteet:

Jos otat huomioon edellä esitetyt skenaariot, huomaat jotakin hyvin selviä piirteitä tämäntyyppiselle testaamiselle.

Näytteet ovat seuraavat:

• Näytteet ovat aina testauksen tavoitteen suuntaisia. Ne ovat kuitenkin tiettyjä rajuja testejä, jotka suoritetaan tarkoituksenaan rikkoa järjestelmä.
• Testaajalla on oltava täydellinen tieto ja tietoisuus testattavasta järjestelmästä. Tämän testauksen tuloksena löydetään virheitä, jotka pyrkivät tuomaan esiin testausprosessin porsaanreiät.
• Katsottaessa edellä mainittuja kahta testiä, luonnollinen reaktio siihen olisi, että – tällainen testi voidaan suorittaa vain kerran, koska uudelleentestaus ei ole mahdollista, ellei siihen liity vikaa.

Milloin teemme ad-hoc-testausta?

Miljoonan dollarin kysymys!

Testausryhmät joutuvat useimmiten aina kuormittumaan liian monista ominaisuuksista, joita pitää testata rajallisessa aikataulussa. Tuossa rajallisessa aikajänteessä on paljon muodollisesta prosessista johdettuja testaustoimintoja, jotka on myös saatava päätökseen. Tällaisissa tilanteissa ad-hoc-testaus löytää tiensä testaukseen heikosti.

Kokemukseni mukaan yksi ad-hoc-testauskierros voi kuitenkin tehdä ihmeitä tuotteen laadulle ja herättää monia suunnittelukysymyksiä.

Koska ad-hoc-testaus on enemmänkin ”villin lapsen” testaustekniikka, jonka ei tarvitse olla strukturoitu, yleinen suositus on, että se on suoritettava sen jälkeen, kun nykyisen testauskauhan suoritus on valmis. Toinen näkökulma on, että sitä voitaisiin tehdä silloin, kun yksityiskohtaista testausta ei voida suorittaa vähäisen ajan vuoksi.

Oman näkemykseni mukaan sanoisin, että ad-hoc-testausta voidaan tehdä melkein milloin tahansa – alussa, keskivaiheilla ja lopussa! Se vain löytää paikkansa milloin tahansa. Se, milloin ad-hoc-testausta on kuitenkin tehtävä maksimaalisen hyödyn tuottamiseksi, on parasta arvioida kokeneen testaajan toimesta, jolla on syvällistä tietoa testattavasta järjestelmästä.

Milloin ei kannata suorittaa?

Jos edellinen kysymys oli miljoonan dollarin arvoinen, tämän pitäisi olla miljardin dollarin arvoinen!

Vaikka olemme selvittäneet, kuinka tehokasta ja hedelmällistä ad-hoc-testaus voi olla, taitavan ja kyvykkään testaajan on myös selvitettävä, milloin tämäntyyppiseen testaukseen ei kannata panostaa. Vaikka se on testaajan harkinnassa, tässä on muutamia suosituksia/esimerkkejä siitä, milloin se ei ehkä ole tarpeen.

• Vältä tätä testausta, kun on olemassa testitapaus, jossa on vika. Tällaisessa tilanteessa on tarpeen dokumentoida testitapauksen vikakohta ja sitten todentaa/testata vika uudelleen, kun se on korjattu. Näin ollen sitä ei voida soveltaa tässä tapauksessa.
• Voi olla myös tiettyjä tilanteita, joissa asiakkaita tai asiakkaita saatetaan kutsua testaamaan ohjelmiston beta-versiota. Tällaisissa tapauksissa tätä testausta ei pitäisi suorittaa.
• Toinen skenaario on, kun lisätään hyvin yksinkertainen käyttöliittymän näyttö. Perinteisen positiivisen ja negatiivisen testauksen pitäisi riittää tässä tapauksessa, jotta saadaan esiin mahdollisimman paljon virheitä.

Tyypit Ad-hoc-testaus

Ad-hoc-testaus voidaan luokitella kolmeen alla olevaan luokkaan:

#1) Kaveritestaus

Tässä testauksen muodossa on testaaja ja kehittäjäjäsen, jotka valitaan työskentelemään saman moduulin parissa. Heti kun kehittäjä on saanut yksikkötestauksen valmiiksi, testaaja ja kehittäjä istuvat yhdessä ja työskentelevät moduulin parissa. Tällaisen testauksen avulla ominaisuutta voidaan tarkastella laajemmin molempien osapuolten kannalta.

Kehittäjä saa näkökulman kaikkiin erilaisiin testeihin, joita testaaja suorittaa, ja testaaja saa näkökulman siihen, miten luontainen suunnittelu on, mikä auttaa häntä välttämään epäkelpoisten skenaarioiden suunnittelua ja siten ehkäisemään epäkelpoisia vikoja. Se auttaa toista ajattelemaan kuten toinen ajattelee.

#2) Paritestaus

Tässä testauksessa kaksi testaajaa työskentelee yhdessä moduulin parissa siten, että sama testiasetelma jaetaan heidän kesken. Tämän testausmuodon ideana on saada kaksi testaajaa ideoimaan ja ideoimaan menetelmiä, joilla on useita vikoja. Molemmat voivat jakaa testaustyön ja tehdä tarvittavaa dokumentaatiota kaikista tehdyistä havainnoista.

#3) Apinatestaus

Tämä testaus suoritetaan pääasiassa yksikkötestauksen tasolla. Testaaja jäsentää tietoja tai testejä täysin satunnaisella tavalla varmistaakseen, että järjestelmä kestää mahdolliset kaatumiset. Tämä testaus voidaan luokitella edelleen kahteen luokkaan:

Ad-hoc-testaus Edut

Testaus takaa testaajalle paljon valtaa olla niin luova kuin on tarpeen.

Tämä lisää testauksen laatua ja tehokkuutta seuraavasti:

• Suurimmaksi eduksi nousee se, että testaaja voi löytää enemmän virheitä kuin perinteisessä testauksessa, koska hän voi soveltaa erilaisia innovatiivisia menetelmiä ohjelmiston testaamiseen.
• Tätä testauksen muotoa voidaan soveltaa missä tahansa SDLC:ssä; sitä ei ole rajoitettu vain testaustiimiin. Myös kehittäjät voivat suorittaa tätä testausta, mikä auttaisi heitä koodaamaan paremmin ja myös ennustamaan, mitä ongelmia saattaa esiintyä.
• Tausta voidaan yhdistää toiseen testaukseen parhaiden tulosten saamiseksi, mikä voi joskus lyhentää tavalliseen testaukseen tarvittavaa aikaa. Tämä mahdollistaisi parempilaatuisten testitapausten tuottamisen ja kaiken kaikkiaan tuotteen paremman laadun.
• Se ei edellytä dokumentoinnin tekemistä, mikä ehkäisee testaajan ylimääräistä taakkaa. Testaaja voi keskittyä taustalla olevan arkkitehtuurin todelliseen ymmärtämiseen.
• Tapauksissa, joissa testaukseen ei ole paljon aikaa, tämä voi osoittautua erittäin arvokkaaksi testien kattavuuden ja laadun kannalta.

Ad-hoc-testauksen haitat

Ad-hoc-testauksella on myös muutamia haittoja. Katsotaanpa joitain niistä haittapuolista, jotka ovat korostuneet:

Koska se ei ole kovin organisoitua eikä dokumentointia ole määrätty, ilmeisin ongelma on se, että testaajan on muistettava ja palautettava mieleen kaikki ad-hoc-skenaarioiden yksityiskohdat muistista. Tämä voi olla vielä haastavampaa erityisesti skenaarioissa, joissa eri komponenttien välillä on paljon vuorovaikutusta.

• Ensimmäisestä kohdasta seuraa, että tämä johtaisi myös siihen, että seuraavissa yrityksissä ei pystytä palauttamaan vikoja uudelleen, jos tietoja pyydetään.
• Toinen hyvin tärkeä kysymys, jonka tämä tuo esiin, on työpanoksen vastuullisuus. Koska tämä ei ole suunniteltua/jäsenneltyä, ei ole mitään keinoa tilittää tällaiseen testaukseen käytettyä aikaa ja vaivaa.
• Ad-hoc-testausta saa suorittaa vain erittäin asiantunteva ja ammattitaitoinen testaaja tiimissä, koska se vaatii ennakoivuutta ja intuitiota mahdollisten vikakohtien ennakoimiseksi.

Parhaat käytännöt tämän testauksen tehostamiseksi

Olemme keskustelleet pitkään tähän testaukseen liittyvistä vahvuuksista ja heikkouksista.

Todennäköisesti ad-hoc-testaus löytää paikkansa SDLC:ssä, mutta jos sitä ei lähestytä asianmukaisella tavalla, se voi osoittautua kalliiksi ja arvokkaan testauksen ajan tuhlaamiseksi. Alla on siis annettu muutamia vinkkejä, joiden avulla ad-hoc-testauksesta saadaan tehokasta:

#1) Tunnista virhealttiit alueet:

Kun sinulla on hyvä ote tietyn ohjelmiston testaamisesta, olet varmasti samaa mieltä siitä, että on tiettyjä ominaisuuksia, jotka ovat muita alttiimpia virheille. Jos olet uusi järjestelmässä, mene eteenpäin ja tarkista ominaisuuksia vastaan avattuja vikoja vastaan.

Virheiden määrä tietyssä ominaisuudessa on osoittaa sinulle, että se on herkkä ja sinun pitäisi juuri valita juuri tämä alue ad-hoc-testausta varten. Tämä osoittautuu erittäin aikatehokkaaksi tavaksi paljastaa joitakin vakavia vikoja.

#2) Asiantuntemuksen rakentaminen:

Epäilemättä testaaja, jolla on enemmän kokemusta, on intuitiivisempi ja osaa arvata, missä virheet saattavat olla, verrattuna henkilöön, jolla ei ole paljon kokemusta. Sanoisin, että kokenut tai ei, on yksilön tehtävä uskaltaa ja rakentaa asiantuntemusta testattavasta järjestelmästä.

Kokeneilla testaajilla on kyllä etulyöntiasema, koska heidän vuosien varrella karttuneet taitonsa tulevat tarpeeseen, mutta uusien testaajien tulisi käyttää tätä alustana hankkiakseen mahdollisimman paljon tietoa parempien ad-hoc-skenaarioiden suunnittelua varten.

#3) Luo testausluokat:

Kun olet tietoinen testattavien ominaisuuksien luettelosta, varaa muutama minuutti aikaa päättääksesi, miten luokittelisit nämä ominaisuudet ja testaisit. Päätä esimerkiksi testata ominaisuudet, jotka ovat näkyvimpiä ja joita käyttäjä käyttää yleisimmin ennen kaikkea muuta, koska ne vaikuttavat kriittisiltä ohjelmiston onnistumisen kannalta.

Sitten voisit kategorisoida ne toiminnallisuuden/prioriteetin mukaan ja testata ne segmenteittäin.

Toinen esimerkki, jossa tämä on erityisen tärkeää, on, jos komponenttien tai moduulien välillä on integrointia. Näissä tapauksissa voi esiintyä paljon poikkeavuuksia. Kategorisoinnin käyttäminen auttaisi koskemaan tällaista testausta ainakin kerran tai kaksi.

#4) Pidä yllä karkeaa suunnitelmaa:

Joo, kyllä tämä kohta saattaa hieman hämmentää, sillä kuvailimme ad hoc -testausta testaukseksi, jossa ei pitäisi olla suunnittelua tai dokumentointia. Ideana tässä on pitää kiinni ad-hoc-testauksen ytimestä, mutta silti pitää olla joitain summittaisia viitteitä muistiin kirjattuna siitä, miten aiot testata.

Hyvin perustavanlaatuinen esimerkki on se, että joskus et ehkä vain pysty muistamaan kaikkia testejä, jotka aiot suorittaa. Joten merkitsemällä ne muistiin varmistat, ettet jätä mitään tekemättä.

#5) Työkalut:

Otetaanpa esimerkki, jonka me kaikki kohtaamme hyvin yleisesti. Usein, jos havainnoit, toiminnallisuuden testaaminen sinänsä onnistuu, eikä sen käyttäytymisessä ole raportoitu poikkeamia. Kulissien takana olevat lokit saattavat kuitenkin raportoida joitain havaittuja poikkeuksia, jotka saattavat jäädä testaajilta huomaamatta, koska se ei haittaa testin tavoitetta millään tavalla.

Nämä voivat olla jopa erittäin vakavia. Siksi meidän on erittäin tärkeää oppia ja työkaluja, jotka auttavat paikallistamaan tämän välittömästi.

#6) Dokumentti lisää vikoja varten:

Ymmärrän, että tämä saattaa taas herättää kulmakarvoja. Dokumentoinnin ei tarvitse olla yksityiskohtaista, vaan vain pieni muistiinpano omaksi viitteeksesi kaikista eri skenaarioista, joita on käsitelty, poikkeaminen vaiheissa, jotka ovat mukana, ja näiden vikojen kirjaaminen tietylle testiominaisuusluokalle.

Tämä auttaa sinua parantamaan myös yleistä testauskauhaa, jolloin voisit päättää, miten parannat olemassa olevia testitapauksia tai lisäät niitä lisää, jos tarpeen.

Johtopäätös

Olemme keskustelleet yksityiskohtaisesti ad-hoc-testaustekniikoista – sen vahvuuksista, heikkouksista, tilanteista, joissa siitä olisi ja ei olisi hyötyä.

Tämä on yksi testaustekniikka, joka taatusti palvelee ja tyydyttää testaajan luovuutta maksimaalisesti. Koko testausurani aikana olen saanut suurimman tyydytyksen ad hoc -testauksesta, sillä innovatiivisuudelle ei ole mitään rajaa, ja lopputuloksena on vain enemmän tietoa.

Sen jälkeen tärkein asia, joka kaikista edellä mainituista tiedoista pitäisi ottaa talteen, olisi määritellä, miten hyödyntää ad hoc -testauksen vahvuuksia ja saada se tuomaan lisäarvoa koko testausprosessiin ja tuotteen laatuun.

Tietoa kirjoittajasta: Tämä on Sneha Nadigin vierasartikkeli. Hän työskentelee testausjohtajana, jolla on yli 7 vuoden kokemus manuaali- ja automaatiotestausprojekteista.

Toteutatko projektissasi ad-hoc-testausta? Mitä ehdotat, jotta ad-hoc-testauksesta tulisi onnistunutta?