Kuinka seuranta ja palaute tuotannossa vaikuttavat ohjelmiston laatuun ja kehitykseen?

Tuotannossa tapahtuvan ohjelmiston käytön ja virheiden seuranta, kuten virhekoodien määrän tarkkailu, on tärkeä osa ohjelmistokehitystä ja ylläpitoa. Seurannan ja hälytysten avulla voidaan nopeasti havaita järjestelmän ongelmat ja reagoida niihin ennen kuin ne vaikuttavat käyttäjäkokemukseen. Tämä tieto voi tulla sekä operaatiotiimin jäseniltä että ohjelmiston seurantalokeista. Käyttäjät muistavat yleensä parhaiten aikaisemmat virhetrendiit ja voivat kertoa niistä tarinoita, jotka auttavat ymmärtämään, miksi virheitä on tapahtunut. Esimerkiksi olin mukana kehittämässä ohjelmistoa, joka seurasi verkkokaupan virhekoodeja. Virhekoodien määrän näyttävä kaavio oli aina esillä, ja kehitystiimit pystyivät reagoimaan odottamattomiin virhepiikkeihin, mikä antoi vihjeitä siitä, että uusi julkaisupäivitys oli tuonut mukanaan ongelman.

Kun aloitin organisaatiossa, virheiden määrä oli vähäinen mutta vakio, eikä niitä pidetty erityisen tärkeinä korjata. Vain muutama operaatio- ja kehitystiimin jäsen ymmärsi ongelmien juurisyyt ja ajoi niiden korjaamista. He muistivat, milloin virheet alkoivat ilmetä, tunsivat virheiden aiheuttavat tilanteet ja tiesivät, kuka oli paras korjaamaan ne. Heidän vaikuttamisensa oli se, mikä palautti kaavion oletustilan virheettömäksi. Tämä tilanne toi esiin myös tulevien julkaisujen ennakoivan testauksen tärkeyden, erityisesti virheiden seurantaan ja niiden havaitsemiseen ennen tuotantoon siirtymistä.

Valvonnan ja hälytysten toimivuuden lisäksi on tärkeää testata myös se, miten hälytykset ilmoitetaan ja reagoidaan niihin. Onko hälytys ratkaistu ja merkitty, ja onko siihen liitetty asianmukaiset tiedot? Onko hälytykset arkistoitu tai poistettu, ja mitä tietoja tallennetaan, kun ongelma ratkaistaan automaattisesti? Jos valvonnassa on visuaalinen käyttöliittymä, päivittyykö se kuten odotetaan? Nämä kaikki asiat vaikuttavat siihen, kuinka luotettavasti ja tehokkaasti järjestelmä toimii tuotannossa.

Kollektiivinen hälytysten melu on myös tärkeä huomioitava tekijä. Hälytysten tulisi kattaa vain tärkeät tilanteet, mutta ei luoda tarpeettomia väärinhälytyksiä. Jos hälytys laukeaa oikein, mutta vaadittava vastaus ei ole selvä, koko valvontaratkaisu on epäonnistunut.

Analytiikka on toinen tärkeä osa tuotannossa tapahtuvaa seurantaa. Se tarjoaa arvokasta tietoa käyttäjien toiminnasta ja järjestelmän tilasta. Verkkosovelluksessa tämä voi olla esimerkiksi sivulatausten määrää, puhelinverkon tapauksessa puheluiden kestoja tai pankkituotteessa tapahtumamääriä. Analytiikkaa voidaan kerätä suoraan mitaten käyttäjien tietoisia toimintoja, kuten verkkosivustojen käyttöä tai puhelinsovelluksen käyttöä, mutta myös epäsuorasti antureiden ja seurantatoimintojen avulla. Esimerkiksi kuntoilusovellukset, sääasemat tai ilmanvaihtojärjestelmät voivat kerätä tietoa ympäristöstään. Näiden tietojen avulla organisaatiot voivat oppia käyttäjiensä käyttäytymisestä ja reagoida siihen.

Suurempien järjestelmien analytiikka voi tuottaa valtavia tietomääriä, mikä johtaa niin kutsuttuun "big dataan". Tietojen analysoiminen ja niistä arvon erottaminen vaatii monimutkaisia taitoja laskennassa, tilastotieteessä ja koneoppimisessa. Kehitystiimien on tärkeää tehdä yhteistyötä analytiikkatiimin kanssa, jotta voidaan määritellä, mitä tietoja on tärkeää seurata. Tämä yhteistyö voi tuottaa syvällisempiä näkemyksiä, kun koodi on tuotannossa.

Analytiikan testaaminen keskittyy enemmän tiedon suunnitteluun kuin yksittäisten tietojen käyttäytymiseen. On tärkeää testata, kuinka ihmiset voidaan jäljittää eri työprosesseissa ja kysyä, onko tiedonkeruun suunnittelu oikea. Esimerkiksi, jos verkkopankin maksupalvelussa on useita siirtotyyppejä, kuten "pikasiirto" ja "perinteinen maksaminen", onko järkevää tallentaa nämä tapahtumat erillisinä, vai pitäisikö ne yhdistää? Samoin, pitäisikö web- ja mobiilikäyttäjien toimet tallentaa erikseen vai yhdistää ne?

