9 ohjelmistotestauksen tyyppiä ohjelmistokehityksessä

Ohjelmistotestaus on käsityötä. Ohjelmistotestaajan, kuten käsityöläisen, tulee tuntea käytössään olevat ohjelmistotestaustyökalut perusteellisesti. Olemme koonneet luettelon yhdeksästä erilaisesta ohjelmistotestauksen tyypistä sekä kunkin tyypin käyttämistä työkaluista auttaaksemme laadunvarmistusanalyytikkoja ja kaikkia muita ohjelmistotestausalalla työskenteleviä ymmärtämään työtään paremmin.

Miksi tarvitsemme ohjelmistotestausta?

Joskus on tärkeää muistaa, miksi tekemällämme työllä on merkitystä. Yksinkertainen tosiasia on, että jokainen menestynyt ohjelmisto on kehitetty ohjelmistotestaajien avulla. He ovat työskennelleet väsymättä varmistaakseen, että tuote täyttää mahdollisimman korkeat laatustandardit. Tässä on kolme syytä, miksi ohjelmistotestauksella on merkitystä. 

1. Asiakastyytyväisyys: Projektia kehitettäessä voi olla helppo eksyä koodin syövereihin ja unohtaa, että käyttäjän on oltava tyytyväinen myös siihen, miten ohjelmisto toimii. Laadunvarmistusanalyytikot ja muut laadunvarmistuksen jäsenet huolehtivat tästä tehtävästä. 
2. Tuotteen laatu: Jokaisessa ammatissa, jossa tiimi tai yksittäinen henkilö luo jotain alusta alkaen, tarvitaan toinen tiimi havaitsemaan tehdyt virheet. Kirjoittajat tarvitsevat toimittajia. Myös elokuvaohjaajat tarvitsevat toimittajia. Ohjelmistokehittäjät eivät tarvitse toimittajia, mutta he tarvitsevat laadunvarmistustiimin tarjoamaan objektiivisen näkökulman ja havaitsemaan mahdolliset virheet. 
3. Tietoturva: Jokaisen päivän myötä tämä seikka vaikuttaa yhä tärkeämmältä. Asiakkaat haluavat mielenrauhan tietäessään, että ohjelmistoon syöttämänsä tiedot ja siinä tekemänsä työ pysyvät yksityisinä. Osa laadunvarmistuksesta on varmistaa, että asiakkaat voivat luottaa tähän. 

Ohjelmistotestauksen menetelmät

Jokainen tässä artikkelissa mainittu ohjelmistotestaustekniikka kuuluu jompaankumpaan kahdesta pääluokasta: staattiseen testaukseen tai dynaamiseen testaukseen. Ennen kuin tarkastelemme yhdeksän eri ohjelmistotestaustekniikan yksityiskohtia, selitän näiden kahden menetelmän eron ja sen, missä kohtaa ohjelmistokehityksen elinkaarta niitä käytetään. 

Staattinen testaus

Staattinen testaus on ohjelmistotestauksen tyyppi, joka suoritetaan varhaisessa vaiheessa kehityksen elinkaarta. Se on kustannustehokas tapa löytää virheet ennen kuin niistä tulee merkittäviä ongelmia kehitystiimille. Staattiset testit suoritetaan varhaisessa vaiheessa kehityksen elinkaarta, koska ne voidaan tehdä ilman täysin toimivaa ohjelmistoa. Aivan oikein: ohjelmiston virheenkorjaus voidaan tehdä jo ennen kuin se on lähelläkään valmis. Näetkö, miten tästä voi olla hyötyä? 

Staattiset testit suoritetaan kahdella tavalla:

• Manuaaliset tarkastukset: Laadunvarmistusanalyytikko tai testaaja analysoi koodin. 
• Automaattinen analyysi: Testaustyökalu tarkistaa ohjelmadokumentin automaattisesti ja merkitsee mahdolliset virheet.

Staattiselle testaukselle on ominaista:

• Se suoritetaan ilman koodin suorittamista.
• Se on kustannustehokasta.
• Se auttaa varmistamaan, että ohjelmisto täyttää varmennusmääritykset.
• Se auttaa määrittämään virheiden perimmäisen syyn.

