fbpx

Tutkiva testaus on erityyppinen ohjelmistotestaus, josta on monia etuja sovellukselle, ja sen avulla se voi hyƶdyntƤƤ koko potentiaaliaan.

Tapa, jolla tiimi integroi tutkivan testauksen rutiinitarkastuksiinsa, voi jopa mƤƤrittƤƤ, miten hyvin ohjelmisto toimii, varsinkin kun testausta lƤhestytƤƤn uusilla ja odottamattomilla tavoilla. TƤmƤ auttaa testaajia paljastamaan sovelluksen ongelmat, jotka voivat muuten jƤƤdƤ huomaamatta ennen kƤyttƶƶnottoa ja johtaa siihen, ettƤ keskeiset ominaisuudet eivƤt toimi.

Tutkivan testauksen prosessien, tyyppien ja lƤhestymistapojen ymmƤrtƤminen voi auttaa sinua ohjaamaan organisaatiota ja sen testaustiimejƤ siinƤ, miten ne voivat sisƤllyttƤƤ sen tavanomaisiin tarkastuksiinsa.

Tiimi voi myƶs kƤyttƤƤ useita ilmaisia tyƶkaluja, joilla se voi helpottaa nƤitƤ tarkastuksia ja havaita ongelmat ennen kuin niistƤ voi tulla kehityksen esteitƤ.

TƤssƤ oppaassa esittelemme kokeilevan testauksen edut sekƤ tƤrkeimmƤt seikat, jotka tiimin tulisi ottaa huomioon ennen kƤyttƶƶnottoa.

 

Table of Contents

MitƤ on tutkiva testaus?

 

Tutkiva testaus yhdistƤƤ testin suunnittelu- ja toteutusvaiheet, mikƤ takaa testaajalle tƤydellisen toimintavapauden ja antaa hƤnelle mahdollisuuden tehostaa tyƶtƤƤn jatkuvasti.

Kun nƤmƤ tiimit tarkistavat ohjelmistoa, he todennƤkƶisesti lƶytƤvƤt uusia komponentteja, jotka vaativat perusteellista tarkastusta, ja he voivat helposti keksiƤ uusia testejƤ, jotka hyƶdyttƤisivƤt sovellusta.

Tutkiva testaus muistuttaa ad hoc -testausta, mutta siinƤ noudatetaan paljon tiukempaa dokumentaatiota ja siihen sisƤltyy myƶs aktiivisempi oppimisprosessi.

VƤhemmƤn strukturoitu lƤhestymistapa auttaa testaajia selvittƤmƤƤn, miten sovellus todennƤkƶisesti reagoi realistisiin skenaarioihin ja testitapauksiin, ja se on tƤrkeƤ tƤydennys kƤsikirjoitustestaukselle.

Tiimin kokeellisen testauksen laatu riippuu usein yksittƤisten testaajien taidoista, sillƤ tarkastukset edellyttƤvƤt luovuutta ja ohjelmiston perusteellista ymmƤrtƤmistƤ. KyseessƤ on jatkuvan lƶytƤmisen prosessi, jossa testaajat kƤyttƤvƤt deduktiivista pƤƤttelyƤ ohjaamaan yleistƤ tekniikkaansa.

Tutkiva testaus on erityisen hyƶdyllistƤ, koska se heijastaa sitƤ, miten kƤyttƤjƤt saattavat kƤyttƤƤ ohjelmistoa. Useimmat kƤyttƤjƤt lƶytƤvƤt virheitƤ ja ongelmia vahingossa, joten nƤmƤ skriptittƶmƤt prosessit voivat auttaa testaajia lƶytƤmƤƤn ongelmia, joita ennalta mƤƤritellyt tarkistukset eivƤt vƤlttƤmƤttƤ paljasta.

Tiimi voi myƶs automatisoida tƤmƤn menettelyn tehokkuuden lisƤƤmiseksi.

 

1. Milloin sinun on tehtƤvƤ tutkivaa testausta?

 

Tutkiva testaus on yleisesti ottaen hyƶdyllistƤ lƤhes kaikissa ohjelmistotestausprosesseissa, mutta se on erityisen hyƶdyllistƤ nopean palautteen antamisessa sovelluksesta.

RyhmƤ voi myƶs sisƤllyttƤƤ nƤmƤ tarkistukset, jos skriptitestit loppuvat kesken. Jos ohjelmistotarkastuksille ei ole selkeƤƤ suuntaa, kokeileva testaus voi auttaa paljastamaan ongelmia, jotka eivƤt kuulu vakiotarkastusten piiriin.

Monipuolisten testausmenettelyjen varmistaminen antaa testaajille mahdollisuuden ymmƤrtƤƤ ohjelmistoa paljon syvƤllisemmƤllƤ tasolla missƤ tahansa vaiheessa, mutta niiden suorittaminen varhaisessa vaiheessa saattaa tarjota enemmƤn etuja.

Tiimit voivat tarvittaessa suorittaa koekƤyttƶkokeita myƶhemmin uudelleen, mikƤ lisƤƤ mielenrauhaa.

 

2. Kun et tarvitse kokeilevaa testausta.

 

On olemassa muutamia tilanteita, joissa kokeilevasta testauksesta ei ole mitƤƤn hyƶtyƤ, vaikka testaajille voi olla hyƶdyllisempƤƤ odottaa, kunnes ohjelmiston ydintoiminnallisuus on valmis.

Sovelluksen ominaisuudet ovat tyypillisesti risteƤviƤ tai vuorovaikutuksessa toistensa kanssa, mikƤ tarkoittaa sitƤ, ettƤ yhden toiminnon kokeilevat testit voivat olla vanhentuneita, kun kehitystiimi lisƤƤ ohjelmistoon uusia toimintoja.

NƤmƤ testit on myƶs mahdollista suorittaa skriptitarkastusten rinnalla ilman ongelmia, kunhan testaajat pystyvƤt varmistamaan vahvan dokumentoinnin sekaannusten vƤlttƤmiseksi.

Tutkiva testaus on erittƤin monipuolista verrattuna muihin testaustyyppeihin, joten nƤitƤ tarkastuksia voidaan soveltaa hyvin.

 

3. Kuka osallistuu kokeilevaan testaukseen?

 

Tutkivaan testaukseen osallistuu jossakin mƤƤrin monia henkilƶstƶn jƤseniƤ, kuten:

– Ohjelmistotestaajat voivat tehdƤ nƤitƤ testejƤ millƤ tahansa taitotasolla, mutta tiimin jƤsenet, jotka tuntevat ohjelmiston paremmin, voivat suunnitella enemmƤn erilaisia tarkastuksia.

Kokemus voi myƶs vaikuttaa heidƤn kykyynsƤ mƤƤrittƤƤ hyƶdyllisimmƤt testit.

– OhjelmistokehittƤjƤt, jotka ottavat huomioon nƤiden testien tulokset, ryhtyvƤt kaikkiin ehdotuksiin ja kehittƤvƤt usein oman ratkaisunsa ongelmaan.

Testeihin saatujen vastausten ansiosta sovellus on kunnossa, jotta se voidaan julkaista menestyksekkƤƤsti.

– ProjektipƤƤllikƶt valvovat koko prosessia ja saattavat jopa pƤƤttƤƤ, mitƤ testaustyyppejƤ tiimit kƤyttƤvƤt.

He voivat myƶs vastata siitƤ, ettƤ tiimeille hankitaan ohjelmistoja, joilla voidaan tehostaa tai jopa automatisoida testejƤ.

 

Tutkivan testauksen elinkaari

 

Tutkivan testauksen prosessissa keskitytƤƤn vahvasti testaajan vapauteen, mutta se noudattaa silti tiettyƤ rakennetta.

TƤmƤn lƤhestymistavan kolme pƤƤvaihetta ovat:

 

Vaihe 1: Oppiminen

 

Testaajat aloittavat kehittƤmƤllƤ vahvan ymmƤrryksen ohjelmistosta ja sen toiminnallisuudesta – he analysoivat sitƤ kriittisesti selvittƤƤkseen, miten se sopii yhteen.

NƤin testaaja voi selvittƤƤ tavanomaiset syƶtteet, joita kƤyttƤjƤ voi tehdƤ, vaikka hƤn saattaa olla jo tietoinen sovelluksesta ja sen toiminnasta.

Oppimisvaihe voi vaatia jopa opastusta ohjelmiston kƤyttƶƶn. TƤmƤ on tutkimusvaihe, ja se antaa testaajalle kaikki tarvittavat tiedot, jotta hƤn voi suunnitella laajan valikoiman hyƶdyllisiƤ testejƤ.

 

Vaihe 2: Testauksen suunnittelu

 

Tutkivan testauksen suunnitteluun liittyy erilaisia sƤƤntƶjƤ ja parametreja, mutta se tarjoaa silti huomattavasti enemmƤn vapautta verrattuna skriptitestaukseen, jonka yksityiskohdat tiedetƤƤn jo ennen testauksen aloittamista.

Testaaja voi laatia tarkistuksia, joiden hƤn uskoo sopivan tarkemmin sovellukseen, ja voi mahdollisesti paljastaa arvokasta tietoa kehitystiimille, mukaan lukien merkittƤviƤ virheitƤ, jotka he voivat korjata.

TestausryhmƤt kƤyttƤvƤt tƤtƤ vaihetta sen selvittƤmiseen, mitƤ lƤhestymistapaa kƤytetƤƤn ja miten tyƶ jaetaan eri testaajien kesken siten, ettƤ heidƤn vahvuuksiaan hyƶdynnetƤƤn.

 

Vaihe 3: Toteutus

 

Kun testaajat ovat suunnitelleet kƤytettƤvƤt tarkistukset, he voivat nyt tarkastaa sovelluksen heidƤn mielestƤƤn tehokkaimmilla tavoilla – he voivat tehdƤ tƤmƤn heti tietyn testin suunnittelun jƤlkeen.

TƤssƤ vaiheessa testaajat etsivƤt aktiivisesti ongelmia ja sitƤ, miten heidƤn havaitsemansa ongelmat voisivat vaikuttaa muihin ominaisuuksiin ja toimintoihin.

Vaikka kokeilevaan testaukseen liittyy jonkin verran intuitiivista tyƶtƤ, se noudattaa silti tiettyjƤ prosesseja ja tavoitteita, mikƤ mahdollistaa sujuvan testauksen, joka voi helposti mukautua erityisiin testaustavoitteisiin.

 

Tutkiva testaus vs. kƤsikirjoitettu testaus

 

Tutkiva testaus on kƤytƤnnƶssƤ kƤsikirjoitetun testauksen vastakohta, vaikka molemmat voivat olla tƤrkeitƤ sovelluksen julkaisuvalmiuden varmistamisessa. JƤlkimmƤinen on yleensƤ muodollisempi ja jƤsennellympi ja sisƤltƤƤ monia laajoja testejƤ verrattuna tutkiviin tarkastuksiin, jotka ovat usein tarkemmin sovelluksen toiminnallisuutta koskevia.

Tutkiva testaus on myƶs huomattavasti mukautumiskykyisempƤƤ, kun taas kƤsikirjoitustesteillƤ voi olla vaikeuksia, jos ohjelmistoon tehdƤƤn suuria muutoksia. Tutkivat testit voivat paljastaa virheitƤ ja toimia niiden suhteen nopeammin, joten ne ovat erityisen hyƶdyllisiƤ tapauksissa, joissa nopea palaute on ensiarvoisen tƤrkeƤƤ.

 

