fbpx

OhjelmistokehittƤjinƤ yksi tƤrkeimmistƤ tehtƤvistƤmme on testaus. KƤytƶssƤ on kymmeniƤ testausmuotoja, joissa testaajat tutkivat jokaisen koodirivin, jotta tuote olisi tƤydellinen.

End-to-end-testaus on koodin ƤƤrimmƤinen testi, jossa arvioidaan ohjelmaa kƤyttƤjƤn nƤkƶkulmasta ja etsitƤƤn mahdollisia virheitƤ, jotka voivat pilata jonkun kokemuksen tyƶstƤ.

Lue lisƤƤ siitƤ, mitƤ pƤƤstƤ pƤƤhƤn -testaus on, mitƤ etuja tƤmƤntyyppisestƤ testauksesta on ja mitkƤ ovat ihanteellisia tyƶkaluja testausprosessien suorittamiseen tyƶpaikalla.

 

Table of Contents

MitƤ on End-to-End-testaus?

 

End-to-End-testausta kƤytetƤƤn ohjelmistokehitysprosessissa testaamaan sovelluksen toimintaa ja suorituskykyƤ, kun sitƤ kƤytetƤƤn tuotteena.

End-to-end-testauksen (E2E) tavoitteena on saada parempi kƤsitys siitƤ, miten tuote toimisi, kun sitƤ kƤytetƤƤn live-ympƤristƶssƤ.

TƤssƤ testauksessa keskitytƤƤn tarkastelemaan koodia kƤyttƤjƤn vuorovaikutuksen alusta loppuun asti, mistƤ termi ”end-to-end” johtuu.

Se on hyvin kattava tapa tutkia ohjelmistoja ja selvittƤƤ, missƤ ja miksi ongelmia voi esiintyƤ tyƶssƤsi.

 

1. Milloin ja miksi tehdƤƤn pƤƤstƤ pƤƤhƤn -testausta

 

Paras aika E2E-testauksen suorittamiseen on kehitysprosessin loppupuolella. TƤmƤ johtuu siitƤ, ettƤ suurin osa asiakkaan kƤyttƤmistƤ ominaisuuksista on jo ohjelmassa, mikƤ tarkoittaa, ettƤ pƤƤstƤ pƤƤhƤn -testi kattaa kaikki tarvittavat ohjelman osat, joita kƤyttƤjƤt kokevat.

Testauksen suorittaminen ennen tƤtƤ aikaa voi aiheuttaa ongelmia, jotka liittyvƤt siihen, ettƤ kyseessƤ on epƤtƤydellinen versio ohjelmasta tai ohjelmistosta.

Organisaatiot suorittavat E2E-testauksen ilmeisistƤ syistƤ, jotka liittyvƤt ensisijaisesti toiminnallisuuteen. TƤmƤn testausprosessin lƤpikƤyminen tarkoittaa, ettƤ ymmƤrrƤt projektin ongelmat siihen asti ja voit ratkaista ne ennen tuotteen julkaisemista yleisƶlle.

 

2. Kun ei tarvitse tehdƤ pƤƤstƤ-pƤƤhƤn-testausta

 

On olemassa muutamia tapauksia, joissa pƤƤstƤ pƤƤhƤn -testi ei ole vƤlttƤmƤtƶn, esimerkiksi tapaukset, joissa yksikkƶtestit ovat tehokkaampia.

YksikkƶtesteillƤ tutkitaan koodin tiettyjƤ yksikƶitƤ, kuten yksittƤisiƤ funktioita ja kahden eri ohjelmatoiminnon vƤlisiƤ yksittƤisiƤ yhteyksiƤ. Yksikkƶtestit voivat olla nopeampia, mutta niiden haittapuolena on, ettƤ ne eivƤt tƤysin simuloi kƤyttƤjƤkokemusta.

Harkitse yksikkƶtestausta silloin, kun yksikƶitƤ on suhteellisen vƤhƤn, kuten verkkosovelluksessa, jossa on vain yksi ominaisuus.

Suuremmat sovellukset vaativat eksponentiaalisesti suuremman tiimin testaamaan kaikki yksikƶt kattavasti.

NƤissƤ tapauksissa paluu pƤƤstƤ pƤƤhƤn -testeihin on paljon helpompi prosessi.

 

3. Kuka osallistuu E2E-testeihin?

 

TƤmƤ riippuu tƤysin organisaation luonteesta. Joillakin yrityksillƤ on erityinen testausryhmƤ, jossa kehittƤjƤt itse suorittavat joidenkin yritysten testausprosessin.

Suuremmilla organisaatioilla on tapana perustaa omat tiimit testausta ja kehitystƤ varten, jolloin nƤmƤ kaksi tahoa pysyvƤt toisistaan riippumattomina, jotta E2E-testauksen tulokset eivƤt olisi vƤƤristyneitƤ.

PyydƤ mahdollisuuksien mukaan joku, joka ei ole kehittƤnyt tiettyƤ ominaisuutta, testaamaan sitƤ. TƤmƤ poistaa mahdollisuuksien mukaan luontaiset vƤƤristymƤt ja pitƤƤ testin lopputuloksen mahdollisimman tarkkana.

PienemmƤt riippumattomat kehittƤjƤt, kuten ensikertalaiset sovelluskehittƤjƤt tai ne, joilla on rajoitetumpi budjetti, suorittavat E2E-testit itse.

NƤissƤ tapauksissa keskity automaattiseen testaukseen. Automaattiset jƤrjestelmƤt poistavat kaikki ennakkoluulot eivƤtkƤ tee virheitƤ tuloksia tuottaessaan.

Mahdollisuuksien mukaan on ihanteellista, ettƤ useampi henkilƶ suorittaa testit ja toistaa ne, sillƤ se antaa lisƤvarmuutta sekƤ automaattisten ettƤ manuaalisten tulosten osalta.

ZAPTESTin kaltaiset End-to-End-automaatiotyƶkalut tarjoavat ohjelmisto + palvelut -mallin, mikƤ tarkoittaa, ettƤ ZAP-sertifioitu asiantuntija tyƶskentelee asiakkaan tiimin rinnalla ja osana sitƤ tukeakseen ja maksimoidakseen erilaisten automatisoitujen testien tuottaman ROI:n, mukaan lukien End-to-End.

 

End-to-End-testauksen edut

 

KehitystiimillƤ on useita etuja, jotka vaihtelevat testattavasta ohjelmistotyypistƤ riippuen.

E2E-testauksen kƤyttƤmisen tƤrkeimpiƤ etuja organisaatiossasi ovat muun muassa seuraavat:

 

1. Havaitse puutteet

 

End-to-end-testaus on ihanteellinen keino lƶytƤƤ ohjelmistosta virheitƤ ja muita puutteita.

Tee testausprosessin aikana muistiinpanoja kaikista havaitsemistasi ongelmista ja virheilmoituksista sekƤ siitƤ, missƤ nƤmƤ ongelmat ilmenevƤt. TƤmƤ nopeuttaa ja helpottaa vikojen korjausprosessia huomattavasti.

EsimerkkejƤ ongelmista, joita kannattaa etsiƤ, ovat esimerkiksi sovelluksen toiminto, jota ei saada valmiiksi, sovellus kaatuu kokonaan tai kƤyttƶliittymƤn ominaisuudet eivƤt lataudu kunnolla, mikƤ vaikuttaa ohjelman ulkoasuun.

 

2. KƤyttƤjƤn nƤkƶkulman ymmƤrtƤminen

 

Yksi kehittƤjien ongelmista on se, ettƤ he eivƤt ymmƤrrƤ kƤyttƤjien nƤkemystƤ heidƤn tyƶstƤƤn. Loppujen lopuksi kehittƤjƤt nƤkevƤt ensisijaisesti tyƶn takapuolen eivƤtkƤ ymmƤrrƤ, miten kƤyttƤjƤ toimii vuorovaikutuksessa.

TƤmƤ prosessi kuroo umpeen tƤmƤn kuilun ja tuo esimerkiksi kƤyttƶliittymƤongelmat kehittƤjƤn tietoon.

Kokoa sovelluksesta tƤydellinen versio, jotta saat nƤissƤ tapauksissa tƤyden kƤyttƶkokemuksen sovelluksen avaamisesta kaikkien kƤytettƤvissƤ olevien toimintojen lƤpikƤymiseen.

Testaajat, jotka eivƤt ole kehittƤjiƤ, ovat hyƶdyllisiƤ nƤissƤ tapauksissa, koska he eivƤt ole niin lepsuja keskittyessƤƤn siihen, miten sovelluksen ”pitƤisi” toimia, ja he nƤkevƤt yksinomaan ulkoisen nƤkƶkulman.

 

3. KehittƤjien luottamuksen lisƤƤminen

 

Jopa useiden testien suorittamisen jƤlkeen kehittƤjien voi olla vaikea luottaa tyƶhƶnsƤ tƤysin.

LoppupƤƤn testauksen lƤpikƤyminen osoittaa, ettƤ kƤyttƤjƤkokemus on myƶnteinen ja ettƤ tuotteen julkaisemiselle on olemassa hyvƤ perusta.

Ongelman sattuessakin on hyƶdyllistƤ tietƤƤ, missƤ nƤmƤ ongelmat ovat, jotta voidaan luoda strategia ja luottaa sovelluksen muihin osa-alueisiin ja toimintoihin.

 