Useimmat staattiset testit suoritetaan asiakirjojen tarkastuksina. Tässä tilanteessa asiakirja on joko tuotteen kirjallinen kuvaus (jota kutsutaan ohjelmiston suunnitteluasiakirjaksi) tai ohjelman lähdekoodi. Tässä on joitakin staattisen testauksen tekniikoita, jotka jokaisen laadunvarmistusanalyytikon tulisi tuntea:

• Epämuodollinen katselmointi:  Epämuodolliselle katselmoinnille ei ole tiukkoja ohjeita. Tiimi käy testiasiakirjat läpi ja kommentoi näkemäänsä. Dokumentaatiota ei laadita.
• Yhteisläpilukeminen: Koodin laatija käy asiakirjansa läpi, ja laadunvarmistustiimi esittää kysymyksiä ja tuo esiin huolenaiheita. Yhteisläpilukemiset ovat yleensä hyvin epämuodollisia ja hyvä tapa keskustella aiheista ohjelmistoalan ulkopuolisten ihmisten kanssa. 
• Tekninen katselmointi: Tekniset asiantuntijat kokoontuvat tarkastelemaan koodin teknisiä määrityksiä. Kun tämä tehdään varhaisessa vaiheessa kehitysprosessia, varmistetaan, että lopputuote täyttää vaaditut määritykset.
• Tarkastukset: Kaikista katselmoinneista muodollisin. Koulutettujen moderaattorien tiimi tarkastaa asiakirjat perusteellisesti kokouksen aikana. Kaikki löydetyt virheet dokumentoidaan ja kirjataan virallisesti tarkastelua varten. Myöhemmin tarkistetaan, että dokumentoituihin virheisiin on puututtu. 

Useimmissa tapauksissa staattisten testien katselmoinnit ovat hyödyllisiä, koska koko laadunvarmistustiimi analysoi tuotteen ja ehdottaa muutoksia havaitsemiensa ongelmien ja ennakoitavien ongelmien perusteella. Sen lisäksi, että keskusteluun saadaan mukaan monenlaisia näkemyksiä, tämä auttaa kaikkia tiimin jäseniä pysymään ajan tasalla projektin edistymisestä ja suunnittelusta. 

Käytä staattista testausta, jos tiimisi:

• On kehitysprosessin alkuvaiheessa.
• Etsii kustannustehokasta tapaa löytää virheitä.
• Työskentelee ohjelmiston parissa, joka ei ole vielä valmis suoritettavaksi.
• Haluaa havaita virheet varhaisessa kehitysvaiheessa.

Dynaaminen testaus

Toisin kuin staattinen testaus, dynaaminen testaus on ohjelmistotestauksen tyyppi, joka edellyttää koodin suorittamista. Tämä edellyttää luonnollisesti, että kehitys on edennyt pidemmälle tuotantosyklissä. Suoritettavan koodin testaamisen etuna on, että laadunvarmistusanalyytikot voivat tarkastella ohjelmiston toimintaa sen ollessa käynnissä todellisessa käyttötilanteessa. Se on erinomainen tapa tarkistaa ohjelmiston toiminnallinen käyttäytyminen sekä esimerkiksi suorittimen käyttö. Dynaamisessa testauksessa tarkistetaan, vastaako odotettu lopputulos todellista lopputulosta. Dynaamisen testauksen päätavoitteena on varmistaa, että tuote täyttää ennen projektin aloittamista määritellyt suunnittelu- ja toiminnalliset vaatimukset.

Järjestelmäohjelmistoa dynaamisesti testattaessa on yleensä mukana neljä vaihetta, jotka laadunvarmistusanalyytikkojen tulisi tuntea:

