Asiakaspuolen testaus

Asiakaspuolen testaus on kokeilua, jossa alkuperäinen sivu toimitetaan selaimeen ja JavaScript-kirjasto muokkaa sitä tuottaakseen variantin. Testaustyökalu päättää, minkä variantin kävijän tulisi nähdä, tekee vastaavat muutokset dokumenttiin ja tallentaa määrityksen. Koska muutokset tehdään selaimessa eikä sovelluksessa, testejä voidaan rakentaa ja käynnistää ilman sovelluskoodin käyttöönottoa, minkä vuoksi tämä lähestymistapa on hallitseva kaupallisissa optimointityökaluissa.

Nopeusetu on syy sen suosioon. Markkinointi- tai optimointitiimi voi rakentaa, varmistaa laadun ja käynnistää testin tunneissa visuaalisen editorin avulla ilman, että se aiheuttaa suunnittelujonoa. Ohjelmalle, jonka on suoritettava jatkuvasti teksti-, asettelu-, tarjous- ja visuaalisen hierarkian kokeita, tämä autonomia mahdollistaa mielekkään kokeilunopeuden. Useimmat organisaatiot, jotka rakentavat onnistuneen testaustavan, aloittavat tästä, koska vaihtoehto vaatii suunnitteluinvestointeja, joita on vaikea perustella ennen kuin käytäntö on osoittanut arvonsa.

Kompromissit on dokumentoitu yhtä hyvin. Muunnelmaa sovelletaan alkuperäisten renderöintien jälkeen, joten ellei testiskripti estä renderöintiä, kävijät näkevät kontrollin lyhyesti ennen muutoksen ilmestymistä. Tätä vikaa kutsutaan alkuperäisen sisällön välkkymiseksi tai välkkymiseksi. Renderöinnin estäminen välkkymisen estämiseksi lisää viivettä jokaiseen sivun latautumiseen, myös kontrolliryhmän kävijöille. Mainostenesto ja yksityisyyteen keskittyvät selainasetukset estävät skriptin suorittamisen osalle yleisöstä, eikä tämä osa ole satunnainen otos. Hitaat laitteet ja huonot yhteydet vahvistavat kaikkia näitä vaikutuksia, mikä vääristää systemaattisesti mobiilituloksia.

Asiakaspuolen testaus on myös rakenteellisesti rajoitettu siinä, mitä se voi muuttaa. Se voi järjestellä, muokata ja kirjoittaa uudelleen palvelimen jo tuottaman sisällön, mutta se ei voi muuttaa palvelimen laskemia tietoja. Hinnoittelusäännöt, haun relevanssi, varastotilanne, suosituslogiikka ja kaikki ennen vastauksen luomista arvioidut liiketoimintasäännöt ovat kaikki saavuttamattomissa. Yritykset simuloida tällaisia ​​muutoksia selaimessa tuottavat usein variantteja, jotka käyttäytyvät eri tavalla kuin todellinen ominaisuus käyttäytyisi, jos se rakennettaisiin. Tämä tarkoittaa, että testi vastaa kysymykseen mallista eikä ehdotuksesta.

Hyvien tulosten saaminen asiakaspuolen testauksesta riippuu siksi vahvasti toteutuksen laadusta. Testikokonaisuuden tulisi latautua synkronisesti dokumentin otsikkoon tiukalla aikakatkaisulla, vilkkumisenestomekanismi tulisi määrittää tarkoituksella eikä jättää oletusarvoiseksi, skriptin suorituskykyvaikutus tulisi mitata eikä olettaa, ja jokainen testi tulisi tarkistaa otossuhteiden epäsuhtaisuuden varalta, jotta voidaan havaita tapaukset, joissa skripti epäonnistui suhteettomasti yhdessä ryhmässä. Testien laatu tulisi myös varmistaa oikeilla laitteilla ja hitailla yhteyksillä, ei vain kehittäjän koneella.

Näiden testien laadunvarmistus vaatii tietyn rutiinin, koska variantti on olemassa vain suorituksen aikana sovellettavana muutoksena ja voi rikkoutua tavoilla, jotka ovat näkymättömiä editorissa. Tarkistuslista, joka havaitsee useimmat ongelmat, sisältää variantin tarkistamisen oikeilla laitteilla eri selaimissa, joita yleisö todellisuudessa käyttää, toiminnan tarkistamisen, kun sivu latautuu hitaasti ja kun testausskripti on estetty, sen varmistamisen, että muutos säilyy dynaamisissa sisällön päivityksissä ja yhden sivun navigoinnissa, testaamisen useilla näyttöalueen leveyksillä ja sen varmistamisen, että seuranta käynnistyy täsmälleen kerran asiaankuuluvaa tapahtumaa kohden molemmissa varianteissa. Testit tulisi myös tarkistaa sivuston omaa julkaisuaikataulua vasten, koska käyttöönotto, joka muuttaa pohjana olevaa merkintää, rikkoo huomaamattomasti siitä riippuvan variantin, jolloin syntyy ajanjakso, jonka aikana jotkut kävijät näkevät rikkinäisen sivun eikä kukaan saa ilmoitusta.

Rajoissa käytettynä asiakaspuolen testaus on edelleen useimpien optimointiohjelmien työjuhta. Tyypillinen muuntokurssin optimointi Engagement suorittaa suurimman osan kokeiluistaan ​​tällä tavalla, samalla kun se reitittää logiikkakerroksen kysymykset palvelinpuolen toteutukseen ja pitää testauspinon suorituskykykustannukset jatkuvasti tarkasteltuna osana verkkosuorituskyky toimi, koska testaustyökalu, joka hidastaa jokaista sivua kolmella sadalla millisekunnilla, voi helposti maksaa enemmän konversioita kuin sen mahdollistamat kokeet tuottavat takaisin.