End-to-End-testien haasteet

 

End-to-End-testien kƤyttƶƶn ohjelmistokehityksessƤ liittyy muutamia haasteita, kuten:

 

1. Hidas toteutus

Kokonaisvaltaisen testin suorittaminen tarkoittaa vuorovaikutusta kƤyttƶliittymƤn kanssa, joka kehottaa toimintaan, eikƤ backendin kƤyttƶƤ, joka voi viedƤ enemmƤn aikaa sovelluksen navigointiin ja kƤyttƶƶn.

TƤmƤ paranee osittain, kun kƤytetƤƤn pƤƤstƤ pƤƤhƤn -testausautomaatiota.

 

2. Monimutkaiset testiympƤristƶt

End-to-end-testaus on suunniteltu siten, ettƤ siinƤ keskitytƤƤn luomaan tarkka versio siitƤ, miten asiakas toimii vuorovaikutuksessa ohjelmiston kanssa, mikƤ tekee tarkemman testiympƤristƶn rakentamisesta vaikeampaa kuin pienempien testien suorittaminen.

 

3. Vaikea virheenkorjaus

Virheenkorjausprosessi on monimutkaisempi pƤƤstƤ pƤƤhƤn -testeissƤ, sillƤ automaattinen testi, joka palauttaa ”Fail”-viestin, ei todennƤkƶisesti ole tarkka ongelman syyn suhteen.

KehittƤjien on tutkittava nƤitƤ tapauksia tarkemmin ongelmien ratkaisemiseksi, varsinkin jos erityisiƤ virheilmoituksia ei ole integroitu.

 

End-to-End-testien ominaisuudet

 

On olemassa muutamia tƤrkeitƤ testejƤ, joita on syytƤ tarkastella, kun mƤƤritetƤƤn, onko testi luonteeltaan pƤƤstƤ pƤƤhƤn -testi.

TƤmƤntyyppisen testin ominaispiirteitƤ ovat muun muassa seuraavat:

 

1. Arviointi alusta loppuun

Kaikki pƤƤstƤ pƤƤhƤn -testit ovat ohjelmiston arviointeja kƤyttƤjƤn ensimmƤisestƤ vuorovaikutuksesta viimeiseen vuorovaikutukseen, ja ne kattavat kaikki ohjelmiston osa-alueet, joiden kanssa kƤyttƤjƤt ovat vuorovaikutuksessa.

TƤmƤ tekee E2E:stƤ yhden ohjelmistokehityksen kattavimmista testausmuodoista.

 

2. Todellisen maailman skenaario

E2E-testauksessa korostetaan reaalimaailman simulointia, ja nƤissƤ testeissƤ pyritƤƤn luomaan reaalimaailman skenaario, joka kuvaa tarkasti sitƤ, miten kƤyttƤjƤ toimii vuorovaikutuksessa saatavilla olevan tiedon kanssa.

TƤmƤ edellyttƤƤ tarkan ympƤristƶn ja kƤyttƤjƤn rakentamista testitapausta varten.

 

3. SelkeƤt tulokset

E2E-testauksen tulokset ovat selkeitƤ ja yksinkertaisia, ja kehittƤjƤt saavat selville, onnistuiko heidƤn ohjelmistonsa vai oliko siinƤ epƤonnistumisia missƤ tahansa kƤyttƤjƤn matkan vaiheessa.

TƤmƤ koskee erityisesti manuaalista testausta, sillƤ testaajat voivat raportoida kaikista ongelmista.

 

E2E-testauksen toimintatyypit

 

KehittƤjƤt ja testaajat tekevƤt monenlaisia toimintoja E2E-testauksen aikana.

NƤihin kuuluvat:

 

KƤyttƤjƤn toiminnot

 

KƤyttƤjƤtoiminnot ovat yksi ensimmƤisistƤ asioista, joihin kannattaa keskittyƤ E2E-testauksessa.

 

1. MitƤ ovat kƤyttƤjƤn toiminnot?

KƤyttƤjƤtoiminnot ovat luettelo kaikista ohjelmistossa olevista ominaisuuksista ja toisiinsa liittyvistƤ jƤrjestelmistƤ.

TƤhƤn kuuluu kaikki se, minkƤ kanssa kƤyttƤjƤ on vuorovaikutuksessa ja mikƤ lisƤƤ ohjelman toiminnallisuutta.

Ilman mitƤƤn kƤyttƤjƤfunktioita ei tarvita ohjelmaa, koska sinulla on vain koodi, joka luo kƤyttƶliittymƤn, joka ei tee mitƤƤn.

 

2. EsimerkkejƤ

Sovelluksen valikkoa pidetƤƤn kƤyttƤjƤn toimintona, koska kƤyttƤjƤ kƤyttƤƤ sitƤ parantaessaan tyƶnsƤ tasoa.

Muita esimerkkejƤ ovat taustapuolen algoritmit, kuten ne, jotka antavat kƤyttƤjille lisƤtietoja ja sallivat tai estƤvƤt pƤƤsyn tiettyihin ohjelmiin.

 

3. KƤyttƤjƤtoimintojen rakentaminen

Luettele kaikki toiminnot ja toisiinsa kytketyt jƤrjestelmƤt, ennen kuin seuraat ja kirjaat ylƶs kaikki jƤrjestelmƤssƤ esiintyvƤt vuorovaikutukset.

TƤmƤ sisƤltƤƤ syƶtetyt tiedot ja ohjelmasta saatavat tuotokset.

Ole tƤssƤ prosessissa mahdollisimman perusteellinen, sillƤ kattava ymmƤrrys ohjelman toiminnallisuudesta ja tiedoista tekee testauksesta paljon yksinkertaisempaa ja ymmƤrrettƤvƤmpƤƤ.

 

Ehdot

 

Ehdoilla tarkoitetaan parametreja, jotka asetetaan pƤƤstƤ pƤƤhƤn -testissƤ ja jotka mƤƤrittelevƤt, miten testi suoritetaan ja miten testaaja arvioi tuloksen.

 

1. MitƤ ovat ehdot?

Ehdoilla tarkoitetaan parametrien joukkoa, jotka mƤƤrittelevƤt testin. NƤitƤ on kahta eri muotoa, mukaan lukien TRUE/FALSE-parametri, joka mƤƤrittƤƤ, onko data tai tuloste kelvollinen, ja data-parametri.

NƤiden ehtojen kƤyttƶ mƤƤrittƤƤ testin tilan ja sen, onko ympƤristƶ oikean kƤyttƤjƤn kannalta tarkka.

 

2. EsimerkkejƤ pƤƤstƤ pƤƤhƤn -testien olosuhteista

Esimerkki TRUE/FALSE-ehdosta on selain, jolla kƤyttƤjƤ kƤyttƤƤ verkkosovellusta, ja TRUE/FALSE mƤƤrittƤƤ, onko kƤyttƤjƤ tyƶpƶytƤversiossa.

Esimerkki tietoehdosta on aika, joka kƤyttƤjƤltƤ kuluu tietyn toiminnon suorittamiseen, tai IP-osoite, josta kƤyttƤjƤ muodostaa yhteyden.

 

3. Rakennusolosuhteet

MƤƤritƤ ihanteelliset olosuhteet testausta varten, mukaan lukien kƤyttƤjƤn sijainti, testin ajankohta ja muut testin tarkkuuteen vaikuttavat olosuhteet.

KƤytƤ tarvittaessa ”kƤyttƤjƤprofiilia” tietojen johdonmukaisuuden ja tarkkuuden lisƤƤmiseksi. MitƤ realistisemmat testin olosuhteet ovat, sitƤ tarkempia ovat sen tulokset.

 

End-to-End-testauksen testitapaukset

 

Testitapaus on joukko toimintoja, joita kƤyttƤjƤ suorittaa jƤrjestelmƤssƤ tutkiakseen, toimiiko se kehittƤjƤn odotusten mukaisesti.

Testitapausten suorittaminen tarkoittaa, ettƤ kehittƤjƤt voivat luottaa tyƶnsƤ laatuun ja nƤhdƤ, ettƤ heidƤn tuotteensa toimivat odotetulla tavalla.

 

1. MitƤ testitapaukset ovat pƤƤstƤ pƤƤhƤn -testeissƤ?

Testaajat suorittavat pƤƤstƤ pƤƤhƤn -testejƤ testitapauksia ohjelman kanssa tapahtuvan vuorovaikutuksen alusta loppuun asti.

Suunnittelemalla nƤmƤ perusteelliset testitapaukset ja noudattamalla niitƤ ohjelmiston jokaisessa iteraatiossa kehittƤjƤ takaa, ettƤ ohjelmiston jokaisessa iteraatiossa on toiminnallisuutta.

PidƤ testitapaukset johdonmukaisina versiosta toiseen, jotta nƤet muutokset tyƶn laadussa ja testien tuloksissa.

 

2. Miten suunnitella E2E-testitapauksia?

 

E2E-testitapausten suunnittelussa on muutamia vaiheita, joista jokainen johtaa parempiin tuloksiin koko testauksen aikana.

NƤihin vaiheisiin kuuluvat:

 

Tunne tavoitteesi

Aloita ymmƤrtƤmƤllƤ kunkin yksittƤisen testitapauksen tavoitteet.