• Yksikkötestaus: Kun ohjelmistoa testataan yksikkötasolla, se jaetaan mahdollisimman pieniin osiin, jotka testataan erikseen. Tällä tavalla testaamalla laadunvarmistusanalyytikot voivat olla varmoja siitä, että ohjelmiston jokainen yksittäinen osa toimii tarkoitetulla tavalla. Jos virhe löytyy, se on helpompi korjata tässä kehitysvaiheessa, koska ongelman aiheuttava koodi voidaan eristää nopeasti. Yleensä kun laadunvarmistustiimi aloittaa dynaamisen testauksen (vaikka tämän vaiheen hoitaakin joskus kehitystiimi), se aloittaa yksikkötesteillä.
• Integraatiotestaus: Kun ohjelmisto on jaettu perusteellisesti osiin ja testattu yksikkötestauksella, osat kootaan ryhmiksi ja testataan uudelleen. Jos yksikkötestauksella varmistetaan, että jokainen yksittäinen osa toimii oikein, integraatiotestauksella varmistetaan, että osat kommunikoivat keskenään odotetulla tavalla. Ajattele tätä auton kokoamisena. Kokoamisen jokaisessa vaiheessa auton osat (moottori, polkimet ja ohjauspyörä) testataan erikseen. Sen jälkeen auto kootaan ja testataan kokonaisuutena, jotta varmistetaan, että kaasupoljin toimii oikein yhdessä moottorin kanssa (ja että myös jarrut toimivat!). Haluatko varmistaa moduulien saumattoman yhteensopivuuden? Suosittelemamme ohjelmistotestaustyökalut voivat auttaa siinä.
• Järjestelmätestaus: Järjestelmätestaus on ohjelmistotestauksen kolmas taso. Tässä vaiheessa testataan valmis ja täysin integroitu ohjelmisto. Järjestelmätestin tarkoituksena on varmistaa, että ohjelmisto täyttää vaatimukset eli tekee sen, mitä varten se suunniteltiin. 
• Hyväksymistestaus: Dynaamisen testauksen viimeinen vaihe. Hyväksymistestissä testataan jälleen vaatimusten mukaisuus ja varmistetaan, että ohjelmisto on viimeistelty hyväksyttävälle tasolle. Sen avulla varmistetaan, etteivät virheet ole päässeet läpi testauksen muista vaiheista. Pohjimmiltaan kyse on uudelleentarkistuksesta turvallisuuden varmistamiseksi. 

Dynaamisen testauksen vaiheet

1. Yksikkötestaus
2. Integraatiotestaus
3. Järjestelmätestaus
4. Hyväksymistestaus
   

Vinkki: verifiointi- ja validointitestaus 

Verifiointitestauksella on kaikki staattisen testauksen keskeiset ominaisuudet. Verifiointitestin tarkoituksena on varmistaa kaikkien asiakirjojen ja koodin oikeellisuus, ja se toteutetaan samoilla menetelmillä kuin staattinen testaus.

Vastaavasti validointitestauksella on kaikki dynaamisen testauksen keskeiset ominaisuudet. Validointitestauksessa keskitytään sen varmistamiseen, että ohjelmisto on korkealaatuinen, mikä on myös järjestelmä- ja hyväksymistestien tavoite.

Nyt kun olemme käsitelleet joitakin ohjelmistotestaukseen liittyviä keskeisiä käsitteitä, tutustutaan yhdeksään ohjelmistotestauksen tyyppiin, jotka jokaisen laadunvarmistusanalyytikon tulisi tuntea.

9 ohjelmistotestauksen tyyppiä, jotka jokaisen laadunvarmistusanalyytikon tulisi tuntea:

1. Musta laatikko
2. Valkoinen laatikko
3. Harmaa laatikko 
4. Automatisoitu testaus 
5. Yksikkötestaus
6. Regressiotestaus
7. Tutkiva testaus
8. Toiminnallinen testaus
9. Käytettävyystestaus

1. Mustan laatikon testaus

Mustan laatikon testaus on ohjelmistotestausstrategia, jossa testaaja ei tunne testattavan ohjelmistojärjestelmän rakennetta.

Muistatko kohtauksen Pulp Fiction -elokuvan lopussa, kun Samuel Jackson avaa salkun ja hänen kasvonsa valaistuvat? Katsojina tiedämme, mitä salkku tarkoittaa ja edustaa elokuvan kontekstissa, mutta emme koskaan saa tietää, mitä sen sisällä on. Mustan laatikon testaaja on katsojan kaltainen: hän tietää, mitä asian (olipa kyseessä salkku tai järjestelmäohjelmisto) pitäisi tehdä, mutta ei sitä, mistä se koostuu.

