Mitä Adhoc-testaus on? Tyypit esimerkillä

Mitä on ad hoc -testaus?

Ad Hoc -testaus on spontaani ja joustava tapa testata ohjelmistoa ilman mitään ennalta määrättyä suunnitelmaa tai dokumentaatiota. Sen sijaan, että valmistelet testitapaukset etukäteen, hyppäät suoraan asiaan ja alat tutkia sovellusta. Termi "ad hoc" tarkoittaa "tiettyyn tarkoitukseen" tai "suunnittelematonta", mikä todella heijastaa tätä testaustyyliä.

Yksinkertaisesti sanottuna. Kuvittele, että olen juuri asentanut uuden sovelluksen laitteelleni. Sen sijaan, että kävisin läpi testivaiheiden listan, alan naputellaping ympäriinsä. Saatan yrittää syöttää outoja tietoja, käyttää sovellusta odottamattomilla tavoilla tai jopa yrittää rikkoa sen työnkulkua tahallani. Tavoitteenani on nähdä, miten sovellus käsittelee tosielämän, arvaamaton käyttö– ei pelkästään ihannetilanteissa.

Ad-hoc-testaus erottuu edukseen, koska se usein paljastaa ongelmia, jotka muodollisissa testeissä jäävät huomaamatta. Ajattelemalla luovasti ja asettumalla eri käyttäjien asemaan voin löytää Bugs ja käytettävyysongelmia jota muut saattavat jättää huomiotta. Tämä menetelmä perustuu testaajan intuitio, kokemus, ja syvällinen ymmärrys sovelluksesta. Se on loistava tapa havaita virheet varhaisessa vaiheessa, varsinkin kun aikaa on vähän tai dokumentaatiota on rajoitetusti.

Vaikka ad-hoc-testaus saattaa vaikuttaa epämuodolliselta, sen todellinen arvo tulee testaajan asiantuntemuksesta ja kyvystä ajattele laatikon ulkopuolellaSitä pidetään usein eräänlaisena musta ruutu testaus koska se keskittyy siihen, miten ohjelmisto käyttäytyy pinnallisesti, ei siihen, miten se on rakennettu pohjimmiltaan. Strukturoidun testauksen rinnalla käytettynä Ad-hoc-testaus auttaa varmistamaan paremman luotettava ja käyttäjäystävällinen tuote.

Seuraava video opastaa sinua Ad-hoc-testauksen tekemisessä.

Napauta täältä jos video ei ole saatavilla

Milloin suorittaa ad hoc -testaus?

Parhaan ad hoc -testausajankohdan tunteminen voi vaikuttaa merkittävästi ohjelmistosi laatuun. Vuosien varrella olen oppinut, että ajoitus on avainasemassa tässä joustavassa ja spontaanissa testaustavassa. Ad hoc -testaus sopii täydellisesti silloin, kun sinun on tarkistettava nopeasti ongelmia, jotka strukturoidut testitapaukset saattavat jäädä huomaamatta. Tarkastellaanpa tärkeimpiä tilanteita, joissa ad hoc -testaus on arvokkainta:

• Kehityksen alkuvaiheessa: Se toimii hyvin, kun viralliset testitapaukset eivät ole vielä valmiita. Voit nopeasti havaita virheet uusissa ominaisuuksissa ennen virallisten testisuunnitelmien luomista.
• Ennen virallisen testauksen alkua: Käytä Ad Hoc -testausta nopeana tarkistuksena varmistaaksesi, että perustoiminnot toimivat. Tämä auttaa välttämään ajan tuhlaamista rikkinäisiin koontiversioihin virallisten testisyklien aikana.
• Virallisen testauksen suorittamisen jälkeen: Vaikka kaikki testitapaukset olisi käyty läpi, jotkin virheet voivat silti livahtaa läpi. Ad hoc -testaus antaa sinun etsiä vikoja, jotka strukturoitu testaus saattaa jäädä huomaamatta, erityisesti ne, jotka eivät sisälly dokumentoituihin vaatimuksiin.
• Kun sinulla on vähän aikaa: Joskus aika ei yksinkertaisesti riitä täydelliseen testauskierrokseen. Tällaisissa tapauksissa kokeneet testaajat voivat käyttää Ad Hoc -testausta löytääkseen tärkeimmät ongelmat nopeasti.
• Ominaisuuden syvällinen tutkiminen: Jos haluat todella ymmärtää, miten tietty osa ohjelmistosta toimii, Ad Hoc -testaus antaa sinun tutkia sitä vapaasti pitäytymättä skriptissä.
• Käytettävyystarkistuksia varten: Voit astua käyttäjän asemaan ja nähdä, onko ohjelmistossa hämmentäviä tai turhauttavia osia. Tämä auttaa parantamaan kokonaisvaltaista käyttökokemusta.
• Beta-testauksen aikana: Monet beta-testaajat käyttävät luonnollisesti ad hoc -testausta kokeillessaan ohjelmistoa todellisissa tilanteissa ja paljastaen ongelmia, jotka ilmenevät vain tosielämän käytössä.

Ad hoc -testauksen tyypit