Aivan ensimmƤisellƤ testikierroksella tarkastellaan perustoiminnallisuutta ja varmistetaan, ettƤ sovellus toimii, ja myƶhemmin E2E-testeissƤ tarkastellaan suorituskykyƤ ja reagointikykyƤ.

TƤhƤn kuuluu testin erityisehtojen ymmƤrtƤminen, mukaan lukien demografiset tiedot, joilla testataan, ja sen varmistaminen, ettƤ ne sopivat keskivertokƤyttƤjƤlle.

Kun sinulla on tavoitteesi mielessƤsi alusta alkaen, prosessi on tarkempi ja selkeƤmpi.

 

Keskity yksinkertaisuuteen

Aloita suhteellisen yksinkertaiselta pohjalta.

Jos luettelet jo ensimmƤisessƤ testissƤ joukon monimutkaisia ehtoja ja vaatimuksia, teet testin lƤpƤisemisestƤ yhƤ vaikeampaa ja lisƤƤt tyƶsi monimutkaisuutta.

Suorita alustava testaus hyvin perustason ehdoilla ja tavoitteilla, ennen kuin kehitƤt myƶhemmissƤ testeissƤ ja lisƤƤt tarvittaessa lisƤtietoja.

Testaus voi olla monimutkaisempaa, mutta tee perusasiat valmiiksi ennen laajentamista.

 

Ole perusteellinen

YritƤ olla mahdollisimman perusteellinen, kun suoritat E2E-testejƤ.

TƤmƤ tarkoittaa, ettƤ jokainen testi on suoritettava kokonaan ja ettƤ kaikki prosessin aikana saadut tiedot on kirjattava ylƶs.

NƤin voit havaita jokaisen koodimuutoksen vaikutuksen.

TƤmƤ on erityisen hyƶdyllistƤ, kun ohjelmaa optimoidaan prosessin myƶhemmƤssƤ vaiheessa ja mitataan aikaa, joka kuluu tiettyjen tehtƤvien suorittamiseen.

 

3. EsimerkkejƤ E2E-testitapauksista

 

EsimerkkejƤ testitapauksista, joita yritykset kƤyttƤvƤt vahvistaessaan ohjelmistojensa laatua E2E-testauksen aikana, ovat seuraavat:

 

Toimintatestaus

Toimintatestauksessa selvitetƤƤn, toimivatko ohjelmiston tietyt toiminnot odotetulla tavalla.

TƤmƤ on yksi E2E-testauksen varhaisimmista vaiheista, ja siinƤ selvitetƤƤn, toimiiko koodi perustasolla, ennen kuin ohjelmiston suorituskykyƤ yritetƤƤn parantaa myƶhemmissƤ iteraatioissa.

 

Reagointinopeus

SelvitetƤƤn, reagoiko ohjelmisto nopeasti kƤyttƤjƤƤn ja suorittaa tehtƤvƤt ajallaan.

Joissakin E2E-testauksissa keskitytƤƤn varmistamaan, ettƤ jƤrjestelmƤ palauttaa nopeasti kelvollisia tuloksia, mittaamalla aikaa, joka kuluu kƤyttƤjƤn prosessin lƤpikƤymiseen, ja vertaamalla sitƤ aiempiin iteraatioihin, jolloin lyhyemmƤt suoritukset ovat kƤyttƤjƤn kannalta ihanteellisia.

Validien ja tarkkojen tulosten sƤilyttƤminen on tƤrkeƤƤ koko prosessin ajan.

 

Tietokannan vastaukset

Jotkin jƤrjestelmƤt on suunniteltu palauttamaan kƤyttƤjƤlle joukko vastauksia tietokannasta.

Kun testaat nƤitƤ sovelluksia, aseta sovellukselle tietty aika vastata ja mittaa tietokannasta saatujen vastausten mƤƤrƤƤ verrattuna saman testitapauksen aiempiin iteraatioihin.

 

Kaksi erilaista pƤƤstƤ pƤƤhƤn -testausta ja menetelmiƤ

 

Kuten muissakin testauksen muodoissa, kehittƤjƤt kƤyttƤvƤt erilaisia pƤƤstƤ pƤƤhƤn -testauksen muotoja, joista jokaisella on erilaiset hyƶdyt tavoitteistasi riippuen.

End-to-end-testaus sisƤltƤƤ horisontaaliset testit ja vertikaaliset testit, jotka eroavat toisistaan huomattavasti testauksen laajuuden ja kehittƤjien prosessissa kƤyttƤmien menetelmien osalta.

NƤihin kuuluvat:

 

1. Vaakasuorat testit

 

Horisontaalinen testi tapahtuu, kun kƤyttƤjƤvirtoja todennetaan useissa sovelluksissa samanaikaisesti, kun kaikki sovellukset ovat kƤynnissƤ alusta loppuun. NƤin varmistat, ettƤ jokainen prosessi toimii moitteettomasti useissa eri kƤyttƶtapauksissa, eikƤ eri tietomuodoilla ole kielteistƤ vaikutusta sovelluksen suorituskykyyn.

Horisontaalisen e-to-e-testauksen tƤrkein hyƶty on se, ettƤ voit varmistaa, ettƤ jƤrjestelmƤt toimivat moitteettomasti useilla kƤyttƤjillƤ, jotka kaikki kƤyttƤvƤt samaa sovellusversiota.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Horisontaalisen testauksen loppuunsaattamiseksi keskity siihen, ettƤ ympƤristƶt on luotu kaikkia tapauksia varten, ennen kuin kƤynnistƤt alusta loppuun ulottuvan testauksen.

Kaikkien sovellusten on toimittava samaan aikaan, mikƤ tarkoittaa, ettƤ tƤmƤ ei ole ihanteellinen vaihtoehto yrityksille, jotka eivƤt ole vielƤ saaneet sovellustensa kehitysprosessia valmiiksi.

TƤllainen e-to-e-testi on perusteellinen kƤyttƤjƤn nƤkƶkulmasta ja varmistaa, ettƤ kƤyttƤjƤt saavat perustoiminnallisuuden lisƤksi odotetun suorituskyvyn.

 

2. Pystysuorat testit

 

Sen sijaan, ettƤ keskityttƤisiin koko sovelluksen toimintaan, vertikaalisessa pƤƤstƤ pƤƤhƤn -testauksessa keskitytƤƤn sovellukseen kerroksittain.

TƤhƤn liittyy yksityiskohtaisempi prosessi, jossa testataan toistuvasti kaikki sovelluksen yksittƤiset osatekijƤt ja testataan yhden jƤrjestelmƤn sisƤllƤ eikƤ sovellusten vƤlillƤ, kuten horisontaalisessa testauksessa.

Vertikaalisen e-to-e-testauksen tƤrkein hyƶty on se, ettƤ saat yksityiskohtaisemman ja tarkemman kuvan siitƤ, miten jƤrjestelmƤsi toimii. NƤet, mitkƤ ongelmat ovat jƤrjestelmƤn kullakin tasolla, ja tyƶskentelet niiden ratkaisemiseksi testausprosessin jƤlkeen sen sijaan, ettƤ vain tietƤisit, ettƤ jossain sovelluksessa on ongelma.

TƤmƤ voi kuitenkin viedƤ enemmƤn aikaa kuin vaakasuorien testien tekeminen.

 

Sekaannusten selvittƤminen – End-to-End-testaus vs. jƤrjestelmƤtestaaminen vs. UAT-testaaminen vs. toiminnallinen testaus

 

On olemassa useita erilaisia testaustyyppejƤ, jotka ihmiset sekoittavat pƤƤstƤ pƤƤhƤn -testaukseen, kun puhutaan tavasta, jolla organisaatiot arvioivat ja ratkaisevat ohjelmistojensa ongelmia.

Koska eri organisaatioilla ja ohjelmistoilla on yksilƶllisiƤ tarpeita, on tƤrkeƤƤ, ettƤ niihin vastataan oikeanlaisella testauksella.

Alla on lueteltu joitakin testauksen eri muotoja, mƤƤritelmiƤ, esimerkkejƤ ja milloin niitƤ kƤytetƤƤn.

 

1. MitƤ on jƤrjestelmƤn testaus? (mƤƤritelmƤ, esimerkkejƤ, milloin sovellamme sitƤ)

 

JƤrjestelmƤtestaus on ohjelmistotestauksen versio, jossa tarkastellaan ohjelmistotuotetta koko jƤrjestelmƤn yhteydessƤ.

TƤmƤ on erƤƤnlaista pƤƤstƤ pƤƤhƤn -testausta, koska se kattaa koko tuotteen; jƤrjestelmƤtestauksessa mennƤƤn kuitenkin pidemmƤlle ja selvitetƤƤn, miten tuote on liitƤnnƤisessƤ suhteessa kyseisen jƤrjestelmƤn muuhun laitteistoon ja laiteohjelmistoon.

JƤrjestelmƤtestauksessa esimerkiksi katsotaan, toimiiko ohjelma tietyssƤ jƤrjestelmƤssƤ, ja tutkitaan sen kƤyttƤmƤt resurssit.

Toteuta jƤrjestelmƤtestausta tuotekehityssyklin loppuvaiheessa, hieman ennen lopullisen tuotteen julkaisua.

