"Kyllä se on aiemminkin toiminut” ja muut versiovaihdosten sudenkuopat

Kauan odotetulle ominaisuudelle on juuri saatu ohjelmiston toimittajalta aikataulu, ja olette saaneet tiedon, että ominaisuus tuodaan osana isompaa versiopäivitystä. Toimittajan puolen omissa testiympäristöissä suoritettavat järjestelmätestit on saatu toteutettua onnistuneesti, ja sen myötä version julkaisu lähestyy. Päivitys päätetään sen suuremmin testaamatta ottaa käyttöön, sillä mikä voisikaan mennä vikaan. Tuotantokäytössä käykin ilmi, että tietyt ominaisuudet ovat menneet enemmän tai vähemmän rikki version mukana tulleiden muutosten myötä; ydinprosessien toteuttaminen tulee huomattavasti työläämmäksi ja tietyille toiminnallisuuksille joudutaan etsimään kiertoreittejä. Tämän lisäksi virheellistä tietoa valuu päivitetystä järjestelmästä eteenpäin rajapintojen kautta muihin järjestelmiin.

Edellä kuvattu tilanne aiheuttaa harmaita hiuksia paitsi operatiivisessa portaassa, mutta myös laajemmin organisaatiossa, kun ylimääräistä aikaa ja resursseja kuluu. Ongelmia tulee erityisesti silloin, jos kyseessä on liiketoimintakriittinen järjestelmä; ongelmat voivat tällöin aiheuttaa suoraan kassavirtavaikutuksia, tai ikävimmillään haasteita lainsäädännön näkökulmasta, jos vaadituissa aikarajoissa ei pysytä tai vaatimuksiin ei pystytä vastaamaan. Mistä siis ratkaisu tähän varsin monitahoiseen haasteeseen? Avataanpa tätä seuraavaksi.

Liiketoimintakriittiset järjestelmät ja ketterä ohjelmistokehitys

Energiayhtiöiden näkökulmasta eräs tärkeimmistä järjestelmistä on asiakastietojärjestelmä, joka toimii alustana useiden ydinprosessien toteuttamiselle, mutta on myös monessa tapauksessa liiketoimintakriittisen datan master-järjestelmä. Muista järjestelmistä tärkeässä roolissa ovat erilaiset asiakasrajapintaa palvelevat portaalit ja CRM-järjestelmät. Monet edellä kuvattujen järjestelmien toimittajat pohjaavat toimintansa ketterän ohjelmistokehityksen erilaisille toimintamalleille, jolloin korjauksia ja uusia ominaisuuksia tuodaan asiakkaiden saataville useita kertoja vuodessa. Järjestelmän tilaajan näkökulmasta on siis yhden vuoden aikanakin useita ajankohtia, jolloin liiketoiminnan sujuvuuteen kohdistuu erityisiä riskejä.

Toimittajat suorittavat järjestelmätestauksia laajalti eri vaiheissa ohjelmistokehitysprosessejaan, mutta ongelmaksi jäävät usein erityisesti testiympäristöjen kattavuuteen ja dataan liittyvät rajoitteet, sekä tarkan tiedon puute ohjelmiston käyttötavasta. Järjestelmäarkkitehtuuri voi aiheuttaa yllätyksiä, joihin ei osattu varautua, vaikka versio olisikin viimeisen päälle testattu toimittajan puolella. Nämä riskit voidaan taklata tilaajan roolissa suorittamalla version vastaanottotestaus itse. Alla olevassa kuvassa on havainnollistettu energiayhtiön suorittamaa version vastaanottotestausta osana ohjelmistokehitysprosessia. Huomioitavaa tosin on, että tuotantokäytön estävien virheiden ilmetessä voidaan testauskierroksia joutua toteuttamaan useampia eri versioilla.

Kuva: Energiayhtiön suorittama vastaanottotestaus osana ohjelmistokehitysprosessia

Mistä version vastaanottotestauksessa on kyse? 

Tietojärjestelmän uuden version vastaanottamisvaiheessa energiayhtiön ja/tai palveluntarjoajan itse suorittaman vastaanottotestauksen tavoitteena on ensisijaisesti varmistaa järjestelmän toimivuus sekä uusien ominaisuuksien, että vanhojen ja muuttuneiden ominaisuuksien osalta. Osittain tavoitteena voi olla myös selvittää uuden version tuomien uusien ominaisuuksien käyttömahdollisuuksia ja hyötyjä. Näiden taustalla puolestaan voivat olla joko lainsäädännölliset vaatimukset vaikkapa Datahubin versiopäivityksiin liittyen, tai yleisimmin liiketoimintojen tarpeet.

Vastaanottotestauksessa on hyvin olennaista, että aiemmin toimineet ohjelmiston toiminnallisuudet ovat myös uudessa versiossa toimivia. Ja toimivia nimenomaan tilaajan omalla testidatalla ja omat toimintamallit huomioiden. Tästä kokonaisuudesta puhutaan yleensä regressiotestauksena. Olennaista on toki huomioida se, että myös ydintoiminnallisuudet muuttuvat versiovaihdoissa; testauksissa tuleekin muodostaa käsitys versiotiedotteiden tai koulutuksen avulla siitä, missä kohdin toiminnallisuus on muuttunut ja mikä puolestaan on virhe. Käytäntö on osoittanut, että pientäkin muutosta tulee testauksessa käsitellä kokonaan muuttuneena ja siten on erittäin suositeltavaa testata se kattavasti.

Regressiotestauksissa suoritettavia testitapauksia voi lähestyä esimerkiksi ohjelmiston moduulien tai toisaalta liiketoiminnan prosessien näkökulmasta. Lisäksi on oleellista muodostaa version mukanaan tuomista uusista ominaisuuksista sopivan tarkat testitapaukset. Laadukkaasti tehty prosessityö tarjoaa hyvät lähtökohdat testitapausten määrittämiseen, ja auttaa muun muassa myös muiden testauksessa tarvittavien järjestelmien testiympäristöjen määrityksessä sekä testauksen valmistelussa.

