Onnistuuko laadunvarmistus, jos testauspäälliköitä ei päästetä ketterään ympäristöön? Säilyykö ketterän ympäristön psykologinen turvallisuus, jos virheitä eksyy tuotantoon? Synnyttääkö hajanainen laadunhallinta syyttelyä, vastuun välttelyä ja hallitsemattomuutta?
Perinteisesti saatetaan ajatella, että testausta suunnittelevan, koordinoivan ja raportoivan testauspäällikön paikka on vain selkeästi määritellyissä projekteissa. On kuitenkin todettava, että erityisesti ketterissä ympäristöissä tarvitaan hyvän laadunhallinnan mahdollistajaa, joka toimii kaikkien eri toimintatapojen, tiimien ja ympäristöjen yli. Laadukas lopputulos edellyttää sitä, että laadun elementit ovat sisäänrakennettu kaikkeen tekemiseen ja organisaatiokulttuuriin, yhtenä osana ketteriä käytäntöjä.
Testiautomaation voidaan sanoa olevan pakollinen osa kokonaisuutta tai testauksen toimivan osana kehitystiimejä. Valitettavan usein kohtaan kuitenkin tilanteita, joissa tiimien sijaan testaus ja laadunvarmistus ovat siiloutuneet. Joissain tapauksissa testaus validoi yksittäisiä tikettejä, jonka lisäksi testiautomaatiofunktio voi löytyä erillisenä kokonaisuutena. Saattaa olla, että kehittäjät tekevät ajoittain yksiköiden välistä integraatiotestausta. Erillisissä yksiköissä kenelläkään ei ole kuitenkaan mahdollisuutta kertoa kokonaisvaltaisesti, mitä on testattu ja kuinka kattavasti.
Kukaan tuskin toivoo laadunvarmistajaa nurkkiin kertomaan kerta toisensa jälkeen, että kenen koodista se vika taas löytyi. Tästä huolimatta tehtävän toteutuksen ja tarvittavan testauksen suhdeluku on saatava riittävälle tasolle, jotta toteutuksen kokonaislaatuun voidaan luottaa. Testauksen ja toteutuksen suhteeseen ei löydy yksiselitteistä ratkaisua, mutta on muutamia lähtökohtia, joista onnistumista voi lähteä etsimään:
1. Laadun vaatimusten asettaminen
Laadun vaatimukset tulee asettaa ja kuvata. Voidaanko testausta suunnitella jo tässä vaiheessa tai ennen kehittämistä? Millä tasolla testaus suunnitellaan, esimerkiksi kehityksen käyttäjätarinoiden vai suurempien kokonaisuuksien pohjalta? Nimetäänkö vastuullinen testaaja kokonaiselle prosessille tai toiminnallisuudelle? Vaatimusten määrittely vaatii hyvää kommunikointia sekä tiedon ja vastuun jakamista.
2. Kehitysprosessin määrittely
Kehityksessä käytettävä prosessi on määriteltävä. Minkälaisia laatuportteja kehitysputken varrella sijaitsee? Millaisia käytäntöjä ja työkaluja koodien yhdistämiseen käytetään ja katselmoidaanko koodit? Millainen yksittäisen tiketin työnkulku on koko matkan läpi suunnittelupöydältä tuotantokäyttöön saakka? Voidaanko viestintää helpottaa esimerkiksi automaattisilla julkaisumuistioilla?
3. Testiautomaation valinnat
Testiautomaatio on edellytys toimivalle ketterälle ja jatkuvalle testaukselle. Kehityksessä on valittava, mitä automatisoidaan ja mitä kannattaa jättää manuaaliseen testaukseen. Lisäksi on päätettävä, sisällytetäänkö testitapaukset osaksi regressiotestausta. Arviot testiautomaation järjestämisestä vaativat tietämystä niin liiketoiminnasta ja teknologiasta kuin esimerkiksi kompleksisuudesta ja riskialttiudesta.
4. Tavoitteena läpinäkyvyys
Läpinäkyvyydellä tarkoitetaan tässä yhteydessä helposti saatavilla olevaa tietoa merkityksellisistä asioita. On siis keskeistä osata arvioida, mitkä asiat ovat oikeasti merkityksellisiä. Usein esimerkiksi testauksen kattavuus tai läpimenneiden testitapausten määrä eivät kerro todellisuudesta mitään. Joskus minulta on pyydetty arviota siitä, miltä testauksen läpimenoprosentti näyttää ensi viikolla, mutta tätä kristallipalloa en valitettavasti omista. Läpinäkyvyyttä voi edistää yhteisellä dashboardilla, joka koostaa useammasta työkalusta tarvittavat tiedot yhteen näkymään. Dashboardin sisältö voidaan käydä läpi esimerkiksi kvartaaleittain, koska merkityksellinen tieto saattaa muuttua ja elää hyvinkin nopeasti.
5. Vastuu kokonaisuuden hallinnasta
Kokonaisuudesta vastaava henkilö, esimerkiksi testauspäällikkö, laadun mahdollistaja tai laadun valmentaja, luo struktuuria laadunvarmistukseen ja toimitusten kokonaislaatuun. En väitä, etteikö testauskokonaisuuden hallinta onnistuisi myös testaajilta, mutta he ovat usein vain yhdessä tiimissä, eivätkä tunne kokonaisia liiketoimintaprosesseja riittävällä tasolla. Heillä ei välttämättä ole myöskään riittävästi aikaa perehtyä muiden tiimien toimintaan, joilla voi olla omat käytäntönsä. Yksi valmentaja on joskus todennut, että vaikka asiat näyttäisivät tänään samalta kuin eilen, se ei takaa sitä, että ne olisivat hallinnassasi.
Varmista digitaalisten palveluidesi laatu ja turvallisuus
