Laadusta laadunvarmistuksen strategiaan
Edellisessä blogissani käsittelin laatua. Kuten laatu, on laadunvarmistus myös asia, jota ei voi määritellä yhdellä tavalla. Oikein rakennettu laadunvarmistus perustuu aina yrityksen ja tuotteen laatuvaatimuksiin ja arvoihin. Laadunvarmistuksen strategia kuvastaakin niitä tavoitteita, joihin yritys haluaa kokonaisuutena suunnata tai mihin he haluavat edetä tuotteen kanssa.
Laadunvarmistusstrategian käsite
Laadunvarmistuksen strategia on aina riippuvainen siitä, mitä varten se on luotu. Esimerkiksi yritykselle se on täysin erilainen kuin ohjelmistolle. Siinä missä yritys voi kohdistaa toimensa esimerkiksi henkilöstöön tai viestintään, voidaan ohjelmiston osalta keskittyä suorituskykyyn, toiminnallisuuteen tai esimerkiksi käytettävyyteen. Yrityksellä voikin olla monia erilaisia strategioita laadunvarmistuksen varalle, ja itse sanoisin jopa että pitäisikin olla.
Kaikkia näitä laadunvarmistuksen strategioita yhdistää kuitenkin se, että ne pyrkivät estämään riskien toteutumisen. Laadunvarmistuksen strategia voidaankin määritellä sarjaksi toimenpiteitä, joita toimija tekee estääkseen ongelmien syntymisen jonkin kokonaisuuden osalta.
Tekoälyn muuttaessa tuotekehityksen kenttää, onkin tärkeää kiinnittää yhä enemmän huomiota sopivien turvaverkkojen luomiseen tekoälyä hyödynnettäessä. Monia laadunvarmistustoimia voidaan myös toteuttaa tekoälyn avulla, mutta tekoäly ei poista tarvetta lisätä painotusta laadunvarmistuksen strategiaan ja -toimenpiteisiin, päinvastoin.
Oli kyse sitten tekoälystä tai perinteisemmästä laadunvarmistuksesta, voidaankin sanoa, että kaikki toimet jotka pyrkivät estämään ongelmia ovat lähtökohtaisesti laadunvarmistustoimia. Ei ole yhtä oikeaa tapaa rakentaa näistä stategiaa laadunvarmistukselle, mutta on olemassa hyviä lähtökohtia!
Esimerkki laadunvarmistuksen strategian toimista
Kollegani Szilard Szell antaa hyvän esimerkin loistavasta laadunvarmistuksen toimesta. Esimerkki on Legoista ja siitä, mitä Lego tekee jo ennen kuin pakkaus lähtee tehtaalta. Jos olet joskus rakentanut Legoja, olet saattanut huomata, että Lego-paketeissa on aina ylimääräisiä pikkuosia. Vaikka voi tuntua epäloogiselta että yritys jakaa ylimääräisiä osia, on Legon toiminnassa logiikka.
Kuvittele tilanne, jossa rakennat Lego-settiä lapsen kanssa ja kohtaat tilanteen, jossa pieni osa puuttuu pakkauksesta. Omasta näkökulmastasi sinä tai lapsesi todennäköisesti harmistutte, koska ette saa rakennelmaa valmiiksi. Seuraavaksi edessä olisikin reklamaatioprosessi tai paketin vieminen takaisin kauppaan. Jos päätät tehdä reklamaation, kestää Legolla jonkin aikaa käsitellä reklamaatio ja sen jälkeen saada osa postitse. Kaupasta saisi ehkä uuden paketin, mutta silloinkin koko rakennusprosessi pitäisi aloittaa alusta. Kokonaisuutena kokemus olisi varmaankin pettymys.
Legon näkökulmasta yllä olevan tilanteen käsittely vaatisi ylimääräistä vaivaa asiakaspalveluorganisaatiolta reklamaatioiden käsittelyyn, varastotoiminnalta pakkausten käsittelyyn ja postipalvelulta lisäpostituksiin. Tätä voi tietysti pitää pakollisena osana yrityksen toimintaa, ja sitä se tietysti onkin.
Jos kuitenkin alkaa pohtia asiaa, muutaman osan lisääminen per paketti voisi poistaa paljon yrityksen kustannuksia reklamaatioiden käsittelyssä, pakkaamisessa ja pakkausten lähettämisessä. Vaikka reklamaatiot ei tietysti täysin häviäisi, mahdollinen suuri vähennys tarkoittaisi suuria säästöjä yritykselle.
Jos mietitään vielä pidemmälle mahdollisten suorien säästöjen lisäksi: kuinka paljon arvoa Lego saa tyytyväisistä asiakkaista? Arvo lisääntyneestä laadusta? Brändiarvo? Asiakkaiden mielenrauha siitä, että on ylimääräisiä pieniä, helposti katoavia osia varalla? Jos vertailemme näitä hyötyjä muutaman ylimääräisen osan lisäämisen kustannuksiin, ei asiaa tarvitse mielestäni edes miettiä. Lisäämällä muutama pieni muoviosa jokaiseen pakkaukseen voidaan saavuttaa kaikki nämä hyödyt. Ja hyödyt saavutetaan vielä automatisoiduilla tuotantolinjoilla, jotka ovat jo olemassa.
Tämänkaltainen toiminta on laatuajattelua, josta puhuin edellisessä blogissani. Asiakkaan tarpeiden ymmärtäminen ja tuotteen rohkea kehittäminen on tapa parantaa laatua.
Yleinen harhaluulo: ”laadunvarmistus = testaus”
Asiakaskentässä ja esim. LinkedInissä näen paljon väärinkäsityksiä siitä, että laadunvarmistus tarkoittaa testausta. Mutta jos tarkastelemme tarkemmin näitä kahta käsitettä, voimme todeta niiden olevan itse asiassa vastakkaisia toimia.
Ero on siinä, että laadunvarmistus pyrkii rakentamaan käytäntöjä ja prosesseja estääkseen riskien toteutumisen, kun taas testaus on laadunvarmistuksen toimenpide, jossa pyritään löytämään ongelmia, joita muut laadunvarmistuksen toimet eivät ole huomanneet.
Selventääkseni tätä vielä: täydellisessä maailmassa laadunvarmistustoimet ovat niin hyviä, ettei testausta tarvita. Näin ei tietenkään koskaan ole, sillä virheitä tapahtuu aina. Testaus voi tietysti olla heikko lenkki, mutta monissa tapauksissa testauksen lisääminen ei ole polku parantuneeseen laatuun, vaikka se aluksi siltä näyttäisikin.
Menestyvän laadunvarmistuksen strategian rakentaminen ohjelmistolle
Kun aloitan laadunvarmistuksen strategian rakentamisen, aloitan aina tietyistä alueista ennen kuin siirryn konkreettisten toimien valintaan. Itse lähden liikkeelle viidestä eri alueesta:
- Tunnista ohjelmiston ydintarkoitus: Ilman ohjelmiston kehittämisen syyn selvittämistä on mahdotonta aloittaa laadunvarmistuksen suunnittelua. Jokaisella tuotteella tai ohjelmistolla on eri tavoitteet. Muista Lego-esimerkistä, että kyse ei ole vain toiminnallisuudesta ja tuotteen toimivuudesta. Laadunvarmistus voi olla monimuotoista!
- Ovatko tarvittavat ohjelmistokehityksen osat paikoillaan? On tärkeää, että laadunvarmistustoimien tuki on olemassa jo ennen niiden toteuttamista. Laadunvarmistus liittyy oleellisesti aina kaikkiin kehitystiimin toimiin, eikä se ole yksittäisen toimijan vastuulla. Laadunvarmistustoimet näillä alueilla voivat vaihdella tuoteajattelusta varsinaisiin ohjelmistokehityskäytäntöihin.
- Nykyiset valmiudet eri QA-toimille: Usein on tarpeen rakentaa perustuksia ennen kuin laadunvarmistustoimet voidaan toteuttaa onnistuneesti. Nämä toimet voivat vaihdella uuden roolin perustamisesta yksinkertaisiin ohjelmistoasennuksiin tai esimerkiksi CI-putkien rakentamiseen. Tärkeää on myös varmistaa, että olemassa olevat rajoitukset on tunnistettu.
- Nykyinen tilanne: Tunnista tuotteen nykyinen laadunvarmistuksellinen tilanne. Laadunvarmistuksen strategiaa ei pidä tehdä vain strategian luomisen vuoksi. Sen on aina pyrittävä estämään mahdollisia ongelmia joita kehityksessä tulee vastaan.
- Ketkä ovat tuotteen käyttäjät? Yritä tunnistaa käyttäjät ja mikä on heille tärkeää tuotetta käyttäessään. On täysin eri asia suunnitella laadunvarmistuksen strategia esimerkiksi yrityksen sisäiselle ohjelmistolle, jolla on satoja käyttäjiä, kuin sovellukselle, joka ladataan mobiilikauppojen kautta ja jota käyttää miljoonia käyttäjiä.
Dokumentaatio on pakollista
Laadunvarmistuksen strategian rakentamisen tylsä osa on dokumentointi. Se on vain yksinkertaisesti tehtävä. Tiedän, että tämä ei ole osa josta ihmiset yleensä nauttivat, mutta strategian ei tulisi olla vain jonkun päässä. Dokumentointi on osa laadunvarmistuksen strategiaa vähentää riskiä pullonkauloista, ja dokumentoimaton strategia luo väistämättä pullonkaulan.
Sisällön tulisi myös kuvastaa tekemääsi selvitystyötä. Mutta helpottaakseni hieman tuskaa, me Eficodella suosittelemme jakamaan kirjoittamisen vähintään ajattelutasolla kolmeen eri osaan:
- Proaktiivinen laadunvarmistus: Mieti, mitä toimia tarvitaan ennen varsinaisen ohjelmistokehityksen aloittamista. Mitä yrityksesi tekee tukeakseen kehitystä? Onko vaatimusten ja spesifikaatioiden hankkimisprosessi kunnossa ja miten varmistetaan, että ne heijastavat liiketoiminnan ja käyttäjien tarpeita?
- Tarkistava laadunvarmistus: Mitä laadunvarmistustoimia teet kehityksen aikana? Varmistatko, että jokainen ohjelmiston osa on laadunvarmistustoimenpiteiden alaisena? Miten koodia kehitetään? Testataan? Otetaan käyttöön?
- Reaktiivinen laadunvarmistus: Mitä toimia teet kehityksen jälkeen? Miten tuet yritystä parantamaan olemassa olevia ominaisuuksia? Mittaatko ja seuraatko mitä tuotannossa tapahtuu? Miten palaudut ongelmista (esim. tuotantoympäristön kaatuminen)?
Päästäksesi alkuun laadunvarmistustoimien kanssa
Kun olet määritellyt tuotteen laatuominaisuudet, on olemassa todella monia laadunvarmistuksen toimia, jotka voit valita osaksi laadunvarmistusstrategiaasi.
Jotta blogi ei menisi täysin teoriaksi, niin tässä muutama oma suosikkini, jotka sopivat melkein jokaiseen ohjelmistokehitysprojektiin:
- Proaktiivinen: ATDD (Acceptance Test Driven Development). Tämä on poikkeuksellisen tehokas työkalu, joka tukee koko kehitysprosessia, ohjaa tiimejä tekemään samoja asioita, selventää vaatimuksia spesifikaatioiksi ja tukee jopa tekoälyn hyödyntämistä kehityksessä.
- Tarkistava: Keyword-pohjainen testiautomaatio CI-ympäristöissä Robot Frameworkilla, yhdistettynä tutkivaan testaukseen (Atlassianin XRay Test Management for Jiran kanssa). Mainitun kaltainen testiautomaatio sopii hyvin yhteen ATDD:n kanssa. Yhdessä asianmukaisten CI-putkien kanssa tämä voi säästää organisaatiosi monilta ongelmilta. Automaatio vapauttaa myös testaajille aikaa löytää ongelmia tutkivalla testauksella sen sijaan, että aika kuluisi triviaalien testausaktiviteettien parissa.
- Reaktiivinen: “Chaos engineering”, menetelmä, jota käytetään laajentamaan ajattelua ja tekemään asioita, joiden ei koskaan pitäisi tapahtua, mutta jotka silti joskus tapahtuvat. Tämä on todella hauskaa puuhaa ja sillä voi säästää yrityksesi suurilta ongelmilta. Tässä saa antaa mielikuvituksen juosta. Toimet voivat olla mitä tahansa verkkokaapeleiden irrottamisesta palvelinhuoneessa (jos vielä käytätte fyysisiä palvelimia) tai virheinjektiotyökalujen käyttämistä esimerkiksi kaatamaan Kubernetes-podeja, tilanteissa missä niiden ei pitäisi sammua. Tärkeintä on luoda sekasortoa järjestelmään ja katsoa, miten se selviytyy!
Yhteenveto
Laadunvarmistusstrategia on monimuotoinen käsite, joka tulisi räätälöidä kuvastamaan yrityksen tai tuotteen erityisiä laatutavoitteita. Laadunvarmistus ei ole pelkkää testausta, vaan siihen kuuluu ennakoiva lähestymistapa riskien estämiseksi ja sen varmistamiseksi, että laatu rakennetaan prosessiin alusta alkaen. Ymmärtämällä tuotteen laatutavoitteiden ydintarkoituksen, linjaamalla laadunvarmistustoimet kehityksen kanssa ja keskittymällä loppukäyttäjiin, voit luoda tehokkaan strategian laadunvarmistukselle. Muista, että menestyksekäs laadunvarmistuksen strategia vaatii perusteellista dokumentointia sekä proaktiivisten, tarkistavien ja reaktiivisten toimenpiteiden tasapainoa jatkuvan parantamisen tukemiseksi.
P.S. Jos haluat lisätietoja kattavan laadunvarmistusstrategian luomisesta tasapainoisen laatumallin avulla, voin suositella Szilard Szellin webinaaria Eurostarista (englanniksi).
Julkaistu: 22. lokakuuta 2024