KƤyttƤmƤllƤ tƤllaista pƤƤstƤ pƤƤhƤn -testausta ohjelmistosuunnittelijat varmistavat, ettƤ heidƤn ohjelmansa toimivat luotettavasti erilaisilla koneilla, ja voivat kƤyttƤƤ tuloksia optimointiprosessissa, jolloin ohjelma toimii entistƤkin tehokkaammin.

 

2. MitƤ on UAT-testaus? (mƤƤritelmƤ, esimerkkejƤ, milloin sovellamme sitƤ)

 

UAT-testaus on lyhenne sanoista User Acceptance Testing (kƤyttƤjƤn hyvƤksymistestaus), ja se on testauksen muoto, jota ei suorita kukaan kehitystiimistƤ vaan kohdeyleisƶn jƤsen.

LoppukƤyttƤjƤt voivat olla tƤysin vuorovaikutuksessa ohjelmiston kanssa ennen julkaisua, jolloin kehittƤjillƤ on aikaa ratkaista kƤyttƤjien havaitsemat ongelmat.

Yleisin esimerkki tƤstƤ on pelin ilmainen beta-testi ennen julkaisua, jossa kehittƤjƤt valitsevat tietyn yleisƶn palautetta varten.

Sovella tƤtƤ prosessia aivan kehitysprosessin lopussa. TƤmƤ on ensimmƤinen versio tuotteesta, jonka esittelet kenellekƤƤn yrityksen ulkopuoliselle, joten on tƤrkeƤƤ, ettƤ tuotteessa on mahdollisimman paljon toiminnallisuutta ja hiomista.

Ainoat asiat, jotka yrityksen pitƤisi pyrkiƤ suorittamaan UAT-testauksen jƤlkeen, ovat UAT-prosessin aikana ilmenneiden virheiden korjaaminen ja kƤyttƤjiltƤ saatuun palautteeseen vastaaminen.

 

3. MitƤ on toiminnallinen testaus? (mƤƤritelmƤ, esimerkkejƤ, milloin sovellamme sitƤ)

Toiminnallinen testaus on ohjelmistotestauksen muoto, jolla varmistetaan, ettƤ ohjelma tƤyttƤƤ kaikki projektin suunnittelun yhteydessƤ mƤƤritellyt perustoiminnot.

TƤmƤ tarkoittaa, ettƤ testejƤ varten annetaan asianmukaiset syƶtteet ja verrataan niitƤ tuloksiin, mikƤ osoittaa, ettƤ jƤrjestelmƤn ydintoiminnot ovat kunnossa.

EsimerkkinƤ tƤstƤ on shakkimoottorin tai vastaavan pelisƤƤnnƶn luominen ja sen varmistaminen, ettƤ se tuntee perussƤƤnnƶt ja toimii asianmukaisesti pelatessaan.

Suorita tƤmƤ testaus kehitysprosessin puolivƤlissƤ, kun uskot, ettƤ kaikki ohjelman perustoiminnot ovat valmiina.

TƤmƤ osoittaa, ettƤ sovelluksen ydinominaisuudet ovat toimivia ja ettƤ sinulla on hyvƤ perustaso suorituskyvylle ilman, ettƤ sinun tarvitsee mukauttaa backend-koodia, jolloin vain kƤyttƶliittymƤ ja muut esteettiset ominaisuudet jƤƤvƤt ratkaistaviksi.

 

4. MitƤ eroa on pƤƤstƤ pƤƤhƤn -testauksella ja jƤrjestelmƤtestauksella?

 

SiinƤ missƤ pƤƤstƤ pƤƤhƤn -testaus on vain ohjelmiston analyysi ja sen tehokkuus, jƤrjestelmƤtestaukseen kuuluu myƶs laitteiston arviointi, jossa se toimii, ja joidenkin laiteohjelmistojen, kuten kƤyttƶjƤrjestelmƤn, joiden kanssa se on vuorovaikutuksessa.

 

5. MitƤ eroa on End-to-End- ja UAT-testauksella?

 

Suurin ero E2E- ja UAT-testien vƤlillƤ on se, ettƤ UAT-testaus tapahtuu ulkoisen kƤyttƤjƤn kautta.

TƤmƤ tarkoittaa sitƤ, ettƤ sovellus on esittelykelpoinen ja ettƤ olet varma, ettƤ se tekee vaikutuksen kƤyttƤjƤƤn.

LisƤksi siinƤ missƤ E2E-testauksen voi suorittaa missƤ tahansa prosessin vaiheessa, UAT-testauksen voi suorittaa vasta, kun tuote on kƤytƤnnƶssƤ valmis paketoitavaksi ja lƤhetettƤvƤksi kƤyttƤjille, kun ohjelmistoon on tehtƤvƤ vain pieniƤ muutoksia.

 

6. MitƤ eroa on pƤƤstƤ pƤƤhƤn -testauksella ja toiminnallisella testauksella?

 

Vaikka E2E-testauksessa ja toiminnallisessa testauksessa testataan molemmissa ohjelmien toiminnallisuutta, ne ovat silti eri testausmuotoja muutamasta syystƤ.

EnsimmƤinen on se, ettƤ toiminnallisuuden testauksessa tarkastellaan yksinomaan sitƤ, onko ohjelma toiminnallinen, eikƤ niinkƤƤn ohjelman esteettisiƤ ja kƤyttƶliittymƤaspekteja.

Toiminnallinen testaus suoritetaan myƶs suhteellisen varhaisessa vaiheessa prosessia sen sijaan, ettƤ siitƤ olisi hyƶtyƤ tyƶnkulun jokaisessa vaiheessa.

 

7. PƤƤtelmƤt: E2E-testit vs. jƤrjestelmƤtestit vs. UAT-testit vs. toiminnallinen testaus.

 

Vaikka kaikki kolme testausmuotoa ovat samankaltaisia siinƤ mielessƤ, ettƤ ne varmistavat tuotteen toimivuuden, ne eroavat toisistaan merkittƤvƤllƤ tavalla.

NƤiden termien kƤyttƤminen vaihtelevasti voi johtaa huonoihin testauskƤytƤntƶihin ja laadunvarmistusprosessien sekoittumiseen keskenƤƤn, joten keskity nƤiden termien ja niiden oikean kƤytƶn opetteluun ennen kuin ryhdyt kƤyttƤmƤƤn niitƤ tyƶpaikalla.

 

Manuaaliset vai automatisoidut End-to-End-testit?

 

KehittƤjƤt voivat valita pari tapaa pƤƤstƤ pƤƤhƤn -testien suorittamiseen kƤytettƤvissƤ olevien resurssien ja henkilƶstƶn mukaan. TƤmƤ tarkoittaa muutosta manuaalisen pƤƤstƤ pƤƤhƤn -testauksen ja nƤiden testien automatisoinnin vƤlillƤ.

Tutustu sekƤ manuaalisen ettƤ automatisoidun pƤƤstƤ pƤƤhƤn -testauksen hyƶtyihin, haasteisiin ja prosesseihin:

 

1. Manuaalinen pƤƤstƤ pƤƤhƤn – testaus – hyƶdyt, haasteet, prosessi

 

Manuaalisessa pƤƤstƤ pƤƤhƤn -testauksessa on kyse siitƤ, ettƤ suoritat pƤƤstƤ pƤƤhƤn -testit itse ja osallistut jokaiseen testiin ”kƤsin” sen sijaan, ettƤ hankkisit automaattisen pƤƤstƤ pƤƤhƤn -tyƶkalun tekemƤƤn sen puolestasi.

Yritykset kƤyttƤvƤt yleensƤ erityistƤ testausryhmƤƤ manuaalisten e-to-e-prosessien loppuunsaattamiseen, sillƤ heillƤ on kokemusta ohjelmistojen testaamisesta ja he ymmƤrtƤvƤt, miten jƤrjestelmissƤ esiintyvƤt virheet ja viat kirjataan ylƶs.

Yksi tƤrkeimmistƤ eduista manuaalisessa pƤƤstƤ pƤƤhƤn -testausprosessissa on se, ettƤ nƤet itse kaikki mahdolliset ongelmat ja huomaat ohjelmistossa olevat puutteet, joita tietokone ei vƤlttƤmƤttƤ nƤe.

Prosessi voi kuitenkin olla suhteellisen hidas verrattuna testausprosessien automatisointiin.

NƤissƤ tapauksissa ihminen, esimerkiksi yksi kehittƤjistƤ, kƤy sovelluksen lƤpi ja tƤydentƤƤ kaikki toiminnot ja oppii nopeasti, mikƤ toimii ja mikƤ ei, kƤytettƤvissƤ olevasta ohjelmistopaketista.

TƤmƤ noudattaa suunnitteluprosessia, jossa testaaja valmistelee tietyn testisarjan ja oppii mittarit, joita hƤn pyrkii seuraamaan koko prosessin ajan tiukasti asetettujen tavoitteiden mukaisesti.

 

2. End-to-End-testiutomaatio – hyƶdyt, haasteet, prosessi

 

Testauksen automatisoinnilla tarkoitetaan prosessia, jossa E2E-testaus suoritetaan tietokoneohjelman avulla testien automatisoimiseksi. Suurin osa automatisoinnista tapahtuu erikoistuneilla pƤƤstƤ pƤƤhƤn -testaustyƶkaluilla, jotka on suunniteltu toimimaan tiettyjen koodauskielten ja ohjelmatyyppien kanssa.

