Ad-hoc-testaus on eräänlainen ohjelmistotestaus, jota kehittäjät ja ohjelmistoyritykset käyttävät tarkastaessaan ohjelmiston nykyistä iteraatiota. Tämä testaustapa antaa paremman käsityksen ohjelmasta, ja siinä havaitaan ongelmia, joita perinteinen testaus ei välttämättä pysty nostamaan esiin.
On ensiarvoisen tärkeää, että testaustiimillä on täydellinen ymmärrys ad hoc -testausprosessista, jotta he osaavat kiertää sen haasteet ja varmistaa, että tiimi voi toteuttaa tämän tekniikan onnistuneesti.
Kun yritys tietää tarkalleen, miten ad hoc -testaus toimii ja mitkä työkalut voivat helpottaa sen toteuttamista, se voi jatkuvasti parantaa omia laadunvarmistusmenettelyjään. Virallisessa testausprosessissa noudatetaan hyvin tarkkoja sääntöjä, minkä vuoksi tiimiltä saattaa jäädä huomaamatta tiettyjä virheitä – ad-hoc-tarkastuksilla voidaan kiertää nämä sokeat kohdat ja testata nopeasti kaikki ohjelmiston ominaisuudet.
Tässä artikkelissa tarkastelemme tarkemmin ad hoc -testausta ja sitä, miten voit käyttää sitä hyödyksesi, kun kehität ohjelmistotuotetta.
Ad-hoc-testauksen merkitys: Mitä on Ad-Hoc-testaaminen?
Ad-hoc-testaus on laadunvarmistusprosessi, jossa vältetään viralliset säännöt ja dokumentointi – se auttaa testaajia löytämään sovelluksesta virheitä, joita perinteiset lähestymistavat eivät pysty tunnistamaan. Tämä edellyttää yleensä ohjelmiston kattavaa tuntemusta ennen testauksen aloittamista – mukaan lukien ohjelman sisäisen toiminnan ymmärtäminen. Näiden tilapäisten tarkistusten tarkoituksena on rikkoa sovellus tavalla, joka vastaa käyttäjän syötettä, ja ottaa huomioon erilaisia mahdollisia tilanteita, jotta kehittäjät voivat korjata mahdolliset ongelmat.
Dokumentoinnin puute on keskeinen tekijä tässä tekniikassa, joka ei sisällä tarkistuslistaa tai testitapauksia, jotka ohjaisivat testaajia sovelluksen ominaisuuksien läpi. Ad-hoc-testauksessa on kyse ainoastaan ohjelmiston testaamisesta sillä tavalla, jonka tiimi päättää juuri sillä hetkellä tehokkaaksi. Tässä voidaan ottaa huomioon jo olemassa olevat viralliset testit, mutta se voi myös yksinkertaisesti tarkoittaa mahdollisimman monen testin suorittamista siihen (todennäköisesti rajalliseen) aikaan, joka tähän tekniikkaan on varattu.
1. Milloin ja miksi ad hoc -testausta tarvitaan ohjelmistotestauksessa?
Tärkein syy siihen, että yritykset tekevät ad-hoc-testausta, on sen kyky paljastaa virheitä, joita perinteiset lähestymistavat eivät löydä. Tämä voi johtua monista syistä, kuten siitä, että perinteiset testitapaukset noudattavat erityisen standardoitua prosessia, jossa ei voida ottaa huomioon sovelluksen erityispiirteitä.
Jokainen testaustyyppi voi tarjota uusia näkökulmia ja mielenkiintoisia lähestymistapoja laadunvarmistukseen – tämä osoittaa myös tavanomaisen testausstrategian ongelmat. Jos esimerkiksi ad-hoc-testauksessa voidaan havaita huolenaihe, jota tiimin testitapaukset eivät käsittele, tämä viittaa siihen, että tiimi voisi hyötyä testausmenetelmien uudelleenkalibroinnista.
Testaajat voivat tehdä ad hoc -tarkastuksia missä tahansa testausprosessin vaiheessa. Tämä täydentää yleensä perinteistä (ja muodollisempaa) laadunvarmistusta, ja testaajat voivat tehdä tilapäistarkastuksia samalla kun heidän kollegansa tekevät muodollisempia tarkastuksia. Sen sijaan ne saattavat mieluummin säästää ad hoc -tarkastukset virallisen testausprosessin jälkeiseen seurantaan, joka kohdistuu erityisesti mahdollisiin sokeisiin pisteisiin.
Ad-hoc-testauksesta voi olla hyötyä myös silloin, kun aikaa on erityisen vähän dokumentaation puutteen vuoksi – oikea aika riippuu yrityksestä ja sen valitsemasta lähestymistavasta.
2. Kun sinun ei tarvitse tehdä ad hoc -testausta.
Jos aikaa ei ole riittävästi sekä ad-hoc- että virallisen testauksen suorittamiseen, on tärkeää, että tiimi priorisoi jälkimmäistä, koska näin varmistetaan kattava testaus – vaikka joitakin puutteita vielä olisikin.
Jos tiimin muodollisissa testeissä löydetään korjausta vaativia virheitä, on yleensä parempi odottaa, kunnes kehittäjät ovat tehneet tarvittavat muutokset, jotta ad hoc -tarkastukset voidaan tehdä. Muuten niiden antamat tulokset voivat pian vanhentua, varsinkin jos testit liittyvät komponenttiin, jossa on jo vikoja.
Tämän lisäksi ad hoc -testauksen on tapahduttava ennen beta-testausvaihetta.
3. Kuka osallistuu ad hoc -testaukseen?
Ad-hoc-testausprosessissa on useita keskeisiä rooleja, kuten:
– Ohjelmistotestaajat ovat tärkeimmät tiimin jäsenet, jotka tekevät tilapäistarkastuksia. Jos testauksessa käytetään kaveri- tai paritestausta, useat testaajat työskentelevät yhdessä samojen komponenttien parissa.
– Kehittäjät voivat itsenäisesti käyttää näitä tarkastuksia ennen virallista laadunvarmistusvaihetta tarkastellakseen nopeasti omia ohjelmistojaan, vaikka tämä ei ole yhtä perusteellista kuin erityinen ad hoc -testaus.
– Tiimin tai osaston johtajat antavat luvan yleiseen testausstrategiaan ja auttavat testaajia määrittämään, milloin ad hoc -testaus aloitetaan ja miten se suoritetaan muita tarkastuksia häiritsemättä.
Ad-hoc-testauksen edut
Ad-hoc-testauksen etuja ohjelmistotestauksessa ovat:
1. Nopeat päätöslauselmat
Koska näihin testeihin ei liity tiheää dokumentointia ennen tarkastuksia, niiden aikana tai niiden jälkeen, tiimit voivat tunnistaa ongelmat paljon nopeammin. Tämä yksinkertaisuus tarjoaa testaajille valtavan vapauden.
Jos tiimi esimerkiksi testaa komponentin eikä löydä yhtään virhettä, se voi yksinkertaisesti siirtyä seuraavaan testiin merkitsemättä tätä asiakirjaan.
2. Täydentää muita testaustyyppejä
Mikään testausstrategia ei ole täydellinen, ja 100-prosenttista kattavuutta on yleensä mahdoton saavuttaa – edes kattavalla aikataululla. Perinteisessä testauksessa on aina aukkoja, joten on tärkeää, että yritykset yhdistävät useita lähestymistapoja.
Ad-hoc-testauksella pyritään erityisesti löytämään ongelmat, joita muodollinen testaus ei pysty kattamaan, mikä takaa laajemman yleisen testikattavuuden.
3. Joustava toteutus
Ad-hoc-testaus voi tapahtua missä tahansa laadunvarmistusprosessin vaiheessa ennen beta-testausta, jolloin yritykset ja tiimit voivat päättää, milloin nämä tarkistukset on parasta suorittaa. He voivat suorittaa ad-hoc-testejä samanaikaisesti perinteisen testauksen kanssa tai odottaa niiden tekemistä vasta sen jälkeen – tiimi hyötyy joka tapauksessa heidän käytettävissään olevista vaihtoehdoista.
4. Yhteistyön lisääminen
Kehittäjät osallistuvat tähän prosessiin enemmän kuin moniin muihin testaustapoihin – etenkin jos yritys käyttää kaveri- ja paritestausta.
Tämän seurauksena kehittäjät saavat paremman käsityksen omista sovelluksistaan ja pystyvät ehkä korjaamaan virheet paremmin. Tämä auttaa parantamaan ohjelmiston yleistä laatua entisestään.
5. Erilaiset näkökulmat
Ad-hoc-testaus voi näyttää sovelluksen uusista näkökulmista, mikä auttaa testaajia tutustumaan näihin ominaisuuksiin uusilla tavoilla. Lisänäkökulmat ovat kriittisiä koko testauksen ajan, sillä muodollisissa tarkastuksissa on usein ainakin pieniä puutteita.
Jos ad-hoc-testaajat käyttävät ohjelmistoa tarkoituksenaan rikkoa se, he pystyvät helpommin havaitsemaan ohjelman rajat.
Ad-hoc-testauksen haasteet
Ad hoc -testausprosessiin liittyy myös useita haasteita, kuten:
1. Vaikeudet raportoinnissa
Dokumentaation puute nopeuttaa ad-hoc-testausta, mutta se voi myös vaikeuttaa raportointia, jos kyseessä on jokin muu kuin merkittävä ongelma.
Esimerkiksi jokin aiemmin tehty tarkastus saattaa myöhemmin osoittautua merkityksellisemmäksi, vaikka se ei aluksi johtanut merkittäviin tuloksiin. Ilman kattavaa dokumentaatiota tiimi ei välttämättä pysty selittämään näitä testejä.
2. Vähemmän toistettavissa
Vastaavasti testaajat eivät välttämättä ole täysin tietoisia siitä, mikä on tarkka edellytys havaittujen reaktioiden aikaansaamiseksi. Esimerkiksi tilapäinen tarkistus, joka palauttaa virheen, ei välttämättä anna riittävästi tietoa, jotta tiimi voisi ryhtyä toimenpiteisiin. He eivät ehkä tiedä, miten tämä testi voidaan toistaa ja saada sama tulos.
3. Vaatii ohjelmistokokemusta
Koska nopeus on avainasemassa ad hoc -testauksessa ja koska siinä yleensä yritetään rikkoa sovellus, on tärkeää, että testaajat tuntevat ohjelman hyvin.
Kun testaajat tietävät, miten se toimii, he voivat rikkoa ja manipuloida ohjelmistoa useammalla tavalla, mutta tämä voi lisätä huomattavasti ad hoc -testauksen taitovaatimuksia.
4. Rajoitettu tilivelvollisuus
Dokumentoinnin puute voi aiheuttaa muitakin ongelmia kuin vain huonon raportoinnin; se voi myös tahattomasti pidentää testausprosessia ja vaikuttaa yksittäisten nopeiden ad-hoc-testausten hyödyllisyyteen.
Testaajien voi olla vaikea seurata edistymistään ilman riittävää dokumentointia jokaisessa vaiheessa. Tämä voi jopa johtaa siihen, että he toistavat tarkistuksen, jonka muut testaajat ovat jo suorittaneet.
5. Ei ehkä vastaa käyttäjäkokemusta
Lähes kaikkien testaustyyppien tavoitteena on löytää virheitä, jotka vaikuttavat loppukäyttäjiin jollakin tavalla. Ad-hoc-testaus perustuu ensisijaisesti siihen, että kokenut testaaja yrittää jäljitellä kokematonta käyttäjää, ja tämän pitäisi olla johdonmukaista jokaisessa tarkistuksessa, mukaan lukien yritykset rikkoa sovellus.
Ad-hoc-testien ominaisuudet
Onnistuneiden ad hoc -testien pääpiirteitä ovat seuraavat:
1. Tutkinta
Ad-hoc-testauksen päätavoitteena on tunnistaa sovelluksen virheet käyttämällä tekniikoita, joita tavanomaiset tarkastukset eivät ota huomioon. Ad-hoc-tarkastukset läpikäyvät tämän ohjelmiston nimenomaisena tarkoituksena löytää aukkoja tiimin testausmenettelyssä, mukaan lukien testitapausten kattavuus.
2. Rakenteeton
Ad hoc -tarkastuksilla ei yleensä ole muuta suunnitelmaa kuin mahdollisimman monen testin suorittaminen muodollisen laadunvarmistuksen tyypillisten rajojen ulkopuolella. Testaajat ryhmittelevät tarkastukset yleensä komponenteittain, mutta tämäkään ei ole välttämätöntä – he saattavat jopa keksiä tarkastukset niitä suorittaessaan.
3. Kokemuslähtöinen
Ad-hoc-testaajat käyttävät olemassa olevaa ohjelmistokokemustaan arvioidakseen, mitkä testit tuottavat eniten hyötyä ja puuttuvat muodollisen testauksen yleisiin sokeisiin pisteisiin.
Vaikka testausprosessi on edelleen täysin strukturoimaton, testaajat käyttävät strategiaa päättäessään muun muassa aiempia ad hoc -tarkastuksia koskevaa tietämystään.
4. Laaja-alainen
Ei ole olemassa tarkkoja ohjeita siitä, mitä tarkastuksia tiimin tulisi suorittaa ad hoc -testauksen aikana, mutta ne kattavat yleensä useita komponentteja – mahdollisesti keskittyen enemmän sovelluksen arkaluonteisempiin osa-alueisiin. Näin testaajat voivat taata, että heidän kokeensa täydentävät täysin muodollista testausta.
Mitä testaamme Ad-Hoc-testeissä?
Laadunvarmistusryhmät testaavat yleensä seuraavia asioita ad hoc -testauksen aikana:
1. Ohjelmiston laatu
Näillä tarkistuksilla pyritään tunnistamaan sovelluksen virheet, joita tavanomaisella testauksella ei pystytä havaitsemaan; tämä tarkoittaa, että prosessissa testataan pääasiassa sovelluksen yleistä kuntoa.
Mitä enemmän virheitä ad-hoc-testauksella voidaan löytää, sitä enemmän parannuksia kehittäjät voivat toteuttaa ennen määräaikaa.
2. Testitapaukset
Ad-hoc-testauksessa ei yleensä toteuteta testitapauksia – ja tämä tehdään nimenomaan siksi, että tiimi voi tutkia, kuinka tehokkaasti ne kattavat laajasti. Testitapaukset ovat todennäköisesti riittämättömiä, jos ad-hoc-tarkastukset voivat löytää virheitä, joita tavanomaiset testausprosessit eivät löydä.
3. Testaushenkilöstö
Tavoitteena voi olla myös testiryhmän taitojen ja tietojen tarkistaminen, vaikka testitapaukset olisivatkin riittävät. Esimerkiksi tapausten toteuttamismenetelmä voi olla riittämätön, ja ad hoc -testaus voi olla ratkaisevan tärkeää, jotta voidaan korjata testauksen kattavuudessa ilmenevät puutteet.
4. Ohjelmiston rajoitukset
Ad-hoc-testauksella pyritään myös ymmärtämään sovelluksen rajoja – esimerkiksi sitä, miten se reagoi odottamattomiin syötteisiin tai suureen järjestelmäkuormitukseen. Testaajat voivat tutkia erityisesti ohjelman virheilmoituksia ja sitä, miten hyvin sovellus toimii, kun siihen kohdistuu huomattavia paineita.
Selvitän hieman sekaannusta:
Ad-hoc-testaus ja tutkiva testaus
Jotkut pitävät ad-hoc- ja kokeilevaa testausta synonyymeinä, vaikka totuus on monimutkaisempi.
1. Mitä on tutkiva testaus?
Tutkiva testaus tarkoittaa laadunvarmistusmenettelyjä, joissa ohjelmistoa tutkitaan kokonaisvaltaisesti ja joissa yhdistetään erityisesti löytö- ja testausprosessit yhdeksi menetelmäksi. Tämä on tyypillisesti täysin strukturoidun testauksen ja täysin vapaamuotoisten ad-hoc-tarkastusten välimuoto.
Tutkiva testaus toimii parhaiten tietyissä tilanteissa, esimerkiksi kun tarvitaan nopeaa palautetta tai jos tiimin on käsiteltävä ääritapauksia. Tämäntyyppinen testaus saavuttaa yleensä täyden potentiaalinsa, kun tiimi käyttää sen rinnalla käsikirjoitettua testausta.
2. Tutkivan testauksen erot
ja Ad-Hoc-testaukset
Suurin ero ad-hoc- ja eksploratiivisen testauksen välillä on se, että ad-hoc-testauksessa käytetään dokumentaatiota tarkastusten kirjaamiseen ja helpottamiseen, kun taas ad-hoc-testauksessa tätä vältetään kokonaan. Tutkivan testauksen yhteydessä painotetaan enemmän testauksen vapautta, mutta ei koskaan samalla tasolla kuin täysin strukturoimattomassa ad hoc -lähestymistavassa.
Tutkivaan testaukseen kuuluu myös sovelluksen ja sen sisäisen toiminnan oppiminen näiden tarkistusten aikana – ad hoc -testaajilla sen sijaan on usein kattava tietämys ohjelmiston toiminnallisuudesta ennen testauksen aloittamista.
Ad-hoc-testien tyypit
Ohjelmistotestauksessa on kolme pääasiallista ad-hoc-testausmuotoa:
1. Apinatesti
Apinatestit ovat ehkä suosituin ad-hoc-testausmuoto, jossa tiimi tutkii satunnaisesti eri komponentteja.
Tämä tapahtuu tyypillisesti yksikkötestausprosessin aikana, ja siinä suoritetaan joukko tarkistuksia ilman testitapauksia. Testaajat tutkivat tietoja itsenäisesti täysin strukturoimattomilla tavoilla, jolloin he voivat tutkia laajempaa järjestelmää ja sen kykyä kestää käyttäjän syötteiden aiheuttamaa voimakasta rasitusta.
Näiden skriptittömien tekniikoiden tulosteen tarkkailu auttaa testausryhmää tunnistamaan virheet, jotka muut yksikkötestit ovat jääneet huomaamatta perinteisten testausmenetelmien puutteiden vuoksi.
2. Kaveritestaus
Ad-hoc-tapauksissa kaveritesteissä käytetään vähintään kahta työntekijää – tyypillisesti testaajaa ja kehittäjää – ja ne tehdään pääasiassa yksikkötestausvaiheen jälkeen. Kaverukset työskentelevät yhdessä saman moduulin parissa virheiden löytämiseksi. Heidän monipuoliset taitonsa ja kattava kokemuksensa tekevät heistä tehokkaamman tiimin, mikä auttaa lievittämään monia ongelmia, jotka johtuvat dokumentoinnin puutteesta.
Kehittäjä voi jopa ehdottaa joitakin testejä itse, jolloin hän voi tunnistaa osat, jotka saattavat tarvita enemmän huomiota.
3. Paritestaus
Paritestaus on samankaltaista, koska siinä on mukana kaksi työntekijää, mutta yleensä kaksi erillistä testaajaa, joista toinen suorittaa varsinaiset testit ja toinen tekee muistiinpanoja.
Muistiinpanojen tekeminen voi antaa ryhmälle mahdollisuuden seurata yksittäisiä ad hoc -tarkastuksia epävirallisesti myös ilman virallista dokumentointia. Testaajan ja kirjurin roolit voivat vaihtua testin mukaan, tai parivaljakko voi säilyttää määritellyt roolinsa koko prosessin ajan.
Se testaaja, jolla on enemmän kokemusta, tekee yleensä varsinaiset tarkastukset – vaikka he jakavat aina työn keskenään.
Manuaaliset vai automatisoidut Ad-Hoc-testit?
Automaattisen testauksen avulla tiimit voivat säästää vielä enemmän aikaa laadunvarmistusvaiheessa, jolloin testaajat voivat sisällyttää aikatauluunsa enemmän tarkastuksia. Vaikka rakenne ei olisikaan selvä, on tärkeää, että testaajat pyrkivät maksimoimaan kattavuuden, ja automatisointi kannustaa ohjelmiston syvällisempään tarkastukseen.
Automatisoidut ad-hoc-tarkastukset ovat yleensä tarkempia kuin manuaaliset testit, koska niiden avulla vältetään inhimilliset virheet rutiinitehtävien aikana – tämä on erityisen hyödyllistä, kun samoja testejä tehdään eri iteraatioissa. Menettelyn onnistuminen riippuu yleensä ryhmän valitsemasta automaattisesta testausvälineestä ja sen toiminnallisuudesta.
Automaattisella testauksella on kuitenkin tiettyjä rajoituksia. Esimerkiksi ad hoc -testauksen tärkein vahvuus on sen kyky jäljitellä käyttäjän syötteitä ja toteuttaa satunnaisia tarkistuksia sitä mukaa kuin testaaja niitä keksii. Nämä testit voivat menettää satunnaisuutensa, jos organisaation testausohjelma ei pysty suorittamaan monimutkaisia tarkistuksia.
Näiden hyvin spesifisten tehtävien automatisointiin kuluva aika saattaa myös rajoittaa tämän prosessin tyypillistä ajansäästöä. On tärkeää, että tiimit tutkivat käytettävissä olevat automaatiotyökalut perusteellisesti löytääkseen yrityksensä projektiin sopivan työkalun.
Mitä tarvitset Ad-Hoc-testauksen aloittamiseen?
Tässä ovat ad hoc -testauksen tärkeimmät edellytykset:
1. Pätevä henkilöstö
Koska ad hoc -testit ovat nopeita, satunnaisia tarkastuksia ohjelmiston sisäisestä toiminnasta, on yleensä hyödyllistä, että testaajilla on kokemusta ohjelmistosta. Heillä on myös oltava tietämys tärkeimmistä testausperiaatteista, jotta he voivat helposti tunnistaa tehokkaimmat tarkastukset.
2. Strukturoimaton lähestymistapa
Testaajien on oltava valmiita luopumaan tavanomaisista ad hoc -testausstrategioistaan; tämä ajattelutapa on yhtä tärkeää kuin itse laatutarkastukset. Menetelmä voi onnistua vain ilman rakennetta tai dokumentointia, ja on tärkeää, että testaajat muistavat tämän joka vaiheessa.
3. Automaatio-ohjelmisto
Vaikka ad hoc -testaus perustuu enemmän satunnaisten syötteiden ja olosuhteiden testaamiseen, automatisointi on silti erittäin tehokas tekniikka kaikissa yhteyksissä.
Tästä syystä ad hoc -tarkastuksissa olisi silti mahdollisuuksien mukaan otettava käyttöön automatisoituja testausvälineitä, sillä oikea sovellus voi virtaviivaistaa prosessia huomattavasti.
4. Muut testausmuodot
Ad-hoc-testit toimivat parhaiten yhdessä muiden, muodollisemman lähestymistavan mukaisten tarkastusten kanssa – ne auttavat tiimiä takaamaan ohjelmiston kattavan kattavuuden. On tärkeää, että testaajat sekoittavat eri tekniikoita, vaikka tämä voi tapahtua ennen ad-hoc-testausta, sen aikana tai sen jälkeen.
Ad-hoc-testausprosessi
Tavanomaiset vaiheet, joita testaajien tulisi noudattaa suorittaessaan ad-hoc-testausta ohjelmistotestauksessa, ovat seuraavat:
1. Ad-hoc-testauksen tavoitteiden määrittely
Tämä vaihe on rajallinen dokumentoinnin ja rakenteen puutteen vuoksi, mutta on silti ensiarvoisen tärkeää, että tiimillä on selkeä painopiste. Testaajat saattavat alkaa jakaa epämääräisiä ajatuksia siitä, mitkä tulevat testit on suoritettava ja mitkä osat on asetettava tärkeysjärjestykseen.
2. Ad hoc -testiryhmän valinta
Kun tiimi ideoi useita mahdollisia ad-hoc-tarkastuksia, se myös miettii, ketkä testaajat soveltuisivat parhaiten tämäntyyppiseen testaukseen. He valitsevat yleensä testaajat, jotka ymmärtävät sovellusta läpikotaisin, ja saattavat myös muodostaa heistä parin kehittäjän kanssa.
3. Ad-hoc-testausten suorittaminen
Kun olet päättänyt, mitkä testaajat sopivat tähän vaiheeseen, nämä ryhmän jäsenet aloittavat tarkastukset sovitussa testausvaiheessa. Heidän tavoitteenaan on suorittaa mahdollisimman monta ad hoc -tarkastusta, joita testaajat saattavat keksiä vasta tässä vaiheessa.
4. Testitulosten arviointi
Testien päätyttyä (tai jopa yksittäisten tarkastusten välillä) testaajat arvioivat tulokset, mutta eivät dokumentoi niitä virallisesti testitapaukseen. Jos hakemuksessa ilmenee ongelmia, ne kirjataan epävirallisesti ja keskustellaan ryhmän seuraavista toimista.
5. Raportointi havaituista virheistä
Kun testaajat ovat arvioineet tulokset, heidän on ilmoitettava kehittäjille ohjelmistossa olevista virheistä, jotta heillä on riittävästi aikaa korjata ne ennen julkaisua.
Testausryhmä käyttää tietoja myös määritelläkseen, miten sen virallisia testausprosesseja voidaan parantaa.
6. Uusintatestaukset tarvittaessa
Testausryhmä todennäköisesti toistaa ad-hoc-prosessin sovelluksen uusille iteraatioille tarkistaakseen, kuinka hyvin se käsittelee päivityksiä. Koska testaajat ovat korjanneet monia aiemmin havaitsemiaan puutteita testitapauksissaan, tulevat ad hoc -tarkastukset saattavat vaatia toisenlaista lähestymistapaa.
Ad-hoc-testauksen parhaat käytännöt
On olemassa tiettyjä käytäntöjä, joita testausryhmien tulisi soveltaa ad hoc -testauksen aikana:
1. Kohdennetaan mahdolliset testauspuutteet
Vaikka ad hoc -testaukseen liittyy paljon vähemmän suunnittelua kuin muihin testaustyyppeihin, tiimi pyrkii silti korjaamaan laadunvarmistuksen puutteita. Jos ad hoc -testaajat epäilevät tiimin testitapauksissa erityisiä ongelmia, heidän olisi asetettava ne etusijalle tarkastuksiaan tehdessään.
2. Harkitse automaatio-ohjelmistoa
Automaatiostrategiat, kuten hyperautomaatio, voivat tarjota monia etuja yrityksille, jotka haluavat tehdä ad-hoc-testejä.
Tämän onnistuminen riippuu useista avaintekijöistä, kuten yrityksen valitsemasta työkalusta sekä ad hoc -testien yleisestä monimutkaisuudesta.
3. Tee kattavat muistiinpanot
Dokumentoinnin puute ad hoc -testauksessa on lähinnä tämän prosessin virtaviivaistaminen entisestään – tiimi voisi hyötyä siitä, että se tekisi epävirallisia muistiinpanoja edetessään. Tämä antaa testaajille selkeän muistiinpanon näistä tarkastuksista ja niiden tuloksista, mikä lisää testauksen yleistä toistettavuutta.
4. Jatka testien hiomista
Ad-hoc-testaajat kehittävät jatkuvasti lähestymistapaansa tiimin testausstrategiassa tapahtuvien muutosten huomioon ottamiseksi. Kun tarkastellaan esimerkiksi yrityksen ohjelmiston uudempia versioita, tarkastuksia saatetaan mukauttaa vastauksena uusiin ja kattavampiin virallisiin testitapauksiin.
7 virhettä ja sudenkuoppaa käyttöönotossa
Ad-hoc-testit
Kuten missä tahansa testausprosessissa, on olemassa lukuisia mahdollisia virheitä, joita tiimin tulisi pyrkiä välttämään:
1. Kokemattomat testaajat
Jotta ad hoc -testauksen odotettu tahti voidaan pitää yllä, ryhmänjohtajan on jaettava testaajat heidän tietojensa ja taitojensa perusteella. Vaikka monet testauksen muodot soveltuvat aloittelevalle laadunvarmistushenkilöstölle, tilapäistarkastukset edellyttävät tiimin jäseniä, jotka ymmärtävät ohjelmistoa täysin; mieluiten heillä on kokemusta näiden testien suorittamisesta.
2. Tarkentamattomat tarkastukset
Ad-hoc-testaus voi parantaa testien kattavuutta merkittävästi nopeamman tahdin ansiosta – tiimin ei tarvitse täyttää laajaa dokumentaatiota ennen ja jälkeen jokaisen tarkistuksen.
Ad-hoc-testaajien on kuitenkin edelleen pidettävä päämäärätietoisuus yllä; he voivat esimerkiksi päättää priorisoida tietyt komponentit, joiden vikaantumisriski on suurempi.
3. Ei suunnittelua
Minkäänlaisen suunnitelman välttäminen saattaa rajoittaa ad hoc -testauksen tehokkuutta. Vaikka tämä lähestymistapa on luonteeltaan strukturoimaton, on tärkeää, että tiimillä on karkea käsitys siitä, mitä testejä se aikoo suorittaa ennen kuin se aloittaa.
Aika on rajallinen tämän prosessin aikana, ja tietäminen siitä, miten edetä, voi tarjota monia etuja.
4. Liian strukturoitu
Tämä lähestymistapa perustuu tyypillisesti suunnittelun puutteeseen, sillä se auttaa testaajia aktiivisesti kiertämään testitapauksia ja löytämään piilotettuja virheitä.
Ad hoc -testausta kutsutaan myös satunnaistestaukseksi, ja rakenteen pakottaminen siihen saattaa estää näitä tarkistuksia löytämästä virheitä.
5. Ei pitkän aikavälin muutoksia
Ad-hoc-testauksen tarkoituksena on tunnistaa tiimin testitapausten mahdolliset heikkoudet; tällöin tutkitaan tiimin yleistä strategiaa yhtä paljon kuin itse ohjelmistoa.
Tämä tarkoittaa kuitenkin sitä, että ad-hoc-testit ovat yleensä tehokkaita vain, jos tiimi käyttää näitä tietoja virallisten tarkastustensa tarkentamiseen ajan myötä.
6. Yhteensopimattomat tietokokonaisuudet
Lähes kaikki testauksen muodot edellyttävät jonkinlaista simuloitua dataa, jotta voidaan arvioida, miten sovellus reagoi; joidenkin työkalujen avulla testaajat voivat automaattisesti täyttää ohjelman mock-datalla.
Tämä ei kuitenkaan välttämättä vastaa sitä, miten käyttäjä käyttäisi ohjelmistoa – tilapäiset tarkastukset edellyttävät tietokokonaisuuksia, joihin ohjelmisto todennäköisesti törmää.
7. Tietosiilot
On tärkeää, että testaajat ja kehittäjät ovat jatkuvasti yhteydessä toisiinsa, vaikka kehittäjät eivät olisikaan mukana ad hoc -testausprosessissa.
Tämä auttaa kaikkia ymmärtämään, mitkä testit on suoritettu, ja näyttää, mitä seuraavaksi on tehtävä, ja estää samalla testaajia toistamasta turhaan tiettyjä tarkastuksia.
Ad-hoc-testien tulostyypit
Ad-hoc-tarkastukset tuottavat useita eri tuotoksia, kuten:
1. Testitulokset
Yksittäiset testit tuottavat erilaisia tuloksia, jotka ovat riippuvaisia tarkasta komponentista ja lähestymistavasta – tämä voi tapahtua monessa muodossa.
Yleensä testaajan vastuulla on määrittää, ovatko tulokset virheitä, vaikka dokumentaation puute vaikeuttaakin vertailua odotuksiin. Tiimi välittää nämä tulokset kehittäjille, jos he huomaavat ongelmia.
2. Testilokit
Itse ohjelmisto käyttää monimutkaista sisäisten lokien järjestelmää, jolla se seuraa käyttäjän syötteitä ja tuo esiin useita tiedosto- tai tietokantaongelmia, joita saattaa ilmetä.
Tämä voi viitata sisäiseen virheeseen, mukaan lukien ongelman aiheuttava ohjelmiston osa. Näiden tietojen avulla ad hoc -testaajat ja kehittäjät voivat puuttua havaitsemiinsa ongelmiin paljon helpommin.
3. Virheilmoitukset
Monien ad hoc -tarkastusten tarkoituksena on nimenomaan rikkoa ohjelmisto ja paljastaa sen rajat, joten sovelluksen virheilmoitukset ovat yksi näiden testien yleisimmistä tuloksista.
Aiheuttamalla tarkoituksellisesti virheilmoituksia tiimi voi näyttää, mitä keskivertokäyttäjä näkee aina, kun hänen tekemänsä odottamattomat toimet vaikuttavat haitallisesti ohjelman toimintaan.
Esimerkkejä Ad-Hoc-testauksesta
Seuraavassa on kolme ad-hoc-testausskenaariota, jotka osoittavat, miten tiimi voi toteuttaa sen eri sovelluksissa:
1. Sähköisen kaupankäynnin verkkosovellus
Jos yritys haluaa testata verkkokauppaan perustuvaa verkkosovellusta, se voi käyttää ad-hoc-testausta – erityisesti apinatestausta – nähdäkseen, miten hyvin alusta käsittelee odottamattomia käyttäjien vuorovaikutustilanteita.
Testaajat voivat pyrkiä viemään jokaisen ominaisuuden äärirajoille esimerkiksi lisäämällä tuotteita koriinsa epärealistisia määriä tai yrittämällä ostaa tuotteita, jotka ovat loppuneet varastosta. Tiimin testitapaukset eivät rajoita heitä, eikä heidän suorittamilleen tarkistuksille ole juurikaan rajoituksia; testaajat saattavat jopa yrittää tehdä ostoksia vanhentuneita URL-osoitteita käyttäen.
2. Työpöytäsovellus
Ad-hoc-testaajat voivat soveltaa näitä tekniikoita myös työpöytäsovelluksiin ja keskittyä mahdollisesti eri koneisiin ja siihen, kuinka hyvin kukin niistä pystyy käyttämään ohjelmaa.
Ryhmän jäsenet saattavat tehdä näitä tarkistuksia toistuvasti nähdäkseen, miten laitteiston tai ohjelmiston asetusten muuttaminen vaikuttaa sovelluksen kokonaissuorituskykyyn. Esimerkiksi tietyllä näytönohjaimella voi olla vaikeuksia käyttöliittymän esittämisessä.
Vaihtoehtoisesti testaajat voisivat yksinkertaisesti antaa ohjelmalleen mahdottomia syötteitä ja katsoa, miten se reagoi, esimerkiksi pystyykö se näyttämään oikein virheilmoituksia, jotka selittävät ongelman asianmukaisesti loppukäyttäjälle.
3. Mobiilisovellus
Yksi tapa, jolla ad hoc -testaajat voivat tutkia mobiilisovellusta, on testata sen tietoturvaprotokollia – he voivat esimerkiksi yrittää päästä suoraan käsiksi sovelluksen kehitystyökaluihin.
Tiimi voi yrittää selvittää, voivatko he suorittaa luvattomia toimia etsimällä yleisiä porsaanreikiä ja hyväksikäyttöjä; he voivat pyytää erityisesti sovellusten tietoturvasta kokemusta omaavia henkilöstön jäseniä helpottamaan tätä.
Tämä voi myös tarkoittaa paritestausta kehittäjien kanssa, koska he ymmärtävät sovelluksen suunnittelun, jolloin testaaja voi rikkoa ohjelmiston ja näyttää tarkalleen, missä sen turvallisuudessa on puutteita.
Havaittujen virheiden ja vikojen tyypit
Ad-hoc-testauksen avulla
Ad-hoc-tarkistukset voivat paljastaa monia ohjelman ongelmia, kuten:
1. Toiminnallisuusvirheet
Sovelluksen perusominaisuuksien tutkiminen ad hoc -testauksella saattaa paljastaa vakavia virheitä, jotka vaikuttavat siihen, miten loppukäyttäjät voivat käyttää sovellusta.
Esimerkiksi sähköisen kaupankäynnin sivuston maksuvaihtoehtojen testaaminen apinoilla havainnollistaa olosuhteet, jotka estävät maksutapahtuman.
2. Suorituskykyyn liittyvät kysymykset
Testaajat voivat erityisesti pyrkiä luomaan ohjelmassa suorituskykyongelmia esimerkiksi täyttämällä tietokannan erilaisilla roskapostin syötteillä.
Tämä voi näkyä merkittävänä viiveenä tai jopa yleisenä ohjelmiston epävakautena, joka todennäköisesti johtaa (mahdollisesti koko järjestelmän laajuiseen) kaatumiseen.
3. Käytettävyysongelmat
Nämä tarkastukset voivat myös tuoda esiin käyttöliittymää ja yleistä käyttäjäkokemusta koskevia puutteita. Esimerkiksi mobiilisovelluksen käyttöliittymä saattaa näyttää erilaiselta eri käyttöjärjestelmässä tai näytön tarkkuudella. Huono käyttöliittymä voi johtaa siihen, että käyttäjillä on vaikeuksia käyttää tätä sovellusta.
4. Turvallisuuspuutteet
Ad-hoc-testauksen satunnainen luonne mahdollistaa sen, että sillä voidaan kattaa useita yleisiä ja harvinaisia tietoturvaongelmia; testaaja voi käyttää näitä tarkistuksia löytääkseen ohjelman hallinnolliset takaovet.
Vaihtoehtoisesti tarkastus voi osoittaa, että ohjelmistossa ei ole tietojen salausta.
Yleiset ad-hoc-testausmittarit
Ad-hoc-testaus käyttää erilaisia mittareita tulostensa helpottamiseksi, mukaan lukien:
1. Vian havaitsemisen tehokkuus
Tällä mittarilla tarkastellaan, kuinka tehokkaasti testausprosessi löytää virheitä kaikissa testauksen muodoissa, mukaan lukien ad hoc -testaus. Virheiden havaitsemisen tehokkuus on havaittujen virheiden prosenttiosuus jaettuna ongelmien kokonaismäärällä, mikä osoittaa, kuinka tehokkaita testit ovat.
2. Testien kattavuusaste
Ad-hoc-testauksen aputoiminto on lisätä kattavuutta tarkistamalla komponentteja tavalla, jota testitapaukset eivät ota huomioon. Tämä tarkoittaa sitä, että testaajat pyrkivät myös lisäämään radikaalisti testien kattavuutta kaikissa tarkastuksissa niin paljon kuin mahdollista.
3. Testin kokonaiskesto
Ad-hoc-testaus on paljon nopeampaa kuin muut laadunvarmistusprosessit – ja on tärkeää, että testaajat pyrkivät säilyttämään tämän edun. Testauksen kestoa koskevat mittarit osoittavat tiimin jäsenille, miten he voivat säästää aikaa ja lisätä ad-hoc-strategioiden etuja entisestään.
4. Onnettomuusaste
Näillä testeillä pyritään usein rikkomaan ohjelmisto ja aiheuttamaan kaatuminen tai vakava virhe, jolloin ne ylittävät tyypilliset testausstrategiat ja löytävät odottamattomia ongelmia. Tätä varten voi olla hyödyllistä tietää, kuinka usein ohjelmisto kaatuu ja mistä nämä ongelmat johtuvat.
5 parasta Ad-Hoc-testaustyökalua
Ohjelmistotestaukseen on saatavilla monia ilmaisia ja maksullisia testausvälineitä, joista viisi parasta ovat seuraavat:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST on kattava ohjelmistotestausohjelma, joka tarjoaa vahvan tason testaus- ja RPA-toiminnallisuutta sekä ilmaisessa että yritysversiossaan.
Tämä täysimittainen ohjelmistoautomaatio + RPA Suite mahdollistaa täydellisen testauksen eri työpöytä- ja mobiilialustoilla; ohjelmiston 1SCRIPT-teknologian avulla käyttäjät voivat myös suorittaa samat tarkistukset toistuvasti helposti. Tämän lisäksi työkalu hyödyntää uusinta tietokonenäköä, jonka ansiosta ZAPTEST voi suorittaa ad-hoc-testejä ihmisen näkökulmasta.
2. BrowserStack
BrowserStack on pilvialusta, joka voi helpottaa testausta yli 3 000 eri koneella, ja sen lisäominaisuutena on Selenium-skriptien automatisointi. Vaikka se tarjoaa vahvan kattavuuden ohjelmistoprojekteille, se toimii parhaiten selain- ja mobiilisovelluksissa.
BrowserStackin testausratkaisuihin sisältyy myös ilmainen kokeiluversio, joka sisältää 100 minuutin automaattisen testauksen – vaikka sen käyttö saattaa olla rajallista.
Vaikka pilvipohjainen lähestymistapa voi olla hyödyllinen, se vaikuttaa myös negatiivisesti alustan vasteaikaan.
3. LambdaTest
Myös LambdaTest käyttää pilvipohjaista teknologiaa ja painottaa vahvasti selaimen testausta, mikä saattaa rajoittaa sen tehokkuutta muissa sovelluksissa – vaikka se sopii silti hyvin iOS- ja Android-ohjelmiin. Tämä on hyödyllinen alusta, kun skaalautuvuus on huolenaihe, ja se integroituu monien muiden testihostauspalvelujen kanssa.
Joillakin käyttäjillä on kuitenkin ristiriitaisia reaktioita sovelluksen hinnoitteluun eri käytettävissä olevien ei-kokeiluvaihtoehtojen osalta, mikä saattaa rajoittaa pienempien organisaatioiden saatavuutta.
4. TestRail
TestRail on yleisesti ottaen melko mukautuva, koska se toimii täysin selaimessa, ja vaikka se keskittyykin vahvasti tehokkaisiin testitapauksiin, siinä on myös suoria ad-hoc-toimintoja. Sen jokaisen testin jälkeen tarjoama analytiikka voi myös auttaa tiimejä, jotka aktiivisesti välttävät oman riippumattoman dokumentaation laatimista, mutta antavat heille silti mahdollisuuden validoida testausprosessinsa.
Suuremmat kokonaisuudet saattavat kuitenkin kamppailla sen selainpohjaisen muodon kanssa, mikä voi rajoittaa ad-hoc-testauksen aikasäästöjä huomattavasti.
5. Zephyr
Zephyr on SmartBearin testienhallinta-alusta, joka auttaa laadunvarmistustiimejä parantamaan testauksen näkyvyyttä ja integroituu samalla hyvin muihin vikaseurantaohjelmistoihin.
Tämä ominaisuus on kuitenkin rajoitettu tiettyihin sovelluksiin, joista Confluence ja Jira hyötyvät eniten Zephyristä – nämä eivät välttämättä ole tehokkaimpia ratkaisuja kaikille yrityksille. Zephyr-tuotemerkin alla on saatavilla useita skaalautuvia ohjelmia eri hinnoilla.
Ad-Hoc-testauksen tarkistuslista, vinkkejä ja temppuja
Seuraavassa on lisävinkkejä, jotka tiimien on otettava huomioon ad hoc -testausta tehdessään:
1. Herkkien komponenttien priorisointi
Joissakin ominaisuuksissa tai osissa on luonnollisesti suurempi virheriski kuin toisissa, varsinkin jos ne ovat tärkeitä ohjelman yleisen toiminnan kannalta.
Jokaisessa testauksessa olisi tunnistettava ne sovelluksen osat, jotka saattavat hyötyä perusteellisemmasta huomiosta. Tämä on erityisen hyödyllistä silloin, kun testaukseen käytettävissä oleva aika on rajallinen.
2. Tutki erilaisia testausvälineitä
Työkalu, jonka organisaatio ottaa käyttöön testiensä helpottamiseksi, voi vaikuttaa näiden tarkastusten kattavuuteen ja luotettavuuteen.
Ad-hoc-testauksen avulla kannattaa tarkastella mahdollisimman monia ohjelmia, jotta löydetään ohjelmat, jotka sopivat sen käyttäjäkeskeiseen näkökulmaan. ZAPTESTin kaltaiset tietokonenäköteknologiaa käyttävät ohjelmistot voivat lähestyä ad-hoc-testejä ihmisen kaltaisella strategialla.
3. Ad-hoc-ajattelutapa
Tilapäinen testaus tarjoaa valtavan vapauden koko laadunvarmistusvaiheessa, mutta tiimin on sitouduttava siihen, jotta se voi hyödyntää strategian keskeisiä etuja.
Esimerkiksi ad hoc -testaajien tulisi luopua kaikista tavanomaisista asiakirjoista lukuun ottamatta perusmuistiinpanoja, ja heidän on tarkasteltava ohjelmistoa täysin uudesta näkökulmasta.
4. Luota testausvaistoihin
Kokemus ad hoc -testauksesta tai yleisistä ohjelmistotarkastuksista voi auttaa nostamaan esiin yleisiä vikakohtia, ja tämä auttaa testaajia määrittämään, miten erityyppiset virheet voidaan havaita.
On tärkeää, että testaajat luottavat vaistoihinsa ja käyttävät tätä tietoa aina hyödykseen – he osaavat aavistaa, mitkä ad hoc -tarkastukset olisivat hyödyllisimpiä.
5. Havaittujen vikojen täydellinen kirjaaminen
Vaikka ad hoc -testauksessa ei ole virallista dokumentaatiota, vaan se perustuu enimmäkseen epävirallisiin muistiinpanoihin, on silti tärkeää, että tiimi pystyy tunnistamaan ohjelmistovirheen syyn ja kertomaan siitä.
Heidän on kirjattava kaikki testin antamat tiedot, jotka ovat tärkeitä kehittäjille, kuten ongelmien mahdolliset syyt.
6. Ota aina huomioon käyttäjä
Kaikissa testauksen muodoissa pyritään jossain määrin mukauttamaan käyttäjän kokonaiskokemusta, eikä ad-hoc-testaaminen ole poikkeus. Vaikka ad-hoc-testaajien tulisi usein tutkia syvällisemmin sovelluksen sisäistä toimintaa ja jopa sen sisäistä koodia, heidän tulisi yrittää rikkoa ohjelmisto tavalla, jolla käyttäjät voisivat teoriassa rikkoa sen.
7. Jatkuva prosessin parantaminen
Testausryhmien tulisi tarkentaa lähestymistapaansa ad hoc -testaukseen saman ohjelmiston useiden iteraatioiden välillä ja projektista toiseen.
He voivat kerätä palautetta kehittäjiltä nähdäkseen, kuinka hyvin heidän ad-hoc-testauksensa auttoivat laadunvarmistusvaihetta ja pystyivätkö he lisäämään merkittävästi testien kattavuutta.
Päätelmä
Ad-hoc-testauksen avulla kaikenlaiset organisaatiot voivat todentaa ohjelmistotestausstrategiansa, mutta tapa, jolla ne toteuttavat tämän tekniikan, voi olla merkittävä tekijä sen tehokkuuden kannalta.
Eri testaustyyppien tasapainottaminen on avain siihen, että ad hoc -tarkastuksista saadaan suurin hyöty – varsinkin kun tämän testauksen tarkoituksena on täydentää muita testaustyyppejä täyttämällä strateginen aukko.
ZAPTESTin kaltaisen sovelluksen avulla tiimit voivat tehdä ad-hoc-testejä varmemmin ja joustavammin, etenkin jos ne ottavat käyttöön automaation. Riippumatta tiimin erityisestä lähestymistavasta, sen sitoutuminen ad hoc -testaukseen voi mullistaa koko ohjelman tai projektin.
