DevOpsin ympäristössä automatisointi on avainasemassa, mutta sen tehokkuus riippuu siitä, miten virheitä havaitaan ja käsitellään eri kehitysvaiheissa. Tässä kuvattu malli DevOpsin virheiden suodattamisesta perustuu kuuteen kerrokseen, jotka jakautuvat kahteen pääosaan: kehitysvaiheen testaukseen ja tuotantovaiheen virheiden tunnistamiseen.

Ylimmät kolme kerrosta ovat suunnattu kehitysympäristössä tapahtuvaan testaamiseen: yksikkötestaukseen, integraatiotestaukseen ja päättymistestiin (end-to-end testing). Nämä testauskerrokset toimivat kuin suodattimet, jotka poimivat virheitä aina pienimmistä yksikkötestauksen löydöksistä aina integraatiovaiheen virheisiin. Testauskerroksissa käytettävä "suodatin" on kuin verkko, jonka säikeet ovat tiheimmät yksikkötestauksessa ja laajenevat kohti päättymistestiä, joka poimii vain suurimmat ongelmat.

Alimmat kolme kerrosta ovat tarkoitettu tuotannossa kerättävälle tiedolle, joka voi auttaa virheiden havaitsemisessa ja tuotteen laadun arvioinnissa: hälytykset, monitorointi ja lokit. Nämä kerrokset toimivat jälkikäteen, havaiten virheitä ja laadun ongelmia tuotannon aikana. Näiden kerrosten "verkko" on vieläkin laajempi, sillä ne käsittelevät laajempia ja monimutkaisempia ongelmia kuin yksinkertaiset yksikkötestit.

Kuvitellaan, että virheet, jotka pääsevät suodattimen läpi, ovat kuin perhosia elinkaarensa eri vaiheissa. Yksikkötestit poimivat "munat" – virheet, jotka eivät ole vielä kehittyneet vakaviksi ongelmiksi. Integraatiotestit tarttuvat "toukkia", jotka voivat olla joko yksikkötestistä kehittyneitä virheitä tai ulkopuolisista järjestelmistä tulleita ongelmia. Päättymistestit, puolestaan, tarttuvat "perhosiin", jotka ovat jo kehittyneet huomattaviksi ongelmiksi.

On tärkeää ymmärtää, että vaikka meillä olisi täydellinen yksikkötestaus, emme voisi estää kaikkien virheiden pääsemistä alempiin kerroksiin. Kehityksessä ja tuotannossa ympäristöt ja järjestelmät voivat muuttua, ja virheet voivat ilmetä yllättävistä lähteistä. Tämä selittää, miksi suodattimen verkon rakenne laajenee kerroksittain.

DevOpsin suodatinmalli tarjoaa mielenkiintoisen lähestymistavan laajempaan keskusteluun testausstrategioista. Testit, joita kehitystiimisi käyttää, ja tuotannossa kerättävät tiedot muodostavat sen verkon, joka määrittelee, kuinka hyvin virheitä voidaan estää. Jos testauskatteesi on puutteellinen, verkossa on aukkoja, joiden kautta virheet voivat päästä läpi ja kasvaa suuremmiksi ongelmiksi. Esimerkiksi yksikkötestauksen puutteet voivat johtaa siihen, että enemmän "toukkia" ilmestyy integraatiovaiheeseen, ja niin edelleen.

Joskus on kuitenkin strateginen päätös hyväksyä virhe myöhemmässä vaiheessa prosessia. Esimerkiksi tietyt integraatiopalvelut voivat olla vaikeasti testattavissa yksittäin, jolloin niitä ei voida sisällyttää aikaisempiin testausvaiheisiin. DevOpsissa on tärkeää keskustella näistä strategisista päätöksistä ja olla tietoinen siitä, missä vaiheessa riskin lieventäminen on tarkoituksenmukaista. Myös se, että testauksen epäonnistuminen ei aina estä julkaisua, on osa DevOpsin kulttuuria, jossa pyritään minimoimaan tarpeeton automaatio ja keskittymään vain tarvittaviin osiin.

