stanford-oval/wikipedia huggingface dataset:
Ohjelmiston testaaminen
Testaustavat > Laatikkomalli > Fuzzing

Fuzzing tai fuzz testing on virheiden etsimisen menetelmä, jossa satunnaisilla syötteillä pyritään aiheuttamaan ohjelman kaatuminen, muistin vuotaminen tai tietoturvariskien tunnistaminen. Menetelmä sai alkunsa jo 50-luvulla kun ohjelmoijat testasivat reikäkorteilla toimivia tietokoneita syöttämällä niille sattumalla tuotettuja tai roskiksesta löytyneitä reikäkortteja ja seuraamalla aiheuttaako se ohjelmassa ongelmia. Mikäli jotain odottamatonta tapahtui oli bugi onnistuneesti tunnistettu. Menetelmä on periaatteeltaan mustan laatikon testaamista, mutta voidaan soveltaa myös kun lähdekoodit ovat saatavilla. Menetelmällä voi saada nopeasti yleiskuvan vikasietoisuudesta ja kriittisistä virheistä. Tehokas fuzzer on sellainen, joka tuottaa tarpeeksi valideja syötteitä, sillä jäsennin usein hylkää epävalidit syötteet heti. Syötteiden tulee kuitenkin olla sellaisia, että ne paljastavat virheitä mahdollisissa nurkkatapauksissa.
Menetelmä on peräisin vuodelta 1988 Wisconsinin yliopistosta. Fuzzing-tekniikat voidaan asettaa erilaisiin kategorioihin, kuten tuotanto- ja mutaatiopohjainen, onko fuzzer tyhmä vai älykäs ja onko se white-, grey- vai black-box testaamista riippuen onko lähdekoodi saatavilla. Mutaatiopohjainen fuzzing toimii muokkaamalla tai mutatoimalla olemassa olevia valideja syötteitä, kuten esimerkiksi syöttämällä ohjelmalle validi PNG tiedosto, jota aletaan mutatoimaan semivalideiksi syötteiksi. Tuotantopohjainen fuzzing taas tuottaa alkuperäisiä syötteitä, jotka voivat olla fiksuja eli käyttäjän syöttömallin mukaisia tai tyhmiä eli täysin sattumanvaraisia. Tämä toimii esimerkiksi flippaamalla sattumanvaraisia bittejä keskenään, vaihtamalla tavujen arvoja tai poistamalla tai siirtämällä datablokkeja. Näitä tekniikoita voidaan käyttää sekä yhdessä että erikseen.
Testaustavat > Integraatiotestaus

Integraatiotestaus on kaikentyyppistä testaamista, jossa pyritään todentamaan rajapintoja komponenttien ja ohjelmistosuunnittelun välillä. Ohjelmistokomponentit voivat olla integroitu iteratiivisesti tai kaikki yhdellä kertaa.
Testaustavat > Toiminnallinen ja ei-toiminnallinen testaus

