Kaikki toimijat ilmoittavat nykyään olevansa ketteriä. Ketterä projekti on siis iteratiivinen ja inkrementaalinen ponnistus, jonka sisältö joustaa, jos aikataulu tai budjetti ei jousta. Eli siis projektin lopputulos ei ole alussa tarkasti selvillä. Ketteryys ei itsestään takaa hyvää lopputulosta. Jos tilaajalla ei ole ns. isot linjat selvillä ja priorisointikyky puuttuu, niin projektilla ei oikein ole onnistumisen edellytyksiä.
Yleisin virhe laadunvarmistuksen näkökulmasta on, että kehitysjaksoon tungetaan liikaa sisältöä. Kaikki uudet toiminnallisuudet ovat yhtä tärkeitä ja niiden pitää olla samaan aikaan valmiita. Tämä ei eroa mitenkään vanhasta V-mallin meiningistä. Tämän seurauksena voi olla esim. seuraavia asioita:
- määrittelyt ovat pahasti puutteellisia ja priorisointi puuttuu
- uudet toiminnallisuudet on saatu toteutettua, mutta ne eivät toimi odotetusti
- vanhoissa toiminnallisuuksissa ilmenee virheitä
- automaatiotestit ovat jääneet tekemättä ja/tai päivittämättä
- teknistä velkaa on kertynyt lisää
Olen todistanut tilannetta, jossa kaikkea uutta toiminnallisuutta ei saatu valmiiksi. Kuitenkin tehty uusi toiminnallisuus ja kaikki vanhat toiminnallisuudet toimivat odotetusti, joten käyttöönotto oli mutkatonta. Silti yrityksessä nosti äläkän yksi tuoteomistaja, koska juuri hänen haluamaansa toiminnallisuutta ei saatu tässä jaksossa valmiiksi.
Sinänsä on yhdentekevää, millä mallilla projekti tehdään, koska testauksessa pitää aina huomioida vähintään kaksi toisiaan täydentävää näkökulmaa:
- tekninen testaus, jossa tarkastetaan, onko järjestelmä, palvelu tai niiden osa tehty teknisesti oikein ja toimii suunnitellusti ja testit pohjautuvat tuotekehityksen suunnitteludokumentteihin sekä vaatimuksiin
- käyttöön liittyvä testaus, eli onko järjestelmä, palvelu tai niiden osa valmis otettavaksi käyttöön ja tukeeko se loppukäyttäjien työtä, ja testit pohjautuvat käyttötapauksiin sekä käyttäjäryhmien tarpeiden tunnistamiseen esim. haastattelemalla tai testaamalla yhdessä
Ensin mainitusta puhutaan enemmän, koska siihen liittyy mm. yksikkötestaus, testauksen automatisointi ja vahvasti myös DevOps. Toinen näkökulma unohdetaan aika usein, koska siihen liittyy ei-toiminnallisia ominaisuuksia esim. käytettävyys ja saavutettavuus ja se on usein hankalampaa testattavaa.
Tähän tarvitaan järjestelmä, joka on yrityksessä laajassa käytössä esim. loppuasiakkaiden mobiiliapplikaatio, jonka avulla pääsee käsiksi taustajärjestelmien tietoihin. Tai sitten perinteisemmät CRM-, ERP- tai potilastietojärjestelmät. Eri käyttäjäryhmien käyttötarpeisiin pohjautuvaa testausta ei ole niin helppo järjestää, kuin jonkun määritellyn rajapinnan testaaminen.
Ketterä projekti tarvitsee onnistuakseen:
- yhteisen tavoitteen ja vastuun lopputuloksesta
- yhteistyökykyä tilaajan ja toimittajien kesken
- priorisointia, jotta tiedetään tekemisen tärkeysjärjestys
- tilaajan ja toimittajien tekemänä koko ajan tapahtuvaa laadunvarmistusta sekä testausta