1. Aktiivinen tutkiva testaus

 

Aktiivisessa tutkivassa testauksessa testaaja suunnittelee tarkastuksiaan varten automaattisen skriptin, jonka toinen testaaja suorittaa. NƤissƤ skripteissƤ otetaan tarvittaessa huomioon edelliset testit.

Kaksi testaajaa vaihtavat yleensƤ roolia koko tarkastusmenettelyn ajan, jotta nƤiden skriptien ja prosessien luotettavuus voidaan tarkistaa.

Aktiivisilla testeillƤ on laajempi kattavuus, mutta ne eivƤt menetƤ tutkivien tarkastusten tavaramerkkispesifisyyttƤ. NƤmƤ skriptit mahdollistavat myƶs paremman dokumentoinnin, jolloin testaajien havaitsemat ongelmat on helpompi toistaa.

Dokumentointi on olennainen osa aktiivista testausta, sillƤ se auttaa sidosryhmiƤ nƤkemƤƤn sovelluksen yleisen edistymisen.

 

2. Passiivinen tutkiva testaus

 

Passiivinen tutkiva testaus vaatii vain yhden testaajan, mutta parityƶskentely voi tehostaa prosessia entisestƤƤn.

TƤhƤn lƤhestymistapaan liittyy erityinen ohjelmisto, joka tallentaa testaajan toimet ja antaa testaajalle helppoja ohjeita havaitun ongelman toistamiseksi. TƤmƤ tapahtuu yleensƤ videon muodossa, jossa testaaja selostaa toimintaansa vaihe vaiheelta.

Testausprosessin tallentaminen antaa myƶs tietoa sovelluksen suorituskyvystƤ, kuten siitƤ, kuinka nopeasti se vastaa syƶttƶpyyntƶihin.

Passiivinen testaus tarjoaa sekƤ testaajille ettƤ kehitystiimille runsaasti yksityiskohtaista tietoa siitƤ, miten ohjelmisto toimii.

 

Tutkivan testauksen tekniikat

 

Tutkiva testaus noudattaa tyypillisesti ”kierros”-mallia, jossa testaaja tutkii ohjelmistoa mahdollisimman tehokkaasti.

Joukkue voi valita erilaisia retkiƤ, kuten:

 

– Opaskirjamatkat

TƤmƤ lƤhestymistapa asettaa sovelluksen korostetut toiminnot etusijalle, jƤljittelee tarkasti sitƤ, miten keskivertokƤyttƤjƤ kƤyttƤƤ ohjelmistoa, ja paljastaa ongelmat, joita hƤn luonnollisesti lƶytƤisi.

 

– Historialliset kierrokset

TƤllƤ kierroksella tarkastetaan sovelluksen vanhimmat ominaisuudet varmistaaksesi, ettƤ ne toimivat yhƤ; tƤmƤ on erityisen tƤrkeƤƤ, jos kehittƤjƤt ovat lisƤnneet uusia ominaisuuksia, jotka ovat ristiriidassa sen kanssa.

 

– Money tour

TƤssƤ kokeilevassa testissƤ tarkistetaan kriittiset sovelluksen ominaisuudet, erityisesti ne, joiden kƤytƶstƤ asiakkaat maksavat rahaa – nƤmƤ ovat yleensƤ testausryhmƤn tƤrkeimpiƤ.

 

– Rikoskierros

Testaajat tyƶskentelevƤt joskus aktiivisesti rikkoakseen sovelluksen tai luodakseen negatiivisia skenaarioita, esimerkiksi syƶttƤmƤllƤ virheellisiƤ tietoja ja tutkimalla, miten sovellus reagoi tƤhƤn.

 

– Back alley tour

TƤhƤn prosessiin liittyy ominaisuuksia, joita harvemmat asiakkaat todennƤkƶisesti kƤyttƤvƤt; ne ovat yhtƤ tƤrkeitƤ minkƤ tahansa testausmenetelmƤn kannalta, varsinkin kun ne ovat vuorovaikutuksessa muiden toimintojen kanssa.

 

– Intellektuaalinen kiertue

TƤllƤ kierroksella sovellus viedƤƤn pidemmƤlle ja testataan monimutkaisimpia toimintoja suuremmilla (joskus enimmƤis)arvoilla, jotta voidaan mƤƤrittƤƤ ohjelmiston kƤsittelynopeus.

 

Tutkivan testauksen lƤhestymistavat

 

Tutkivan testauksen lƤhestymistapoja on kaksi:

 

1. Istuntopohjainen tutkiva testaus

 

KyseessƤ on aikapohjainen tekniikka, jonka tarkoituksena on kvantifioida testausprosessi jakamalla se ”istuntoihin”, joilla on kaksi komponenttia: tehtƤvƤt ja toimeksiannot.

TehtƤvƤ on kyseisen istunnon tarkoitus ja kesto, ja se antaa tutkivalle testaajalle selkeƤn painopisteen.

Peruskirjassa mƤƤritellƤƤn jokaisen istunnon laajuus ja yksityiskohtaisesti kaikki erityistavoitteet, jotka testaajan on tarkoitus saavuttaa. TƤmƤ johtaa suurempaan vastuullisuuteen (ja dokumentointiin), kun tarkastukset jaetaan helpommin hallittaviin osiin.

Istuntopohjaiset testit parantavat myƶs tuottavuutta ja antavat testaajalle selkeƤt mittarit ja vianmƤƤritystiedot.

 

2. Paripohjainen tutkiva testaus

 

Paritestaus muistuttaa aktiivista tutkivaa testausta, sillƤ siinƤ tyƶskennellƤƤn pƤƤasiassa pareittain – yleensƤ samalla laitteella – ja tarkistetaan sovellusta jatkuvasti ja samanaikaisesti. TƤssƤ jƤrjestelyssƤ toinen testaaja ehdottaa erilaisia testitapauksia ja tekee muistiinpanoja edistymisestƤ, kun toinen testaa ohjelmistoa.

Kommunikointi on olennaista koko paritestauksen ajan, sillƤ sen avulla varmistetaan, ettƤ molemmat testaajat ovat tietoisia tarkistuksista ja niiden tarkoituksesta.

Jos mƤƤrittelet nƤmƤ parit itse, varmista, ettƤ otat huomioon jokaisen testaajan vahvuudet ja heikkoudet, sillƤ nƤin voit rakentaa vahvemmat tutkivan testauksen prosessit.

 

MitkƤ tekijƤt vaikuttavat testaukseen?

 

Tiimin kokeilevan testauksen laatuun voivat vaikuttaa muun muassa seuraavat tekijƤt:

 

– Ohjelmiston yleistavoite ja ydintoiminnot.

– Sovelluksen nykyisen vaiheen erityiset testaustavoitteet.

– Tiimin jokaisen testaajan yksilƶlliset roolit ja kyvyt.

– KƤytettƤvissƤ olevat tyƶkalut, kuten ilmaiset ohjelmistot testien automatisoimiseksi.

– Testaajien vertaisilta tai johdolta saama tuki.

– Asiakkaan toiveet ja markkinoiden tƤmƤnhetkiset yleiset suuntaukset.

– Sovelluksen helppokƤyttƶisyys, kuten kƤyttƶliittymƤn sujuvuus.

– Aika, joka testaajilla on kƤytettƤvissƤƤn testausvaiheen suorittamiseen.

– Syƶtteet ja muut valikoidut tiedot, joita testaajat aikovat kƤyttƤƤ.

– Ominaisuudet, joita kehittƤjƤt lisƤƤvƤt ohjelmistoon ajan myƶtƤ.

 

Tutkivan testauksen tyypit

 

Kolme pƤƤasiallista kokeilevan testauksen tyyppiƤ, joita tiimi voi kƤyttƤƤ, ovat:

 

1. Vapaamuotoinen tutkiva testaus

 

Vapaatyylinen testaus perustuu ad hoc -lƤhestymistapaan sovelluksen tarkistamisessa. TƤssƤ on vain vƤhƤn sƤƤntƶjƤ, joten sen tehokkuus voi vaihdella; jotkin ohjelmistot ja komponentit edellyttƤvƤt vankempaa menetelmƤƤ.

NƤistƤ tarkistuksista voisi silti olla paljon hyƶtyƤ, sillƤ ne auttaisivat testaajia tutustumaan sovellukseen ja vahvistaisivat edellisen testaajan tyƶn.

Vaikka tiukkoja sƤƤntƶjƤ ei olisikaan, kokeneet ja taitavat testaajat voivat helposti kƤyttƤƤ tƤtƤ formaattia hyvƤkseen. He voivat liikkua ohjelmiston kaikilla osa-alueilla helposti – joissakin tilanteissa testaussƤƤnnƶt ovat rajoittavia ja saattavat tahattomasti rajoittaa tiimin tuloksia.

 

2. Skenaariopohjainen tutkiva testaus

 

Skenaariopohjaisessa testauksessa kƤytetƤƤn realistisia tilanteita jokaisen testin perustana, esimerkiksi tarkistamalla syƶtteet, joita kƤyttƤjƤt todennƤkƶisesti tekevƤt ohjelmiston tyypillisen kƤytƶn aikana.

Testaajat tekevƤt kovasti tƶitƤ varmistaakseen, ettƤ jokainen heidƤn suunnittelemansa skenaario vastaa sitƤ, miten kƤyttƤjƤ kƤyttƤƤ sovellusta.

Aika voi olla rajoitteena, sillƤ ryhmƤn tavoitteena on testata mahdollisimman monia skenaarioita; tulevista mƤƤrƤajoista riippuen tƤmƤ ei todennƤkƶisesti kata kaikkia mahdollisuuksia.

Testaajien tulisi kƤyttƤƤ monenlaisia testejƤ eri luokissa.

 

3. Strategiaan perustuva tutkiva testaus

 

Strategiaan perustuvaan testaukseen kuuluu monenlaisia erityismenetelmiƤ, kuten raja-arvotestaus, ekvivalenssitekniikat, riskiperusteiset tekniikat ja paljon muuta. TƤmƤ asettaa yleensƤ etusijalle testaajat, jotka tuntevat sovelluksen, koska he voivat kehittƤƤ rƤƤtƤlƶityjƤ strategioita, jotka sisƤltƤvƤt nƤmƤ yksittƤiset menetelmƤt.

Strategiaan perustuvassa lƤhestymistavassa keskitytƤƤn ensisijaisesti ohjelmiston toiminnallisuuteen (ja sisƤiseen toimintaan) tarkastelematta mahdollisia skenaarioita, jotka voivat johtaa kƤyttƤjƤn kohtaamaan esiin tulevia ongelmia. TƤmƤ voi johtaa sovelluksen ja sen eri ominaisuuksien laajempaan analyysiin, joka voi olla syvƤllisempi kuin monet muut lƤhestymistavat.

 

Manuaaliset vai automatisoidut tutkivat testit?

 

TestausryhmƤt voivat tehdƤ kartoittavia tarkastuksia joko manuaalisesti tai automatisoida ne. Kummallakin vaihtoehdolla voidaan saavuttaa valtavia etuja; oikea vaihtoehto riippuu usein hankkeen erityispiirteistƤ.

 

Manuaalinen tutkiva testaus

 