Toiminnallinen ja ei-toiminnallinen testaus (engl. functional and non-functional testing) ovat yksi ohjelmistotestauksen perustyökaluja. Toiminnallisessa testauksessa testataan, että kyseisen ohjelman kaikki ominaisuudet ja toiminnot toimivat siten, kuin ne on vaatimusmäärittelyissä määritelty. On siis helpompi ajatella, että toiminnallinen testaus on yläkäsite, ja siihen kuuluukin mm. yksikkötestausta, API-testausta, integraatiotestausta, järjestelmätestausta sekä hyväksymistestausta. Toiminnallisessa testauksessa dokumentaation merkitys korostuu. Testejä suorittaessa esiintyy harvoin epäselvyyksiä asiakkaan ja toimittajan välillä siitä, että onko testiä tehty vai ei, sillä toiminnallisessa testauksessa testataan ohjelman/ohjelmiston ns. ”fyysisiä/olemassa olevia” ominaisuuksia, joista tehdään dokumentaatiota. Esimerkiksi tekstinkirjoituseditorin funktionaalisissa testeissä voitaisiin suorittaa yksikkötestejä tekstin fontin ja koon muuttamiselle. Järjestelmätestausta suorittaessa voitaisiin testata sitä, että pystyköö tiedostoja tallentamaan pilveen tai tulostamaan verkon kautta tulostimella.
Vastaavasti ei-toiminnallisessa testauksessa testataan ohjelman / ohjelmiston turvallisuutta, luotettavuutta, käytettävyyttä, viiveaikaa, suorituskykyä sekä skaalautuvuutta. Kyseisessä testauksessa keskitytään siihen, että millä tavoin ohjelmisto toimii ja miten se selviää erilaisissa ympäristöissä ja tilanteissa. Ei-toiminnallinen testaus on toiminnallisen testauksen tavoin ns. yläkäsite, jonka piiriin kuuluu mm dokumentaatiotestausta, suorituskykytestausta, luotettavuustestausta, käytettävyystestausta, skaalautuvuustestejä sekä penetraatiotestejä. Ei toiminnallisten testien suorittamisessa esiintyy ajoittain epäselvyyksiä asiakkaan ja toimittajan välillä siitä, että onko jokin testi tehty tarpeeksi hyvin tai kattavasti. Dokumentaation merkitys on suuri ja usein sen verukkeella pystytään perustelemaan riitatilanteissa, onko jokin testi tehty riittävällä kattavuudella vai ei. Esimerkki ei-funktionaalisesta testistä voisi olla sähköpostipalvelu, johon suoritetaan turvallisuustestejä. Turvallisuustesteissä voitaisiin testata sitä, että pystyykö toisen tilille kirjautumaan kepulikonstein tai estääkö sähköpostipalvelu selvät huijaus- ja virusviestit.
Testaustavat > Regressiotestaus

Regressiotestaus on kaikentyyppistä testaamista, jossa pyritään paljastamaan ohjelmistoregressioita. Regressio ilmenee, kun ohjelman toimiva osa lakkautetaan toimimasta tarkoituksellisesti. Tyypillisesti regressio tapahtuu tahattomasti ohjelmistoa muutettaessa, kun uudet osat törmäävät yhteen vanhojen kanssa. Tyypillisiä regressiotestauksen tapoja ovat ajaa vanhoja testejä läpi ja katsoa, ilmenevätkö jo korjatut virheet uudelleen.
Regressiotestaus on myös usein suurin askel kaupallisessa ohjelmistokehityksessä, sille se vaatii aiempien ohjelmistoversioiden monien yksityiskohtien tarkastusta. Uutta ohjelmistoa voidaan kehittää samanaikaisesti käyttäen joitakin vanhoja testitapauksia uusien suunnitteluosien testaamiseen varmistaaksemme, että aiemmat toiminnallisuudet säilyvät.
Testauksen intensiteetti vaihtelee julkaisu prosessin vaiheen ja lisättyjen ominaisuuksien riskien myötä. Testit voivat olla joko kattavia, erityisesti myöhään lisättyjen muutosten tai riskialttiiden ominaisuuksien osalta tai ne voivat olla hyvin pintapuolisia, sisältäen postitiivisa testejä jokaiselle ominaisuudelle, jos muutokset tehdään varhaisessa vaiheessa tai niitä pidetään lähes riskittöminä.
Testaustavat > Käytettävyystestaus