Ajanseurantaohjelmiston mustan laatikon testauksesta vastaava testaaja avaa ohjelman tuntematta ohjelmiston sisäistä rakennetta ja kokeilee eri ominaisuuksia ja valikoita varmistaakseen, että ne toimivat odotetulla tavalla. Mustan laatikon testauksen tarkoituksena on, että ilman ohjelmiston rakenteen yksityiskohtaista tuntemusta testaaja lähestyy ohjelmistoa samankaltaisin odotuksin kuin loppukäyttäjä. 

Mustan laatikon testauksen hyötyjä ovat:

• Testaajilta ei vaadita paljon ohjelmointikielten tuntemusta, koska testaaja käyttää ohjelmistoa käyttäjän näkökulmasta.
• Tarjoaa ohjelmistosta puolueettoman arvion, koska ohjelmistotestin suorittaa QA-tiimi ohjelmistokehittäjien sijaan.
• Testaajien ei tarvitse olla perehtyneitä ohjelmistojärjestelmän kehitykseen, joten testien suorittamiseen tarvitaan hyvin vähän valmisteluaikaa.

Aiheeseen liittyvää luettavaa: 10 parasta mustan laatikon testauksen työkalua

2. Valkoisen laatikon testaus

Valkoisen laatikon testauksessa QA-tiimin jäsen tuntee täysin testattavan ohjelmiston sisäisen rakenteen ja suunnittelun. Hän lähestyy testiä tarkastajan tavoin ja varmistaa, että ohjelman jokainen osa toimii asianmukaisesti. Valkoisen laatikon testauksesta käytetään joskus nimitystä läpinäkyvän laatikon testaus, koska testaaja tarkkailee yksiköiden välisiä vuorovaikutuksia testatessaan ohjelmistoa. Toisin kuin mustan laatikon testauksessa, valkoisen laatikon testaaja ei ole läheskään yhtä huolissaan käyttökokemuksesta. 

Valkoisen laatikon testauksen hyötyjä ovat:

• Testejä voidaan suorittaa jo kehityksen varhaisissa vaiheissa. Graafisen käyttöliittymän (GUI) ei tarvitse olla täysin toimiva. 
• Testit ovat perusteellisempia ja harkitumpia kuin mustan laatikon testit.

Pulp Fiction -esimerkissä valkoisen laatikon testaaja on Tim Rothin esittämä hahmo, joka katsoo suoraan salkun sisällä olevaa sisältöä. 

3. Harmaan laatikon testaus

Harmaan laatikon testauksessa testaaja tuntee jonkin verran ohjelmiston sisäistä rakennetta ja suunnittelua (valkoinen laatikko), mutta testaa silti loppukäyttäjän näkökulmasta (musta laatikko). Näin harmaan laatikon testaus sai alkunsa. Harmaan laatikon testauksessa testi suunnitellaan tarkastelemalla ohjelmiston sisäistä rakennetta, mutta varsinainen testi suoritetaan käyttöliittymän avulla.

Jälleen kerran, jos kyseessä olisi kuuluisa Pulp Fiction -kohtaus, harmaan laatikon testaaja ei olisi yleisö eikä Tim Roth. Tällä kertaa testaaja olisi Quentin Tarintino itse.  

4. Automaattinen testaus

Automaattiset testit käyttävät ohjelmistoa tehtävien suorittamiseen ilman testaajan manuaalisia ohjeita.

Manuaalisessa testauksessa testaaja kirjoittaa suoritettavan koodin tai suunnittelee ohjelmiston toimintapolun, jonka hän haluaa tarkistaa toimivaksi. Automaattiset testit huolehtivat tällaisista asioista testaajien puolesta. Tässä on lyhyt luettelo automaattisista ohjelmisto- ja QA-työkaluista, jotka QA-analyytikoiden tulisi tuntea:

• Selenium 
• Cucumber
• Katalon Studio

Jos haluat perehtyä automaattisen testauksen työkaluihin perusteellisemmin, tutustu luetteloon parhaista automaattisen testauksen työkaluista, joita sinun tulisi käyttää.

5. Yksikkötestaus

Yksikkötestaustyökalut varmistavat, että ohjelmiston jokainen yksittäinen osa toimii asianmukaisesti. On erittäin tärkeää varmistaa, että yksikkötestaus tehdään oikein, sillä muuten kehitystiimi kärsii suuresta takaiskusta, kun myöhemmin huomataan, ettei jokin ohjelmiston keskeinen osa toimi. 

