Näin valmistaudun julkaisuihini ja testaan niitä

Julkaisut ja julkaisujen hallinta ovat olennainen osa työtämme. Oikean tuotteen julkaiseminen asiakkaille tekee heidät tyytyväisiksi. Sujuva julkaisu tekee meidät, julkaisuun osallistuvat ihmiset, tyytyväisiksi. 

Miten voimme saavuttaa sujuvan julkaisun? 

Olen osallistunut lukuisiin julkaisuihin, ja voin sanoa, että onnistuneen julkaisujen hallinnan saavuttamista tukevat muutamat keskeiset seikat. 

Kerron, mitä ne ovat.

Onnistunut julkaisu alkaa kehityksen aikana.

Testitapausten tunnistaminen

Hyvä julkaisujen hallinta alkaa kauan ennen julkaisupäivää, jo silloin kun julkaistava ominaisuus on kehitysvaiheessa. Tänä aikana ominaisuuden on saatava laadunvarmistuksen hyväksyntä. Tämä tarkoittaa, että meidän on testattava kaikki mahdolliset mieleemme tulevat ja kyseisen ominaisuuden kannalta järkevät skenaariot, jotta voimme varmistaa ominaisuuden toimivan vaatimusten mukaisesti. Osa näistä skenaarioista testataan automaattisilla testeillä, kun taas joidenkin kohdalla automaation luominen on joko liian vaikeaa tai ei ole vaivan arvoista. 

Kun tunnistamme, millaista testausta kyseiselle ominaisuudelle on tehtävä, meidän tulisi ottaa huomioon seuraavat asiat: kun tämä ominaisuus viedään ensimmäisen kerran tuotantoon, meidän on testattava se perusteellisesti. Meidän on varmistettava, etteivät asiakkaat löydä kriittisiä ongelmia. Meidän on validoitava vaatimukset. Lisäksi meidän on varmistettava ominaisuuden hyvä suorituskyky. 

Testauksen viivästykset ja ongelmat voivat vaikuttaa vakavasti aikatauluihin ohjelmistojulkaisuja valmisteltaessa. Tehokkaiden julkaisujen hallinnan käytäntöjen käyttöönotto auttaa varmistamaan, että testaus ja käyttöönotto pysyvät luotettavina ja ennakoitavina.

Kun ominaisuus on kuitenkin otettu käyttöön, sitä ei tarvitse testata yhtä perusteellisesti jokaisen saman koodikannan tulevan julkaisun yhteydessä, ellei siihen tarvita päivityksiä. Ominaisuuden toiminta muuttuu vain, jos sen taustalla olevaa koodia on muutettu tai jos jossakin sen käyttämistä riippuvuuksista on tapahtunut ulkoinen muutos. Muuna aikana ominaisuuden perustason testaus riittää; siihen sisältyvät luonnollisesti tärkeimmät testitapaukset. 

Tästä huolimatta varmista ominaisuuden ollessa kehitysvaiheessa, että arvioit seuraavat asiat: kuinka monta testitapausta sinun on testattava; kuinka paljon aikaa sinulla on käytettävissä testaukseen; mitkä testitapaukset ovat kriittisiä; mitkä testitapaukset suoritat jokaisen julkaisun yhteydessä.

Näin voit tunnistaa, mitkä testitapaukset automatisoit. Keskity siihen, että vähintään kriittinen toiminnallisuus on automaation kattama. Muita testejä varten sinun tulisi luoda kirjalliset testitapaukset joko projektinseurantajärjestelmään (esimerkiksi Jira) tai käyttämääsi testienhallintatyökaluun. Näin ne eivät katoa tai unohdu, ja ne voidaan suorittaa aina, kun julkaisu sitä edellyttää.

Testien suorittaminen CI:ssä

Kun automaattiset testit ovat käytössä, sinun tulisi alkaa suorittaa niitä CI:n kautta kehitysympäristöissä säännöllisesti. Koska muita ominaisuuksia kehitetään ennen julkaisua, on hyvä varmistaa, että julkaistava ominaisuus toimii edelleen oikein, erityisesti jos se on jo hyväksytty sprintin aikana. Kiinnostavan ominaisuuden testien suorittaminen esimerkiksi päivittäin antaa nopeasti palautetta ominaisuuteen tarvittavista korjauksista, jotka johtuvat järjestelmän muista muutoksista.

