Testaus ja julkaisu – verkkopalvelun ostajan opas 8/10

Testaus ja julkaisu ovat verkkopalveluprojektissa melkoisen usein melko triviaaleja ja yksinkertaisia työvaiheita, mikäli projekti on sujunut tähän pisteeseen saakka sovitun prosessin mukaisesti niin kommenttikierrosten, kuin sisällöntuotannon ja sen syöttämisen suhteen. Lisäksi on valmiiksi hyvä olla selvitettynä esimerkiksi mille palvelimelle verkkopalvelu asennetaan ja kuka vastaa domainin (www.esimerkki.fi) ohjaamisesta uudelle palvelimelle. Käyn tässä kirjoituksessa läpi, mitä testaus- ja julkaisutyövaiheisiin sisältyy. Voit kätevästi kurkata kootusta Ostajan Oppaastamme kaikki loputkin vaiheet.

Testaus ja julkaisu ovat jälleen kerran työvaiheita, joihin kuluu aikaa. Välillä olemme kuulleet ihmetystä siitä, että työvaiheiden yhteenlaskettu työmäärä esimerkiksi muutaman kymmenen päivän verkkopalveluprojektissa saattaa olla vaikkapa kaksi tai kolme henkilötyöpäivää. Maksaa siis 1600-2400,00€. Me kuitenkin haluamme julkaista asiakkaidemme verkkopalvelut toimivina ja luotettavina ilman, että törmätään julkaisun aikaisiin tai jälkeisiin korjaustoimenpiteisiin jotka aiheuttavat päänvaivaa sekä meille, että asiakkaallemme.

Testaus

Käyttöliittymän testaus

Käyttöliittymän testaus tarkoittaa sitä, että testaamme verkkosivuston ulkoasun toimivuuden ja vastaavuuden layout-suunnitelmiimme eri päätelaitteilla, näyttöleveyksillä ja selaimilla. Tarkoitus on, että verkkopalvelu toimii millä tahansa (ylläpitäjänsä kehityksen piirissä olevilla) päätelaitteilla ja selaimilla. Me testaamme:

• Natiiveilla päätelaitteilla: PC, Mac, iPad, iPhone, Android…
• Googlen Developer -työkaluilla, joilla voidaan simuloida verkkopalvelun toimivuutta eri päätelaitteilla ja käyttöjärjestelmillä
• BrowserStack-testauspalvelu, jolla voidaan simuloida verkkopalvelun toimivuutta eri selaimilla
• Googlen Lighthouse-audintointityökalut teknisen optimoinnin ja saavutettavuuden testaamiseen

Tyypillisesti käyttöliittymän lopullinen testaus on hyvä tehdä vasta siinä vaiheessa, kun verkkopalvelun todelliset sisällöt ovat syötettynä. Tämä siitä syystä, että voimme tehdä testausmuutosvaiheessa tarvittaessa vielä muutoksia koodin päässä esimerkiksi sisällön muuttuneisiin tai yllättäviin tarpeisiin. 

Lisäksi työvaiheessa varmistetaan verkkopalvelun saama arvostus hakukoneiden näkökulmasta. Lähes poikkeuksetta testauksessa ilmenee pieniä parantamista vaativia yksityiskohtia, jotka hoidetaan kuntoon ennen julkaisua, jotta muun muassa Google osaa rakastaa toteuttamamme verkkopalvelun pellin alta löytyviä ratkaisuja heti julkaisusta lähtien.

Toimenpiteitä verkkopalvelun tekniseen optimointiin ovat muun muassa:

• Cachen määritykset
• Tietoturvalaajennos
• SEO-laajennos
• Palvelinkutsujen gzip-pakkaus
• Lähdekoodien minifiointi
• Kuvatiedostojen ja -kokojen automaattisen optimoinnin asentaminen

Verkkosivuston testausprosessiin liittyy käyttöliittymän ja toiminnallisuuksien testaus, joista ensimmäiseen liittyy myös sisällöllinen sekä hakukoneoptimaalisuuteen liittyvä aspekti.

Toiminnallisuuksien testaus

Sivuston toiminnallisuuksia voivat olla esimerkiksi hakutoiminto tai maksamiseen liittyvä integraatio. Tai vaikkapa tuotesuodatus.