Manuaalisen testauksen avulla voidaan tehdƤ enemmƤn rƤƤtƤlƶityjƤ tarkastuksia. Vaikka tƤmƤ voi kestƤƤ kauemmin, koska ihmistestaajat ovat hitaampia kuin tietokoneet, manuaalinen tarkastelu voi olla tƤrkeƤƤ kƤyttƤjƤkokemuksen mƤƤrittƤmisessƤ.

Testaajan tehtƤvƤnƤ ei ole vain varmistaa, ettƤ kaikki sovelluksen ominaisuudet toimivat niin kuin niiden pitƤisi, vaan myƶs varmistaa, ettƤ kƤyttƤjƤt voivat kƤyttƤƤ sovellusta helposti. TƤmƤ on kenties yleisin kokeilevan testauksen muoto – vaikka se ei vƤlttƤmƤttƤ olekaan tehokkain.

 

1. Tutkivan testauksen manuaalisen suorittamisen edut

 

Manuaalisen kokeilevan testauksen etuja ovat muun muassa:

 

Vahvempi keskittyminen kƤytettƤvyyteen

 

Automaattiset tutkivat testit saattavat havaita ohjelmistossa poikkeavuuksia, mutta ne eivƤt vƤlttƤmƤttƤ pysty tulkitsemaan nƤitƤ ongelmia samalla tavalla kuin ihmistestaaja.

TƤhƤn sisƤltyy ymmƤrrys siitƤ, miten ohjelmiston kƤyttƤjƤt todennƤkƶisesti navigoivat tai ovat vuorovaikutuksessa sovelluksen kanssa, mitƤ automaatio ei voi ottaa huomioon.

Manuaaliset tutkivat testaajat voivat antaa laajempaa palautetta, mukaan lukien yksityiskohtaiset tiedot siitƤ, miten heidƤn havaitsemansa ongelmat vaikuttavat koko ohjelmistoon tai yleiseen kƤyttƶkokemukseen.

 

Voi tehdƤ reaaliaikaisia muutoksia

 

Yksi tutkivan testauksen tƤrkeimmistƤ vahvuuksista on se, ettƤ testin tarve on mahdollista tunnistaa ja toteuttaa suhteellisen nopeasti ennen tarvittavien parannusten huutokauppaamista.

Automatisoitu testaus on yleensƤ paljon nopeampi prosessi, mutta testaajien on odotettava, ettƤ kaikki on valmis ennen kuin he tekevƤt muutoksia – manuaaliset testaajat voivat tehdƤ tƤmƤn, kun kartoittava testausprosessi on vielƤ kesken.

TƤmƤ on kuitenkin usein mahdollista vain sellaisten virheiden osalta, jotka vaikuttavat ohjelmiston pieniin osiin.

 

EnemmƤn huomiota yksityiskohtiin

 

Tutkivan testauksen tarkoituksena on pƤƤasiassa lƶytƤƤ uusia tapoja testata sovellusta ja samalla ymmƤrtƤƤ sitƤ; tƤmƤ voi joskus tarkoittaa sitƤ, ettƤ yksi testi johtaa toiseen ja antaa testaajalle ideoita.

Automatisoidut testit eivƤt vƤlttƤmƤttƤ ota tƤtƤ huomioon, koska testausryhmƤ ei vƤlttƤmƤttƤ tarvitse tehdƤ mitƤƤn. Manuaaliset testaajat parantavat jatkuvasti tietƤmystƤƤn ohjelmistosta ja kehittƤvƤt uusia, mutta yhtƤ tƤrkeitƤ testejƤ – mutta tƤmƤ voi olla vaikeaa, jos kolmannen osapuolen ohjelmisto automatisoi ne.

 

Voi lƶytƤƤ virheitƤ koodin ulkopuolelta

 

Manuaalisten kartoittavien tarkastusten avulla testaajat voivat tarkastella sovelluksen ja ohjelmiston kaikkia puolia, myƶs itse koodin ulkopuolella.

Monet automatisoidut lƤhestymistavat rajoittuvat koodiin ja sen toimintaan, mikƤ voi johtaa siihen, ettƤ testiryhmƤt eivƤt huomaa ongelmia, joita saattaa esiintyƤ sovelluksen muissa osissa.

TƤmƤ riippuu pƤƤasiassa kƤytƶssƤsi olevasta automaatio-ohjelmistosta, sillƤ jotkin ratkaisut voivat tarjota laajemman lƤhestymistavan kokeilevaan testaukseen.

 

Varmistaa laadun koko hankkeessa

 

Automatisoidut kartoittavat tarkastukset etsivƤt vain sovelluksen virheitƤ ja mittareita; manuaaliset testaajat voisivat sen sijaan tarkastaa ohjelmiston ja antaa omaa kattavaa palautettaan.

He voivat esimerkiksi testata koodia ja todeta, ettƤ se on liian monimutkaista – tƤmƤ on erityisen tƤrkeƤƤ, koska kuollut koodi voi hidastaa suorituskykyƤ, mutta automaattiset prosessit eivƤt kƤytƤnnƶssƤ havaitsisi sitƤ.

Testaajan tietƤmys ohjelmistosta voi olla hyƶdyksi diagnosoitaessa ongelmia, joita ilmenee testauksen muissa vaiheissa.

 

2. Manuaalisen testauksen haasteet

 

Manuaalisen kokeilevan testauksen haasteisiin kuuluvat:

 

Inhimillisten virheiden mahdollisuus

 

Automatisoidulla tutkivalla testauksella voidaan suorittaa tƤsmƤlleen sama tarkistus niin monta kertaa kuin on tarpeen ilman, ettƤ tarkkaa etenemistƤ muutetaan, mikƤ takaa johdonmukaisuuden ja luotettavat tulokset.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Manuaalinen testaaminen on altis inhimillisille virheille, eli testaaja voi syƶttƤƤ vƤƤrƤn arvon. NƤmƤ testit on yleensƤ mahdollista tarkistaa kahdesti ja korjata mahdolliset ristiriidat, sillƤ ne saattavat olla ilmeisiƤ jo ensi silmƤyksellƤ.

Testin uusiminen virheen havaitsemisen jƤlkeen saattaa kuitenkin viedƤ enemmƤn aikaa.

 

YleensƤ aikaa vievƤmpƤƤ

 

Vaikka testaajat suorittaisivat jokaisen kartoittavan tarkastuksen oikein ilman inhimillisiƤ virheitƤ, tƤmƤ kokonaisprosessi vie huomattavan paljon aikaa verrattuna automatisoituihin ohjelmistoihin, jotka pystyvƤt laskemaan testit paljon nopeammin.

TƤmƤ voi olla vƤhintƤƤnkin useiden tuntien ero; aikaa, jonka testaajat voisivat kƤyttƤƤ sellaisiin sovelluksen osiin, joiden automatisoinnista ei olisi mitƤƤn hyƶtyƤ.

Tutkivat testit vaativat myƶs jatkuvaa valvontaa, kun taas automaatio mahdollistaa testien suorittamisen yƶn yli.

 

PitkƤ dokumentointiprosessi

 

Samoin manuaalinen dokumentointi manuaalisen testauksen aikana ja sen jƤlkeen voi rasittaa tarpeettomasti eksploratiivista testausprosessia.

TƤmƤ vaikeuttaa muutosten ja ohjelmistomuutosten seuraamista ajan mittaan – automatisoidut ohjelmistot pystyvƤt yleensƤ intuitiivisesti ottamaan tƤmƤn huomioon testejƤ suorittaessaan.

TƤmƤ on toinen hallinnollinen asia, joka vie aikaa ja energiaa muilta asioilta, mikƤ vƤhentƤƤ tehokkaasti koko ohjelmistotestausmenettelyn laajuutta ja laajuutta.

 

On tunnettava ohjelmisto lƤpikotaisin

 

MinkƤ tahansa taitotason manuaaliset testaajat voivat tarkastaa sovelluksen ja testata sen perusteellisesti. TƤmƤ johtuu siitƤ tyƶstƤ, jonka he ovat tehneet ohjelmiston ymmƤrtƤmiseksi – tutkimusprosessin ensimmƤinen vaihe.

Jos testaajalla on kuitenkin vaikeuksia tai hƤn laiminlyƶ sen opettelemisen, miten sovellus toimii, hƤnellƤ on todennƤkƶisesti vaikeuksia laatia ja toteuttaa sopivia testejƤ.

Ohjelmiston hyvƤ tuntemus antaa testaajille mahdollisuuden ylittƤƤ tavanomaiset testausparametrit.

 

Kallis yllƤpitƤƤ

 

Manuaalisen kartoittavan testauksen kƤyttƤminen edellyttƤƤ yleensƤ suurempaa testausryhmƤƤ, mikƤ voi johtaa korkeampiin pitkƤn aikavƤlin kustannuksiin verrattuna automatisoituihin tarkastuksiin. Kolmannen osapuolen ohjelmisto, joka suorittaa nƤmƤ kartoittavat testit, voi tarjota valtavasti arvoa tai olla jopa tƤysin ilmainen.

TehtƤvien monimutkaisuudesta riippuen yritys voi tarvita erittƤin ammattitaitoisia testaajia, joilla on vuosien kokemus sovelluksen tƤydellisestƤ tarkastamisesta. TƤmƤ voi lisƤtƤ testauksen kustannuksia merkittƤvƤsti verrattuna ilmaisten automaatio-ohjelmistojen kƤyttƶƶn.

 

3. Milloin kƤytetƤƤn manuaalista testausta

 

Manuaaliseen kokeilevaan testaukseen liittyy usein useita haasteita, mutta se on silti tƤrkeƤ osa perusteellista ohjelmistotestausta. TƤmƤ johtuu siitƤ, ettƤ ohjelmistossa on nƤkƶkohtia, joita automaatio ei voi tƤysin ottaa huomioon ja jotka vaativat myƶs vahvaa keskittymistƤ.

Ohjelmistot eivƤt esimerkiksi pysty antamaan luotettavaa palautetta kƤyttƶliittymistƤ tai kƤyttƤjƤkokemustesteistƤ. Testaajat voivat saada hyvƤn kƤsityksen siitƤ, miten sovellus toimii kƤytƤnnƶssƤ, vain testaamalla sitƤ manuaalisesti. TƤmƤ tarkoittaa sitƤ, ettƤ sekƤ kehittƤjien ettƤ testausryhmien on harkittava ainakin jonkinasteisen manuaalisen testauksen sisƤllyttƤmistƤ tarkastuksiinsa.

 

Automatisoitu tutkiva testaus

 

Automaattisessa testauksessa kƤytetƤƤn kolmannen osapuolen ohjelmistoja tiettyjen tarkistusten automatisoimiseksi – testaajat voivat yleensƤ mukauttaa tƤmƤn kƤytƤnnƶssƤ mihin tahansa testiin.

TƤmƤ edellyttƤƤ kuitenkin yleensƤ, ettƤ tiimi suorittaa tarkistuksen manuaalisesti vƤhintƤƤn kerran, jotta automaatio voidaan kalibroida. TƤmƤ voi virtaviivaistaa prosessia merkittƤvƤsti sekƤ testaus- ettƤ kehitystiimien kannalta.

Vaikka tutkivien testien automatisointi saattaa olla harvinaista, siitƤ on useita selkeitƤ etuja sovelluksen ja sen suorituskyvyn kannalta.

 