Julkaistavan ominaisuuden mahdollisten virheiden varhainen havaitseminen antaa runsaasti aikaa korjausten tekemiseen ja ominaisuuden uudelleentestaamiseen ilman, että tämä joudutaan tekemään julkaisuvaiheeseen käytettävissä olevan rajallisen ajan aiheuttamassa paineessa. Mitä kattavammin vaatimukset on huomioitu automaattisissa testeissä, sitä todennäköisempää on, että julkaisuvaiheessa löydetään vain pieni määrä virheitä.

Esituotanto on tärkeää, ja siihen tulisi sisältyä varoaika.

Aikataulut 

Julkaisuvaiheeseen kuuluu yleensä tuotantoon julkaisemiseen varatun päivän tai ajanjakson lisäksi esituotannon integraatioympäristössä testaamiseen varattu ajanjakso. Julkaisuun osallistuvana testaajana varmistan aina, että pyydän julkaisulle asianmukaiset aikaikkunat siten, että esituotantovaihe antaa minulle mahdollisuuden testata julkaistavat ominaisuudet asianmukaisesti. 

Otan aina huomioon myös varoajan, koska odotan julkaisujen hallinnan prosessin aikana ilmenevän ennalta arvaamattomia ongelmia, olivatpa ne julkaistavien ominaisuuksien virheitä tai ulkoisia tekijöitä. Mainitakseni yhden tällaisen tekijän, esituotantoympäristöt ovat testiympäristöjä, eivätkä ne välttämättä ole niin luotettavia kuin niiden pitäisi olla. Usein ne toimivat joko hyvin hitaasti tai muuttuvat hetkeksi käyttökelvottomiksi juuri julkaisun testauksen aikana. 

Lisäpuskuriajan varaaminen on aina hyvä idea, ja vaikka et käyttäisi tuota ylimääräistä aikaa, se ei haittaa. Voit antaa hyväksyntäsi ennen varatun testausajan päättymistä, sillä voit käyttää jäljellä olevan ajan jonkin muun asian parissa työskentelyyn. On pahempaa, jos puskuriaikaa ei ole ja sitä tarvitaan, sillä silloin kaikki tarvittava testaus on jotenkin mahdutettava lyhyempään aikaan. Tämä voi johtaa siihen, että joitakin testitapauksia ei suoriteta, mikä puolestaan saattaa johtaa siihen, että jotkin virheet paljastuvat vasta suoraan tuotannossa.

Laajuus

Toinen tärkeä esituotantoversion näkökulma on mielestäni omistautuneen julkaisunhallinnan koordinaattorin nimeäminen. Minulle tämä tarkoittaa henkilöä, joka huolehtii tietyistä osa-alueista. Ensimmäinen niistä on julkaisun laajuuden tarkistaminen. Ennen minkä tahansa version testaamisen aloittamista testaajan on tiedettävä, mitä testataan. Tämä kiteytyy julkaisun laajuuteen. 

Tuotetiimit eli PO:t tai BA:t odottavat tiettyjen ominaisuuksien sisältyvän julkaisuun, ja tästä sovitaan kehityksen alkaessa. Julkaisuun päätyvä koodi ei kuitenkaan aina kata täsmälleen sitä laajuutta, jota tuotetiimi odottaa. Joskus ihmiset unohtavat viedä koodin siihen haaraan, josta julkaisuversio rakennetaan. Tai mikä pahempaa, he saattavat viedä tähän haaraan koodia, jota ei pitäisi viedä sinne. Tämä voi tarkoittaa ominaisuuksia, jotka eivät ole vielä valmiita eivätkä QA:n hyväksymiä, tai ominaisuuksia, jotka eivät kuulu nykyiseen laajuuteen.

Jotta laajuus varmasti saavutetaan, julkaisukoordinaattorin tulisi verrata odotettua laajuutta todelliseen laajuuteen. Odotetun laajuuden tulisi olla peräisin tuotetiimiltä, ja se tulisi esittää selkeästi jonkinlaisissa asiakirjoissa (ja ehkä myös laadunvarmistussuunnitelmassasi). Käytössäsi voi esimerkiksi olla suunnitteluasiakirjoja, joissa esitetään projektin virstanpylväät ja kuhunkin virstanpylvääseen sisältyvät asiat. 

