1. Ketterä
hyväksymistestaus
Antti Auer, Laatupäällikkö, OP-Palvelut Oy

2. Sisällys
Vuoropuhelu ja keskustelu hyväksymistestauksen
kokemuksista
• Hyväksymistestaus ja ketteryys
• Hyväksymistestauksen problematiikka alihankinnassa
• Miten hyväksymistestausta voitaisiin ketteröittää?
11.4.2013

3. Omasta toimialueesta
• OP-Palvelut Oy, palvelukehitys
• Mobiilisovellukset, sähköinen myynti, digitaalinen markkinointi
• Yli 200 000 mobiilikäyttäjää (Android, iPhone, Windows Phone)
• Rahasta kyse -> tiukat laatukriteerit tuotantoonvientiin
• n. 100 hengen joukko Oulussa, tuotehallinta koko elinkaarelta
• Ketterät menetelmät, alihankintaa
11.4.2013

4. Hyväksymistestaus
• Tavoitteena on varmistaa ohjelmiston olevan laadultaan ja
ominaisuuksiltaan riittävän hyvä julkaisua varten
• Hyväksymistestauksessa testataan kokonaista valmista tuotetta tai sen
inkrementtiä ympäristössä, joka vastaa tuotantoympäristöä
• Osoitetaan, että vaatimukset täyttyy; virheitä ei enää odoteta löytyvän, joten
ajallisesti sen pitäisi sujua lyhyessä ajassa
• Käytännössä hyväksymistestauksella voidaan tarkoittaa
• vimeistä vaihetta, jossa kesken jääneet testaukset saatetaan loppuun
(integrointi- ja järjestelmätestaus). Suunnittelu aloitetaan usein aivan liian
myöhään ja perustuen teknisiin dokumentteihin
• sisäisiä ja ulkoisia pilotointeja ja käytettävyystutkimusta ennen käyttöönottoa
• liiketoiminnan tekemää kokeilua/katselmusta/todennusta
• tilaaja-toimittaja –suhteessa tilaajan itsensä suorittamaa hyväksymistestausta
• mitä tahansa keinoa, jolla tilaaja todistaa itselleen, että toimittajan työ voidaan
hyväksyä ja lasku maksaa
 Hyväksymistestaus voi olla vaikka kuinka työläs ja johtaa raskaaseen
muutoshallintaan ja pitkittyneeseen aikatauluun
11.4.2013

5. Ketterät menetelmät
• Ovat syntyneet vastareaktiona perinteisemmän
muutoshallinnan jäykkyydelle.
• Ketteryys tarkoittaa sitä, että pystytään reagoimaan ja
toteuttamaan muutoksia sekä oppimaan muutoksista,
jotta voidaan tuottaa jatkuvasti lisäarvoa asiakkaalle.
• Sisältävät usein ajatuksen siitä, että tuottava tiimi
kykenee itsenäisesti hoitamaan tuotteen alusta loppuun,
mukaan lukien kaiken testauksen ja ylläpidon.
11.4.2013

6. Ketterät menetelmät ja testaus
• Skaalautuvuus katsotaan omaksi ongelmaksi; perinteinen
sovellusalue on pienet järjestelmät ja testaus kuvataan
lähinnä yksikkö- ja integrointitestauksen kannalta.
• Ketteriä menetelmiä käytetään eriasteisina sovelluksina
tilaaja-toimittaja –suhteissa
• Esimerkiksi toimittaja tekee ketterillä menetelmillä sovelluksen,
jolle tilaaja tekee hyväksymistestauksen
• On kuitenkin muistettava, että kokonaisuuden ketteryys ratkaisee.
Ei paljon auta, jos kehitys on nopea, mutta testaus kestää kauan.
11.4.2013

7. Hyväksymistestauksen problematiikasta
• Useita erilaisia tapoja hankkia kehitystä alihankinnalla
• Osaprosesseittain (määrittely, toteutus, testaus, käyttöönotto)
• Mikä on lopputuloksen ketteryys?
• Kiinteällä hinnalla osatoimitus tai kokonaistoimitus
• Voidaanko ylipäätään ennustaa, että muutoshallinta ei muodostu
ongelmaksi? Voidaanko sitten aikataulu ja sisältö pitää?
• Tuntihinnalla
• Mistä tiedetään, että tehdään koko ajan arvoa tuottavaa työtä?
• Asiakkaan tiloissa/toimittajan tiloissa ja kehitysympäristöissä
• Näkyvyys ja testaustulosten paikkansapitävyys
• Perinteisen projektihallinnan ja ketterän kehittämisen sekoituksina
• Roolien ja vastuiden päällekkäisyydet tiimissä ja tiimin johtamisessa
(PO, projektipäällikkö, scrum master)?
11.4.2013