1. Tutkivan testauksen automatisoinnin edut

 

Tutkivan testauksen automatisoinnin tƤrkeimmƤt edut ovat seuraavat:

 

Johdonmukainen testien suorittaminen

 

Inhimillinen erehdys voi helposti johtaa testausvirheisiin, joiden korjaamiseen kuluu aikaa ja rahaa; automaattisten tutkimustarkastusten avulla testausryhmƤt voivat kiertƤƤ tƤmƤn ongelman.

Testaajat opettavat automaatio-ohjelmistolle tehokkaasti, miten testi suoritetaan oikein, ja varmistavat, ettƤ se suorittaa testin joka kerta samalla tavalla. TƤmƤ parantaa testien yleistƤ luotettavuutta ja vƤhentƤƤ kehittƤjien kƤyttƤmƤƤ aikaa tulosten odottamiseen – varsinkin kun testaajat voivat helposti asettaa testin ajettavaksi yƶn yli.

 

SƤƤstƤƤ kaikkien aikaa

 

Automatisoitujen testien avulla kehittƤjƤt voivat aloittaa ongelmien korjaamisen paljon nopeammin, ja testaajat voivat samalla tehdƤ laajemman valikoiman tutkimustarkastuksia. Tiimi voi ottaa huomioon vain tietyn mƤƤrƤn skenaarioita mƤƤrƤajasta riippumatta, joten on tƤrkeƤƤ, ettƤ testaajat sisƤllyttƤvƤt mahdollisimman monta tarkistusta sallittuun aikatauluunsa.

Automaatio auttaa suorittamalla nƤmƤ kartoittavat testit paljon nopeammin kuin manuaaliset testaajat.

 

Kustannustehokas lƤhestymistapa

 

Tiimin valitsemasta ohjelmistosta riippuen automatisointi voi olla paljon kustannustehokkaampaa kuin manuaalinen testaus – se voi olla jopa ilmaista.

Vaikka manuaalisten testaajien palkkaaminen on edelleen kriittisen tƤrkeƤƤ ja osa heistƤ vastaa automatisointimenettelyjen kalibroinnista, mahdollisimman monen tutkivan testin automatisointi antaa yritykselle mahdollisuuden alentaa henkilƶstƶkustannuksia.

Kun tiimi ymmƤrtƤƤ automaatio-ohjelmiston, se voi mukauttaa sitƤ monenlaisiin tehtƤviin.

 

Sovitettavissa useille laitteille

 

Manuaalinen testaus voi vaatia henkilƶstƶƤ, jolla on kokemusta eri laitteista, kuten tietoa eri puhelinten kƤyttƶjƤrjestelmistƤ, kuten Androidista ja iOS:stƤ, jos rakennetaan mobiilisovellusta.

Automatisoidut ohjelmistot voivat ottaa tƤmƤn huomioon ja testata useita eri laitteita varmistaakseen, ettƤ sovellus toimii jatkuvasti hyvin. TestausryhmƤt, jotka tuntevat nƤmƤ laitteet, voivat kokea prosessin tyƶlƤs; automaatio pystyy jƤlleen kerran virtaviivaistamaan tavanomaisia tutkivan testauksen prosesseja ja testaamaan kutakin iteraatiota samanaikaisesti.

 

UudelleenkƤytettƤvƤt skriptit

 

Jos tiimi testaa useita versioita samasta ohjelmistosta tai jopa useita tuotteita, joilla on samanlainen arkkitehtuuri tai samankaltaisia ominaisuuksia, skriptejƤ on mahdollista kƤyttƤƤ uudelleen testausjaksosta toiseen.

Jos yhteensopivuuden varmistamiseksi tarvitaan mukautuksia, manuaaliset testaajat voivat tehdƤ ne paljon nopeammin kuin kokonaan uuden skriptin kirjoittaminen.

Automaatio optimoi lƤhes kaikki tutkimustestausprosessin vaiheet, ja se on helppo ottaa kƤyttƶƶn kaikissa eri ohjelmistokokoonpanoissa.

 

2. Tutkivan testauksen automatisoinnin haasteet

 

TƤhƤn prosessiin liittyy myƶs erilaisia haasteita, kuten:

 

Edustaa vain yhtƤ puolta testauksesta

 

Ei ole kƤytƤnnƶllistƤ tai jƤrkevƤƤ automatisoida kaikkia tarkistuksia sovelluksen testauksen aikana, koska on joitakin seikkoja, joista vain manuaalinen testaaja voi antaa luotettavaa palautetta.

TƤmƤ koskee myƶs kƤyttƤjƤkokemusta, vaikka perusteellinen suorituskyky- ja kuormitustestausanalyysi saattaa olla mahdollista saada automaation avulla, riippuen valitsemastasi ohjelmistosta.

Tutkivan testauksen automatisoinnista puuttuu inhimillinen harkintakyky, ja se voi toimia parhaiten manuaalisen testaajan rinnalla joissakin tarkastuksissa.

 

EpƤrealistiset odotukset valmiuksista

 

Vastaavalla tavalla automatisoidut kokeilevat testausmenettelyt voivat tarjota valtavia etuja sovellukselle ja koko projektille.

TƤmƤ lƤhestymistapa ei kuitenkaan aina ole ratkaisu. Organisaatioilla, jotka luottavat vahvasti automatisointiin jokaisessa vaiheessa, voi olla epƤtƤydellinen nƤkemys ohjelmistosta.

Automaatio tunnistaa ongelmat, mutta testaus- ja kehitystiimit ovat vastuussa niiden korjaamisesta. On tƤrkeƤƤ mƤƤritellƤ kattava automaatiostrategia, jotta kaikki projektissa tyƶskentelevƤt ymmƤrtƤvƤt sen mahdollisuudet ja rajoitukset.

 

Korkeammat ammattitaitovaatimukset

 

Automaatio edellyttƤƤ yleensƤ monimutkaisten tarkastusten suorittamisen osaamista sekƤ niiden ohjelmointia ja varsinaista automatisointia. TƤmƤ edellyttƤƤ usein vuosien kokemusta skriptien laatimisesta, vaikka automaatio-ohjelmistot voivat auttaa optimoimaan nƤitƤ prosesseja merkittƤvƤsti.

On ratkaisevan tƤrkeƤƤ, ettƤ yritys rekrytoi testaajia, joilla on monipuoliset ja vankat taidot tehokkaan automatisoinnin helpottamiseksi.

Automaatiossa kokeneet testaajat tietƤvƤt myƶs, mitkƤ toiminnot on asetettava etusijalle valittaessa kolmannen osapuolen ohjelmistovaihtoehdoista, jotta tiimi saa hyvƤn tuotteen.

 

EpƤasianmukaiset strategiat ja viestintƤ

 

Johdonmukaisen strategian kommunikointi on ensiarvoisen tƤrkeƤƤ onnistuneelle automatisoinnille; kehittƤjien, testaajien ja jopa projektipƤƤllikƶiden on oltava samalla sivulla koko testauksen ajan.

Ryhmien on yhdessƤ mƤƤriteltƤvƤ tulevien toimenpiteiden laajuus ja aikataulu. TƤmƤ pƤtee kaikkiin testausprosesseihin, mutta se on erityisen tƤrkeƤƤ automaation tuomien lisƤmonimutkaisuuksien vuoksi. Paremmat viestintƤyhteydet ja tiedonsiilojen puuttuminen antavat tiimeillesi mahdollisuuden suorittaa testit tehokkaammin.

 

Oikean automaatio-ohjelmiston valinta

 

Automaatio edellyttƤƤ yleensƤ sellaisen kolmannen osapuolen sovelluksen valitsemista, joka on yhteensopiva tiimin testaustavoitteiden kanssa. Jokaisella vaihtoehdolla on erilaiset hinnoittelusuunnitelmat ja toiminnot. TƤmƤ voi olla merkittƤvƤ pitkƤn aikavƤlin kustannus, vaikka ohjelmisto suorittaisi onnistuneesti automaattiset testit ja tuottaisi samalla huomattavan mƤƤrƤn lisƤarvoa.

On olemassa useita ilmaisia vaihtoehtoja, jotka tarjoavat vaikuttavia toimintoja, jotka ovat verrattavissa premium-vaihtoehtoihin. On tƤrkeƤƤ, ettƤ testausryhmƤ tutkii kaikki kƤytettƤvissƤ olevat vaihtoehdot, myƶs ilmaiset ohjelmistot.

 

JohtopƤƤtƶkset: Tutkivan testauksen automatisointi vs. manuaalinen tutkiva testaus

 

Vain harvat projektit hyƶtyvƤt tƤysin manuaalisesta testauksesta tai tƤysin automatisoidusta testauksesta, sillƤ kaikenlaiset sovellukset toimivat paremmin molempien yhdistelmƤllƤ.

Vaikka automatisoidut testit voivat optimoida prosessin kehitys- ja laadunvarmistusryhmien kannalta, jotkin suunnittelun osa-alueet edellyttƤvƤt manuaalista koetestausta; tƤmƤ on ainoa tapa saada kƤyttƤjƤlƤhtƶistƤ palautetta.

Ajan myƶtƤ yhƤ useammat organisaatiot pyrkivƤt ottamaan kƤyttƶƶn hyperautomaation, prosessin, jossa automaatio pyritƤƤn maksimoimaan ƤlykkƤƤsti ja varmistamaan, ettƤ liiketoiminnalla on tehokas strategia – tƤmƤ voi olla edelleen olemassa manuaalisen testauksen rinnalla.

Automatisoidusta testauksesta on tulossa helpommin lƤhestyttƤvƤƤ yrityksille, koska automaatio-ohjelmistot ovat yleistyneet, erityisesti koska tarjolla on useita ilmaisia vaihtoehtoja, joissa on runsaasti ominaisuuksia. NƤin yritysten on helpompi ottaa kƤyttƶƶn yhdistetty manuaalinen ja automatisoitu kartoittava testaus.

KetterƤn (projektinhallintatekniikka, jossa keskitytƤƤn asteittaiseen mutta merkittƤvƤƤn edistymiseen) kehittƤmisen kasvava suosio on myƶs ollut yksi tekijƤ, sillƤ se edellyttƤƤ lyhyitƤ testausjaksoja. Yhdistetty testausstrategia voisi ottaa huomioon tƤmƤn ja useita muita kehitysstrategioita, kuten jatkuvan integroinnin, joka edellyttƤƤ toistuvaa testausta, jotta voidaan varmistaa onnistuminen useissa saman ohjelmiston iteraatioissa.

 

MitƤ tarvitset kokeilevan testauksen aloittamiseen

 

Tutkivan testauksen edellytyksiƤ ovat:

 

1. SelkeƤt testauksen tavoitteet

 

Vaikka kokeileva testaus on synonyymi vapaudelle ja sekoitetaan joskus ad hoc -testaukseen, se noudattaa kuitenkin tiettyjƤ sƤƤntƶjƤ tai mƤƤriteltƤviƤ tavoitteita. Ainoa tapa, jolla laadunvarmistusryhmƤ voi onnistua lƤhes missƤ tahansa testausrakenteessa, on tietƤƤ kunkin testin odotettu lopputulos, varsinkin kun testaajat yleensƤ suunnittelevat nƤmƤ tarkistukset itse.

 

2. Luovat, intuitiiviset testaajat

 