Käytettävyystestaus (engl. usability testing) on testausta, joka keskittyy arvioimaan ja mittaamaan käyttäjien kykyä käyttää ohjelmistoa tehokkaasti ja sujuvasti. Testausmenetelmällä pyritään varmistamaan, että käyttäjäkokemus (UX) on hyvällä tasolla ja että käyttäjät kykenevät suorittamaan haluamansa tehtävät ilman vaikeuksia. Käytettävyystestaus on olennainen osa käyttäjäkeskeisestä suunnittelua, sillä se auttaa löytämään ohjelmistosta käyttäjille mahdollisesti aiheutuvia ongelmia. Käytettävyystestaus ei ole automatisoitavissa oleva testausmenetelmä vaan siihen tarvitaan todellisia ihmiskäyttäjiä, joita valvovat joko kehitystiimi tai ammattitaitoiset suunnittelijat, ja jonka pohjalta tietoa kerätään ja analysoidaan. Käytettävyystestaus tarjoaa monia etuja, jotka voivat tehdä ohjelmiston kehittämisestä sujuvampaa ja tehokkaampaa.
Käytettävyystestaukseen kuuluu useita periaatteita ja käytäntöjä:
Kohdeyleisö. Testauksessa on tärkeä valita, kuka ohjelmistoa tulee käyttämään. Tämä auttaa määrittelemään tavoitteet, jotta voidaan varmistaa, että se vastaa todellisten käyttäjien tarpeita.
Testauskohde. Testauksessa on hyvä määrittää, mitkä osat ohjelmistosta tullaan testaamaan, ja mitkä tehtävät käyttäjille annetaan.
Testin tarkoitus. Testauksen toteuttamisen kannalta on tärkeä määrittää testin tarkoitus. Tämä antaa testaukselle tavoiteltavan lopputuloksen.
Testiympäristö. Testausta varten luodaan testiympäristö, jossa testit suoritetaan. Tämä voi olla joko fyysinen tai virtuaalinen ympäristö.
Datan keräys ja analysointi. Testauksen aikana kerätään dataa testaajien suorituksesta ja havaituista ongelmista. Tätä tietoa analysoidaan ja tulkitaan korjausten ja parannusehdotusten löytämiseksi.
Raportointi. Testauksen tulokset raportoidaan kehitystiimille. Raportti sisältää havainnot, suositukset ja korjaustoimenpiteet, joiden avulla tuotetta voidaan parantaa
Käytettävyystestaus on siis keskeinen osa ohjelmiston kehitysprosessia ja sen avulla voidaan varmistaa, että käyttäjien tarpeet ja odotukset täyttyvät. Tämä parantaa käyttäjäkokemusta, vähentää virheitä ja edistää ohjelmiston toimivuutta.
Testaustavat > Hyväksyttämistestaus

Hyväksyttämistestausta ovat:
Aloitustestaus. Sitä käytetään hyväksyttämistestauksena ohjelmiston uudelle versiolle ennen integraatio- ja regressiotestausta.
Asiakkaalla hyväksyttäminen. Toteutetaan asiakkaan omassa työympäristössä asiakkaan laitteistolla (UAT).
Hyväksymistestaus eli User acceptance testing (UAT) on yleensä testausprosessin viimeinen vaihe, ja se on edellytys ohjelman julkaisulle. Siinä asiakas on aina mukana, ja nimenomaan hän päättää onko ohjelma valmis käytettäväksi ja vastaako se heidän vaatimuksiaan. Hyväksymistestaamisessa asiakas itse testaa ohjelmaa, käyttää tuotetta sekä lukee dokumentaation läpi. Siksi olisi hyödyllistä, että ohjelman tilanneessa organisaatiossa olisi joku, kenellä on ymmärrystä ohjelmistotestaamisesta. Hyväksymistestaus voi vaihdella huomattavasti riippuen projektin luonteesta sekä loppuasiakkaiden tarpeista. Esimerkiksi sidosryhmien suuri määrä tai ohjelman toiminnan kriittisyys voivat tehdä hyväksymistestauksesta monimutkaisemman.
Hyväksymistestaamisessa ohjelman on tarkoitus olla valmis niin, ettei sitä enää muokata. Löydetyt kriittiset bugit tai muut virheet tietenkin korjataan, mutta ohjelmaan ei ole enää tarkoituksena lisätä esimerkiksi uusia ominaisuuksia. Riippuen mallista, jolla projektin on toteutettu, asiakkaalla voi olla hyvin erilaisia rooleja. Perinteisissä malleissa, kuten vesiputousmallissa, asiakas testaa ohjelmaa vasta hyväksymistestausvaiheessa. Ketterissä menetelmissä asiakas on kuitenkin paljon aktiivisemmin mukana projektissa, ja testaa ohjelmaa jo projektin aikana ennen kuin projekti on kokonaan valmis. Siksi ketterissä menetelmissä, kuten V-mallissa, on lähes oletuksena, että asiakas tulee hyväksymään ohjelman hyväksymistestauksessa. Kun asiakas lopulta on hyväksynyt tuotteen, se julkaistaan asiakkaan, ja kaikkien muiden ohjelman mahdollisten käyttäjien, käyttöön.
Testaustavat > Toimintaan liittymätön testaus