Ad hoc -testaus ei välttämättä noudata virallista suunnitelmaa, mutta ajan myötä on syntynyt useita hyödyllisiä tyylejä. Nämä eivät ole tiukkoja luokkia, mutta ne heijastavat sitä, miten testaajat sopeutuvat todellisten tarpeiden perusteella. Kokemukseni mukaan näiden menetelmien käyttäminen oikeassa tilanteessa voi paljastaa piileviä virheitä nopeammin ja tehokkaammin.

• Buddy testaus: Tässä menetelmässä kehittäjä ja testaaja työskentelevät rinnakkain. Kehittäjä selittää, miten ominaisuus rakennettiin. Samaan aikaan testaaja tutkii sitä käyttäjän näkökulmasta. Tämä koodaustietämyksen ja testaustaitojen yhdistelmä auttaa havaitsemaan ongelmat varhaisessa vaiheessa, usein heti koodauksen päätyttyä.
• Paritestaus: Kaksi testaajaa työskentelee yhdessä samalla laitteella. Toinen tutkii sovellusta, kun taas toinen ehdottaa erilaisia ​​​​syötteitä ja tarkkailee käyttäytymistä. He vuorottelevat ja jakavat muistiinpanoja. Tämä reaaliaikainen yhteistyö lisää luovuutta ja löytää usein enemmän vikoja kuin yksin testaaminen.
• Apinan testaus: Tämä on kaikkein arvaamattomin lähestymistapa. Testaaja tai työkalu klikkaa, kirjoittaa tai navigoi sovelluksessa satunnaisesti. Tavoitteena on ajaa järjestelmää loppuun, kunnes se rikkoutuu. Vaikka tämä saattaa vaikuttaa kaoottiselta, se on loistava tapa löytää kaatumisia tai heikkoja kohtia. Muista vain, että tällä tavalla löydettyjen virheiden toistaminen voi olla hankalaa.

Jokaisella näistä lähestymistavoista on omat vahvuutensa. Oikean tavan valinta riippuu projektisi tarpeista, tiimin dynamiikasta ja siitä, kuinka nopeasti palautetta tarvitaan. Näkemäni perusteella näiden menetelmien yhdistäminen voi tuoda parhaan hyödyn ad hoc -testauksesta – paljastaa ongelmia, jotka skriptitestaus ei ehkä huomaa.

Ad-hoc-testauksen edut

Ad-hoc-testaus tarjoaa ainutlaatuisen arvon, joka strukturoidussa testauksessa usein jää huomaamatta. Se on joustavaa, nopeaa ja perustuu testaajan vaistoihin eikä kiinteisiin menetelmiin. Kokemukseni mukaan tämäntyyppinen testaus on tehokas kumppani muodollisille menetelmille, erityisesti nopeasti muuttuvissa kehitysympäristöissä.

• Paljastaa piilotettuja bugeja: Ilman ennalta määriteltyjen testitapausten rajoja se tutkii odottamattomia polkuja, joissa virheet usein piilevät.
• Nopea ja yksinkertainen asennus: Ei tarvetta yksityiskohtaisille testaussuunnitelmille tai dokumentaatiolle, mikä säästää paljon aikaa, kun tarvitaan nopeaa palautetta.
• Kustannustehokas, kun aika on tiukka: Ihanteellinen tilanteisiin, joissa resurssit ovat rajalliset, mutta kriittiset virheet on silti löydettävä nopeasti.
• Todellisten käyttäjien näkemykset: Koska testaajat käyttäytyvät loppukäyttäjien tavoin, testausprosessi voi tuoda esiin käytettävyysvirheitä, joita muodolliset testit saattavat jättää huomaamatta.
• Käyttää testaajan intuitiota: Taitavat testaajat voivat luottaa kokemukseensa paljastaakseen hienovaraisia ​​vikoja, jotka työkalut tai skriptit saattavat jättää huomaamatta.
• Parantaa virallista testausta: Se ei korvaa virallista testausta. Sen sijaan se lisää luottamusta laajentamalla testien kattavuutta.
• Välitön palautesilmukka: Erityisen hyödyllinen ketterissä kokoonpanoissa, joissa virheet on löydettävä ja korjattava nopeasti, jotta asiat etenevät.

Ad-hoc-testauksen haitat

Ad hoc -testaukseen liittyy useita rajoituksia, jotka voivat vaikuttaa sekä testauksen laatuun että lopputulokseen. Selitän nämä selkeästi testauskokemukseni pohjalta.