Tutkiva testaus keskittyy uusien ja luovien testien suunnitteluun, jotka saattavat paljastaa sovelluksen ongelmia. Jopa testaajat, joilla on vain vƤhƤn kokemusta, voivat tehdƤ tƤmƤn, jos he ymmƤrtƤvƤt ohjelmistoa.

On tƤrkeƤƤ, ettƤ testaajat ymmƤrtƤvƤt sovelluksen ja sen toiminnan, jotta he voivat intuitiivisesti kehittƤƤ erilaisia hyƶdyllisiƤ tarkistuksia.

 

3. Johdonmukainen dokumentointi

 

Jokaisella testaustyypillƤ on oltava vahva dokumentaatio, jolla varmistetaan, ettƤ jokainen tiimin jƤsen noudattaa odotettua testausaikataulua ja ettƤ kukaan ei vahingossa toista tarkistusta.

TƤmƤ on elintƤrkeƤ nƤkƶkohta viestinnƤssƤ yksittƤisen osaston sisƤllƤ ja useiden osastojen vƤlillƤ, esimerkiksi kehittƤjƤt, jotka tarvitsevat sƤƤnnƶllisiƤ testauspƤivityksiƤ selvittƤƤkseen, miten ongelmat korjataan.

 

4. Asiakkaan nƤkƶkulma

 

Tutkiva testaus kattaa monia strategioita ja skenaarioita, mukaan lukien ne, jotka heijastavat sitƤ, miten kƤyttƤjƤt kƤytƤnnƶssƤ kƤyttƤvƤt sovellusta. On tƤrkeƤƤ, ettƤ testausryhmƤt ottavat tƤmƤn huomioon tarkastuksissaan, vaikka ne eivƤt suorittaisikaan skenaariopohjaisia testejƤ.

TƤmƤn omaksuminen antaa testaajalle mahdollisuuden lƤhestyƤ testausta eri nƤkƶkulmista, mikƤ parantaa tarkastusten laatua.

 

5. Automaattiset testausohjelmistot

 

Koska tiimi voi todennƤkƶisesti automatisoida huomattavan osan suunnittelemistaan testeistƤ, on tƤrkeƤƤ, ettƤ se pystyy hankkimaan laadukkaan automatisoidun testausohjelmiston ennen toteutusvaihetta.

KehittƤjƤt ja testausryhmƤ voivat kƤyttƤƤ hanketta koskevaa ymmƤrrystƤƤn mƤƤrittƤƤkseen kolmannen osapuolen sovelluksen, joka sopisi heidƤn omiin vaatimuksiinsa.

 

Tutkivan testauksen prosessi

 

Tutkivan testauksen vaiheet ovat seuraavat:

 

1. Luokittele testausmenettely

 

Tutkivan testauksen ensimmƤinen vaihe on, ettƤ asianomaiset tiimin jƤsenet ymmƤrtƤvƤt, miten he voisivat lƤhestyƤ nƤitƤ tarkastuksia, esimerkiksi luokittelemalla yleiset viat ja tekemƤllƤ perussyyanalyysin.

TƤssƤ vaiheessa testaajat kehittƤvƤt itse ideansa testejƤ varten; tarkasta metodologiasta riippuen he voivat myƶs suunnitella testisuunnitelman.

SiinƤ mƤƤritellƤƤn kyseisen istunnon tai tyƶpƤivƤn laajuus ja testit.

 

2. Aloita testit

Vaikka tarkat parametrit (kuten kunkin testin tai koko istunnon kesto) riippuvat tiimin omista mieltymyksistƤ ja projektin vaatimuksista, kaikilla tutkimusmenetelmillƤ on tiettyjƤ yhteisiƤ piirteitƤ.

Kun asiaankuuluvat tarkastukset on luokiteltu, laadunvarmistushenkilƶstƶ aloittaa testien suorittamisen ja tulosten kirjaamisen.

Jos tarkastukset edellyttƤvƤt automatisointia, testaajat voivat asettaa sen toimimaan yƶn yli tai valvoa sitƤ itse pƤivƤn aikana.

 

3. Tarkastele tuloksia

 

Seuraavassa vaiheessa tarkastellaan tuloksia ja verrataan niitƤ oletus- ja odotettuihin tuloksiin. Jos nƤissƤ testeissƤ ilmenee merkittƤviƤ odottamattomia poikkeamia, testaajat voivat toistaa tarkastuksen tai ryhtyƤ vƤlittƶmƤsti selvittƤmƤƤn, miten asia voidaan korjata. HeidƤn kehittƤjille tekemƤnsƤ ehdotukset voivat olla ratkaisevia oikean lƤhestymistavan mƤƤrittƤmisessƤ – ja heidƤn vikailmoituksissaan tƤmƤ voidaan esittƤƤ yksityiskohtaisesti.

 

4. Testin jƤlkipuinti

 

Testitulosten huutokauppaamisen jƤlkeen laadunvarmistusryhmƤ alkaa tarkastella itse testausmenettelyƤ ja mƤƤrittƤƤ sen avulla, oliko heidƤn tutkivan testauksen lƤhestymistapansa sopiva.

Testiyhteenvetoraportissa saatetaan jopa todeta, ettƤ tarkastuksissa on tapahtunut toimintavirheitƤ, jotka edellyttƤvƤt uusintatestiƤ. TestausryhmƤ voi myƶs tarkistaa sovelluksen uudelleen sen jƤlkeen, kun kehittƤjƤt ovat korjanneet nƤmƤ ongelmat, ja selvittƤƤ, ovatko he onnistuneet.

 

Tutkivan testauksen parhaat kƤytƤnnƶt

 

Tutkivan testauksen tehokkaimpia kƤytƤntƶjƤ ovat:

 

1. Testaajien yhdistƤminen

Monissa kokeilevan testauksen muodoissa testaajat tyƶskentelevƤt yhdessƤ, mikƤ sujuvoittaa prosessia entisestƤƤn ja antaa mahdollisuuden tarkastella samoja tarkastuksia useista eri nƤkƶkulmista.

Paritestauksella vƤltetƤƤn myƶs tunnelinƤkƶkulman mahdollisuus ja kannustetaan luovempaan testisuunnitteluun.

Jos useampi henkilƶ tyƶskentelee samojen testien parissa, voidaan saavuttaa suurempi tarkkuus, ja tyƶmƤƤrƤn jakaminen auttaa myƶs nopeuttamaan testausta koko tiimin kannalta.

 

2. Manuaalisten ja automaattisten testien yhdistƤminen

 

Jotkin yritykset kamppailevat edelleen automaation kƤyttƶƶnoton kanssa, kun taas toiset kƤyttƤvƤt sitƤ liikaa, vaikka manuaaliset nƤkƶkulmat saattaisivat olla hyƶdyllisempiƤ. Kun nƤmƤ tarkastukset tasapainotetaan keskenƤƤn, testaustiimi voi kattaa useamman perustan ja varmistaa laadun koko sovelluksessa, myƶs subjektiivisempien nƤkƶkohtien, kuten ohjelmiston kƤyttƶliittymƤn, osalta.

Manuaalisten ja automatisoitujen testien suorittaminen yhdessƤ on ainoa tapa taata jokaisen ominaisuuden tai toiminnon tƤydellinen testauskattavuus.

 

3. Markkinoiden ymmƤrtƤminen

 

On tƤrkeƤƤ, ettƤ testaajat tuntevat testausprosessin aikana sekƤ kohderyhmƤnsƤ ettƤ kilpailijansa; tƤmƤ auttaa heitƤ arvioimaan, miten ihmiset todennƤkƶisesti reagoivat sovelluksen nykyisiin toimintoihin.

Tiettyjen ominaisuuksien kysyntƤ on suurta, ja testausryhmƤ voi hyƶtyƤ nƤiden ominaisuuksien priorisoinnista tarkastusten aikana. Vaikka niiden on myƶs yllƤpidettƤvƤ laajaa testikattavuutta. TƤmƤ voi mƤƤrittƤƤ testauksen suunnan sekƤ ohjelmiston mahdollisen menestyksen lanseerauksen yhteydessƤ.

 

4. KƤytƤ oikeita laitteita testaukseen

 

OhjelmistotestausryhmƤt saattavat kƤyttƤƤ emulaattoreita helpottaakseen tutkimustarkastuksiaan; tƤmƤ voi olla hyƶdyllistƤ, mutta harvoin se vastaa kƤytƤnnƶn kƤyttƶympƤristƶƤ.

Oikeat laitteet parantavat kartoittavan testauksen luotettavuutta luomalla realistisemman kokemuksen – emulaattorit ovat epƤtƤydellisiƤ, ja niissƤ saattaa olla virheitƤ, joita asiakkaat eivƤt huomaa.

Emulointi on nopea tapa testata useita alustoja, mutta se ei korvaa varsinaisia laitteita.

 

Tutkivan testin tuotostyypit

 

Testaajat voivat saada erilaisia tuloksia tarkastuksen suorittamisen jƤlkeen, kuten:

 

1. Testitulokset

 

Tulokset voivat olla moninaisia, sillƤ kokeileva testaus voi sisƤltƤƤ satoja ainutlaatuisia testejƤ. NƤmƤ tulokset muodostavat suurimman osan testausrutiinin tuloksista, ja ne tarjoavat tƤrkeƤƤ tietoa sovelluksen tilasta ja sen kyvystƤ tƤyttƤƤ kƤyttƤjƤn tarpeet.

Testaajat voivat tarkistaa jƤrjestelmƤn uudelleen ja validoida tiedot saatuaan nƤmƤ tulokset ja mƤƤrittƤƤ seuraavat toimet.

 

2. Testilokit

 

Sovelluksen omat lokit paljastavat usein testausprosessin aikana ilmenneet virheet ja ongelmat, jotka antavat vahvimmat vihjeet siitƤ, miksi ohjelmisto epƤonnistui testissƤ. Vanhemmat testaajat ovat erityisen taitavia tulkitsemaan sovelluksen lokitietoja, jolloin he voivat tunnistaa monimutkaisten ongelmien syyn.

MitƤ enemmƤn tietoa testaajat saavat nƤistƤ lokitiedoista, sitƤ enemmƤn he pystyvƤt auttamaan kehittƤjiƤ.

 

3. Testiraportit

 

Tiimin automatisointimenettelystƤ riippuen niiden tuotokset saattavat tuottaa automaattisesti vikailmoituksen. TƤssƤ esitetƤƤn kaikki sovelluksessa esiintyvƤt virheet, mahdollisesti myƶs niiden syyt ja muut kehittƤjien kannalta merkitykselliset tiedot.

Testaajat voivat kƤyttƤƤ tƤtƤ tarjotakseen oman mielipiteensƤ siitƤ, onko ohjelmisto valmis lanseerattavaksi, mikƤ tunnetaan yleisesti go/no-go-pƤƤtƶksenƤ.

 

EsimerkkejƤ tutkivasta testauksesta

 

Seuraavassa on kolme esimerkkiƤ siitƤ, miten yritys voisi kƤyttƤƤ kokeilevaa testausta:

 

1. Mobiilipelisovellus

 