Ohjelmiston suorituskykyä testaamalla selvitetään, voiko ohjelmisto käsitellä suurta määrää tietoa tai käyttäjiä. Tätä kutsutaan usein ohjelmiston skaalautuvuudeksi.
Vakaustestaus testaa, toimiiko ohjelmisto normaalisti pitkiä aikoja. Sitä kutsutaan myös kestävyys- tai kuormitustestaamiseksi.
Käytettävyystestausta tarvitaan tarkastamaan, onko käyttöliittymä helppokäyttöinen ja helposti omaksuttavissa.
Turvallisuustestaus on olennainen ohjelmistolle, joka prosessoi luottamuksellista tietoa. Testaamisella estetään mahdollisia tietoturva-aukkoja.
Kansainvälistämis- ja lokalisointitestausta tarvitaan ohjelmiston osiin. Pseudolokalisointi-metodia voidaan käyttää tässä tapauksessa.
Testaustavat > Destruktiivinen testaus

Destruktiivinen testaus on ohjelmiston testaamisen menetelmä, jossa pyritään tarkoituksella aiheuttamaan vikoja tai toiminnallisia häiriöitä järjestelmään. Tavoitteena on selvittää, miten ohjelmisto reagoi äärimmäisiin tai epätyypillisiin tilanteisiin sekä arvioida sen suorituskykyä ja kestävyyttä. Tämäntyyppinen testaus auttaa kehittäjiä ja testaajia tunnistamaan mahdolliset heikkoudet, jotta ne voidaan korjata ennen ohjelmiston julkaisua.
Destruktiivisessa testauksessa voidaan käyttää erilaisia menetelmiä ja tekniikoita. Esimerkiksi ohjelmiston suorituskykyä voidaan testata kuormitustestien avulla, jossa ohjelmistoa altistetaan suurelle määrälle käyttäjiä tai tiedonkäsittelyyn. Lisäksi stressitestaus voi simuloida äärimmäisiä kuormitustilanteita, kuten suurta määrää samanaikaista käyttäjää tai suurta tietoliikennemäärää. Tavoitteena on selvittää, minkä kohdan järjestelmä pettää tai mihin resurssirajaan se pystyy vastaamaan.
Destruktiivisen testauksen avulla voidaan myös arvioida järjestelmän kestävyyttä äkillisille häiriötilanteille, kuten virheille tai vioille. Yleinen lähestymistapa on simuloituun ympäristöön vikoja tai väärinkäyttötarkoituksiin, jolloin voidaan tutkia, miten järjestelmä reagoi ja palautuu niistä. Tällainen testaus voi auttaa tunnistamaan haavoittuvuuksia ja kehittämään parempia turvallisuusratkaisuja.
Destruktiivinen testaus varmistaa, että ohjelmisto toimii kunnolla, jopa silloin kun se saa virheellisiä tai odottamattomia syötteitä. Tämä vahvistaa syötteiden tarkistuksen ja virheiden hallinnan toimivuutta. Ohjelmistoon kohdistuvien virheiden syöttäminen, esimerkiksi fuzz-testaus, on yksi esimerkki kyseisestä epäonnistumistestauksesta. Kaupallisia ei-toiminnallisen testauksen työkaluja, jotka liittyvät ohjelmistovikojen syöttämiseen, löytyy ohjelmistovirheiden lisäyksen nettisivuilta; lisäksi on olemassa monia ilmaisia ja avoimen lähdekoodin työkaluja, jotka suorittavat destruktiivista testausta.
Testaustavat > Virheen syöttäminen

Ohjelmistoa voidaan testata syöttämällä virhe (engl. fault injection), jolloin voidaan testata vikasietoisuutta harvoin ilmenevissä tilanteissa. Tietyissä standardeissa kuten IEC 61508 vaaditaan tämän tyyppistä testaamista vikatilanteiden käsittelyn testaamiseksi. Perinteisiä kohteita ovat olleet laitteistokomponentit kuten suorittimet ja muistit, joissa tilaa voidaan seurata ja ohjata tietyllä tavalla. Vikoja voidaan mallintaa myös syöttämällä vikoja suoraan ohjelmaan tai lähdekoodiin.
Testaustavat > Visuaalinen testaus