tarkat asiakaskohtaiset kokoonpanot ja tiettyjen testitapausten painottaminen eivät ole mahdollisia, minkä vuoksi energiayhtiön omat panostukset vastaanottotestaamiseen ovat tärkeässä roolissa.

Vastaanottotestaukset tulevat ajankohtaisiksi luonnollisesti vain silloin, kun ohjelmistosta julkaistaan uusi versio, joka halutaan ottaa käyttöön. Julkaisut puolestaan yleensä tehdään järjestelmätoimittajan ennalta määritettyjen aikataulujen mukaan.

Kolme vinkkiä onnistuneeseen vastaanottotestaukseen

Tunnista liiketoiminnan tarpeet

Liiketoiminta voi kärsiä voimakkaasti, jos esimerkiksi myyntisopimusten tekeminen ei sähkönmyyntiyhtiöllä toimi. Toisaalta jotkin tukiprosessit voivat olla sellaisia, että ne toistuvat vain kuukausittain tai harvemmin, eivätkä silloinkaan ole kriittisen tärkeitä. Tee siis testitapaukset huolella ja määritä niille testausjärjestys. Tärkeää on myös hahmottaa kokonaiskuva, ja muodostaa pidemmän aikavälin, esimerkiksi vuoden kattava versiosuunnitelma, joka huomioi liiketoiminnan tarpeet kokonaisuutena.

Määritä tarvittavat testausympäristö

Harva prosessi toteutetaan nykyään energiayhtiön arjessa vain yhden järjestelmän sisällä; tietoa liikkuu sisään ja ulos asiakastietojärjestelmästä, ja liiketoimintaprosessit toteutuvat järjestelmäkokonaisuudessa. Huolehdi siis, että testaus tehdään tarvittavassa laajuudessa ja eri järjestelmien testausympäristöt, sekä näiden väliset integraatiot ovat käytettävissä. Pyri myös varmistamaan, että testausympäristöt toimivat mahdollisimman samalla tavoin, kuin tuotantoympäristö.

Varaa riittävästi aikaa testaamiselle

Jotta ohjelmiston toimivuudesta saadaan tarpeeksi kattava kuva, on testitapaukset suoritettava kulloinkin asiaankuuluvalla tarkkuudella. Monessa tapauksessa testaus vaatii tämän vuoksi paljon asiantuntijoiden aikaa, minkä lisäksi sitä tehdään yleensä muiden töiden lomassa. Tällöin on tärkeää, että testaamiselle ja muille töille löydetään sopiva tasapaino testausjakson ajaksi. Lisäksi tulee huomioida myös mahdollisten bugikorjausten ja uudelleen testaamisen viemä aika.

Energiayhtiöiden, kuten muidenkin julkisen ja yksityisen puolen organisaatioiden arki pyörii hyvin pitkälti tietojärjestelmien avustamana tai mahdollistamana. Tilaajan puolella ohjelmiston käyttäjillä on paras käsitys ohjelmiston käyttötavasta kyseisessä organisaatiossa, ja toisaalta heillä on yleensä käytössään myös käyttökelpoisin testidata, jossa mahdolliset yrityskohtaiset asiat on huomioitu. Näiden asioiden pohjalta ongelmat saadaan yleensä tehokkaasti havaittua ja tuotannon ongelmat vältettyä. Asiaa voidaan lähestyä toisestakin näkökulmasta; tietojärjestelmät ovat työntekijöille tärkeä työkalu tehtävien suorittamiseen heidän arjessaan, mutta myös tärkeä kanava asiakkaiden palvelemiseen. Organisaation ja ohjelmiston käyttäjien tarpeet täyttävällä järjestelmällä pidetään ”pyörät pyörimässä” ja ihmiset tyytyväisenä.

Maksuton alkukartoitus: versiotestauksen hallintamallipalvelu energiayhtiöille

Varaa alta aika maksuttomaan 20 minuutin alkukartoitukseen. Alkukartoituksesta saat lyhyen raportin sisältäen toimenpide-ehdotukset. Ajan varaaminen ei velvoita sinua mihinkään. 

Alkukartoituksessa muodostamme asiakastietojärjestelmän, online-palvelun tai muun tietojärjestelmän toimenpide-ehdotuksen. Käymme läpi muun muassa tuotantopäivitysten jälkeisiä tilanteita läpi, sekä arvioimme suunnitelman kattavuutta ylätasolla. Kartoituksen pohjalta teemme lyhyen koosteen, mikä sisältää ehdotukset laajemman kartoituksen painopisteistä. Kiinnostuitko?  Varaa aika alkukartoitukseen täältä >

Solteq Utilities Consulting - Energia-alan asiantuntija- ja projektipäällikköpalvelut

Autamme energia-alan asiakkaitamme kirkastamaan tavoitteet ja suunnittelemaan sekä läpiviemään hankkeet asetettujan päämäärien saavuttamiseksi laadukkaasti ja aikataulussa. Toimimme luontevasti rintarinnan osana energiayhtiön omaa asiantuntijatatiimiä, olipa kyse sitten kilpailutuksista, järjestelmähankkeiden läpiviennistä tai toiminnan ja prosessien kehittämisestä.

Meissä yhdistyy energialiiketoiminnan tuntemus ja ICT-projektiosaaminen. Toimimme järjestelmäriippumattomasti. Haluamme että asiakkaamme onnistuvat hankkeissaan ja saavuttavat asettamansa tavoitteet.

Lue lisää energia-alan konsultointipalveluista >