6. Regressiotestaus

Regressiotestaustyökalut suorittavat vanhat testit uusilla koontiversioilla varmistaakseen, että ohjelmisto toimii edelleen tarkoitetulla tavalla. Regressiotestien suorittaminen suojaa kehittäjiä piileviltä vaikutuksilta varmistamalla, ettei ohjelmistoon kohdassa A tehty muutos vahingossa rikkonut jotain kohdassa D. 

QA-analyytikon näkökulmasta kahta askelta eteenpäin ja yhtä taaksepäin ei pitäisi pitää kielteisenä asiana. Ottamalla silloin tällöin yhden askeleen taaksepäin varmistat, ettet joudu myöhemmin ottamaan viittäkymmentä askelta taaksepäin.

7. Tutkiva testaus

Tutkiva testaus sopii ihmisille, jotka eivät pidä suunnittelusta. Useimmissa muissa tilanteissa testitapaus suunnitellaan perusteellisesti ennen sen suorittamista. Ei kuitenkaan tässä tapauksessa. Kun testaaja suorittaa tutkivaa testiä, hän tutkii ohjelmistoa ilman ennalta määriteltyä suunnitelmaa käyttäen erityisiä tutkivan testauksen työkaluja.

Tutkivan testauksen etuna on, että testaaja voi mukautua havaintoihinsa lennossa ilman, että hänen tarvitsee kirjoittaa uutta testitapausta. Tutkiva testaus mahdollistaa myös yhteistyön ja teorioiden kehittämisen lennossa.

Kun ketterä kehitysteoria on yleistynyt, myös tutkiva testaus on yleistynyt. Kun QA-testaajat voivat käyttää intuitiotaan, havaitaan monia kiinnostavia virheitä, joita perinteisessä testien suorituksessa ei välttämättä olisi etsitty. 

Varoitus: tutkiva testaus voi vaatia paljon luovuutta. 

8. Toiminnallinen testaus

Toiminnallinen testaus suoritetaan sen varmistamiseksi, että järjestelmäohjelmisto vastaa projektin vaatimuksia, jotka määriteltiin ennen kehityksen aloittamista.

Ohjelmistotestaaja tarkistaa, vastaavatko syötetyt arvot odotettua tulosta. Testaus suoritetaan yhdessä testauksen viimeisistä vaiheista joko järjestelmätestauksen tai hyväksymistestauksen aikana, ja se on yksinomaan mustan laatikon testausta, koska siinä ei olla kiinnostuneita siitä, miten ohjelmisto toimii, kunhan se toimii. 

9. Käytettävyystestaus

Käytettävyystestaajat varmistavat, että suunnitteluratkaisut ovat toimivia ja samalla intuitiivisia.

Jos ennustat, että monet ohjelmistosi käyttäjät haluavat varmuuskopioida asiakirjansa puolen tunnin välein, varmuuskopiointitoiminto kannattaa sijoittaa helposti saatavilla olevaan paikkaan sen sijaan, että se olisi piilotettu neljän alivalikon taakse. 

Monissa tapauksissa on kehitetty ohjelmisto, joka toimii moitteettomasti ja täyttää tärkeän tarpeen markkinoilla, mutta jota on käyttäjän näkökulmasta täysin mahdotonta käyttää. Tämä voi johtua käytettävyystestauksen puutteesta ohjelmiston testausvaiheessa.

Loppujen lopuksi, riippumatta siitä, kuinka hyvä ohjelmisto on teknisesti, sille on vaikea löytää markkinoita, jos käyttäjät eivät nauti sen käyttämisestä.

Haluatko lisää?

Ohjelmistotestausala muuttuu jatkuvasti, ja QA-analyytikkojen on pysyttävä ajan tasalla nykyisistä trendeistä. Ohjelmistotestauksesta on loputtomasti resursseja, kuten podcasteja, kirjoja, uutiskirjeitä ja paljon muuta.

Tilaa The CTO Clubin uutiskirje saadaksesi tuotepäivityksiä, työkaluarvosteluja ja lisää resurssikoosteita.