Visuaalisessa testauksessa kehittäjille näytetään, mitä ohjelmistovirheen sattuessa tarkalleen tapahtui. Data esitellään siinä muodossa, että kehittäjän on siitä helppo löytää ongelman korjaamiseen tarvitsemansa tieto.
Visuaalisen testauksen pääideana on se, että on selkeämpää näyttää mitä on tapahtunut, sen sijaan, että vain kuvailtaisiin ongelmaa. Tämä vähentää huomattavasti riskiä väärinymmärryksille. Täten visuaalinen testaus edellyttää sitä, että koko testausprosessi tallennetaan videomuodossa, josta käy ilmi kaikki testaussysteemissä tapahtuva. Video täydennetään testaajan reaaliaikaisella, testauksen aikana tapahtuvalla, kommentaariolla, johon sisältyy web-kamera kuva sekä äänitallenne.
Visuaalisella testauksella testauksella on useita etuja. Se parantaa kommunikaatiota huomattavasti, kun testaajat voivat näyttää ongelman ja siihen johtaneet tapahtumat testaajille suoraan, sen sijaan, että vain kuvailisivat sitä. Tämä myös usein tekee tarpeettomaksi toistaa virhe uudelleen kehittäjien toimesta, kun he voivat tarkastella sitä videomateriaalilta. Testaajat saavat käyttöönsä heti kaikki tarvitsemansa tiedot virheestä ja voivat keskittyä paikantamaan virheen syytä ja sitä kuinka sen voi korjata.
Testaustavat > Ad hoc -testaus

Ad hoc -testaus ja tutkiva testaus ovat tärkeitä metodeja ohjelman eheyttä testattaessa, koska niiden toteuttaminen ei vaadi niin paljoa valmistautumista, joten bugeja voidaan löytää nopeasti. Ad hoc -testauksessa, missä testaus tapahtuu improvisoidusti, testaajan kyky perustaa testaus dokumentoituihin menetelmiin ja sitten luoda näistä testeistä muunnelmia voi auttaa tekemään vikojen etsinnästä entistä tarkempaa. Yksi ad hoc -testauksen rajoitteista kuitenkin on, että ilman tarkkaa dokumentointia tehdyistä toimista, testejä on vaikea toistaa.
Ad hoc -testauksen huomattava etu on sen kyky antaa nopeita tuloksia ja auttaa kehittäjiä korjaamaan erilaisia vikoja nopeasti. Tämä tekee ad hoc-menetelmästä arvokkaan työkalun nopeissa ja ketterissä kehitysympäristöissä, joissa ohjelmistoon tulee muutoksia ja päivityksiä usein.
Kuitenkin ad hoc -testauksen yksi haasteista on se, että ilman järjestelmällistä ja asianmukaista dokumentointia sekä tarkkaa seurantaa on vaikea arvioida tekstien kattavuutta tai toistaa niitä. Tämän vuoksi, vaikka testaus tapahtuukin nopeasti ja joustavasti, on tärkeää dokumentoida bugit riittävän hyvin, jotta ne pystytään korjaamaan ja testaus voi jatkua kattavana ja toimivana jatkossakin.
Testaustavat > Paritestaus