Jos peliyritys haluaa julkaista merkittƤvƤn pƤivityksen mobiilisovellukseensa, kokeilevat testaajat voivat tarkistaa sekƤ vanhoja ettƤ uusia ominaisuuksia selvittƤƤkseen, onko sovellus edelleen vakaa. TƤmƤ saattaa lisƤtƤ ohjelmiston monimutkaisuutta niin paljon, ettƤ se ei toimi tietyillƤ laitteilla.

Testaajat pyrkivƤt minimoimaan tƤmƤn vaikutukset ja varmistamaan samalla kƤytettƤvyyden mahdollisimman monella alustalla.

Tutkivat testaajat tarkistavat pelin ja sen monet monimutkaiset skenaariot perusteellisesti varmistaakseen, ettƤ kaikki toiminnot toimivat tarkoitetulla tavalla; tƤmƤ prosessi vaatii yleensƤ manuaalista testaajaa.

 

2. Palveluntarjoajan verkkosivusto

 

Verkkosivustoja testataan myƶs alustavasti, jotta varmistetaan, ettƤ ne toimivat sekƤ kƤyttƤjien ettƤ henkilƶkunnan kannalta, joten testaajat voivat aloittaa kirjautumalla verkkosivustolle. TƤllƤ testataan sivuston kyky luoda uusia kƤyttƤjƤprofiileja ja tarkistetaan, ettƤ kƤyttƤjƤt eivƤt pƤƤse kƤyttƤmƤƤn hallintatoimintoja.

TƤmƤn jƤlkeen testaajat siirtyvƤt tarkistamaan palvelua, mikƤ voi tapahtua ajanvarauksen tai tilauksen tekemisen muodossa. Sen jƤlkeen he suorittavat ostoksen varmistaakseen, ettƤ kassatoiminto toimii asianmukaisesti, ja tarkastelevat sitten tilauksen sƤhkƶpostivahvistusta ja tilihistoriaa.

 

3. Sairaalan johtamisjƤrjestelmƤ

 

Kaikenlaiset sovellukset ja jƤrjestelmƤt voivat hyƶtyƤ kokeilevasta testauksesta. SairaalahallintajƤrjestelmien osalta testaaja voi tarkastella, miten maksumoduuli on vuorovaikutuksessa muiden ominaisuuksien kanssa.

Korkeammat integraatiotasot saattavat johtaa merkittƤviin virheisiin ilman tarkkaa testausta. NƤihin tarkastuksiin voi sisƤltyƤ arkkitehtuurikaavio, jossa seurataan jƤrjestelmƤn monia komponentteja ja niiden keskinƤisiƤ yhteyksiƤ.

Testaajat tarkastelevat myƶs jƤrjestelmƤn aiempien iteraatioiden ongelmia ja testaavat erityisesti, ovatko ne edelleen olemassa, ja ryhtyvƤt nopeisiin toimiin, jos he havaitsevat virheitƤ.

 

Tutkivan testauksen avulla havaittujen virheiden ja vikojen tyypit

 

Tutkivan testauksen aikana testaajat voivat havaita muun muassa seuraavia virheitƤ:

 

1. Yhteensopimattomat ominaisuudet

Tietyt sovelluksen toiminnot eivƤt vƤlttƤmƤttƤ toimi odotetulla tavalla keskenƤƤn, mikƤ voi johtaa siihen, ettƤ kƤyttƤjƤt eivƤt voi suorittaa ostoksia tai kƤyttƤƤ sovellusta. Testaajat tarkistavat toiminnot erikseen ja yhdessƤ toistensa kanssa varmistaakseen, ettƤ kaikki sopii yhteen.

 

2. Virheellinen kƤyttƶliittymƤsuunnittelu

Sovelluksen kƤyttƶliittymƤ mƤƤrittƤƤ, miten joku kƤyttƤƤ ohjelmistoa. Jos asiakkaat eivƤt esimerkiksi huomaa tƤrkeitƤ ominaisuuksia, he eivƤt vƤlttƤmƤttƤ huomaa niiden olemassaoloa, mikƤ rajoittaa heidƤn nautintoaan sovelluksesta.

Manuaalisella kƤyttƶliittymƤtestauksella tunnistetaan ja korjataan kƤyttƤjƤystƤvƤllinen suunnittelu.

 

3. Tunnistusvirheet

Monet sovellukset ja verkkosivustot mahdollistavat kƤyttƤjƤprofiilin luomisen tietyin etuoikeuksin. On tƤrkeƤƤ, ettƤ testaajat tarkistavat, pƤƤsevƤtkƶ tavalliset kƤyttƤjƤt jotenkin kƤsiksi arkaluonteisiin tietoihin tai jopa hallinnollisiin ominaisuuksiin kƤyttƤessƤƤn ohjelmistoa odottamattomalla tavalla.

 

4. Kuollut koodi

Testaajat saattavat lƶytƤƤ sovelluksesta edelleen vanhentunutta koodia, joka saattaa jopa olla syynƤ huomattaviin suorituskykyongelmiin. Kuollut koodi monimutkaistaa liikaa sovelluksen sisƤistƤ toimintaa ja voi johtaa vƤltettƤvissƤ oleviin virheisiin. TƤmƤn tunnistaminen ja optimoiminen tekee ohjelmistosta nopeamman henkilƶstƶn ja kƤyttƤjien kannalta.

 

Yleiset tutkivan testauksen mittarit

 

Tavanomaisia mittareita, joita testaajat saattavat kohdata tutkivien testien aikana, ovat muun muassa seuraavat:

 

1. Suorituskykytestin mittarit

Sovelluksen yleistƤ suorituskykyƤ tarkastelevat testit voivat tuottaa monenlaisia mittareita. TƤmƤ voi sisƤltƤƤ minimi-, keski- ja maksimivasteajat sekƤ epƤonnistumis- ja onnistumisprosentit vakauden mƤƤrittƤmiseksi.

 

2. Testauksen kattavuusmittarit

Testien kattavuus on tƤrkeƤƤ, koska se mƤƤrittƤƤ, kuinka monta sovelluksen luokkaa ja puolta testit kattavat. Vaatimusten kattavuusprosentti esimerkiksi arvioi, onko olemassa toimintoja, jotka vaativat lisƤƤ testauskierroksia.

 

3. Testin yleinen tehokkuus

Onnistuneiden ja epƤonnistuneiden tarkistusten mƤƤrƤn seuraaminen auttaa testaajia selvittƤmƤƤn sovelluksen yleisen kunnon. TƤmƤn lisƤksi tiimi voi seurata, kuinka moni havaituista virheistƤ on kriittinen.

 

4. Vikojen jakautuminen

Vastaavasti virheiden jakautumisen tarkistaminen osoittaa, mitkƤ osat tai toiminnot ovat alttiimpia virheille. NƤmƤ saattavat olla sovelluksen osia, jotka ovat usein vuorovaikutuksessa muiden osien kanssa, joten on tƤrkeƤƤ priorisoida nƤmƤ testit.

 

5. Regressiomittarit

Tutkivan regressiotestauksen avulla testaajat nƤkevƤt, miten saman ohjelmiston eri iteraatiot kƤyttƤytyvƤt ja miten tƤmƤ voi vaikuttaa suorituskykyyn.

Virheiden mƤƤrƤ ja rakennuskohtaiset virheet ovat erityisiƤ mittareita, jotka auttavat tƤssƤ.

 

SelvitƤn hieman sekaannusta: Ad Hoc -testit: Tutkiva testaus vs. Ad Hoc -testit

 

Koska testaajan vapaus on vahvasti esillƤ, jotkut sekoittavat usein tutkivan testauksen ad hoc -testaukseen. NƤillƤ kahdella formaatilla on useita keskeisiƤ yhtƤlƤisyyksiƤ, mutta ne palvelevat lopulta eri tarkoituksia.

 

1. MitƤ on ad hoc -testaus?

 

Ad hoc -testaus on tƤysin strukturoimaton lƤhestymistapa, joka rikkoo perinteistƤ testaussuunnittelua lƶytƤƤkseen vikoja, joita ei ehkƤ muuten havaittaisi.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

TƤhƤn testaustapaan ei tyypillisesti liity dokumentointia, mikƤ vaikeuttaa ongelmien toistamista, ellei testaaja ole tƤysin varma ongelman syystƤ.

Yksi esimerkki tƤstƤ on ”apinatestaus”, jossa kƤytetƤƤn satunnaisia syƶtteitƤ ja jonka tarkoituksena on lopulta rikkoa jƤrjestelmƤ.

Tutkivan testauksen tapaan monet ad hoc -testaajat tyƶskentelevƤt pareittain suorittaakseen nƤmƤ tarkistukset, mikƤ parantaa niiden luotettavuutta. Ad hoc -lƤhestymistapa voi olla hyƶdyllinen virallisen testauksen suorittamisen jƤlkeen, jotta voidaan varmistaa, ettƤ tarkastuksissa otetaan huomioon kaikki mahdollisuudet; tƤmƤ auttaa myƶs silloin, kun lisƤtestien suorittamiseen on vain vƤhƤn aikaa. Oikeanlaisella toteutuksella ad hoc -testeistƤ on paljon hyƶtyƤ.

 

2. Tutkivan testauksen ja ad hoc -testien erot

 

Ad hoc -testaukseen ei yleensƤ liity muodollista dokumentointia. TƤmƤ on jyrkƤssƤ ristiriidassa kokeellisten testien kanssa, joissa tarkastusten improvisoitu luonne tekee kirjanpidosta entistƤkin tƤrkeƤmpƤƤ.

Tutkivissa testeissƤ kƤytetƤƤn enemmƤn erilaisia virallisia testaustekniikoita, kun taas ad hoc -tarkastuksissa tƤtƤ vƤltetƤƤn katsomalla tavanomaisen testausetiikan ulkopuolelle. TƤmƤ auttaa heitƤ lƶytƤmƤƤn virheitƤ, joita testaajat eivƤt muuten lƶytƤisi.

Tutkivalla testauksella on selkeƤt tavoitteet ja rajat, mutta se antaa tiimin jƤsenille silti mahdollisuuden kƤyttƤƤ luovia testejƤ. Ad-hoc-testeillƤ ei yleensƤ ole mƤƤriteltƤvissƤ muita pƤƤmƤƤriƤ kuin ohjelmiston tyƶntƤminen miten vain mahdollista. Ad hoc -testaus edellyttƤƤ usein myƶs ohjelmiston ja sen toimintojen tuntemusta, kun taas tutkivassa testauksessa sovelluksen oppiminen sisƤllytetƤƤn tavanomaisiin prosesseihin.

 

Tutkiva testaus ketterƤssƤ testauksessa

 

KetterƤt menetelmƤt edistƤvƤt voimakkaasti jatkuvaa parantamista. TƤmƤ tarkoittaa, ettƤ se sopii hyvin yhteen kokeilevien testien kanssa, etenkin kun ohjelmistopƤivitysten kysyntƤ kasvaa.

YhdistƤmƤllƤ tutkivan testauksen ja ketterƤn testauksen voi antaa tiimin jƤsenille vahvemman testausrakenteen, kun julkaisusuunnittelu ja sprintin toteutus sisƤllytetƤƤn heidƤn aikatauluihinsa. KetteriƤ tekniikoita hyƶdyntƤvƤ yritys voi hyƶdyntƤƤ tƤtƤ vielƤ enemmƤn yhdistƤmƤllƤ sen kokeilevaan testaukseen; tƤmƤ on erinomainen tapa testata sovelluksen kutakin yksittƤistƤ ohjelmistokomponenttia. Koska testaajat voivat tehdƤ kartoittavia tarkastuksia ilman skriptejƤ, tƤmƤ sƤƤstƤƤ sekƤ laadunvarmistushenkilƶstƶn ettƤ kehittƤjien arvokasta aikaa.