Prosessissa on edelleen ihmisen osallistuminen, mutta vain koodauksen alkuvaiheessa ja lopullisessa analyysivaiheessa.

Yksi automatisoidun pƤƤstƤ pƤƤhƤn -testauksen tƤrkeimmistƤ eduista on se, ettƤ suuremmat sovellukset ja ohjelmat vaativat paljon perusteellisempaa arviointia ja analyysiƤ, kun yhƤ useammat toiminnot ja kƤyttƶliittymƤelementit tulevat osaksi tyƶnkulkua.

Automaattiset e-to-e-testit lƶytƤvƤt nƤmƤ pienemmƤt vaihtelut. Automaattisen testauksen haasteena on kuitenkin se, ettƤ ihmissilmƤ huomaa joitakin eroja, joita tietokone ei huomaa, mikƤ johtaa siihen, ettƤ automatisoidusta testauksesta jƤƤ joskus huomaamatta virheitƤ, joita ihmistestaajat eivƤt huomaa.

Kun haluat suorittaa automatisoidun testauksen loppuun asti, pƤƤtƤ testitapauksista ja kirjoita ne koodiksi ja integroi ne ohjelmistotestausvƤlineeseesi.

TƤmƤn jƤlkeen suorita testi ja vastaanota tulokset ja kƤytƤ tietoja sovelluksen mahdollisten parannusten tekemiseen.

Suorita kaikki testitapaukset mahdollisuuksien mukaan erikseen, sillƤ eri testitapauksissa etsitƤƤn eri asioita. Niiden suorittaminen itsenƤisesti vƤhentƤƤ mahdollisuutta, ettƤ testit hƤiritsevƤt toisiaan.

 

3. JohtopƤƤtƶkset: Testausautomaatio: Manuaalinen vai pƤƤstƤ pƤƤhƤn -testausautomaatio?

 

Se, onko manuaalinen testaus vai automatisointi ihanteellinen vaihtoehto, riippuu tƤysin kehitystiimin tarpeista.

PienemmƤt projektit voidaan testata perusteellisesti tiimin toimesta manuaalisesti, jolloin koodista etsitƤƤn kaikki virheet ja ne kirjataan vƤlittƶmƤsti muistiin.

PƤinvastoin, suuremmat projektit ovat yksinkertaisesti liian suuria manuaaliseen testaukseen ja vaativat paljon ohjelmistotestauksen automatisointia.

Mieti projektisi erityistarpeita ja mukauta sƤhkƶisen testauksen suunnitelmia sen mukaan, mitƤ saat selville testauksen laajuudesta.

Budjetti ei vƤlttƤmƤttƤ ole tekijƤ, sillƤ testiautomaatioista on useimmissa tapauksissa sekƤ ilmaisia ettƤ yritysversioita.

 

MitƤ tarvitset pƤƤstƤ pƤƤhƤn -testauksen suorittamiseen?

 

Ennen kuin aloitat pƤƤstƤ pƤƤhƤn -testauksen, tarvitset muutamia asioita riippumatta siitƤ, keskitytkƶ manuaaliseen menetelmƤƤn vai automatisoitko tyƶsi.

NƤihin kuuluvat:

 

1. Edustava laitteisto

 

Monilla kehittƤjillƤ on kƤytƶssƤƤn huippuluokan laitteisto, ja he kƤyttƤvƤt nykyaikaisia tietokoneita ohjelmistojensa kehittƤmisen vƤlineenƤ. TƤmƤ on ihanteellinen tiukkoihin testeihin ja ohjelmiston eri osien toimivuuden tarkistamiseen, mutta se ei edusta tarkasti loppukƤyttƤjƤn valitsemaa laitteistoa.

Hanki laitteisto, joka sopii paremmin keskivertokƤyttƤjƤn profiiliin, sillƤ saat tarkemman kuvan ongelmista, joita heillƤ on testaamasi ohjelman kanssa.

EsimerkkinƤ mainittakoon, ettƤ matkapuhelimen kƤyttƶ puhelinsovellusta varten on ihanteellista, ja teollisuus-PC:n kƤyttƶ valmistusohjelmistoa varten on ihanteellista.

 

2. Testausautomaatiotyƶkalut

 

Kun kƤytƤt testausautomaatiota, varmista, ettƤ sinulla on testausohjelmisto kƤytettƤvissƤsi heti e-to-e-testin alusta alkaen.

Valitse ohjelmisto huolellisesti, sillƤ sekƤ ilmaisilla ettƤ yritysversioilla on omat etunsa ja mahdolliset haittansa. Tutki kƤyttƤmƤƤsi ohjelmistoa ja tee joitakin harjoitusajoja, jotta voit vƤhentƤƤ testausalustaan sopeutumiseen kuluvaa aikaa.

Monet kokonaisvaltaiset ohjelmistopaketit tarjoavat perusteellisia oppaita tai asiantuntijoita, kuten ZAPTESTin testaustuki, ja jotkin asiantuntijat luovat opetusohjelmia YouTubeen ja muille vastaaville sivustoille, jotka tarjoavat lisƤtietoa.

 

3. YhtenƤinen suunnitelma

 

Yksi tƤrkeimmistƤ asioista, jotka on oltava hallussa, kun siirrytƤƤn testauksen alusta loppuun, on johdonmukainen testaussuunnitelma.

TƤmƤ on asiakirja, johon merkitƤƤn testaamasi ohjelmistoversio, ohjelmistolle tekemƤsi erityistestit, kƤyttƤmƤsi laitteisto ja kƤytƶssƤ oleva testausalusta.

MitƤ perusteellisempi dokumentointi on, sitƤ enemmƤn hyƶdyllistƤ tietoa saat suorittamistasi e to e -testeistƤ.

Jos organisaatiossasi kehitetƤƤn paljon ohjelmistoja, luo testaussuunnittelumalli ja kƤytƤ sitƤ jokaisessa testissƤ, jotta saat aikaan enemmƤn johdonmukaisuutta.

 

4. TƤydellinen ohjelmisto

 

Ohjelmistotestausprosessin lƤpikƤyminen edellyttƤƤ, ettƤ testausryhmƤ saa kƤyttƶƶnsƤ tƤydellisen ohjelmiston.

NƤissƤ tapauksissa on olennaisen tƤrkeƤƤ, ettƤ kƤytƶssƤ on ajantasaisin ohjelmistopaketti, sillƤ tuoreempi versio tarkoittaa, ettƤ kaikki havainnot ovat mahdollisimman edustavia lopulliseen julkaisuversioon verrattuna.

MitƤ lƤhempƤnƤ julkaisua ohjelmistopaketti on, sitƤ hyƶdyllisempiƤ tuloksia tiimi saa E2E-testauksesta.

KƤƤnnƤ uusin saatavilla oleva koodi juuri ennen testiƤ, jotta varmistat, ettet vahingossa tyƶskentele vanhalla versiolla.

 

Automaatiotestausprosessi pƤƤstƤ pƤƤhƤn

 

On olemassa yksityiskohtainen prosessi, jota on noudatettava, kun pƤƤstƤ pƤƤhƤn -testaus suoritetaan automatisoidusti:

 

1. Harkitse e-to-e-testitapauksia

 

Aloita miettimƤllƤ testitapauksia, joita tarkastelet pƤƤstƤ pƤƤhƤn -testauksessa.

Varhaisissa testeissƤ testitapauksiin kuuluu esimerkiksi sen varmistaminen, ettƤ toiminnallisuus on oikein, ja sen testaaminen, ettƤ kaikki ohjelmiston ominaisuudet toimivat ja tuottavat oikeat tuotokset.

Myƶhemmin prosessin aikana on otettava huomioon testitapaukset, kuten ohjelman tehokkuus ja nopeus, jolla se toimii.

Tasapainota testitapaukset projektin tarpeiden mukaan riippuen kehitysvaiheesta ja aiemmin suoritetun lopputestauksen mƤƤrƤstƤ.

 

2. Koodaa testitapaukset alusta loppuun

 

Kun olet pƤƤttƤnyt testitapaukset, koodaa testitapaukset kƤyttƤmƤƤsi testausohjelmistoon.

Ole varovainen koodatessasi testitapauksia alusta loppuun, sillƤ epƤtarkasti koodattu testitapaus ei vƤlttƤmƤttƤ testaa oikeaa asiaa tai se saattaa etsiƤ vƤƤrƤƤ mittaria prosessin lopussa.

TƤmƤ on yksinomaan osa automaatiotestausprosessia, sillƤ manuaalinen testaus koostuu yksinkertaisesti siitƤ, ettƤ testaaja arvioi ohjelman laatua ilman tietokoneen toimenpiteitƤ.

Suorita mahdollisuuksien mukaan yksi testi kerrallaan, jotta tulokset pysyvƤt yhdenmukaisina ja ilman hƤiriƶitƤ.

 

3. Suorita E2E-testit

 

Kun kaikki testit on koodattu testausohjelmistoon, suorita testit.

Suoritettavien testien luonteesta riippuen tƤhƤn voi kulua aikaa muutamasta minuutista muutamaan minuuttiin, ja eri tekijƶitƤ ovat muun muassa testattavan sovelluksen koko ja tehtƤvƤt testit.