Paritestauksella tarkoitetaan ohjelmistotestausta, jossa ohjelmistoa testataan kahden ihmisen toimesta. Testaus toteutetaan samalla laitteella operoiden, mikä mahdollistaa toisen testaajan testata ohjelmistoa ja toisen henkilön arvioida tai analysoida testausta. Testauksen voi toteuttaa usealla tavalla. Esimerkiksi siten,  että henkilöt ovat molemmat ohjelmistotestaajia ja vuorottelevat testaajan sekä testauksen arvioijan rooleissa.
Paritestauksen hyötyjä:
Yksilöhyödyt osallistuville henkilöille:
Kahdestaan työskentely parantaa molempien osallistuvien osapuolien ymmärrystä testaamisesta sekä testattavasta projektista. Esimerkiksi, jos toinen paritestaukseen osallistuu senioritason sekä junioritason testaaja, luo testausprosessi junioritason testaajalle kouluttamistilanteen, jossa junioritason testaajan rooli voi olla testaaja ja kouluttavan senioritason testaajan rooli on testauksen arvioija.
Projektikohtaiset hyödyt:
Kahden henkilön osallistuminen prosessiin tuo varmuutta, tehokkuutta sekä laatua. Paritestaus voi auttaa bugien etsimisessä sekä niiden korjaamisessa. Jaettu tieto työparin välillä mahdollistaa myös testauksessa edistymisen, vaikka toinen tiimistä ei olisi paikalla. Parityöskentely mahdollistaa myös kattavamman perehtymisen testattavaan projektiin testausprojektin alussa. Molemmat osapuolet voivat itsenäisesti tutustua projektiin ja sen jälkeen yhdistää tietonsa. Tämä tekee valmistautumisesta tehokkaampaa. Lisäksi työparin testausprojektissa syntyvä jaettu ymmärrys projektista parantaa testauksen laatua.
Testaustavat > Staattinen testaus

Staattinen testaus tarkoittaa ohjelmiston testausta sitä tai sen osia ajamatta. Testauksen aikana ohjelmistoa, koodia ja dokumentaatiota tarkastellaan suoraan lukemalla, analysoimalla ja silmäilemällä, eikä ohjelmiston toiminnan perusteella. Näin tämä eroaa dynaamisesta testauksessa jossa koodin ajaminen on välttämätöntä tuloksien saamiseksi. Staattinen testaus voidaan jakaa kahteen ryhmään: ohjelman katselmointi ja staattinen analyysi.
Ohjelman katselmointi sisältää lähdekoodin tarkastamisen lukemalla, lähdekoodin vertaamisen dokumentaatioon ja dokumentaation tarkastamisen. Katselmointi tehdään usein ryhmässä. Pelkän koodin tarkastamisessa kyse on usein siitä, että kehittäjät tarkastavat toistensa koodia ja antavat siitä palautetta. Virheiden lisäksi tällä tavalla voidaan löytää koodista mm. tyylivirheitä, "kuollutta koodia" ja huonoa optimointia.
Vertaamisessa tarkastetaan puutteet ja ristiriitaisuudet dokumentaation ja koodin välillä. Näin varmistetaan että koodi vastaa dokumentaation vaatimuksiin. Jos taas tarkastellaan pelkkää dokumentaatiota, halutaan varmistaa että dokumentaatio on laadukas ja kattava, eli asiaan perehtymätönkin saa yksityiskohtaisen ja selkeän kuvan ohjelmasta pelkästään dokumentaation lukemalla.
Staattisessa analysoinnissa taas käytetään analysointityökaluja, jotka pyrkivät löytämään koodista virheitä. Useat nykyaikaiset koodikielet ja -editorit tukevatkin staattista analyysia etenkin syntaksivirheiden osalta, mutta myös tyylivirheiden, kirjoitusvirheiden ja joidenkin bugien löytäminen on mahdollista staattisella analyysilla.
Kokonaisuudessaan staattinen testaus on hyvä tapa löytää kriittisiä virheitä, laatuvirheitä, puutteita ja ristiriitoja varhaisessa vaiheessa. Tällä tavalla voidaan vähentää dynaamisen testauksen tarvetta, joka vaatii enemmän resursseja ja aikaa kuin staattinen testaus.
Testaustavat > Esteettömyystestaus

Esteettömyystestausta suoritetaan, jotta saadaan varmistettua ohjelmiston saavutettavuus myös vammaisille henkilöille. Yleisiä saavutettavuuden testauksia ovat esimerkiksi:
fontin ja taustavärin välisen kontrastin on sopivuuden arviointi.
Fontin koon arviointi.
Kuva- ja äänisisältöjen mahdollinen korvaaminen tekstisisällöllä.
Ohjelmiston koeajo myös näppäimistön näppäimillä pelkän hiirellä käytön sijaan.
Testaustavat > Turvallisuustestaus