Todellisen laajuuden määrittämiseksi projektin käyttämästä VCS:stä (versionhallintajärjestelmä, esim. Git) tulisi poimia muutosloki. Muutosloki sisältää kaikki kehitysvaiheen aikana siihen haaraan tehdyt commitit, josta julkaisuversio luodaan. Jos työskentelet järjestelmällisesti, jokaisella commitilla on toivottavasti kuvaus, joka viittaa Jira-tehtävään, johon koodi liittyy. Näin näet, mitkä Jira-tehtävät sisältävät julkaisuversioon tulevaa vastaavaa koodia ja mitä näistä tehtävistä ei olisi pitänyt sisällyttää tähän koontiversioon. Jos tietysti huomaat, että nämä commitit liittyvät tarpeellisiin virheenkorjauksiin, se on täysin hyväksyttävää. Et halua, että nämä commitit edustavat keskeneräistä ominaisuustyötä tai työtä, joka liittyy ominaisuuksiin, joita ei pitäisi viedä tuotantoon nykyisen julkaisun mukana.

Kun perehdyt edistyneisiin julkaisunhallintatekniikoihin, huomaat, että prosessien integrointi Jiralle suunniteltuihin testinhallintaratkaisuihin voi tarjota yhtenäisemmän ja tehokkaamman työnkulun

Aina kun odotetun ja todellisen laajuuden välillä havaitaan ristiriita, julkaisunhallinnan koordinaattorin tulisi tehdä yhteistyötä tuotetiimin ja kehitystiimien esihenkilöiden kanssa parhaan toimintatavan selvittämiseksi. Jos laajuuteen kuulumattomiksi todetut commitit edustavat keskeneräistä ominaisuustyötä, ne on parasta poistaa. Tämä johtuu siitä, että olet jo esituotantovaiheessa etkä halua ottaa riskiä, että jäljellä oleva koodi kirjoitetaan ja testataan kiireessä vain siksi, että se päätyisi julkaisuun. Se on riskialtista, koska kiire voi johtaa testitapausten unohtamiseen ja suorittamatta jättämiseen sekä kriittisten virheiden päätymiseen tuotantoon. Tässä tapauksessa on parasta antaa näiden ominaisuuksien jäljellä olevan työn valmistua asianmukaisesti tulevaa julkaisua varten.

Testaus

Kun laajuus on selvä, testausvaiheen tulisi alkaa. Esituotantotestauksen aikana sinun on validoitava uudelleen koko julkaistava ominaisuus. Kuvittele, että katsot sitä ensimmäistä kertaa, ja testaa kaikki kehitysvaiheen aikana testaamasi tilanteet. Suorita jo kirjoittamasi automatisoidut testit esituotantoympäristössä äläkä unohda manuaalisia tilanteita. Tee tälle ominaisuudelle kattava regressiotestaus yksinkertaisesti siksi, että kun olet tässä julkaisunhallinnan vaiheessa ja esituotantoympäristössä, todennäköisesti myös muut tiimit tarvitsevat julkaista omia muutoksiaan kanssasi samaan aikaan. Tämä on käytännössä ensimmäinen kerta, kun kaikki riippuvuudet yhdistyvät samassa ympäristössä tuotantovalmiin koodin kanssa. Teoriassa tämä on myös se kokoonpano, joka toimii tuotannossa julkaisusta alkaen.

Paitsi jos testauksen aikana paljastuu ongelmia ja korjauksia tarvitaan. Jos näin tapahtuu, sinun on harkittava, mitä pitää testata uudelleen. Riippumatta siitä, onko korjaus omassa koodissasi vai jonkin ulkoisen riippuvuuden koodissa, sinun on harkittava uutta testauskierrosta, jos muutokset vaikuttavat ominaisuuteesi millään tavalla. Varmista, että testaat vähintään ominaisuuden kriittiset toiminnot uudelleen.

Tämä saattaa vaikuttaa tylsältä, etenkin jos tässä vaiheessa tehdään paljon korjauksia. Et kuitenkaan voi ennustaa tarkasti, millaisia vaikutuksia korjauksilla voi olla ominaisuutesi eri osiin.

Pienet muutokset voivat aiheuttaa valtavia sivuvaikutuksia, joten on parempi tylsistyä mutta luottaa siihen, että kriittiset toiminnot toimivat edelleen asianmukaisesti, kuin katua sitä, ettei testausta tehty riittävästi.

Jos jokin tämän testausvaiheen aikana löydetty virhe on vähäinen, älä tietenkään vaivaudu korjaamaan sitä tässä vaiheessa. Et jälleen halua kiirehtiä muuten täydellisesti toimivan ominaisuuden toteutusta tai testausta niin, että sen rikkoutumisen riski kasvaa.

Julkaisun aikana viestintä ja testaus ovat avainasemassa.

Kun ominaisuus on hyväksytty esituotantoympäristössä, se on valmis siirrettäväksi tuotantoympäristöön.