Suurin osa E2E-testausautomaatio-ohjelmista ilmoittaa sinulle prosessin jƤljellƤ olevan ajan ja sen vaiheen, jossa prosessi on.

Manuaaliset testit vaativat enemmƤn aikaa ja vaivaa, kun testaaja kƤy lƤpi kaikki sovelluksen ominaisuudet ja prosessit.

 

4. Oppia tuloksista

 

Itse testin lopussa ohjelmoijat ja testaajat saavat joukon mittareita ja muita testiin liittyviƤ tietoja.

KƤytƤ nƤitƤ tietoja saadaksesi lisƤtietoa sovelluksestasi tai ohjelmastasi, kuten parannusta vaativista alueista ja erityisistƤ prosesseista, jotka vaativat enemmƤn rƤƤtƤlƶintiƤ, jotta ne toimisivat korkeampien standardien mukaisesti.

Testimittarit ovat arvokkaimpia tietoja, joita organisaatio saa, ja kƤyttƤmƤllƤ niitƤ oikein parannat lopputuotteen laatua merkittƤvƤsti. SƤilytƤ aiempien testien pitkƤaikaiset tiedot, jotta voit tehdƤ perusteellisemman vertailun versiosta toiseen.

 

Parhaat kƤytƤnnƶt pƤƤstƤ pƤƤhƤn -testaukseen

 

Parhaiden kƤytƤntƶjen noudattaminen millƤ tahansa alalla ja millƤ tahansa osaamisalueella on ensimmƤinen askel parempien tulosten varmistamiseksi.

Ohjelmistokehitysprosessin kokonaisvaltaisen testauksen parhaita kƤytƤntƶjƤ ovat muun muassa seuraavat:

 

1. MƤƤrittele testin kattavuus

 

Kun suoritat E2E-ohjelmistotestausta, mƤƤrittele testin kattavuus asianmukaisesti.

TƤhƤn sisƤltyy se, kuinka suuri osa sovelluksesta testataan ja mitƤ erityisiƤ mittareita testeistƤ etsitƤƤn.

Kun nƤmƤ tiedot mƤƤritellƤƤn selkeƤsti heti prosessin alussa, tiedƤt, mitƤ etsit koko prosessin ajan, ja tulokset ovat helposti tulkittavissa. ”DatahƤiriƶt”, kuten muista sovelluksista tai testeistƤ perƤisin olevat tiedot, poistetaan.

 

2. Keskity tehokkaisiin testeihin

 

Tehokkuus on olennainen osa testausta, sillƤ mitƤ enemmƤn resursseja kƤytƤt testausohjelmaan, sitƤ enemmƤn otat pois itse sovelluksesta.

TƤtƤ vastaan kannattaa keskittyƤ hyvin yksinkertaisten ja tehokkaiden testien asettamiseen.

Jos kukin testi kƤsittelee erillisiƤ ja suhteellisen pieniƤ parametreja, se vie vƤhemmƤn resursseja ja tarkoittaa sitƤ, ettƤ tulos on mahdollisimman tarkka, jolloin projektin lopussa saadaan enemmƤn hyƶdyllistƤ tietoa.

 

3. Luo yksinkertainen ilmoitussarja

 

Ilmoitussarjat ovat vƤlineitƤ, joita testaajat kƤyttƤvƤt saadakseen tietoa testeistƤ.

Kun luot ilmoitussarjaa, painota selkeyttƤ ja yksinkertaisuutta. Jos ymmƤrrƤt virhekoodit helposti, esimerkiksi luomalla koodin, jossa ilmoitetaan ongelman luonne ja missƤ kohtaa jƤrjestelmƤƤ ongelma on, parannat mahdollisuuksiasi lƶytƤƤ ongelmat ajoissa ja reagoida niihin tavalla, joka korjaa ohjelman mahdollisimman pian.

 

Lopputestauksen tulostyypit

 

Kun suoritat pƤƤstƤ pƤƤhƤn -testiƤ, voit etsiƤ useita erilaisia tuotoksia, joista jokainen tarjoaa ainutlaatuisen nƤkemyksen.

Joitakin tƤllaisia tulostyyppejƤ, joita kannattaa etsiƤ, ovat:

 

1. Tiedot

NƤin tapahtuu, kun testauksen lopputulos on yksinkertainen datamittari.

Tietoihin sisƤltyy aika, joka kuluu prosessin tarkan tuloksen, laskennan tuloksen tai jopa tietokannasta poimitun kuvan palauttamiseen.

 

2. TOTTA/VƄƄRIN

Jotkin E2E-testaukset tuottavat TRUE- tai FALSE-tulosteen, joka kertoo, ovatko parametrit tai ehdot totta vai epƤtotta prosessin lopussa.

TƤmƤ on hyƶdyllistƤ turvallisuusjƤrjestelmissƤ, sillƤ FALSE-palautus turvallisuusolosuhteissa voi laukaista hƤlytyksen.

 

3. Vikatilanteet

Yksi hyƶdyllinen tulostustyyppi on ajatus vikatilanteesta ja siitƤ, ovatko sovelluksen prosessit toimineet odotetulla tavalla.

NƤissƤ tapauksissa ohjelman suorittamisen jƤlkeen se ilmoittaa, onko se suorittanut prosessinsa loppuun vai ei, ja epƤonnistumistapauksissa nƤyttƶƶn tulee erityisiƤ virheilmoituksia ja -koodeja.

 

EsimerkkejƤ pƤƤstƤ pƤƤhƤn -testeistƤ

 

LoppupƤƤn testien ymmƤrtƤminen on paljon helpompaa, kun sinulla on joitakin esimerkkejƤ, sekƤ onnistuneita ettƤ epƤonnistuneita yrityksiƤ.

Seuraavassa on joitakin esimerkkejƤ kehittƤmisprosessiin kuuluvasta pƤƤstƤ pƤƤhƤn -testauksesta:

 

1. Manuaaliset pƤƤstƤ pƤƤhƤn -testit

ErƤs yritys on tuotekehityksensƤ loppuvaiheessa, ja se on luonut yksinkertaisen verkkotyƶkalun freelance-tulojen verojen laskemiseen.

Kehitystiimi kƤy lƤpi manuaalisen E2E-testausprosessin, jossa tarkistetaan, ettƤ ohjelma vastaa oikeilla arvoilla ja ettƤ kaikki kƤyttƶliittymƤn ominaisuudet toimivat kehittƤjien odotusten mukaisesti.

RyhmƤ havaitsee joitakin pieniƤ virheitƤ laskennassa ja reagoi niihin pƤivittƤmƤllƤ ohjelmaa ennen seuraavan testin suorittamista.

 

2. Automaattinen pƤƤstƤ pƤƤhƤn -testi

Yrityksen talouden laskemiseen tarkoitetun suuren verkkosovelluksen kehittƤjƤ on julkaisemassa tuotettaan ja kƤy sitƤ ennen lƤpi E2E-testausprosessin.

Tiimi koodaa testit automaattiseen testausalustaan, vastaanottaa tulokset ja kƤyttƤƤ mittareita toimivuuden ja tehokkuuden varmistamiseen.

Kun ohjelma on tehokas, testaajat siirtyvƤt parantamaan ohjelmiston suorituskykyƤ ja vƤhentƤmƤƤn resurssien kƤyttƶƤ ennen UAT-testausta.

 

3. Heikkolaatuinen pƤƤstƤ pƤƤhƤn -testaus

Yritys haluaa julkaista ohjelmistonsa mahdollisimman pian.

KehittƤjƤt kƤyvƤt sovelluksen lƤpi nopeasti ja tarkastelevat sen ominaisuuksia hyvin lyhyesti suunnittelematta etukƤteen koko sovelluksen kattavaa testausta.

Yritys ei huomaa joitakin ohjelmistoon liittyviƤ ongelmia, jotka asiakkaat havaitsevat tuotteen julkaisun jƤlkeen. Maineen menettƤminen on yksi tƤmƤn huonon testauksen suurimmista vaikutuksista, ja yritys on myƶs palauttanut joitakin ostoksia.

 

End-to-End-testauksessa havaitut virheet ja viatyypit

 

Virheiden ja vikojen havaitseminen on yksi ohjelmistokehityksen testausprosessin pƤƤtavoitteista, ja jotkin viat ja ongelmat ovat yleisiƤ, kuten:

 

1. Visuaaliset hƤiriƶt

 

Visuaalisia hƤiriƶitƤ esiintyy, kun ohjelma nƤyttƤƤ erilaiselta kuin kehittƤjƤt ovat tarkoittaneet.

Joitakin ongelmia ovat tƤssƤ tapauksessa esimerkiksi tekstuurit, jotka eivƤt lataudu virtuaaliympƤristƶihin, vƤƤristyneet tai vƤƤrƤn kokoiset kuvat ja teksti, joka ei nƤy kƤyttƶliittymƤssƤ.

Ohjelmisto, jossa on visuaalisia virheitƤ, voi olla vastenmielinen kuluttajille, jotka arvioivat ohjelmistoa ensi silmƤyksellƤ.

 

2. Toiminnan epƤonnistuminen

 

Toiminnallisuus on tapa, jolla ohjelmiston odotetaan kƤyttƤytyvƤn, ja epƤonnistunut toiminnallisuus tarkoittaa yksinkertaisesti sitƤ, ettƤ sovellus ei suorita odotettua tehtƤvƤƤnsƤ.