Tämä "DevOpsin tiimalasi" -malli tarjoaa yksinkertaistetun lähtökohdan keskusteluille testauksen strategioista. Jos ajattelemme hälytyksiä, monitorointia ja lokitietoja alkuperäisen testipyramidin vastineina, voimme nopeasti laajentaa perinteistä keskustelua DevOpsin suuntaan. Tällöin testausstrategia ei perustu vain kehitysympäristössä tehtäviin testeihin, vaan huomioi myös sen, millaista tietoa operatiivinen ympäristö voi tarjota. Tämä viittaa siihen, kuinka myös ei-toiminnallisten testien, kuten turvallisuuden, suorituskyvyn ja käytettävyyden, automaattinen mittaaminen voi tuottaa arvokasta palautetta tuotannossa.

DevOpsin ympäristössä on kuitenkin tärkeää huomioida myös tutkimustestaaminen. James Lyndsay kirjoittaa erinomaisessa artikkelissaan "Why exploration has a place in any strategy" siitä, miksi eksploratiivisella testauksella on paikkansa kaikessa strategisessa testauksessa. Vaikka DevOps-kulttuurissa korostetaan nopeaa toimitusta, tutkimustestausta ei pidä sivuuttaa. Se voi olla hyödyllistä ennen koodin yhdistämistä päähaaraan tai sen jälkeen, kun käyttäjät ovat vuorovaikutuksessa ohjelmiston kanssa. Automaattisessa putkessa ei ole yhtä paljon mahdollisuuksia tutkia, ja testauksen strategiaa määriteltäessä on tärkeää löytää tasapaino.

Kun testauksen lähestymistapa on asetettu, voidaan käyttää mittareita arvioimaan, kuinka syvälle testaus menee. Ajattele pendulumia: sen liike edustaa testauksen lähestymistapaa, joka voi olla liian syvällinen tai liian pinnallinen. Hyvä testausstrategia tunnistaa, milloin pendulum on saavuttanut ylärajan, ja osaa säätää lähestymistapaa sen mukaan. Tämä arviointi tapahtuu kolmen päämittarin avulla: virhemäärä, tiimiltä saatu palaute ja johdon palaute. Virheiden määrä kertoo, onko testaus riittävän syvällistä, vai jääkö se pinnalliseksi. Tiimiltä saatu palaute voi puolestaan kertoa, onko testaus liian suppeaa vai liian laajaa, ja johdon palaute auttaa arvioimaan, onko testaus linjassa organisaation strategisten tavoitteiden kanssa.

Miten visuaaliset työkalut voivat parantaa yhteistyötä tiimien välillä?

Yhteistyö tiimien välillä, erityisesti kehityksen ja testauksen kentällä, on nykyään tärkeämpää kuin koskaan. Visuaaliset työkalut, kuten kaaviot ja diagrammit, tarjoavat erinomaisen välineen helpottaa monimutkaisten ideoiden jakamista ja keskustelua eri alojen asiantuntijoiden välillä. Maaret Pyhäjärven ja Christina Ohanianin mukaan visuaaliset mallit voivat toimia tehokkaina keskustelun herättäjinä, jolloin yksittäinen ajatus saattaa laajentua ja kehittyä yhteisessä prosessissa.

Kun asiat, kuten testauksen eri osa-alueet, esitetään visuaalisesti, se ei pelkästään helpota muistamista, vaan myös avaa mahdollisuuden syvällisempään keskusteluun. Esimerkiksi, Ohanian mainitsee niin sanotut "luovat seinät", jotka voivat toimia tilassa, jossa kaikki voivat tarkastella ja kommentoida visuaalisesti esitettyjä ideoita. Tällainen ympäristö innostaa ihmisiä ajattelemaan uusin tavoin ja saamaan uusia näkökulmia. Vähitellen syntyy kulttuuri, jossa ajatukset eivät ole enää henkilökohtaisia muistiinpanoja, vaan jaettuja ja jatkuvasti kehittyviä konsepteja.