8. Peruskysymyksiä
• Miten saadaan tuotekehitykseen ajoissa riittävää
näkyvyyttä ja muutoshallintaa, jotta
hyväksymistestauksessa ei löydy enää vikoja?
• Tinkimättä hyväksymistestauksen perusperiaatteista
• Sopimusehdot ja muutoshallinta
• Johtoryhmä/Projektipäällikkö/tiimi vastuut
• Voidaanko toimittajaan luottaa?
• Tekninen velka? Metriikkojen todenmukaisuus?
• Ammattitaitoa ja vastuu tehdä itse puuttuvat osat vs. vedota
puutteellisiin määritelmiin?
• Ylläpidon vastuu kolmannella osapuolella
• Dokumentaatio, kompetenssi, hiljainen tieto?
• Tekninen velka!
11.4.2013

9. Keinoja ketteryyteen
• Varmista kehitysympäristöjen toimivuus
• Laajemmissa sovelluksissa erilliset ympäristöt kehitykseen,
integrointi/järjestelmätestaukseen ja hyväksymiseen
• Stabiilisuus kasvaa siirryttäessä ylempään ympäristöön. Kevyet
entry-kriteerit jokaiseen vaiheeseen siirryttäessä (ITIL-mukaiset
CAB:it voi toteuttaa kevyestikin)
• Baseline ajattelu; mikä ja missä on se yhteisesti sovittu
integrointipohja kehitystyötä varten. Integrointi ei saa sotkea
muitten töitä
• Hyväksymistestausympäristö mahdollisimman lähellä
tuotantojärjestelmää
• Alihankkijan ympäristöt mahdollisimman lähellä toimittajan
järjestelmää, jos kehittävät yhdessä samaa järjestelmää. Tai
sovittava, miten yhteinen baseline jaetaan ennen mitään
tuotekehitystä. Tätä ei saa jättää hyväksymistestauksen aikana
päätettäväksi
11.4.2013

10. Keinoja ketteryyteen
• Aloita hyväksymistestaus ajoissa
• Ketterä kehitys tuottaa tuoteinkrementtejä, jotka on
hyväksymistestattava sprinteittäin.
• Tilaaja ja hyväksymistestaaja mukana alusta saakka joka sprintin
hyväksynnässä joko tekemässä tai hyväksymässä. Löytyneet viat
korjattava seuraavassa sprintissä
• ÄLÄ sotke hyväksyntätestausta järjestelmätestaukseen, pilotointiin,
käytettävyystutkimukseen tai liiketoiminnan todennukseen.
• Käytä testauksen ammattilaisia. Älä usko koko tiimin kykenevän
tekemään kaikkia tehtäviä
• Viimeinen hyväksyntätestauskierros on siten vain uusintakierros
regression paljastamiseksi. JOS vikoja löytyy, korjaukset on
priorisoitava niin, että vain julkaisua ESTÄVÄT viat korjataan heti ja
loput siirretään seuraavaan julkaisuun. Päätös yksinomaan
tuoteomistajlle korjauksista.
• Jos mahdollista, kehitä hyväksymistestausautomaatiota tehtyjen
sprinttien hyväksyntätestausten pohjalta (ainakin kuormitustestit)
• Älä missään nimessä kirjaa sopimusehtoihin, että KAIKKI viat kuuluu
korjata, tämä johtaa väistämättä uusiin neuvotteluihin
11.4.2013