TƤmƤ voi tarkoittaa esimerkiksi sitƤ, ettƤ tekstiƤ ei tulosteta kunnolla, tietoja ei kerƤtƤ tietokannasta tai se toimii hitaammin kuin asiakas ja kehittƤjƤ odottavat.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

 

3. VirheenkƤsittelyn puutteet

 

VirheenkƤsittelyyn liittyvillƤ ongelmilla tarkoitetaan sitƤ, ettƤ ohjelmistossa on ongelma, mutta sen syytƤ ei voida mƤƤritellƤ. TƤmƤ on syynƤ ohjelmiston pitkiin ja monimutkaisiin virheilmoituksiin.

Suurin ongelma virheenkƤsittelyongelmissa on se, ettƤ kƤyttƤjƤ ei pysty mƤƤrittƤmƤƤn, mistƤ ongelma johtuu, eikƤ nƤin ollen pysty ratkaisemaan ongelmaa.

Virheiden kƤsittely on myƶs merkittƤvƤ ongelma kehittƤjille, sillƤ se on esteenƤ tehokkaalle virheiden korjaamiselle.

 

Yleiset lopputestauksen mittarit

 

Kun E2E-testausprosessi saatetaan pƤƤtƶkseen, yksinkertaiset mittarit on otettava kƤyttƶƶn, sillƤ ne tarjoavat vahvan perustan, jonka pohjalta voit vertailla sovelluksen eri iteraatioita.

EsimerkkejƤ pƤƤstƤ pƤƤhƤn -testauksen mittareista ovat:

 

1. Testin suoritusaika

TƤmƤ on aika, jonka automaattinen jƤrjestelmƤ tarvitsee kaikkien testien suorittamiseen. MitƤ nopeampi tƤmƤ aika on, sitƤ tehokkaampi ohjelmisto on.

Vertailemalla testien suoritusaikaa testien vƤlillƤ kehittƤjƤt voivat nƤhdƤ, ovatko he lisƤnneet ohjelmiston nopeutta tehokkaasti edellisestƤ iteraatiosta.

 

2. EpƤonnistumisten mƤƤrƤ

Jotkut kehittƤjƤt seuraavat epƤonnistumisten mƤƤrƤƤ versiosta toiseen. TƤmƤ on raakaluku, ja kun kehittƤjƤt nƤkevƤt summan pienenevƤn merkittƤvƤsti versiosta toiseen, he tietƤvƤt, ettƤ he ovat ratkaisemassa merkittƤviƤ ongelmia koodissa.

 

3. Vikaantumistiheys

VikatiheydellƤ tarkoitetaan vikojen mƤƤrƤƤ, kun otetaan huomioon koodin koko.

Jos esimerkiksi sovelluksen koodi kasvaa nelinkertaiseksi, mutta vikaantumisaste kasvaa vain 50 prosenttia, vikatiheys osoittaa, ettƤ kyseessƤ on pikemminkin parannus kuin sovelluksen ongelmien lisƤƤntyminen.

 

Parhaat ilmaiset End-to-End-testaustyƶkalut

 

Kun luot pƤƤstƤ pƤƤhƤn -testiƤ, voit aloittaa kƤyttƤmƤllƤ ilmaista tyƶkalua.

 

5 parasta ilmaista pƤƤstƤ pƤƤhƤn -automaattista testaustyƶkalua

 

Joitakin parhaita ilmaisia automatisoituja testaustyƶkaluja ovat:

 

1. ZAPTEST FREE Edition

ZAPTEST Free Edition on ZAPTEST-alustan versio, joka on kaikkien kƤyttƤjien kƤytettƤvissƤ ilman maksua.

Ilmaisversio keskittyy automatisointiin, jonka avulla voit suorittaa virheenkorjausharjoitukset Just-in-Time-aikataulun mukaisesti. E-to-e-testien suorittaminen tƤllƤ tavoin tukee erityisesti ketterƤƤ kehitystƤ kƤyttƤviƤ organisaatioita, koska se tukee huomattavasti nopeampia lƤpimenoaikoja.

 

2. Katalon

Avoimen lƤhdekoodin vaihtoehto, joka tarjoaa perusautomaatiotyƶkalut koodittomassa jƤrjestelmƤssƤ.

Helppo laajentaa, mutta vaatii joitakin laajennuksia ja lisƤominaisuuksia, jotka ovat maksumuurin takana, jotta ohjelmistosta saisi kaiken irti.

Toinen ongelma on, ettƤ se toimii hitaammin kuin jotkin vaihtoehdot, kuten Selenium.

 

3. Seleeni

Selenium on myƶs avoimen lƤhdekoodin alusta, joka toimii useilla eri koodauskielillƤ ja selaimilla, joten se on erittƤin joustava vaihtoehto.

Voi olla hieman liian monimutkainen kƤyttƤjille, jotka haluavat oppia lisƤƤ testiautomaatiosta. TƤmƤ ei myƶskƤƤn ole vain testausta varten, vaan se toimii yleisenƤ selaimen automatisointityƶkaluna.

 

4. Watir

Watir on erittƤin kevyt avoimen lƤhdekoodin testaustyƶkalu. Se on ihanteellinen hyvin pienten koodinpƤtkien testaamiseen, mutta koska se on riippuvainen manuaalisesta syƶtteestƤ, se on vaikeuksissa intensiivisempien tehtƤvien ja prosessien kanssa.

KƤytƤ Watiria manuaalisen E2E-testauksen tukena, mutta ei puhtaana automaatiotyƶkaluna.

 

5. Capybara

Capybara pyrkii jƤljittelemƤƤn kƤyttƤjƤn kƤyttƤytymistƤ ohjelmistojen kanssa tyƶskennellessƤƤn, mutta se toimii pƤƤasiassa verkkosovellusten kanssa, mikƤ tekee siitƤ hieman rajoitetumman kuin se on ihanteellinen tyƶkalu.

PienemmissƤ testeissƤ tƤmƤ voi olla hyvƤ ratkaisu, mutta itsenƤisissƤ ohjelmissa Capybara ei pysy kilpailijoiden perƤssƤ.

 

5 parasta yritystestaustyƶkalua End-to-End-testaukseen

 

Jos ilmainen pƤƤstƤ pƤƤhƤn -testaustyƶkalu ei riitƤ, koska sovelluksesi on liian suuri tai tyƶkalussa ei ole tarvitsemiasi toimintoja, vaihtoehtona on aina yritystyƶkalu.

Joitakin yritystason pƤƤstƤ pƤƤhƤn -testaustyƶkaluja, joiden kƤyttƶƤ voit harkita, ovat esimerkiksi:

 

1. ZAPTEST ENTERPRISE Edition

ZAPTESTin Enterprise Edition on perusteellisempi tyƶkalu kuin ilmainen versio, ja se tarjoaa ominaisuuksia, kuten rajoittamattomat lisenssit, koodittoman kƤyttƶliittymƤn, 1SCRIPT cross-platform, cross-device, cross Application -teknologian ja kokopƤivƤisen pƤƤsyn ZAP-sertifioituun asiantuntijaan, joka tyƶskentelee etƤnƤ asiakastiimin rinnalla, osana sitƤ.

Hinta-laatusuhteeltaan ja laadultaan tƤmƤ on tƤydellinen vaihtoehto ohjelmistojen testaamiseen alusta loppuun riippumatta siitƤ, onko sinulla jo kokemusta.

 

2. BugBug

BugBug on ketterille tiimeille suunniteltu selaintestaustyƶkalu, ja vaikka se on suhteellisen helppokƤyttƶinen, sen keskittyminen selaimiin ja ketterƤƤn kehitykseen ei auta sen joustavuutta.

Kun suuria ohjelmistoja kehitetƤƤn perinteisemmƤn prosessin mukaisesti, BugBug on vaikeuksissa ja soveltuu huonommin e-to-e-testaajaan.

 

3. Cypress

Cypress on laajalti arvostettu testaustyƶkalu, joka on suunniteltu kƤyttƶliittymƤtestaukseen, eli se ei tue backend-testausta, joka on vƤlttƤmƤtƶntƤ tehokkaille E2E-testeille.

Tyƶkalu on vahva kehityksen loppuvaiheessa, mutta sen kƤyttƤmƤttƶmyys toiminnallisuuden testauksessa tekee siitƤ suhteellisen heikon E2E-tyƶkalun.

 

4. Testigma

Avoimen lƤhdekoodin tyƶkalu, joka keskittyy tekoƤlytestien yllƤpitoon, ja pilvitallennus tarjoaa mahdollisesti tietoturvauhan jo ennestƤƤn korkeaan hintaan.

Melko toimiva, mutta siitƤ puuttuu ZAPTESTin kaltaisten yritysten tarjoama henkilƶkohtainen tuki.

 

5. Autify

Ihanteellinen aloittelijoille ja rinnakkaiseen testaukseen, mutta hinnoittelu pyynnƶstƤ voi aiheuttaa hƤmmennystƤ organisaation pitkƤn aikavƤlin suunnittelussa.

Hyƶdyllinen testauksen varhaisemmissa vaiheissa, mutta voi olla hankalaa joidenkin monimutkaisempien tehtƤvien kanssa, joita suoritat pƤƤstƤ pƤƤhƤn -testausprosessin aikana.

 