Tietoturvatestaus on välttämätöntä luottamuksellisia tietoja sisältäville ohjelmistoille järjestelmään tunkeutuvien hakkereiden estämiseksi.
Kansainvälinen standardointijärjestö (ISO) määrittelee tämän "testaukseksi, joka suoritetaan sen arvioimiseksi, missä määrin testikohde ja siihen liittyvät tiedot on suojattu siten, että asiattomat henkilöt tai järjestelmät eivät voi käyttää, lukea tai muokata niitä, ja valtuutetuilta henkilöiltä tai järjestelmiltä ei evätä pääsyä niihin."
Testaustavat > A/B testaus

A/B-testaus on menetelmä, jossa testataan ohjelmiston kahta eri versioita keskenään. Testin tavoitteena on kerätä dataa siitä, onko ohjelmistoon ehdotettu muutos tehokkaampi kuin nykyinen lähestymistapa. Asiakkaat reititetään joko ominaisuuden nykyiseen versioon tai muokattuun versioon, ja tietoja kerätään sen määrittämiseksi, kumpi versio on parempi saavuttamaan haluttu tulos. A/B-testausta voi voi suorittaa oikeastaan mille tahansa ohjelmiston ominaisuudelle, kunhan testauksen tulokset ovat mitattavissa.
Testiprosessi > Alpha-, Beta- ja Gammatestaus

Ohjelmistotestauksessa suoritetaan kolme vaihetta alfa, beeta ja gamma. Ne suoritetaan järjestyksessä (α → β → γ) ja pyrkivät varmistamaan laadukkaan ohjelmiston julkaisun.
Testiprosessi > Alpha-, Beta- ja Gammatestaus > Alpha-testaus

Alpha-testaus suoritetaan yrityksen sisäisen kehitys- tai laadunvarmistustiimin toimesta. Sen pääasiallinen tarkoitus on löytää ohjelmistovikoja. Alfa-testauksessa ohjelmiston toimintaa tarkastellaan todellisissa käyttöolosuhteissa jäljittelemällä loppukäyttäjien toimintaa.
Alfa-vaiheeseen sisältyy seuraavat testityypit:
Järkevyyden testaus(sanity test)
Integraatiotstaus
Järjestelmätestaus
Käytettävyystestaus
Käyttöliittymätestaus (UI)
Hyväksymistestaus
Regressiotestaus
Toiminnallinen testaus
Testiprosessi > Alpha-, Beta- ja Gammatestaus > Beta-testaus

Beta-testaus on ennen julkaisua tapahtuva testaus. Beta-testauksen päätarkoitus on varmistaa ohjelmiston yhteensopivuus erilaisten ohjelmisto- ja laitekonfiguraatioiden kanssa. Lisäksi käyttäjiltä saadaan palautetta ohjelmiston käytettävyydestä ja toiminnallisuudesta. Beta-testauksen aikana loppukäyttäjät havaitsevat ja raportoivat löytämänsä virheet. Kaikki testausaktiviteetit suoritetaan ohjelmiston kehittäneen organisaation ulkopuolella.
Beta-testauksessa on kaksi tyyppiä:
Avoin beta-versio, joka on saatavilla suurelle joukolle käyttäjiä
Suljettu beta-versio, joka on saatavilla vain valitulle ja rajatulle käyttäjäkunnalle
Testiprosessi > Alpha-, Beta- ja Gammatestaus > Gamma-testaus

Gamma-testaus on ohjelmiston julkaisua edeltävän testausprosessin viimeinen vaihe. Sen tarkoituksena on varmistaa, että tuote on valmis julkaistavaksi markkinoille, ja kaikki sille määritetyt vaatimukset toteutuvat. Gamma-testaus keskittyy ohjelmiston turvallisuuteen ja toiminnallisuuteen, mutta siihen ei sisälly mitään organisaation sisäisiä laadunvarmistustoimintoja. Gamma-testauksen aikana ohjelmistoon ei tehdä muutoksia, ellei havaittu virhe ole korkean prioriteetin ja/tai vakavuuden virhe. Gamma-testauksesta saatu palaute otetaan huomioon tulevien ohjelmistoversioiden päivityksissä. Kuitenkin rajoitetun kehityssyklin vuoksi gamma-testaus jätetään yleensä väliin.