Viestintä

Tuotantojulkaisun yhteydessä julkaisunhallinnan koordinaattorilla on muutamia tehtäviä hoidettavanaan. Ensinnäkin julkaisupäivä ja -aika tulee määrittää hyvissä ajoin ja ilmoittaa kaikille osapuolille. Olen huomannut, että julkaisupäivän ja -ajan merkitseminen kokouksena osallistujien kalentereihin on erittäin hyödyllistä julkaisunhallinnan kannalta, jotta osallistujat voivat järjestää päivänsä. Koordinaattori voi hoitaa tämän tehtävän.

Julkaisupäivänä koordinaattorin tulee muistuttaa kaikkia julkaisun aikatauluun liittyviä henkilöitä. Viestintä tulisi ihannetapauksessa hoitaa kanavassa, jota kaikki käyttävät, esimerkiksi Slackissa. Erillinen Slack-kanava, jossa kaikista tärkeistä asioista viestitään, varmistaa, että kaikilla osapuolilla on sama käsitys siitä, mikä julkaisun vaihe on milloinkin valmis, mikä sen laajuus on, mitä ongelmia on havaittu ja kuka voi auttaa niiden ratkaisemisessa. Tällainen viestintä varmistaa, että julkaisun tietyistä asioista tarvitseva henkilö näkee nämä tiedot, toisin kuin suullisessa viestinnässä, jossa kyseinen henkilö saattaa olla poissa ilman, että tietoa välittävä henkilö huomaa hänen puuttuvan. 

Julkaisunhallinnan koordinaattorin tulee seurata julkaisun virstanpylväitä ja ilmoittaa niistä tässä kanavassa, esimerkiksi milloin julkaisu alkaa ja milloin julkaisu on hyväksytty. Jokaisen julkaisuun osallistuvan osapuolen tulee myös ilmoittaa tässä kanavassa suorittavansa hänelle määrättyjä vaiheita, jotta kaikki muut ovat tietoisia julkaisun tilasta ja etenemisestä. Jos jokin julkaisun vaiheessa tarvittava osapuoli ei ole saatavilla, julkaisukoordinaattorin tulee ottaa yhteyttä sopiviin henkilöihin, jotta kaikki sujuisi ongelmitta.

Testaus

Tuotantojulkaisun aikana uusi ominaisuus tulee testata jälleen kokonaisuudessaan. Tämä johtuu siitä, että vaikka ominaisuus olisi hyväksytty muissa testiympäristöissä, kyseiset ympäristöt eivät kokoonpanoltaan ja resursseiltaan ole täysin samanlaisia kuin tuotantoympäristöt.

Julkaistun ominaisuuden odottamattoman virheellisen toiminnan estämiseksi on tärkeää suorittaa kaikki käytettävissä olevat automatisoidut testit sekä ne automatisoimattomat osat, joita varten olet kirjoittanut testitapaukset. Älä koskaan hyväksy ominaisuutta tuotannossa testaamatta sitä ensin.

Pelkkä oletus siitä, että ominaisuus toimii tuotannossa, ei tarkoita, että se todella toimii.

Varmista sen toimivuus testaamalla se.

Julkaisun jälkeen

Julkaisu on siis valmis. Sen varmistaminen, että ominaisuus toimii asianmukaisesti, vaatii kuitenkin enemmän työtä kuin pelkkä sen testaaminen julkaisuvaiheessa.

Kun olet tehnyt tämän, varmista, että automatisoidut testisi suoritetaan tuotantoa varten CI-ympäristössä. Näin havaitaan kaikki ulkoisten, sinulle tuntemattomien muutosten aiheuttama ei-toivottu toiminta.

Seuraa jatkuvasti ominaisuuden suorituskykyä varmistaaksesi, etteivät tuotannon kuormitus ja asiakkaiden käyttö aiheuta suorituskyvyn heikkenemistä.  Varmista myös, että seuraat asiakkaidesi lähettämiä ongelmaraportteja. Ne voivat paljastaa alueita, jotka eivät toimi asianmukaisesti, jotta voit tarvittaessa ajoittaa nopeasti tulevan päivityksen.

Jos julkaisu ei sujunut odotetusti, järjestä julkaisun jälkeinen retrospektiivikokous. Siinä voit käsitellä kaikkia julkaisun hallintaprosessin aikana ilmenneitä ongelmia ja osoittaa toimenpiteet asiaankuuluville henkilöille, jotta tulevat julkaisut sujuisivat ongelmitta ja onnistuneesti.