Visuaalisten työkalujen hyödyntäminen ei rajoitu vain peruskaavioihin ja aikajanoihin. Testaajat voivat käyttää esimerkiksi Venn-diagrammeja, aikarajoja tai tilasiirtymäkaavioita testattavuuden ja kattavuuden arviointiin. Ajan myötä visuaaliset mallit voivat kehittyä ja muotoutua organisaation tarpeiden mukaan, ja tiimit voivat jakaa omia kokemuksiaan ja kommenttejaan siitä, miten mallit ovat muuttuneet ja kehittyneet.

Yhteistyö ei kuitenkaan rajoitu vain kehittäjiin ja testeihin. Organisaatiossa tapahtuva yhteistyö saattaa vaatia myös muiden tiimien, kuten operaatioiden, tukea. Esimerkiksi testiautomaation parantamisessa Selenium Gridin käyttöönotto oli prosessi, joka vaati testiautomaatiokoodin muuttamista, mutta myös ympäristön konfigurointia. Operaatioiden tiimi oli tärkeässä roolissa, koska he olivat vastuussa tarvittavien ympäristöjen luomisesta ja säätämisestä. Yhteistyö eri tiimien välillä ei ainoastaan auttanut parantamaan prosessia, vaan loi myös uusia suhteita ja yhteyksiä organisaation sisällä.

Kun tiimit tekevät yhteistyötä, on tärkeää muistaa, että yhteys ei tapahdu pelkästään teknisen työn tasolla. Usein onnistunut yhteistyö perustuu siihen, että osoitetaan aitoa kiinnostusta muiden työntekijöiden työtä kohtaan. Esimerkiksi Carol Brandsin kertomus asiakastuen kanssa yhteistyön tekemisestä osoittaa, kuinka tärkeää on osoittaa, että arvostat muiden asiantuntemusta ja mielipiteitä. Tällainen arvostus voi johtaa syvempään yhteistyöhön, joka hyödyttää kaikkia osapuolia.

Toinen tärkeä näkökulma on "kutsuminen" eli invitation. Kutsuminen voi olla muodollista tai epämuodollista, mutta sen ydin on siinä, että se luo ympäristön, jossa ideat ja mielipiteet voivat kulkea tiimien välillä. Kate Falangan esimerkki siitä, kuinka hän oli mukana järjestämässä tiedonjakotilaisuuksia eri tiimeille, kuvastaa hyvin, kuinka tärkeää on ymmärtää, mitä muut tekevät ja kuinka ne voivat liittyä omaan työhön. Tällaiset tilaisuudet voivat toimia siltoina eri tiimien välille ja edistää yhteistyön syventämistä.

Tässä yhteydessä on myös tärkeää huomioida, että visuaaliset työkalut voivat toimia pitkällä aikavälillä merkkinä, joka tallentaa keskusteluja ja tietoa. Näitä "merkkejä" voivat olla esimerkiksi dokumentit, esitykset tai jopa automaattiset testausputket, jotka välittävät palautetta jatkuvasti ja visuaalisesti. Tällaisten työkalujen avulla voidaan luoda yhteisiä prosesseja ja varmistaa, että tieto on saavutettavissa kaikille osapuolille.

Kun organisaatiossa hyödynnetään visuaalisia työkaluja ja luodaan avoin tiedonjakokulttuuri, tiimien välinen yhteistyö voi kasvaa syvemmäksi ja laajemmaksi. Uusien näkökulmien ja ideoiden esiin tuominen auttaa kehittämään paitsi itse prosesseja myös työskentelytapoja, jotka tekevät koko organisaatiosta tehokkaamman ja dynaamisemman. Tällöin myös testaus, joka voi joskus jäädä kehityksen varjoon, voi saada enemmän huomiota ja resursseja. Visuaaliset työkalut auttavat pitämään keskustelut elossa ja kehittämään niitä eteenpäin.

Voiko viha olla oikeus? Taistelulliset julkiset sfäärit ja yhteiskunnan muutokset
Miten ulkomaalaisvaikuttaminen ja vaalirahoituslainsäädäntö yhdistyvät Yhdysvalloissa?
Miten psykologinen epätasapaino vaikuttaa politiikkaan ja yhteiskuntaan?
Miten Tekoäly ja Koneoppiminen Parantavat Kyberturvallisuutta?
Molekyyligenetiikan tutkimusstrategiat ja niiden soveltaminen