Kuinka testata ja hallita ominaisuuksia, jotka käyttävät "feature toggles"-mekanismeja?

Ominaisuuksien kytkimet, eli feature toggles, ovat tehokkaita työkaluja ohjelmistokehityksessä, koska ne mahdollistavat erilaisten ominaisuuksien hallinnan ilman, että koko järjestelmän koodia tarvitsee muuttaa tai julkaista. Kuitenkin näiden työkalujen käyttöön liittyy myös haasteita, erityisesti testaamisessa ja hallinnassa. Tässä käsitellään, miten testata näitä kytkimiä ja mitä muita näkökohtia tulisi ottaa huomioon.

Ensimmäinen askel on määritellä, kuinka kytkimet on asetettu: ovatko ne päällä (ON) vai pois päältä (OFF)? Yksinkertaisimmillaan kytkimet voivat olla täysin itsenäisiä muista tiimeistä kehitettyihin ominaisuuksiin, mutta jos tilanne on monimutkaisempi, voi olla tarpeen miettiä tarkemmin testausstrategiaa. Jos kytkin määritellään dynaamisesti säännön avulla, on järkevää testata käyttäjiä, jotka siirtyvät kohderyhmän sisälle tai sen ulkopuolelle. Jos taas kytkin liittyy kokeiluihin, on tärkeää varmistaa, että käyttäjä saa aina oikean version joka kirjautumiskerralla.

Kun kyseessä ovat operatiiviset kytkimet tai käyttöoikeudet, on myös järkevää tutkia eri kytkinkombinaatioiden yhteisvaikutuksia, sillä nämä voivat tuoda esiin ei-toivottuja vuorovaikutuksia muiden asetusten kanssa. Testauksen skaala voi nopeasti laajentua ja tuntua ylivoimaiselta, mutta on tärkeää lähestyä tätä itsenäisesti ja jakaa ajatuksia tiimin kanssa. Tiimi voi auttaa löytämään puutteet tai tarpeettomat kokeet, jotka saattavat olla mukana. Yhteistyö on yleensä tehokkaampaa kuin luulo siitä, että omat testit olisivat riittäviä.

Ominaisuuksien julkaisemisen yhteydessä on tärkeää muistaa, että kytkimen pois päältä laittaminen on turvaverkko. Erityisesti julkaisutoken kohdalla tämä on tärkeää, koska käyttäjillä saattaa olla vain rajoitettua altistumista uudelle toiminnallisuudelle. Jos virhe ilmenee ominaisuudessa, jota hyvin harvat käyttäjät ovat nähneet, on ongelma saattanut jäädä vähälle huomiolle. Toisaalta, jos kytkin on ollut päällä pitkään, se voi luoda riskejä, kuten mainehaittaa, jos premium-ominaisuuksia poistetaan uskollisilta käyttäjiltä.

Testauksessa ei pidä keskittyä vain ohjelmiston käyttäytymiseen, vaan myös kytkinten itsensä testaamiseen. Onko nykyinen kytkinasetelma helposti tarkistettavissa? Onko komentoa, jolla voi noutaa tämän asetelman elävästä järjestelmästä? Jos konfiguraatiotiedostoa luetaan, kuinka voi olla varma, että se vastaa nykyistä käyttötilannetta? Onko olemassa tarkastelutietoa, joka kertoo, kuka on muuttanut kytkimen tilan ja milloin? Tällainen historia on elintärkeää erityisesti, jos kytkimen tila muuttuu usein. Jos kytkin ei muutu, vaikka se olisi aina päällä tai pois päältä, onko se yhä tarpeellinen?

Testauksen laajentaminen kytkinten ympärillä voi johtaa niin sanotun "kombinatoriisen testipauhun" syntymiseen, jossa testattavia skenaarioita kertyy valtavasti. Tämän estämiseksi kytkimien määrää kannattaa rajoittaa mahdollisimman pieneksi. Yksi tapa on kyseenalaistaa, onko itse kytkintä ylipäätään tarve käyttää. Jos ominaisuuden kehitystyö voidaan tehdä pieninä osina siten, että käyttäjäkokemus muuttuu viimeisenä vaiheena, ei kytkintä välttämättä tarvita ollenkaan.

Jim Birdin mukaan feature toggles ovat yksi pahimmista teknisen velan muodoista. Hänen mukaansa näiden kytkinten käyttö tekee järjestelmän tukemisesta ja virheiden jäljittämisestä yhä vaikeampaa, koska suurten määrien konfiguraatioiden käsitteleminen voi tehdä tuotantoympäristössä ilmenevien ongelmien jäljittämisestä erittäin haastavaa. Tämä on tärkeä huomio erityisesti pitkälle kehitetyissä ja monimutkaisissa järjestelmissä.