11. Keinoja ketteryyteen
• Älä kiinnitä aikataulua ja aloita hyväksymistestausta ennen
kuin olet varma, että kaikki halutut ominaisuudet on tehty.
• Kiinteällä aikataululla yritetään pääsääntöisesti mahduttaa ”vielä yksi
uusi ominaisuus”
• Kiinteähintainen alihankinta sopii vain erittäin harvoille
projekteille
• Muutoshallinta johtaa helposti sopimusneuvotteluihin
• Jos mahdollista, palkkaa alihankkija tuntihinnalla omiin tiloihin
tekemään ketterästi, ohjaavana tekijänä ainoastaan
kokonaisbudjetti koko elinkaarelle
• Lyhyt irtisanomisaika, jos tuotejono ei ala lyhentyä
• Vältä ehdottomasti maantieteellistä hajauttamista sekä tiimin että
johtamisen osalta.
• Älä jaa kehitystiimiä prosesseittain (määrittely, suunnittelu, toteutus,
testaus)
• Älä jaa edes kehityssykliä prosesseittain (sprintin taskeina ei ole
määrittely, toteutus ja testaus)
11.4.2013

12. Keinoja ketteryyteen
• Valtuuta tuoteomistaja tekemään tuotteen
liiketoiminnallisia päätöksiä tuotteen koko elinkaarelta
• Älä kierrätä muutoksia johtoryhmän kautta: tuoteomistaja vain saa
ohjausta johtoryhmältä mutta päättää itse
• Hyväksymistestaus tai ylläpito ei missään nimessä saa olla
projektin ulkopuolella. Liian helposti syntyneet ongelmat kipataan
muualle.
• Hyvää tuoteomistajaa harvoin löytyy heti, mutta yhteistuumin,
selkeällä roolijaolla ja valmentavalla otteella sellainen kehittyy.
• Vähänkin laajemmassa projektissa tuoteomistaja on
PÄÄTOIMINEN. Työtä EI tehdä periaatteella ”jos ehtii”
11.4.2013

13. Keinoja ketteryyteen
• Satsaa ketterään dokumentaatioon
• Wiki-tyyppiset määrittelyt, kuvaukset, testispesifikaatiot yms
täydentyy ja kehittyy projektin aikana.
• Minkään dokumentin valmiusaste ei saa olla esteenä jonkin työn
aloittamiselle. Varmista, että tarvittavat henkilöt ovat aina paikalla
tekemässä muutoksia.
• Dokumenttien jäädytykset tehdään vasta käyttöönoton jälkeen
• Käytä mieluusti integroitua vikahallintaa ja menetelmätyökalua
(esimerkiksi Scrumworks tai Jira), jotta korjaukset saadaan heti
tehtävälistalle. Sen sijaan testaushallintatyökalu voi olla erillinen
(esim. QC)
• Tee tekninen velka näkyväksi joka sprintissä
• Missään nimessä ei saa lakaista ongelmia maton alle, ei
varsinkaan silloin, jos ylläpito siirtyy toiselle organisaatiolle
11.4.2013

14. Lopuksi
• Hyväksyntätestaus on oikeasti haastavaa ja sitä ei pidä
missään nimessä väheksyä eikä aloittaa liian myöhään
• Hyväksyntätestaus on mahdollista olla osa ketterää kehitystä
ja välttää tyypillisiä ongelmia aikataulujen venymisestä tai
laadusta
• Elinkaariajattelu, vastuujako, sopimuskäytännöt, tiimin kokoonpano,
dokumentaatio jne. on mietittävä kokonaisuutena
• Anna ihmisille mahdollisuus ja vastuu päättää yksityiskohdista joka
tasolla. Tee selväksi, että luottamus on ansaittava ja että sen
menettää hetkessä. Luottamuksen puute johtaa tiukkaan kontrolliin,
joka hävittää motivaation tehdä yhtään mitään käskemättä.
• Valmista mallia ei ole, todennäköisesti ketteryys voi kasvaa vain
määrätietoisella kehittämisellä. Jos ei tilaajalla ole ketteryydestä tai
teknologiasta kompetenssia, kannattaa rekrytointi aloittaa kokeneesta
tuoteomistajasta.
• Hyvä valmistelu voi ketteröittää hyväksyntätestausta, mutta varaudu
siitä huolimatta pahimpaan. Kannattaa aina muistaa riskit
testaussuunnittelussa.
11.4.2013

15. KIITOS
• Antti Auer, FT
• Laatupäällikkö, OP-Palvelut Oy
• antti.auer@op.fi
• www.op.fi
11.4.2013