Automatisoitu testaaminen lisƤƤ nƤitƤ sƤƤstƶjƤ, sillƤ se auttaa yrityksiƤ tarkistamaan sovellustensa viimeisimmƤt iteraatiot paljon nopeammin, mahdollisesti jopa yhdessƤ yƶssƤ. Tutkivat tarkistukset tuottavat nopeasti kƤyttƶkelpoisia tuloksia, ja kehittƤjƤt voivat tehdƤ tarvittavat muutokset osana seuraavaa sprinttiƤ.

Manuaalisesta kokeilevasta testauksesta on edelleen monia etuja ketterƤn testauksen yhteydessƤ, koska sen avulla voidaan tunnistaa ongelmia, jotka automatisoitu lƤhestymistapa voisi jƤttƤƤ huomiotta. Muut testauksen muodot vievƤt yksinkertaisesti liian kauan tai tuottavat liian vƤhƤn hyƶtyƤ, jotta ne sopisivat mukavasti ketterƤƤn kehykseen. Tutkivan tarkastuksen avulla voidaan varmistaa, ettƤ jokainen ketterƤ vaihe parantaa ohjelmistoa ja sen toimivuutta merkittƤvƤsti.

 

7 virhettƤ ja sudenkuoppaa, joita kannattaa vƤlttƤƤ tutkivien testien kƤyttƶƶnotossa

 

Seuraavassa on seitsemƤn yleistƤ virhettƤ, joita yritykset usein tekevƤt ottaessaan kƤyttƶƶn tutkivia testejƤ, ja kerrotaan, miten yritykset voivat vƤlttƤƤ nƤmƤ ongelmat:

 

1. EpƤtasapainoinen manuaalinen/automaattinen testaus.

 

Sen selvittƤminen, mitkƤ testit toimivat parhaiten manuaalisilla tarkistuksilla ja mitkƤ testit hyƶtyisivƤt automatisoinnista, vie aikaa, mutta antaa tiimeille mahdollisuuden testata paljon tehokkaammin.

Liian monien testien automatisointi voi johtaa sovellukseen, joka on hankala tai kƤyttƤjƤystƤvƤllinen, koska testaajasta ei ole apua.

 

2. Aikarajoitteet

Tutkiva testaus on nopeampaa kuin monet muut testauksen muodot, mutta projektin aikataulujen vuoksi tiimi voi silti suorittaa vain rajallisen mƤƤrƤn testejƤ.

Ajanhallinta ja sitoutuminen testien kattavuuteen auttavat testausryhmƤƤ suorittamaan mahdollisimman monta tarkastusta useista eri luokista.

 

3. Joustamattomat testaajat

Vaikka tutkivat testaajat eivƤt vaadi ennakkotietoa ohjelmistosta tai erityisen syvƤllisiƤ taitoja, tarkastukset perustuvat silti yksittƤisten tiimin jƤsenten kykyihin ja aloitteellisuuteen.

ProjektipƤƤllikƶn on jaettava nƤmƤ testaustehtƤvƤt viisaasti ja varattava ne tarvittaessa tiimin luovemmille ja intuitiivisemmille jƤsenille.

 

4. Vaikeus toistaa epƤonnistumisia

Aina ei ole selvƤƤ, mitkƤ toimet vaikuttavat testin epƤonnistumiseen; voi myƶs olla epƤselvƤƤ, mitkƤ sovelluksen osatekijƤt ovat syyllisiƤ.

TƤmƤn vuoksi monissa tutkimuksellisissa lƤhestymistavoissa testaajat yhdistetƤƤn pareittain tai jopa nauhoitetaan suoraan testaajan ruutu, jotta ongelmista ja niiden tarkoista syistƤ saataisiin selkeƤmpi kƤsitys.

 

5. EpƤselvƤ dokumentaatio

Olipa kyseessƤ sitten automaattinen vikailmoitus tai manuaalinen kirjaus suoritetuista testeistƤ, hyvƤ dokumentaatio helpottaa kehittƤjien toimintaa testausryhmƤn havaintojen perusteella.

TestausryhmƤn on sitouduttava varmistamaan laadukas kirjanpito jokaisessa tarkastuksessa ja annettava mahdollisimman paljon yksityiskohtia jokaiseen raporttiin.

 

6. Korkeat odotukset

Tutkiva testaus on hyƶdyllistƤ lƤhes kaikissa ohjelmistoprojekteissa, mutta sen soveltamisala on silti rajallinen – se toimii parhaiten yhdessƤ muiden testausmenetelmien kanssa.

Testausryhmien on suoritettava nƤmƤ tarkistukset tavanomaisten kƤsikirjoitettujen testien ohella; tƤmƤ on ainoa tapa, jolla laadunvarmistusosastot voivat varmistaa jatkuvasti laajan testikattavuuden.

 

7. EpƤasianmukainen automaatio

On tƤrkeƤƤ, ettƤ testausryhmƤ ja projektipƤƤllikkƶ ymmƤrtƤvƤt, mikƤ automaatio-ohjelmisto tarjoaa eniten hyƶtyƤ kyseiselle sovellukselle.

Eri kolmannen osapuolen vaihtoehdoilla on omat ainutlaatuiset ominaisuutensa, joten tiimin valinta voi mƤƤrittƤƤ robottiprosessien automatisoinnin onnistumisen; tiimin on harkittava kaikkia vaihtoehtoja.

 

5 parasta ilmaista testaustyƶkalua

 

LaadunvarmistusryhmƤt voivat kƤyttƤƤ ilmaiseksi viittƤ parasta kokeilevan testauksen tyƶkalua:

 

1. ZAPTEST FREE Edition

ZAPTEST Free tarjoaa premium-tason toiminnot tƤysin ilmaiseksi, joten mikƤ tahansa organisaatio voi hyƶtyƤ helposta kokeellisen testauksen toteuttamisesta.

TƤmƤ sovellus voi automatisoida minkƤ tahansa alustan, laitteen ja selaimen innovatiivisen 1SCRIPT-tekniikan avulla.

ZAPTEST tarjoaa myƶs joustavan RPA-automaation, jonka avulla voit yhdistƤƤ sen manuaaliseen lƤhestymistapaan.

 

2. XRAY Exploratory App

XEA:n avulla kƤyttƤjƤt voivat luoda kattavia testauskaavioita ja helposti kirjata edistymisensƤ, mikƤ tehostaa kokeellisen testauksen vikailmoitusvaihetta.

TƤmƤ vaihtoehto keskittyy tƤysin kƤyttƤjƤn nƤkƶkulmaan ja tarjoaa keskitetyn tuloskeskuksen, josta muut testaajat voivat pƤivittƤƤ tuloksia.

XRAY:ssƤ ei kuitenkaan ole tƤllƤ hetkellƤ integroitua automaatiota, mikƤ saattaa rajoittaa sen tehokkuutta pitkƤllƤ aikavƤlillƤ.

 

3. Bug Magnet

Bug Magnet on selainlaajennus, joka tarjoaa perusteellista eksploratiivista testausta, ja sen avulla testaajat voivat tarkistaa reunatapaukset ja muut ongelmalliset arvot.

TƤmƤ laajennus tarjoaa myƶs yksinkertaisen dummy-tekstin, sƤhkƶpostiosoitteiden ja useiden merkistƶjen integroinnin.

TƤmƤ on kuitenkin saatavilla vain Firefox- ja Chrome-pohjaisille selaimille, joten se ei ole yhtƤ monipuolinen valinta kuin kilpailijansa.

 

4. Azure-testisuunnitelmat

Azure Test Plans on keskeinen osa Microsoftin Azure-alustaa, ja sen avulla testaajat voivat kerƤtƤ monipuolisia tietoja monista skenaarioista.

TƤmƤ vaihtoehto soveltuu sekƤ tyƶpƶytƤ- ettƤ verkkopohjaisiin sovelluksiin, ja se tarjoaa myƶs pƤƤstƤ pƤƤhƤn ulottuvan jƤljitettƤvyyden, jonka avulla ohjelmiston kehityksestƤ on selkeƤt tiedot.

TƤmƤ lƤhestymistapa edellyttƤƤ kuitenkin usein syvempƤƤ integrointia Azureen, joten joustavuus kƤrsii.

 

5. Testiny

Testiny on erikoistunut manuaaliseen kokeilevaan testaukseen ja tarjoaa ƤlykkƤƤn editorin, jonka avulla testaajat voivat suunnitella tarkistuksia puurakenteen avulla mahdollisimman joustavasti.

Jokainen ajoon tai testitapaukseen tehty muutos jƤƤ sovelluksen historiaan tƤydellisen vastuuvelvollisuuden ja jƤljitettƤvyyden varmistamiseksi.

TƤmƤ on kuitenkin ilmaista vain pienille tiimeille ja avoimen lƤhdekoodin projekteille.

 

Milloin kannattaa kƤyttƤƤ Enterprise- ja milloin Free Exploratory Test -tyƶkaluja?

 

Tutkiva testaus on kannattava investointi, ja maksulliset sovellukset tarjoavat yleensƤ enemmƤn toimintoja, mutta monet ilmaiset vaihtoehdot tarjoavat enemmƤn kuin tarpeeksi ominaisuuksia.

Tutkiva testaus voi olla merkittƤvƤ toimintakustannus, jos sitoudut premium-malliin, mutta kaikilla ohjelmistokehitysyrityksillƤ tai -tiimeillƤ ei ole varaa tƤhƤn. Parhaan kolmannen osapuolen ohjelmiston valinta riippuu usein yrityksen erityisvaatimuksista.

Maksullinen ratkaisu voi olla ainoa tapa tƤyttƤƤ kyseisen projektin tarpeet; ryhmƤn on tutkittava eri vaihtoehtoja ennen kuin se sitoutuu sovellukseen.

Pienempien tiimien yritykset voivat hyƶtyƤ eniten ilmaisista testaustyƶkaluista, sillƤ monet vaihtoehdot ovat ilmaisia rajoitetulle kƤyttƤjƤmƤƤrƤlle.

Vaihtoehtoisesti he voivat valita vaihtoehtoja ilman tƤtƤ rajoitusta ja sellaisia vaihtoehtoja, joihin testausryhmƤn mittakaava mahtuu. TƤmƤ voi tehdƤ entistƤkin kannattavammaksi koetestaajien parityƶskentelyn tarkempien tulosten varmistamiseksi – tiimi tarvitsee luonnollisesti vƤhemmƤn kƤyttƤjƤprofiileja.

Monet palvelut tarjoavat ilmaisen kokeilujakson ohjelmistostaan, jotta organisaatiot voivat nƤhdƤ, vastaako se heidƤn tarpeitaan; tƤmƤ kestƤƤ yleensƤ vain pari viikkoa.

 

Tutkivan testauksen tarkistuslista, vinkkejƤ ja temppuja

 

Testaajat voivat ottaa huomioon monia muita vinkkejƤ aloittaessaan tutkivia tarkastuksiaan:

 

1. Jaa ominaisuudet ja moduulit asianmukaisesti