Kun testaus tehdään oikein, se voi paljastaa potentiaalisia ongelmia, joita ei välttämättä muuten huomattaisi. Kytkinten hallinta ja niiden testaaminen voivat toimia tehokkaasti ongelmien ennaltaehkäisynä ja parantaa ohjelmiston luotettavuutta ja käyttökokemusta.

Miten hallita riskejä DevOps-ympäristössä?

Riskejä käsiteltäessä keskustelu saattaa jäädä yleiselle tasolle, jolloin pyritään tunnistamaan vain tarvittavat toimenpiteet riskien vähentämiseksi, tai keskustelu voi syventyä tarkempiin yksityiskohtiin. Erityisesti, jos henkilö kokee epämukavuutta riskin vähentämisen käsittelyssä, voi olla hyödyllistä selventää, että kyse ei ole riskin poistamisesta kokonaan, vaan sen hallitsemisesta. Esimerkkinä tästä käytän omaa kokemustani vapaaehtoistyössäni Brownie-johtajana. Yhdessä leirikeskuksista, joissa pidämme yöpymisleirejä, on portaikko, jota käytetään wc-tiloihin, jotka sijaitsevat alemmassa kerroksessa. Riskin vähentämiseksi siitä, että tyttö voisi kaatua portaissa yöllä, pidämme portaat valaistuina. Tämä ei tarkoita sitä, että kukaan ei voisi kaatua portaissa, mutta se merkittävästi vähentää kaatumisriskin todennäköisyyttä. Riski on vähennetty, mutta ei poistettu.

Agile-testauksessa käytettävä testipyramidi on ollut laajalti tunnettu käsite. Mike Cohn kehitti sen vuonna 2009, ja se jakaa testaukset kolmeen kerrokseen: yksikkötestaukseen, integraatiotestaukseen ja loppukäyttäjätestaukseen. Tämä pyramidimalli kannustaa kehitystiimejä tarkastelemaan automaatiotestauksen jakautumista eri tasoille. Yksikkötestit, jotka ovat tarkkoja ja yksittäisiä toiminnallisuuksia testaavia testejä, tulisi tehdä suurissa määrin. Käyttöliittymätestejä, jotka testaavat koko järjestelmää, tulisi olla vähemmän. Viime vuosina testausyhteisössä on kuitenkin kasvanut tyytymättömyys testipyramidin laajalle ja yksinkertaiselle hyväksymiselle testausstrategian pohjaksi. Ei ole aina selvää, että testipyramidi sopii kaikille projekteille ja kaikille tiimeille. Ei ole myöskään aina niin, että tehokkaat automaattiset testipaketit noudattavat pyramidin kuvaamaa jakautumista. Itse asiassa, monet testausasiantuntijat ovat hylänneet tämän perinteisen mallin ja esittäneet vaihtoehtoisia malleja.

Tässä lähestymistavassa on kiinnostava idea siitä, että virheitä voi siirtyä kerroksesta toiseen, ja joitakin voi jäädä huomaamatta. DevOps-ympäristössä tämä ajatus voi auttaa meitä ymmärtämään, että virheitä voi syntyä missä tahansa tuotteen toiminnallisuudessa, ja niitä voidaan havaita eri tasoilla. Kuvitellaanpa käyttäjärekisteröintifunktio. Saattaa olla virhe, jossa lomake ei hyväksy oikeaa puhelinnumeroa, ja toinen, joka estää käyttäjää suorittamasta rekisteröitymistä. Pienet virheet ovat tarkasti määriteltyjä epäonnistumisia, jotka on yleensä helpompi tunnistaa ja korjata. Ne on myös helpompi testata. Kun virheen syy ei ole selvä, tarvitaan testejä, jotka lähestyvät ongelmaa laajemmasta näkökulmasta. Loppukäyttäjätestaus auttaa tunnistamaan isompia ongelmia, jotka saattavat jäädä huomaamatta yksittäisissä yksikkötesteissä.

Tässä yhteydessä voidaan myös tutkia, kuinka virheiden suodattaminen toimii DevOps-ympäristössä. Yksikkötestit keskittyvät puhtaasti ohjelmiston koodiin, mutta integraatiotestit voivat sisältää tietokantoja tai ulkoisia web-palveluja. Loppukäyttäjätestaus kattaa vielä laajemman arkkitehtuurin. Virheitä voi ilmaantua näissä uusissa järjestelmissä ilman, että ne ovat käyneet aiemmassa suodattimessa. Lisäksi virheitä voi ilmetä, kun ohjelmisto siirtyy tuotantoon, sillä käyttäjät tuovat mukanaan omat odotuksensa ja käsityksensä ohjelmiston toiminnasta. Käyttäjät saattavat kokea toiminnan virheelliseksi, vaikka se ei ole teknisesti virhe.