Minulta usein kysytään mihin kehitykseen varattu aika tarkemmin käytetään. Verkkokehitykseen kuuluu monta työvaihetta koodauksen lisäksi ennen kuin muutokset voidaan julkaista. Itse asiassa varsinainen koodaaminen voi olla vain puolet työstä, kun koko ketju halutaan hoitaa ammattimaisesti. Asiakkaan näkökulmasta käytäntömme tarkoittavat vähemmän virheitä ja siis tehokkaampaa työskentelyä molemmin puolin. Tässä kirjoituksessa avaan laadunvarmistuksen vaiheita työnkulussamme.
Lyhyesti termeistä
Tuotantoympäristö on käytössä oleva –yleensä julkinen– versio palvelusta.
Kehitysympäristö on rinnakkaisversio jota käytetään muutosten testaamiseen, esittelyyn ja tarkastukseen. Kehitysversio on joskus piilotettu salasanan taakse.
Lokaali ympäristö taas on ainoastaan kehittäjän omalla työkoneellaan pyörivä versio palvelusta, ns. työversio.
Laadunvarmistuksen vaiheet
1 Code Review
Ensimmäinen selkeästi erillinen laadunvarmistusvaihe on koodin tarkistus eli code review. Työn toteuttaja siirtää työnsä versionhallintaan nimetylle tarkastajalle, joka on kokenut Agendan webbikehittäjä. Tarkastaja käy läpi tiedostoihin tehdyt muutokset ja arvioi ne mm. tietoturvan, selkeyden ja yleisen toimivuuden osalta. Näin koodista tulee sekä turvallisempaa, toimintavarmempaa että paremmin jatkokehitettävää. Tyypillisesti muutokset voi lukea suoraan versionhallinnasta, mutta joskus tarkastaja voi haluta kopioida koodin itselleen lokaalisti tarkastusta varten. Kun tarkastaja antaa vihreää valoa, voi toteuttaja siirtää muutoksensa kehitysympäristöön.
Koodintarkistuksessa tarkastetaan muun muassa:
- voisiko ratkaisu olla yksinkertaisempi
- escapetus, eli datan muuntaminen turvalliseen muotoon, jottei siitä aiheudu virhetilanteita tai tietoturvauhkia
- ovatko muuttujat ja funktiot selkeästi nimettyjä ja koodi riittävästi kommentoitu
- ettei koodissa ole turhia kommentteja tai käyttämättömiä muuttujia
2 UX-review
Toinen laadunvarmistusvaihe on ux review eli käyttökokemuksen tarkastus. Tarkastaja riippuu toteutuksen laajuudesta: Jos muutokset koskevat käyttöliittymää on tarkastaja tyypillisesti web designer tai suunnittelija, mutta pienen tai puhtaasti toiminnallisen muutoksen voi hyvin tarkastaa myös kehittäjä tai projektipäällikkö. Pääasia on että toinen ihminen toteaa että muutos toimii myös oikeassa palvelinympäristössä kuten sen on tarkoitettu. Joskus muutosten testausten laajuuteen on kuuluttava esimerkiksi verkkokaupan asiakaspolku. Tärkeää on huomioida myös eri selainleveydet (eli että muutos toimii sekä desktopissa että mobiilina). Kieliversiointi on tärkeää muistaa, sillä usein muutokset vaativat uusien käännöksien lisäämistä. Tämä on myös se vaihe jossa visuaalisia detaljeja kuten välistyksiä voidaan hienosäätää. Kun tarkastaja hyväksyy muutokset, on aika koota julkaisupaketti jotta voidaan asiakasta pyytää tarkastamaan työ.
Käyttökokemuksen osalta tarkastetaan muun muassa:
- Toimiiko kohde sujuvasti ja kuten asiakas on määritellyt
- Miten kohde käyttäytyy selainikkunan koon muutoksissa ja mobiilikäytössä
- Toimiiko ratkaisu myös eri kieliversioissa
- Onko visuaalinen viimeistely tehty hyvin
3 Client review
Kolmantena laadunvarmistuksen vaiheena pyydämme asiakasta tarkastamaan työn kehitysympäristössä. Tätä varten yksittäiset sisäisen tarkastuksen läpäisseet, julkaisuun tarkoitetut työt (eli issuet) kootaan yhdeksi julkaisupaketiksi. Julkaisupaketti on käytännössä erillinen oksa versionhallinnassa, joka ”jäädytetään” niin etteivät mahdolliset muut muutokset projektiin sekoita pakkaa suunnitellun julkaisun osalta. Julkaisupaketin mukainen versio päivitetään kehitysympäristöön, ja asiakkaalle lähetetään pyyntö tarkastaa julkaistavat muutokset. Näin asiakas näkee omin silmin työn lopputuloksen ja voi vahvistaa että se toimii kuten on tarkoitettu. Toisaalta joskus tässä vaiheessa tajutaan asiakkaan kanssa että asia täytyykin ratkaista jotenkin eri tavalla. Mahdolliset muutokset tehdään julkaisupakettiin. Kun työ on hyväksytty, voidaan julkaisun ajankohta sopia.
Julkaisu
Systemaattisen huolellisuuden tueksi käytämme ennalta valmisteltua issue-pohjaa, jossa julkaisun eri vaiheet ja tarkastukset ovat näppärä ”checklist” raksittavaksi sitä myötä kun julkaisu etenee. Tällaisia tärkeitä tarkastettavia ja muistettavia asioita ovat mm. palvelun tai yksittäisten toimintojen sulkeminen ja varmuuskopiointi. Varsinaisen julkaisun jälkeen täydennetään olennainen dokumentaatio (kuten muutosloki ja versionumerointi). Selkeä dokumentaatio luo jatkuvuutta, helpottaa jatkokehitystä ja ehkäisee virheitä. Julkaisussa (kuten myös itse työn aikana) hyödynnetään regressiotestausta, eli automaattista visuaalista testaustyökalua.
Lopuksi
Pyrimme jatkuvasti kehittämään käytäntöjämme ja osaamistamme, jotta voimme palvella asiakkaitamme entistä paremmin. Asiantuntijatyössä on tärkeää jatkuvasti hakea oikeaa balanssia ennalta määriteltyjen prosessien ja asiantuntijan toiminnan vapauden väliltä. Samalla täytyy pysyä hereillä käytäntöjen kuormittavuuden kanssa, jotta fokus pysyy itse tuottavassa työssä eli ohjelmistokehitykselle. Prosessit ja dokumentaatio ovat lopulta vain tukimuotoja, vaikkakin tärkeitä sellaisia. Haluamme asiakkaidemme voivan luottaa siihen että meille osoitetut toimeksiannot on aina tehty laadukkaasti ja luotettavasti.
Otamme mielellämme vastaan kysymyksiä ja ideoita, esimerkiksi sähköpostiin info@agendadigital.fi