End-to-End-testauksen tarkistuslista

 

Kokonaisvaltaisen testauksen on oltava perusteellinen prosessi, minkƤ vuoksi monet tiimit kƤyttƤvƤt tarkistuslistaa varmistaakseen, ettƤ ne testaavat kaikki sovelluksen tƤrkeƤt osat.

E2E-testauksen tarkistuslistalle kannattaa lisƤtƤ muun muassa seuraavat asiat:

 

1. Toiminnallisuuden testaus

Testaa ohjelmiston toimivuutta yleisesti kƤyttƤjƤn nƤkƶkulmasta ja pistƤ merkille, miten toimivia toiminnot ovat ja mitkƤ ominaisuudet ovat ongelmallisia.

 

2. Suorituskyvyn testaus

Testaa ohjelmiston suorituskyky ja varmista, ettƤ se toimii tehokkaasti viemƤttƤ resursseja, mukaan lukien arvio siitƤ, kuinka kauan ohjelmistolla kestƤƤ suorittaa tehtƤviƤ, ja kuormitustestaus.

 

3. Tietojen testaus

Testaa sovelluksen tallennus ja varmista, ettƤ kaikki tiedot ovat turvassa ja jƤrjestetty oikealla tavalla ja ettƤ tietyt merkinnƤt ovat tarvittaessa helposti lƶydettƤvissƤ.

 

4. KƤytettƤvyystestaus

Testaa, ettƤ kƤyttƶliittymƤ on kƤyttƶkelpoinen ja ettƤ sen kanssa on jƤrkevƤƤ toimia sellaisen asiakkaan nƤkƶkulmasta, joka ei ole osallistunut suunnittelu- ja kehitysprosesseihin.

 

5. Turvallisuuden testaus

Testaa sovelluksen mahdolliset tietoturva-aukot tai -haavoittuvuudet sovelluksen suojaamiseksi kolmansilta osapuolilta tai mahdolliset aukot, joita koodipohjassa on jo nyt GDPR-standardien noudattamiseksi.

 

PƤƤtelmƤ

 

LoppupƤƤtelmƤnƤ voidaan todeta, ettƤ pƤƤstƤ pƤƤhƤn -testaaminen on uskomattoman perusteellinen tapa varmistaa, ettƤ ohjelma toimii odotetulla tavalla.

LoppupƤƤstƤ pƤƤhƤn -testaus on erittƤin joustava tyƶkalu, jonka kaikenkokoiset kehittƤjƤt voivat sisƤllyttƤƤ prosesseihinsa ja varmistaa, ettƤ loppukƤyttƤjƤlle toimitetaan laadukas tuote. TƤmƤ on erityisen hyƶdyllistƤ ennen julkaisua.

Mieti, minkƤ tyyppistƤ testausta kƤytƤt, manuaalista ja horisontaalista vai automaattista ja vertikaalista, mutta kaikkien kehittƤjien tulisi nƤhdƤ pƤƤstƤ pƤƤhƤn -testaus mahdollisuutena parantaa lopputuotteita.

 

Usein kysytyt kysymykset & resurssit

 

Koska pƤƤstƤ pƤƤhƤn -testaus on laaja kehitysalue, se voi herƤttƤƤ paljon kysymyksiƤ. Lue usein kysytyistƤ kysymyksistƤ lisƤƤ pƤƤstƤ pƤƤhƤn -testeistƤ ja siitƤ, miten voit parantaa testauksen laatua tulevaisuudessa.

 

1. Parhaat kurssit pƤƤstƤ pƤƤhƤn -testausautomaatiosta

 

Yksi parhaista tavoista parantaa lopputestauksen tasoa on osallistua kurssille. E2E-testausvalmiuksiaan parantamaan pyrkivien suosimiin kursseihin kuuluvat muun muassa seuraavat:

– End to End Testing Implementation Skillsoftilta, kurssi kestƤƤ vain reilun tunnin ja tarjoaa alustavan perustan oppimiselle.

– PluralSightin automatisoidun testauksen kurssi, joka opettaa kƤyttƤjille, miten testit suoritetaan automaation ja ohjelmistojen avulla.

– TestCafen E2E-verkkotestaus, lyhyt kurssi, joka kattaa testausprosessien automatisoinnin perusteet NodeJS:n avulla.

– Ohjelmistotestauksen ja automaation erikoistumiskoulutus Courserasta, joka kattaa useimmat ohjelmistotestauksen taidot ja osaamiset.

– Johdatus ohjelmistotestaukseen Courserasta, ihanteellinen kaikille, jotka ovat tƤysin uusia ohjelmistotestauksen alalla.

 

2. Parhaat kirjat End-to-End-testauksesta?

 

Jotkut haluavat kehittƤƤ taitojaan omaan tahtiinsa ja kƤydƤ lƤpi lukuprosessin sen sijaan, ettƤ suorittaisivat monimutkaisen kurssin osana E2E-testaustaitojensa kehittƤmistƤ.

Parhaita saatavilla olevia kirjoja ohjelmistojen E2E-testauksesta ovat muun muassa seuraavat:

– ”TƤydellinen opas testausautomaation kƤyttƶƶn”, Arnon Axelrod

– ”Ohjelmistotestauksen automatisointivihjeitƤ” by Gennadiy Alpaev

– Daniel Knottin ”Mobiilisovellusten testaaminen kƤytƤnnƶnlƤheisesti” (Hands-On Mobile App Testing)

– ”Tutkiva ohjelmistotestaus”, kirjoittanut James A. Whittaker

– ”KehittƤjien testaus: Alexander Tarlinder: Laadun rakentaminen ohjelmistoon

 

3. MitkƤ ovat 5 tƤrkeintƤ haastattelukysymystƤ End-to-End-testauksesta?

 

Kun haet tehtƤvƤƤ kehitysyhtiƶssƤ, monet rekrytointiryhmƤt kysyvƤt erityisesti E2E-testaukseen liittyviƤ kysymyksiƤ.

Joitakin tƤrkeimpiƤ haastattelukysymyksiƤ, joita hakijat saavat, ovat:

– Millaisia kokemuksia sinulla on E2E-testauksesta aktiivisessa tyƶympƤristƶssƤ ja mitƤ haasteita olet kohdannut prosessissa?

– Voitteko kertoa, mitƤ eroja UAT- ja E2E-testauksen vƤlillƤ on ja milloin kƤyttƤisitte kutakin testaustyyppiƤ kehityssyklin aikana?

– Miten automatisoitu E2E-testaaminen eroaa manuaalisesta E2E-testaamisesta ja miksi yritykset kƤyttƤvƤt nƤitƤ menetelmiƤ?

– Miten olet aiemmin ratkaissut ongelmia E2E-testauksen yhteydessƤ?

– MitƤ etuja E2E-testaus tarjoaa kehitystyƶssƤ ja miksi nƤmƤ edut ovat tƤrkeitƤ?

 

4. Parhaat YouTube-opetusohjelmat pƤƤstƤ pƤƤhƤn -testauksesta

 

YouTube on yksi parhaista paikoista oppia erilaisia taitoja, ja siellƤ on runsaasti YouTube-oppaita, joiden avulla kƤyttƤjƤt voivat kehittƤƤ taitojaan. Joitakin ihanteellisia YouTube-oppaita kaikille, jotka kehittƤvƤt E2E-testaustaitojaan, ovat esimerkiksi:

– ”Ohjelmistotestauksen opetusohjelma #28 – Ohjelmistotestauksen lopputestauksesta lopputestaukseen” by Software Testing Mentor

– ”Free End-To-End Complete Course On Manual Testing – July Batch 2022” by Suorituskyvyn testaus Basic ja Advanced

– ”Nyt on loppupƤƤn testauksen aika!” by Academind

 

5. Miten yllƤpitƤƤ End-to-End-testejƤ?

 

Loppuun asti ulottuvien testien yllƤpitƤminen tarkoittaa, ettƤ testausprotokollat ovat kƤynnissƤ koko kehitysprosessin ajan.

Yksi parhaista tavoista varmistaa, ettƤ testauksesi pysyy yllƤ, on suorittaa samat testit toistuvasti, jolloin varmistetaan suurempi johdonmukaisuus testistƤ toiseen.

Keskity tƤssƤ prosessissa myƶs yksinkertaisuuteen, sillƤ mitƤ yksinkertaisempia testit ovat, sitƤ helpompi tietoja on yllƤpitƤƤ ja sitƤ helpompi testit on toistaa tuleville tietokokonaisuuksille.

 

6. MitƤ on pƤƤstƤ pƤƤhƤn -testaus laadunvarmistuksessa?

 

End-to-end-testaus laadunvarmistuksessa viittaa E2E-testausprosessin rooliin laadunvarmistusprosesseissa. NƤissƤ tapauksissa prosessi on samanlainen, ja testaajat tutkivat koko sovelluksen tai ohjelman, mutta testauksen erityistavoitteet eroavat toisistaan.

NƤissƤ tapauksissa tavoitteena on varmistaa kƤyttƤjƤkokemuksen korkea laatutaso sen sijaan, ettƤ varmistettaisiin, ettƤ kaikki on mahdollisimman toimivaa ja tehokasta.

Laadunvarmistustestaus tapahtuu yleensƤ vasta kehitysprosessin pƤƤtyttyƤ.

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