Viime vuosina vastuu testauksesta on jakautunut laajemmalle. Sen sijaan, että erilliset tiimit vastaisivat testauksesta, tiimit kannustavat nyt käyttäjiä, analyytikkoja, kehittäjiä ja testaajia jakamaan testausvastuuta uudelleen paremman yhteistyön tukemiseksi. Siksi joitakin testaustoimintoja ja -vastuita siirretään prosessissa aiemmaksi.
Tässä artikkelissa käsittelen seuraavia aiheita:
- Testauksen siirtäminen prosessissa aiemmaksi
- Testaus toimintana, ei roolina
- Uusi rooli
- Ketterän testauksen väliintulot
- Suhteet kehittäjiin
- Hajautettujen ja ulkoistettujen tiimien haasteet
Testauksen siirtämisen prosessissa aiemmaksi esittely
Testauksen siirtäminen prosessissa aiemmaksi voi tarkoittaa muutamaa eri tilannetta. Se voi tarkoittaa, että kehittäjät ottavat enemmän omistajuutta ja vastuuta omasta testauksestaan. Se voi myös tarkoittaa, että testaajat osallistuvat projektiin aiemmin, haastavat vaatimuksia ja välittävät esimerkkejä kehittäjille käyttäytymislähtöisen kehittämisen (BDD) prosessin kautta.
Joskus se voi tarkoittaa, ettei testaajia ole lainkaan (dun-dun-duuu), jolloin liiketoiminta-analyytikot ja kehittäjät ottavat täyden vastuun testauksesta.
Testauksen siirtäminen prosessissa aiemmaksi ei ole uutta – testauksen puolestapuhujat ovat saarnanneet jo vuosia mantraa ”testaa aikaisin, testaa usein”. Jo vuonna 1993 esitettiin, että kaikki vaiheistetun prosessin tuotokset – sekä dokumentaariset että ohjelmistoon liittyvät – voitaisiin ja usein pitäisi testata.
Testauksen siirtämisessä prosessissa aiemmaksi on pääasiassa kyse siitä, että testaukseen liittyvä ajattelu tuodaan prosessissa aikaisempaan vaiheeseen.
Vaikka vesiputousmalli oli tuolloin hallitseva elinkaarimenetelmä, vaiheiden määrä tai kesto ei ole olennaista. Perusperiaatteena oli, että ohjelmiston suunnittelulle ja kehittämiselle suuntaa antavat tietolähteet tulisi haastaa tai testata.
Vaiheistetussa projektissa tämä voi tarkoittaa muodollisia katselmointeja. Ketterässä projektissa testaaja (tai kehittäjä, liiketoiminta-analyytikko tai käyttäjä) voi ehdottaa skenaarioita, jotka haastavat vaatimuksen tai tarinan laatijan pohtimaan konkreettisia esimerkkejä ja keskustelemaan niistä ennen minkään koodin kirjoittamista.
Nämä ovat tärkeimmät testauksen siirtämiseen prosessissa aiemmaksi liittyvät muutokset:
- Käyttäytymislähtöinen kehittäminen (BDD) on mahdollistanut kehittäjien, käyttäjien/liiketoiminta-analyytikkojen ja testaajien yhteistyön niin sanottujen liiketoimintatarinoiden ympärillä. Testauslähtöistä kehittämistä ovat monet kehittäjät käyttäneet vähintään 15 vuoden ajan. Nykyään BDD:tä otetaan laajemmin käyttöön, koska se edistää parempaa yhteistyötä ketterissä tiimeissä ja tuo samalla kehittäjien käyttöön BDD-työkaluja. Se on helpompi testaus ensin -lähestymistapa.
- Jatkuva toimitus (CD) on ollut käytössä 5–10 vuotta, ja sen juuret ovat suurten verkkoliiketoimintojen edelläkävijänä toimineissa pitkälle automatisoiduissa koonti- ja julkaisunautomatisointimenetelmissä. Nykyään useimmat verkkoläsnäoloa omaavat organisaatiot ovat ottaneet sen käyttöön.
- CD järjesti ja nopeutti julkaisuprosessia automaation avulla. Samalla se kuitenkin toi esiin tuotantoon, käyttöönottoon ja infrastruktuurin muutoksiin liittyvät viiveet, jotka hitaat koonti-, testaus- ja julkaisuprosessit olivat aiemmin peittäneet. DevOps on kulttuurinen ajattelutavan muutos, jossa kehittäjät tekevät paljon tiiviimpää yhteistyötä operatiivisen henkilöstön kanssa. Juuri nyt uusia työkaluja ilmestyy lähes päivittäin, ja toimittajat markkinoivat DevOpsia ”seuraavana suurena asiana”. Tilanne on erittäin hypetetty ja dynaaminen.
- SMAC eli sosiaalinen media, mobiili, analytiikka ja pilvi edustaa muutosta siinä, miten organisaatiot hallitsevat liiketoiminnan ja järjestelmien muutoksia mobiiliympäristössä. Liiketoiminnan kokeiluja, jotka toteutetaan tuotantojärjestelmien muutoksina, seurataan yksityiskohtaisella tasolla. Kerättyä massadataa käsitellään, ja liiketoimintapäätökset tehdään saatujen analyysitulosten perusteella.
Tuotantojärjestelmien toistuva kokeileminen mahdollistaa liiketoiminnan innovoinnin ”markkinoinnin nopeudella”. Kokeileminen on ollut keskeisessä roolissa siinä, mistä muodostui 2010-luvun tärkein muotisana – digitaalinen transformaatio.
Have an account? Log In
Testaus toimintana, ei roolina
Testauksen siirtäminen prosessissa aiemmaksi muuttaa testaajien roolia. Lähestymistavan käynnistämä testauksen uudelleenjako tekee selväksi, etteivät testaajat ole yksin vastuussa testauksesta eli testaajat eivät enää omista testausta.
Jos asiaa ajattelee, he eivät koskaan oikeastaan omistaneet testausta, mutta projekteissa vallitsi hiljainen ymmärrys siitä, että mitä tahansa muu tiimi, erityisesti kehittäjät, testauksessa tekikin, testaajat toimivat turvaverkkona. Jos kehittäjillä oli kiire ja he vähensivät testaustaan saadakseen toimituksen valmiiksi, testaajat muodostivat turvaverkon.
Testaus on nyt toimintaa, ei rooli.
Kehittäjät omaksuvat parempia testaustapoja ja lisäävät työnsä näkyvyyttä. Hyvällä komponenttitason tai yksikkötason testauksella on esimerkiksi järjestelmätestauksesta poikkeavat erityiset tavoitteet. Siksi järjestelmätason testauksen laajuutta (tai määrää) voidaan vähentää.
Testaustavoitteiden ja niiden saavuttamiseksi tehtävän testauksen oikea jakaminen on testausstrategian ensisijainen tarkoitus. Valitettavasti kehittäjiä ei vielä vähän aikaa sitten pidetty tehokkaasti vastuullisina, joten he turvautuivat myöhäiseen järjestelmätestaukseen puutteiden korjaamiseksi.
Testauksen siirtäminen vasemmalle tekee kehittäjistä vastuullisempia.
Kaiken kaikkiaan vastuu testauksesta jaetaan uudelleen, joten testaajan rooli muuttuu. Testaajat saattavat tehdä vähemmän taktista testausta, mutta heidän strateginen panoksensa kasvaa. Testaajat voivat vastata testausstrategiasta, haastaa vaatimuksia, konsultoida sidosryhmiä ja luoda läheisemmän suhteen kehittäjiin tukeakseen parempaa kehittäjien tekemää testausta ja testiautomaatiota.
Uusi rooli
Testauksen siirtäminen vasemmalle tarkoittaa, että aina kun on mahdollista antaa palautetta, joka auttaa tiimiä ymmärtämään, haastamaan ja parantamaan tavoitteita, vaatimuksia, suunnittelua tai toteutusta, palautetta tulisi antaa.
Käyttäjien, liiketoiminta-analyytikoiden, kehittäjien ja koko ohjelmistotiimin tulisi olla valmiita vaihtamaan palautetta tällä tavalla. Joskus esiintyy vastarintaa, mutta yleisenä tavoitteena on toteuttaa parempi ja paremmin tietoon perustuva projekti – ei sen kummempaa.
Helpoin tapa tiivistää tämä toimintatapa on ”osallistu varhain” – mahdollisimman varhain. Osallistu keskusteluun ja tee yhteistyötä ideoiden, vaatimusten ja jokaisen sellaisen vaiheen parissa, jossa kyseisen vaiheen lopputulos vaikuttaa projektin lopullisen toimituksen arvoon.
Yksinkertaisesti sanottuna testaaja haastaa tiedon lähteet riippumatta siitä, ovatko nämä lähteet sidosryhmiä, käyttäjiä, kehittäjiä, liiketoimintatarinoita, asiakirjoja tai ennakkotapauksia.
Yleisin lähestymistapa on haastaa esimerkkien avulla. Kaikissa vaiheissa näitä esimerkkejä voidaan pitää testeinä. Ne voidaan käytön jälkeen hylätä nopeasti tai muuntaa testiautomaatioksi tai manuaalisiksi tarkistuksiksi. Näitä esimerkkejä voidaan käyttää taktisesti osoittamaan puutteita ihmisten ajattelussa tai toimittaa kehittäjille esimerkiksi ideoina tai lähtökohtina kehittäjien testeille. Niitä voidaan käyttää myös valmennuksen apuvälineinä osoittamaan käyttäjille tai kehittäjille, miten parempia testejä voidaan luoda.
Ajattele ohjelmistoprojektiasi tiedonhankintaprosessina. Tätä tietoa kerätään koko projektin ajan, ja se kehittyy usein ajan mittaan. Testauksen siirtämisen vasemmalle tavoitteena on varmistaa tämä tieto haastamalla ja testaamalla lähellä sen lähdettä sekä varmistaa mahdollisuuksien mukaan, että siihen luotetaan ennen kuin se jäädytetään koodiin.
Testauksen siirtäminen vasemmalle vie testivetoista filosofiaa pidemmälle. Ketterissä menetelmissä on aina edistetty yhteistyötä ja nopeaa palautetta – testauksen siirtämistä vasemmalle voidaan pitää määrätietoisena nopean palautteen lähestymistapana. Jos tiimisi omaksuu testauksen siirtämisen vasemmalle, oikeilla työkaluilla voi olla ratkaiseva merkitys. Tutustu kuratoituun ohjelmistotestaustyökalujen luetteloomme löytääksesi tiimillesi parhaiten sopivan vaihtoehdon.
Ketterän kehityksen testausinterventiot
Testauksen siirtäminen vasemmalle on ketterien projektien testausstrategian perusta. Ketterässä toimintaympäristössä testausstrategia voidaan nähdä testausinterventioiden sarjana. Kaikissa projekteissa on kriittisiä hetkiä, jolloin syntyy mahdollisuuksia kerätä ja antaa palautetta. Testaajan on keskityttävä näihin kriittisiin hetkiin ja oltava valmis osallistumaan silloin.
Omissa projekteissasi sinun on tunnistettava kriittiset hetket, jolloin interventio on mahdollinen, sekä vaihtoehdot, joita voit tehdä tiiminä testatessanne. Pitäisikö testaajan esimerkiksi kirjoittaa kehittäjille yksikkötestejä, tarjota esimerkkejä työn aloittamiseksi vai valmentaa heitä parantamaan testaustaitojaan? Vain sinä ja uusi ohjelmistotestaustiimisi voitte päättää tästä.
Käytämme tyypillistä Scrum-prosessia osoittamaan, miten testausinterventiot voidaan sijoittaa Scrum-lähestymistapaan. Interventioita tapahtuu joko projektin (tai julkaisun) tasolla tai sprintin tasolla. Alla oleva kaavio esittää projektitason näkymän ja viisi keskeistä interventiota.
Tarinaan kohdistuvassa haastamisessa ja tarinan määrittelyssä testaaja validoi käyttäjätarinan ja tarinalle ehdotetut hyväksymiskriteerit. Integraatiotesteillä tarkistetaan, että uudet ominaisuudet liittyvät oikein muihin ominaisuuksiin ja koko järjestelmään. Järjestelmä- ja käyttäjätestit (hyväksymistestit) suoritetaan tarpeen mukaan.
Projektissa on yleensä useita sprinttejä, ja alla olevassa kaaviossa esitetään neljä sprintin aikaista interventiota. Päivittäinen tilannepalaveri tarjoaa mahdollisuuden raportoida edistymisestä, tuoda esiin huolenaiheita, tunnistaa riskejä tai keskustella sprintin aikana esiin nousseista kysymyksistä ja saaduista vastauksista.
Tarinoiden täsmentäminen ja osallistuminen kehittäjien tekemään testaukseen ovat päivittäisiä toimintoja, joita tapahtuu käyttäjien, analyytikoiden ja kehittäjien kanssa käytävien keskustelujen yhteydessä. Testaaja sisällyttää kehittäjien tekemät ja uudet järjestelmätestit kasvavaan automatisoitavien testien kokoelmaan.
Alla olevassa taulukossa on yhteenveto testaajien tekemistä toimenpiteistä. Prosessisi voi olla erilainen tai perustua johonkin Scrumin muunnelmaan, mutta taulukossa esitetään tyypilliset toimenpidetyypit tyypillisessä Scrum-prosessissa. Omassa ainutlaatuisessa prosessissasi voi eri vaiheissa olla aktiivisena enemmän tai vähemmän toimenpiteitä.
Suosittelen tunnistamaan kriittiset hetket, ehdottamaan omaa panostasi ja neuvottelemaan tiimisi kanssa. Tarjoat enemmän testauksen johtamista ja ohjausta sen sijaan, että ilmoittautuisit vapaaehtoiseksi ottamaan vastuun testaustyöstä. Tämä lähestymistapa helpottaa huomattavasti oman arvosi osoittamista tiimille, mutta tiimi ei välttämättä tarvitse yhtä paljon testaajia.
Suhteet kehittäjiin
Joissakin organisaatioissa kehittäjien ja testaajien välinen suhde voi olla epäluottamuksellinen, syyllistävä ja vihamielinen. Pahimmillaan suhde on myrkyllinen: kehittäjät eivät juuri testaa lainkaan, ja testaajia pidetään kehittäjien palvelijoina. Testaajat omaksuvat niin sanotusti läheisriippuvaisia toimintatapoja ja käyttäytyvät uhreina. Vasemmalle siirtämisen lähestymistavalla pyritään välttämään juuri tällainen tilanne.
Hyvän kehittäjä–testaaja-suhteen kuvaamiseen on käytetty monia vertauskuvia. Havainnollistamme vertailukelpoisen kehittäjä–testaaja-suhteen toimintaa lentäjän ja navigaattorin työskentelytavan avulla. Katsotaan kuitenkin ensin toimimatonta tilannetta.
Navigaattori ei nouse koneeseen, vaan vilkuttaa lentäjälle tämän lähtiessä nousuun. Navigaattori matkustaa bussilla erikseen ja hitaasti. Lopulta navigaattori saapuu määränpäähän, mutta jonkin ajan kuluttua huomataan, että kone on lentänyt väärään suuntaan ja törmännyt vuoreen.
Eikö navigaattorin olisi pitänyt olla koneessa? Kuvittele, miten lentäjät ja navigaattorit todellisuudessa työskentelevät yhdessä.
- Lentäjä ei voi lentää konetta ilman navigaattoria. Navigaattori ei voi lentää konetta.
- Lentäjä ja navigaattori sopivat lentosuunnitelmasta ennen matkan alkua.
- Lentäjä nousee ilmaan ja lentää konetta.
- Navigaattori seuraa reittiä ja vertaa sitä lentosuunnitelmaan ja/tai lopulliseen määränpäähän ottaen huomioon haitalliset tapahtumat, erityisesti sään.
- Navigaattori etsii poikkeamia, suunnittelee uuden reitin ja ilmoittaa siitä lentäjälle, joka tekee muutoksia lentorataan.
- Ja niin edelleen.
Lentäjän ja navigaattorin suhde vastaa ohjelmoijan ja testaajan suhdetta. Kehittäjien ja testaajien erottaminen erillisiksi tiimeiksi, jotka työskentelevät peräkkäin, ei myöskään ole järkevää. Silti juuri näin olemme perinteisesti toimineet noin viimeisten kolmenkymmenen vuoden ajan – erityisesti suuremmissa ja pitkäkestoisemmissa projekteissa.
Vasemmalle siirtäminen jakaa testausta koskevan ajattelun uudelleen ja tuo sen käytännössä aiemmaksi. Testaajat toimivat kehittäjien täysivaltaisina kumppaneina aivan kuten navigaattorit toimivat lentäjien kanssa:
- Testaaja ja kehittäjä kokoavat yhdessä vaatimuksia koskevat tiedot.
- Tyypillisesti testaaja haastaa vaatimukset esimerkkien avulla (mahdolliset tai todelliset testi-ideat).
- Kehittäjä pohtii toteutusta ja käyttää esimerkkejä suunnittelunsa suuntaviivoina.
- Testaaja, kehittäjä, sidosryhmät, käyttäjät ja analyytikot muodostavat yhteisen ymmärryksen luotettavasta vaatimuksesta.
- Testaaja viestii jatkuvasti kehittäjän kanssa ja keskustelee vaatimusten muutoksista, epäonnistumisen riskeistä sekä siitä, miten testauksella voidaan osoittaa ominaisuuksien toimivan tai paljastaa virheitä.
- Testaaja tarkastelee, miten työstettävä ominaisuus integroituu sekä teknisellä tasolla että käyttäjän etenemisen näkökulmasta ja miten integraatiota voidaan testata.
- Testaaja tarkastelee kehittäjän parhaillaan työstämää ominaisuutta laajemmassa yhteydessä ja tunnistaa tulevia haasteita, riskejä, muutoksia ja epävarmuustekijöitä.
- Ja niin edelleen.
Juuri kuvattu ihanteellinen kehittäjä–testaaja-suhde ei synny automaattisesti. Tiimin on rakennettava se yhdessä. Voit ajatella jokaista edellä mainittua toimintaa toimenpiteenä, mutta toimenpiteet eivät aina tunnu mukavilta kaikista osapuolista. Anna tälle lähestymistavalle parhaat mahdollisuudet onnistua keskustelemalla jokaisesta toimenpidetyypistä kumppaneidesi kanssa heti alussa – kun tiedät ensimmäisen kerran, että tulette työskentelemään läheisesti yhdessä.
Toimenpiteet, kuten hyvät käyttäjätarinat, käynnistävät keskusteluja.
Jokainen toimenpidetyyppi edellyttää molempien osapuolten hyväksyntää sille, että kyseessä on pätevä toimintatapa. Jotta työskentely tuntuisi luontevalta, kummankin osapuolen on luotettava siihen, että kysymysten esittämiseen, ongelmien esiin tuomiseen sekä vaatimusten tai ymmärryksen haastamiseen päivittäisissä tilannepalavereissa, suunnittelutilaisuuksissa tai retrospektiiveissä on hyvä syy.
More Articles
Hajautettujen ja ulkoistettujen tiimien haasteet
Edellä käydyissä keskusteluissa on oletettu hiljaisesti, että kaikki työskentelevät samassa tiimissä ja samassa toimipaikassa. Kun ohjelmistotestaustiimin työkuorma ulkoistetaan ja/tai siirretään ulkomaille, mukaan tulee useita kielteisiä tekijöitä. Taulukossa esitetään kolme tyypillistä huomioon otettavaa tekijää.
| Fyysinen (ja ajallinen) etäisyys | Tiimit voivat olla hajautettuina samaan toimistoon, eri rakennuksiin, paikkakunnille, maihin ja aikavyöhykkeille. Viestintä häiriintyy, viestintäkanavat ovat rajalliset ja tietoa kulkee vähemmän. |
| Erilaiset motivaatiot | Toimittajatiimi työskentelee organisaatiolle, jolle maksetaan testaustyön tekemisestä. Viime kädessä heidän motivaationsa on tuottaa voittoa. Kiinteähintaisissa sopimuksissa paineena on työskennellä nopeasti. Aikaperusteisissa ja materiaalikustannukset sisältävissä sopimuksissa houkutuksena on pitkittää työtä. |
| Kulttuurierot | Kansalliset ja kulttuuriset erot voivat olla merkittäviä. Niiden tunnistaminen ja huomioon ottaminen voi toisinaan viedä aikaa. |
| Yritys- ja organisaatiokulttuuri | Myös yrityskulttuurit eroavat toisistaan – yritykset tekevät yleensä parhaiten yhteistyötä kooltaan, joustavuudeltaan ja muodollisuudeltaan samankaltaisten yritysten kanssa. Yritykset ovat yksityisyyden, turvallisuuden, luottamuksellisuuden ja muiden vastaavien asioiden suhteen eri tavoin varovaisia. Yrityksillä on erilaisia johtamistyylejä, ja myös valtionhallinnon ja kaupallisten organisaatioiden välinen ero vaatii totuttelua. |
| Toimittajat työskentelevät sopimusten mukaisesti | Toimittajasi ei ole lojaali projektisi sidosryhmille tai heidän liiketoimintatavoitteilleen. He työskentelevät sopimuksessaan määriteltyjen sääntöjen mukaisesti. Jos mahdollista, varmista, että sopimuksissasi määritellään kaikkien osapuolten vastuut ja että sopimus palkitsee hyvästä toiminnasta ja määrää seuraamuksia huonosta toiminnasta. |
Jotkin yritykset täydentävät olemassa olevia ohjelmistotestaustiimejä kasvattaakseen valmiuksiaan suurempia projekteja varten tai palkkaavat testaukseen erikoistuneita yrityksiä sen sijaan, että ne turvautuisivat alihankkijoihin tai sisäiseen käyttäjähenkilöstöön. Muissa tilanteissa kaikki kehitys ja/tai testaus voidaan siirtää toimittajien tehtäväksi. Kaikissa tapauksissa asiakasyrityksen on hallittava toimittajiaan. Tämä ei tarkoita sitä, että rajoittavan sopimuksen laatiminen ankarine sanktioehtoineen riittäisi.
Kun asiat menevät pieleen, haluat toimittajaltasi nopeita vastauksia ja yhteistyötä; et halua heidän piiloutuvan sopimusten oikeudellisten ehtojen taakse.
Menestyksen salaisuudet ovat seuraavat:
- Jos et hallitse toimittajaasi, toimittaja hallitsee sinua (jos ette ole tasavertaisia kumppaneita ja annat toimittajan määritellä ehdot, toimittajalla on kaikki valttikortit).
- Tavoitteena on määritellä hyvä työsuhde. Se on luotava kaikilla tasoilla – sidosryhmien, esihenkilöiden ja käytännön toteuttajien tasolla.
- Sopimukset tulee muotoilla siten, että niissä yksilöidään molempien osapuolten kaikki vastuut ja määritellään asianmukaiset mittarit, kynnysarvot, vaihekohtaiset maksut ja hyväksymiskriteerit hyvän toiminnan kannustamiseksi (sopimuksen molemmilla osapuolilla).
- Sopimusten tulee kannustaa avoimuuteen ja sitoutumiseen projektin yhteiseen onnistumistavoitteeseen.
Ajattelemisen aihetta
Ja lopuksi muutamia kysymyksiä pohdittavaksi.
Millainen suhde sinulla testaajana on kehittäjiin? Tai jos olet tätä lukeva kehittäjä, millainen suhteesi on testaajiin? Voit ehkä kysyä kehitys- tai testaustyötä tekeviltä kumppaneiltasi, miten he kuvailisivat suhdettanne. Verratkaa näkemyksiänne!
Jotta ohjelmistotestaustiimit voivat olla tuottavia, niiden on viestittävä ja tehtävä yhteistyötä.