Lokitiedostot ovat vielä yksi tärkeä pala tuotannon seurantaa ja virheiden diagnosointia. Lokitiedostot tallentavat tietoa ohjelmiston toiminnasta, virheistä ja varoituksista. Ne voivat kertoa yksityiskohtaisesti, miksi virheitä on syntynyt, ja ne voivat auttaa kehittäjiä ja ylläpitäjiä ratkaisemaan ongelmia nopeasti. Kehitystiimin tulisi ymmärtää, millaisia tietoja on tärkeää kirjata ja miten lokit viestit tulisi luokitella, oliko kyseessä virhe, varoitus, informaatio vai virheenkorjaustieto.

Erityisesti virheiden jäljittäminen ja analysointi tuotannossa on osa jatkuvaa parantamista, joka edistää ohjelmiston laadun ja käytettävyyden parantamista pitkällä aikavälillä.

Miten organisaatiot voivat optimoida ohjelmistokehityksen ja tuotannon testausta: käytännön esimerkkejä

Candy Crushin tapauksessa regression testaus voi varmistaa, että peli pysyy toimivana ja menestyksen taso säilyy muuttumattomana. BPU jatkaa tuotantodatan hyödyntämistä, pitäen botin kalibrointitarkastelun jatkuvana. Tämä toimii loistavana esimerkkinä siitä, kuinka kehitystiimit ja operatiiviset tiimit voivat tehdä yhteistyötä hyödyntäen tuotantodatasta saatuja analyysejä parantaakseen ennakkotestausta ennen ohjelmiston julkaisua. Näin kehityksen ja operaatioiden yhteistyö parantaa jatkuvasti ohjelmiston laatua ja nopeuttaa virheiden havaitsemista jo ennen kuin ne ehtivät vaikuttaa käyttäjiin.

Capital Onen kehitystiimi on kehittänyt Hygieia-nimisen hallintapaneelin, joka visualisoi toimitusputken tilan reaaliaikaisesti. Hygieia kerää tietoa kaikista niistä työkaluista, joita organisaatio käyttää, mutta ei tuo uutta tietoa putkeen. Tämä mahdollistaa sen, että koko ohjelmistokehitysprosessin tila on nähtävissä yhdestä koontinäytöstä. Hygieian avulla voidaan seurata muun muassa sitä, kuinka monta tarinaa tiimit ovat käsitelleet, koodin sitoutumistiheyttä, testaustuloksia, rakenteiden tilaa ja mahdollisia virheitä. Näiden tietojen avulla kehitystiimit voivat tehdä nopeita ja tietoon perustuvia päätöksiä siitä, miten prosessia voidaan parantaa. Hygieian kautta on mahdollista tunnistaa pullonkauloja ja odotusaikoja, mikä puolestaan parantaa koko putken nopeutta.

Toinen esimerkki tulee brittiläiseltä The Guardianilta, joka on siirtynyt pois perinteisestä testaamisesta ja siirtänyt testauksen tuotantovaiheeseen. Vuonna 2016 The Guardian julkaisi noin 400 ohjelmistopäivitystä päivittäin, ja testaaminen oli pitkälti automatisoitua. Tämä huima muutos vaati myös testausstrategian uudelleenarviointia. Sally Goble, The Guardianin QA-päällikkö, kertoi, kuinka vuonna 2011 he julkaisivat ohjelmiston vain 25 kertaa vuodessa, mutta vuonna 2014 määrä oli noussut yli 24 000 automaattiseen julkaisuun. Tämä ei ollut vain tekninen haaste, vaan myös liiketoiminnallinen kysymys: käyttäjien saaminen käyttöön nopeammin oli tärkeämpää kuin täydellisen ohjelmiston julkaiseminen.

Goble ja hänen tiiminsä huomasivat, että testaaminen ei tarvitse olla täydellistä ennen julkaisua, koska riskit pienenevät huomattavasti, kun virheet voidaan havaita nopeasti tuotannossa ja palauttaa ohjelmisto aiempaan versioon tarvittaessa. Tämä ajattelutapa siirsi automaattisen testauksen ennen julkaisua tuotannon puolelle, jossa testit ajetaan todellisessa ympäristössä ja virheet korjataan nopeammin. Tämä lähestymistapa vaati uutta ajattelua ja työkalujen kehittämistä, jotta ongelmat voitaisiin havaita ja ratkaista mahdollisimman nopeasti.

Sekä Capital One että The Guardian tarjoavat esimerkkejä siitä, kuinka nykyaikainen DevOps-menetelmä voi parantaa ohjelmistojen julkaisuprosessia ja laatua. Nämä organisaatiot ovat ottaneet käyttöön avoimen lähdekoodin työkaluja ja automatisoituja prosesseja, joiden avulla he voivat nopeuttaa ohjelmistokehitystä ilman, että se vaikuttaa negatiivisesti laatuun. Tämä on mahdollista vain, jos testaus ja tuotanto ovat integroituneet toisiinsa saumattomasti.

On tärkeää ymmärtää, että testaus ei ole enää vain erillinen vaihe ohjelmiston kehityksessä, vaan jatkuva prosessi, joka kulkee mukana koko kehityksen ja julkaisun ajan. Nykyaikaisessa ohjelmistokehityksessä laatu ei ole vain lopputuote, vaan se on osa koko elinkaarta. Testaus automatisoidaan niin pitkälle kuin mahdollista, ja virheitä käsitellään nopeilla palautusmekanismeilla tuotannossa. Tämä lähestymistapa vaatii kulttuurista muutosta, jossa virheitä ei nähdä epäonnistumisina, vaan osana jatkuvaa parantamisen prosessia.