fbpx

Get your 6-month No-Cost Opt-Out offer for Unlimited Software Automation?

 

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.

 

Table of Contents

Ad-hoc-testauksen merkitys: MitƤ on Ad-Hoc-testaaminen?

tarkistuslista uat, web-sovellusten testaustyƶkalut, automaatio ja paljon muuta

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?

Testauksen huippuosaamiskeskuksen perustamisen edut. Eroaako suorituskykytestaus toiminnallisesta testauksesta?

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.

Testauksen huippuosaamiskeskuksen perustamisen edut. Eroaako suorituskykytestaus toiminnallisesta testauksesta?

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?

joiden tulisi olla tekemisissƤ ohjelmistotestauksen automatisointityƶkalujen ja -suunnittelun kanssa.

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

Zaptest, paras toiminnallisen testauksen automatisointityƶkalu

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

haasteet kuormitustestaus

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

api-testaus ja automaatio

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Ƥ?

End to end -testaaminen - MitƤ on E2E-testaaminen, tyƶkalut, tyypit ja paljon muuta.

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

UAT-testauksen vertailu regressiotestaukseen ja muuhun testaukseen

Jotkut pitƤvƤt ad-hoc- ja kokeilevaa testausta synonyymeinƤ, vaikka totuus on monimutkaisempi.

 

1. MitƤ on tutkiva testaus?

Testauksen huippuosaamiskeskuksen perustamisen edut. Eroaako suorituskykytestaus toiminnallisesta testauksesta?

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

Testauksen huippuosaamiskeskuksen perustamisen edut. Eroaako suorituskykytestaus toiminnallisesta testauksesta?

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.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

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

web-sovelluksen automaatiotestaus

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?

tietokonenƤkƶ ohjelmistojen testauksessa

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?

Automaation kuormitustestaus

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

Bak end testaus, tyƶkalut, mitƤ se on, tyypit, lƤhestymistavat, lƤhestymistavat, jne.

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

2-2.png

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

hyƶdyt UI-testaus

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

ohjelmistotestauksen automaatio virka

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.

 

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Havaittujen virheiden ja vikojen tyypit

Ad-hoc-testauksen avulla

zaptest-runtime-error.png

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

kuormitustestaus

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

parhaat ilmaiset ja yritysten ohjelmistotestaus + RPA-automaatiotyƶkalut

Ohjelmistotestaukseen on saatavilla monia ilmaisia ja maksullisia testausvƤlineitƤ, joista viisi parasta ovat seuraavat:

 

1. ZAPTEST Free & Enterprise Edition

harmaalaatikkotestaus artikkeli - tyƶkalut, lƤhestymistavat, vertailu verrattuna valkolaatikko- ja mustalaatikkotestaukseen, harmaalaatikkotestaus ilmaiseksi ja yritystyƶkalut.

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

Ohjelmistotestauksen tarkistuslista

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.

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post