VƤƤrinkƤsitysten vƤlttƤmiseksi testausryhmien tulisi laatia selkeƤ luettelo jokaisesta ominaisuudesta ja tarkistuksista, jotka ne aikovat suorittaa. TƤmƤ tarkoittaa myƶs sen varmistamista, ettƤ testit jakautuvat riittƤvƤsti eri ohjelmistotoimintojen kesken.

Parhaiden tulosten saavuttamiseksi on ensiarvoisen tƤrkeƤƤ, ettƤ testausryhmƤ neuvottelee, ketkƤ jƤsenet suorittavat kunkin testin omien taitojensa ja vahvuuksiensa perusteella.

 

2. Tyƶskentele ymmƤrtƤƤkseen ohjelmistoa

Oppimisvaihe on kriittinen osa kokeilevaa testausta. TƤmƤ tarkoittaa sitƤ, ettƤ testaajien on oltava aktiivisesti tekemisissƤ ohjelmiston kanssa ja selvitettƤvƤ, miten se toimii, ennen kuin he laativat testejƤ.

Ohjelmiston sisƤisten toimintatapojen oppiminen voi olla yhteistyƶprosessi, jolla varmistetaan parempi ymmƤrrys koko tiimissƤ. NƤin testaajat voivat kehittƤƤ parempia tarkastuksia ja testitapauksia.

 

3. SelvitƤ ongelma-alueet

Jokaisessa sovelluksessa on ominaisuuksia tai komponentteja, jotka leikkaavat toisiaan. Kun ohjelmistot monimutkaistuvat, niihin syntyy todennƤkƶisemmin virheitƤ, mikƤ voi vaatia enemmƤn testausta. Tiimin on aktiivisesti selvitettƤvƤ, mitkƤ osat tarvitsevat lisƤapua.

He saattavat kƤyttƤƤ erityisiƤ testauskierroksia, jotka vastaavat parhaiten sovelluksen tarpeita ja tiimin yleisiƤ testausprioriteetteja.

 

4. Aloita peruskƤyttƤjƤskenaarioista

LaadunvarmistusryhmƤt voivat tarvittaessa suorittaa kartoittavia testejƤ missƤ tahansa jƤrjestyksessƤ, mutta voi olla hyƶdyllisempƤƤ aloittaa helpommilla tarkistuksilla ennen monimutkaisempiin ominaisuuksiin syventymistƤ.

NƤin monimutkaisuus voi edetƤ tasaisesti, ja testaajat pƤƤsevƤt ymmƤrtƤmƤƤn ohjelmistoa. Se auttaa myƶs testaamaan, toimivatko perusominaisuudet odotetulla tavalla.

 

5. Paritetaan testaajat yhteen

Parittainen kokeileva testaus sekƤ sujuvoittaa ettƤ validoi laadunvarmistusvaihetta, jolloin testaajat voivat tyƶskennellƤ ehdottoman luottavaisin mielin jokaisen tarkistuksen yhteydessƤ. Yhteistyƶ tekee testauksesta tehokkaampaa, koska se parantaa jokaisen ryhmƤn jƤsenen tuntemusta ohjelmistosta.

He voivat myƶs antaa vikailmoituksia paljon syvƤllisemmin, koska heillƤ on yksilƶllinen nƤkƶkulma, mikƤ antaa kehittƤjille enemmƤn tietoa kƤytettƤvƤksi.

 

6. Suorita useita testejƤ

RyhmƤn mahdollisuudet testata hakemus uudelleen riippuvat ryhmƤn aikataulusta ja mƤƤrƤajoista. Mutta jos se on mahdollista, erityisen ongelmallisten komponenttien kaksinkertainen tarkastus voi olla hyƶdyllistƤ.

TƤmƤn lisƤksi testejƤ toistamalla voidaan varmistaa, ettƤ aiemmin havaittu ongelma on nyt korjattu eikƤ vaikuta ohjelmistoon enƤƤ. TƤmƤ huolellisuus on joskus tarpeen, jotta testaus onnistuu.

 

PƤƤtelmƤ

 

Tutkivalla testauksella on paljon annettavaa kaikenlaisille ohjelmistokehitysyrityksille, sillƤ se tƤydentƤƤ kƤsikirjoitustestausta ja monia muita tarkastuksia.

Tutkivan testauksen avulla laadunvarmistusryhmƤt voivat testata sovelluksia korkeammalle tasolle, parantaa lopullisen ohjelmiston laatua ja auttaa kehittƤjiƤ korjaamaan mahdolliset virheet.

Manuaalisen ja automatisoidun testauksen yhdistelmƤllƤ voidaan varmistaa suurin hyƶty, sillƤ se mahdollistaa yhtƤlƤisen huomion kiinnittƤmisen kaikkiin ohjelmistokomponentteihin.

Jos yrityksesi tarvitsee tutkimusautomaatio-ohjelmistoa, ZAPTEST FREE Edition tarjoaa paljon laajemmat ja joustavammat toiminnot kuin muut premium-sovellukset, joiden avulla testaajat voivat helposti optimoida nƤmƤ tarkistukset.

 

Usein kysytyt kysymykset ja resurssit

 

1. Parhaat kurssit tutkivan testauksen automatisoinnista

 

SekƤ uudet ettƤ kokeneet kokeilevat testaajat voivat hyƶtyƤ kursseista, joilla he voivat parantaa taitojaan. TƤhƤn kuuluu myƶs sen selvittƤminen, miten uusia ohjelmistoja lƤhestytƤƤn.

HyƶdyllisiƤ kursseja, jotka voivat auttaa tƤssƤ, ovat muun muassa:

– Udemyn Complete 2023 Software Testing Bootcamp; tƤmƤ opettaa laajan ohjelmistotestauksen 28 tunnin aikana.

– Coveros’s Exploratory Testing; tƤssƤ keskitytƤƤn siihen, miten kehittƤƤ peruskirjoja ja soveltaa tutkivia testejƤ API-rajapintoihin.

– Polteqin kaksipƤivƤinen tutkivan testauksen koulutus; tƤssƤ koulutuksessa tarkastellaan, miten tutkivat testit toimivat ketterƤssƤ kontekstissa.

– LinkedIn’s Exploratory Testing; tƤmƤ osoittaa, miten nykyaikainen ohjelmistotestaus on ottanut kƤyttƶƶn tutkivat tarkastukset.

– Courseran Introduction to Software Testing; tƤmƤ auttaa ensikertalaisia testaajia ymmƤrtƤmƤƤn tyypillisiƤ menettelytapoja.

 

2. MitkƤ ovat 5 tƤrkeintƤ haastattelukysymystƤ eksploratiivisesta testauksesta?

 

Kun haastattelet tutkivan testauksen tehtƤviin, on tƤrkeƤƤ, ettƤ palkkaavat johtajat esittƤvƤt hyviƤ kysymyksiƤ, jotta he voivat arvioida tarkasti hakijan taitoja ja kokemusta.

Viisi tƤrkeintƤ kysymystƤ ovat:

– MitkƤ ovat kƤsikirjoitetun ja kokeilevan testauksen tƤrkeimmƤt erot, niiden soveltuvuus mukaan luettuna?

– Millaisia haasteita olet kohdannut kokeilevana testaajana ja miten olet selvinnyt niistƤ?

– Anna esimerkkejƤ kokeellisista testeistƤ, jotka hyƶtyisivƤt eniten robottiprosessien automatisoinnista.

– MikƤ on mielestƤnne merkittƤvin (tekninen tai muu) taito, joka tarvitaan kokeilevan testaajan tyƶhƶn?

– MitƤ neuvoja antaisit testaajalle, jolla on vaikeuksia ymmƤrtƤƤ ohjelmistoa ja sen tarkistamista?

 

3. Parhaat YouTube-oppaat tutkimustestauksesta

 

YouTuben kaltaisilla videonjakosivustoilla on saatavilla monia ilmaisia opetusohjelmia, jotka voivat auttaa tulevia testaajia ymmƤrtƤmƤƤn sen keskeiset periaatteet. Jotkut niistƤ ovat osa sarjaa, toiset taas ovat yksittƤisiƤ videoita, joissa syvennytƤƤn aiheeseen.

NƤitƤ opetusohjelmia tarjoavat muun muassa seuraavat kanavat:

– The Testing Academy tarjoaa satoja videoita, jotka kattavat kaikki ohjelmistotestauksen osa-alueet.

– Software Testing Mentor, joka tarjoaa myƶs laajoja videoita ohjelmistotestauksen perusteista.

– QAFox, joka tarjoaa myƶs todellisia esimerkkejƤ ja live-projekteja tƤydentƤmƤƤn kaikkia videoita.

– SDET-QA Automation Techie, jossa on useita kattavia videoita erilaisista testausmenetelmistƤ.

– GlitchITSystem, joka tutkii erilaisia verkkosivustoja ja yrittƤƤ lƶytƤƤ hƤiriƶitƤ testaamalla.

 

4. Miten yllƤpitƤƤ tutkivia testejƤ?

 

Hyvin toteutettuihin kokeileviin testeihin sisƤltyy vahva dokumentaatio, johon kehittƤjƤt ja tulevat testaajat voivat palata ohjelmiston uusia iteraatioita varten.

Kun sovellukseen tehdƤƤn merkittƤviƤ pƤivityksiƤ, sen ensisijaisten toimintojen uudelleentestaus on tarpeen, jotta voidaan varmistaa, ettƤ lisƤyksillƤ ei ole kielteisiƤ vaikutuksia jo olemassa oleviin ominaisuuksiin.

TƤmƤ on ainoa tapa taata, ettƤ kokeelliset testit onnistuvat pitkƤllƤ aikavƤlillƤ. Se auttaa myƶs ottamaan huomioon tulevaisuuden suunnitelmat, kuten alustavat ominaisuudet, kun alkuperƤistƤ sovellusta ja sen tarkistuksia suunnitellaan.

QA-henkilƶstƶn on suunniteltava nƤmƤ testit asianmukaisesti ja selvitettƤvƤ, milloin sovellus on tarkistettava uudelleen; automatisoidut testaustyƶkalut voivat auttaa tiimiƤ tƤssƤ.

 

5. Onko tutkiva testaus mustan laatikon testausta?

Tutkiva testaus on hyvin samankaltaista kuin mustan laatikon testaus, jolla tarkoitetaan sovelluksen tarkistamista tarkastelemalla sen ominaisuuksia tarkastelematta suoraan koodia.

Tutkivan testauksen piiriin kuuluville tarkastuksille ei ole selkeƤƤ rajaa; tƤmƤ lƤhestymistapa voi kattaa kaikki ohjelmiston osa-alueet, myƶs koodin.

Yksi nƤiden kahden testaustyypin keskeisistƤ yhtƤlƤisyyksistƤ on se, ettƤ testaajalla ei ole ennakkotietoa. Mustan laatikon testaajat eivƤt yleensƤ tunne ohjelmistoa ennen sen testaamista, ja tutkivat testaajat oppivat ohjelmiston toiminnan osana alustavaa tarkastelua.

Vaikka tutkivaa testausta ei yleensƤ aina luokitella mustan laatikon testaukseksi, on totta, ettƤ nƤiden kahden lƤhestymistavan vƤlillƤ on huomattavan paljon ristikkƤisyyttƤ.

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

Virtual Expert

ZAPTEST

ZAPTEST Logo