Asiakas on verkko-oppimisalusta, jossa on interaktiivisia oppitunteja, kotitehtäviä, oppilaiden ja vanhempien tilejä sekä verkkomaksut. Liiketoiminta on erittäin kausiluonteista: syyskuussa aloittaa eniten uusia oppilaita, ja alustan käyttökatko lukuvuoden ensimmäisinä viikkoina tarkoittaa asiakkaiden pysyvää menetystä. Oma QA-tiimi puuttui; kehittäjät testasivat muiden tehtävien lomassa. Julkaisua edeltävä regressiotestaus kesti kolme päivää, mutta kriittiset tilanteet — maksu, oppitunnille ilmoittautuminen ja luokkaan liittyminen — jäivät silti havaitsematta. Asiakas tuli luoksemme jälleen yhden häiriön jälkeen: maksuvika vei koululta osan kesän aikana keräämistään liideistä.
Luoda laadunvarmistusprosessi alusta alkaen:
liiketoimintariskien mukaan priorisoitu testausstrategia, keskeisten tilanteiden automatisointi, CI-tarkistukset ja kuormitustestaus ennen syyskuun ruuhkaa. Rajoitteena oli kehitystyön jatkuminen: julkaisuja tehtiin viikoittain eikä syyskuu voinut odottaa.
Aloitimme riskianalyysista, emme automaattitesteistä: mitkä tilanteet rikkoutuvat useimmin ja missä vian hinta on suurin? Automatisointi eteni tiukasti tämän luettelon mukaan.
- Auditoimme laadun: kävimme läpi viimeisen puolen vuoden virheet, haastattelimme tiimejä ja kartoitimme kivuliaimmat tilanteet — maksaminen, oppitunnille ilmoittautuminen, luokkaan liittyminen ja vanhempien ilmoitukset.
- Kirjoitimme testausstrategian: testaustasot, vastuualueet, ominaisuuden valmiin määritelmä ja virheraportoinnin käytännöt, jotka ovat yhteisiä kolmelle kehitystiimille.
- Automatisoimme kriittisen polun: Playwrightin päästä päähän -skenaariot verkkopalvelulle, API-testit taustajärjestelmälle sekä smoke-testisarja ennen jokaista julkaisua.
- Lisäsimme QA-portit CI:hin: julkaisua ei voi tehdä ennen kuin smoke-testisarja menee läpi, koko regressio ajetaan joka yö ja tulokset näkyvät kaikille tiimeille GitLabissa.
- Teimme k6-kuormitustestit syyskuun huippuliikennettä mallintaen, löysimme pullonkaulat ja poistimme ne yhdessä taustajärjestelmätiimin kanssa ennen sesonkia.
- Siirsimme prosessin asiakkaan vastuulle: dokumentaatio, toimintatavat ja QA-insinöörin koulutus automaattitesteihin sekä julkaisuprosessiin.
Ratkaiseva valinta oli priorisoida liiketoimintariskin, ei ”testikattavuuden kauneuden” perusteella. Emme tietoisesti tavoitelleet täydellistä automaatiota: kriittisten tilanteiden 75 prosentin kattavuus tuotti suurimman osan vaikutuksesta, koska se suojasi juuri niitä polkuja, joilla alusta ansaitsee rahaa ja menettää asiakkaita. Muu osa katetaan manuaalisella tutkivalla testauksella ennen merkittäviä julkaisuja.
Tärkein taloudellinen vaikutus oli virheiden havaitsemisen siirtyminen aikaisemmaksi: CI-automaattitestissä löytyvä vika maksaa kymmeniä kertoja vähemmän kuin oppilaan vanhemman tuotannossa huomaama virhe. Alusta aloitti sesongin turvamarginaalilla, ja tiimit pystyivät julkaisemaan muutoksia usein pelkäämättä ”perjantai-ilmiötä”. Lisähyöty oli liiketoiminnan luottamus: myynti voi nyt luvata kumppanikouluille rehellisesti vakaan alustan ilmoittautumishuipun aikana.
| Mittari | Tulos |
|---|---|
| Kriittiset tuotantovirheet | 5–7 kuukaudessa → 1–2 vuosineljänneksessä |
| Julkaisua edeltävä regressio | 3 päivää käsin → 4 tuntia automaattitesteillä |
| Syyskuun kuormitushuippu | Häiriöitä joka vuosi → 0 häiriötä, ei suorituskyvyn heikkenemistä |
| Milloin vika havaitaan | Useimmiten tuotannossa → Automaattitestit löytävät ennen julkaisua |
Tunnusluvut on siirretty tapausmateriaalin alkuperäislähteestä. Ajanjakso ilmoitetaan siellä, missä se on lähteessä määritelty.
- kriittisiä virheitä vuosineljänneksessä (oli 5–7 kuukaudessa)
- 1–2
- regressio automaattitesteillä (oli 3 päivää käsin)
- 4 h
- avainskenaarioista automaattitestien piirissä
- 75%
- häiriöitä syyskuun huipussa
- 0
Havainnollistava asteikko: 3 päivää muunnetaan 72 tunniksi. Pylväiden pituutta varten kuukausittainen virhemäärä skaalataan neljännekseen kertomalla kolmella; vertailussa käytetään vaihteluvälien ylärajoja.
- 01Commit
- 02Smoke-testisarjaEi läpäisyä, ei julkaisua
- 03JulkaisuViikoittain
- 04YöajoTäysi regressio
Suosittelemamme seuraavat askeleet alustalle:
- Visuaalinen regressiotestaus — oppituntien, sähköpostien ja henkilökohtaisten tilien ulkoasun automaattinen tarkistus.
- Testidatatehdas — realististen oppilaiden, ryhmien ja maksujen luominen jokaista testiajoa varten.
- QA tuotannossa — feature flagit ja canary-julkaisut uusien ominaisuuksien asteittaiseen käyttöönottoon.
Emme enää pelkää julkaisuja. Ennen jokainen perjantai saattoi muuttua valitusten selvittelyksi, mutta nyt tuotantoon julkaisu on rutiininomainen viidentoista minuutin toimenpide.
— Verkkokoulun teknologiajohtaja