Toiminnallisuuksien suhteen testataan luonnollisesti niin toiminnallisuuden käyttöliittymä, kuin itse toimivuus. Kun kirjoitan hakukenttään ’’kissa’’, löytyykö sivustolta kaikki kissaan liittyvät aihealueet sisältötyyppeihin jaettuna? Kun teen testimaksun, meneekö se läpi, saanko automaattisen tilausvahvistuksen ja kulkeeko tieto testitilauksesta asiakkaan ERP-järjestelmään? Kun suodatan tuotehaussa vain kultakellot näkyville, tapahtuuko suodatus raketinnopeasti ja oikein? Ja tämä kaikki testataan eri selaimilla ja päätelaitteilla.

Toiminnallisuuksien testauksen tarkoitus on kaikessa yksinkertaisuudessaan se, että ennen julkaisua vielä varmistetaan, että kaikki toimii niin kuin pitää. Verkkopalveluprojektien ollessa esimerkiksi 70 henkilötyöpäivän ohjelmoinnin vaativia ohjelmistohankkeita, joissa on lukuisia toisiinsa vaikuttavia muuttujia, on testausprosessin oltava kunnossa, jotta julkaisun aikaisilta ongelmilta vältytään.

Tyypillisesti toiminnallisuuksien testaus tapahtuu kehittäjiemme toimesta käsipelillä, mutta myös yksikkötestausta (unit testing) ja muuta ohjelmallista testausta tehdään bisneskriittisissä ja monimutkaisimmissa toteutuksissa. Testaustarpeet siis arvioidaan yksilöllisesti.

Julkaisu

Pitäähän uusi verkkopalvelu saada käyttäjien käsille. Julkaisu jakautuu kolmeen vaiheeseen: 1) verkkopalvelun asennus live-palvelimelle, 2) domainin ohjaaminen live-palvelimelle ja 3) uudelleenohjaukset.

1. Meidän toimintamalliimme kuuluu se, että verkkopalvelun kehitys niin uudistuksen kuin julkaisun jälkeisen ylläpidon aikana tapahtuu kehityspalvelimella, esimerkiksi osoitteessa esimerkkidomainstaging.demo.fi. Julkaisun ensimmäinen vaihe on siis se, että palvelu kopioidaan kehityspalvelimelta varsinaiselle palvelimelle.
2. Kun palvelu on onnistuneesti asennettu myös live-palvelimelle, on syytä ohjata verkkopalvelun kävijäliikenne sinne. Tämä työvaihe pitää siis sisällään sen, että toimittaja (meidän hankkeissa me) ohjeistaa domainin ylläpitäjätahoa (nimipalveluntarjoaja) ohjaamaan domainin (esimerkki.fi) liikenteen vanhan palvelimen (eli missä vanha verkkosivusto sijaitsi) sijaan uudelle, meidän pystyttämälle palvelimelle, jossa uusi komeus sijaitsee. Tämän muutoksen jälkeen esimerkki.fi on siis julki, käy ja kukkuu.
3. Uudelleenohjaukset ovat hakukonelöydättävyyden kannalta kriittisen tärkeä toimenpidekokonaisuus. Tässä työvaiheessa verkkopalvelulle kerrotaan, mihin uuden verkkopalvelun sivuille entisen verkkopalvelun osoitteista eli sivuista ohjataan. Alla taulukko konkretisoimaan tätä:

Koska verkkopalvelumaailma on mielenkiintoinen, kannattaa toimittajan aina varautua olemaan ’’passissa’’ vahtimassa, että domain- ja uudelleenohjaukset menevät nappiin ja verkkopalvelussa on kaikki kunnossa myös julkaisun jälkeen. Täten suositeltu julkaisuajankohta ei ole perjantai-iltapäivä, vaan mieluummin maanantai. Vaikka julkaisu olisikin valmisteltu parhaalla mahdollisella tavalla.  

Yhteenveto

Ja noin – verkkosivusto tai -kauppa on testattu ja julkaistu onnistuneesti. Kuten alussa kirjailin, ei tämä työvaihe ole kovinkaan haastava. Haastavan siitä tekee potentiaalinen huolimattomuus testauksessa, selvitysten myöhästyminen esim. palveliasioiden suhteen tai kommunikaatiokatkokset vastuissa julkaisun aikaan. Vältä näitä sudenkuoppia, niin julkaisu sujuu kuin tammenlehvillä.

Tsemppiä!

Terveisin

Jani