• Vaikea toistaa bugeja: Koska strukturoitua lähestymistapaa tai vaiheittaista dokumentaatiota ei ole, ongelman toistaminen voi olla hankalaa. Tämä vaikeuttaa ongelman korjaamista kehittäjille.
• Testaajan kokemukseen perustuva: Tämän menetelmän onnistuminen riippuu paljon testaajan taidosta tai tuotteen tuntemuksesta. Aloittelija saattaa jättää huomaamatta tärkeitä puutteita, jotka kokenut testaaja huomaisi.
• Ei täydellistä testikattavuutta: Ad hoc -testaus ei seuraa suunniteltua polkua. Tämä tarkoittaa, että jotkin tärkeät alueet saattavat jäädä testaamatta huomaamatta, ennen kuin on liian myöhäistä.
• puuttuu Tracking ja mittarit: Ilman testitapauksia tai lokeja on vaikea mitata edistymistä, tunnistaa kaavoja tai ymmärtää, mitä on testattu. Tämä heikentää tiimien ja sidosryhmien näkyvyyttä.
• Ei sovellu korkean riskin sovelluksiin: Terveydenhuollon, pankkitoiminnan tai turvallisuuskriittisten järjestelmien projektit vaativat perusteellista dokumentointia ja validointia. Pelkkä ad hoc -testaus ei täytä näitä tiukkoja standardeja.
• Voiko aikaa tuhlata ilman keskittymistä: Jos testaajalla ei ole ainakaan epävirallisia tavoitteita, hän saattaa käyttää liikaa aikaa vähemmän tärkeiden ominaisuuksien tutkimiseen. Tämä hidastaa koko testaussykliä.

Parhaat käytännöt tehokkaaseen ad hoc -testaukseen

Jotta Ad Hoc -testauksen hyödyt olisivat mahdollisimman suuria sen epämuodollisesta luonteesta huolimatta, harkitse näitä käytäntöjä, jotka kurovat umpeen kuilua strukturoimattoman etsinnän ja luotettavan vikaantumisen välillä. trackuningas:

1) Hyvä liiketoimintaosaaminen

Testaajilla tulisi olla hyvä tietämys liiketoiminnasta ja selkeä käsitys vaatimuksista. Yksityiskohtainen tietämys koko liiketoimintaprosessista auttaa löytämään vikoja helposti. Kokeneet testaajat löytävät enemmän vikoja, koska he ovat parempia virheiden arvaamisessa.

2) Testaa avainmoduulit

Keskeiset liiketoimintamoduulit tulisi tunnistaa ja kohdistaa ad-hoc-testaukseen. Liiketoimintakriittiset moduulit tulisi testata ensin, jotta järjestelmän laatuun voidaan luottaa.

3) Tietuevirheet

Kaikki viat on kirjattava muistiin tai kirjoitettava muistiin. Viat on osoitettava kehittäjille korjattaviksi. Jokaista kelvollista vikaa kohden on kirjoitettava vastaavat testitapaukset ja lisättävä ne suunniteltuihin testitapauksiin.

Nämä Vika havainnot tulisi tehdä opiksi, ja niiden pitäisi näkyä seuraavassa järjestelmässämme, kun suunnittelemme testitapauksia.

4) Parittautuminen

Kuten on nähty Buddy tai paritestauksessa yhteistyö voi tuoda mukanaan erilaisia ​​näkökulmia ja parantaa vikojen havaitsemista.

Esimerkkejä adhoc-testeistä

Ad-hoc-testauksessa on kyse sovelluksen tutkimisesta ilman kiinteää suunnitelmaa. Skriptien seuraamisen sijaan luotamme intuitioon ja aiempaan kokemukseen. Olen usein havainnut tämän lähestymistavan hyödylliseksi yrittäessäni havaita epätavallisia tai odottamattomia virheitä, jotka skriptitestit saattavat jäädä huomaamatta.

• Kirjautumisominaisuuden stressitesti: Testaaja kirjautuu toistuvasti sisään ja ulos eri tunnuksilla, joista osa on vääriä, nähdäkseen, kaatuuko järjestelmä tai reagoiko se oudosti.
• Epätavallinen käyttäjän syöte: Symbolien, erittäin pitkien merkkijonojen tai odottamattomien tiedostomuotojen syöttäminen järjestelmän toiminnan tarkistamiseksi. Se auttaa selvittämään, kuinka hyvin syötteen validointi on käsitelty.
• Satunnaiset klikkaukset ja navigointi: Testaaja napsauttaa sovellusta satunnaisesti – hyppääping sivujen välillä, käynnistämällä painikkeita väärässä järjestyksessä – havaitakseen odottamattomia toimintoja.
• Tiedoston latauksen kaaos: Lataa ei-tuettuja tiedostotyyppejä tai vioittuneita tiedostoja lataustoiminnon kestävyyden testaamiseksi.
• Keskeytystestaus: Prosessin keskeyttäminen (kuten välilehden sulkeminen kesken tallennuksen tai internet-yhteyden katkaiseminen) järjestelmän palautumisen tarkistamiseksi.

Vertaileva analyysi ja tutkiva testaus

Vaikka ad hoc -testaus ja tutkiva testaus usein sekoitetaan, niillä on erilliset toiminnalliset parametrit:

ominainen	Ad Hoc -testaus	Tutkiva testaus
Dokumentaatio	Vain suorituksen jälkeen	Jatkuva tallennus
Suunnittelu	Ei eristetty	Kevyt charter-pohjainen
Istunnon rakenne	Täysin jäsentämätön	Aikarajatut iteraatiot
Vian lisääntyminen	33 %:n toistettavuus	78 %:n toistettavuus
Automaatiointegraatio	Rajoitettu sovellettavuus	42 % työkalujen sisällyttäminen

UKK