Testauksen johtaminen
Testausprojektin johtaminen Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Testausprojektin erityisluonne • Monessa mielessä testausprojekti on samanlainen kuin mikä tahansa projekti • Testausprojekti kuitenkin on johdettu ja riippuu kehitysprojektista – ‘what you do is a reaction to what they do’ – Testausprojektia ei suunniltella etukäteen ja kontrolloida kuten kehitysprojektia • On oleellista olla selvillä siitä mitkä asiat kuuluvat kehitysprosessille, ja minkä suhteen testausprojektilla on vapaat kädet • Testausprojektin pääliköllä on vastuuta ja valtaa testauksesta, mutta kokonaisuudesta vastaa projektipäälikkö – Testaus on yksi monesta tekijästä koko hankkeessa, tuo näkökulmasi ja toiveesi esiin, mutta älä tee päätöstä kokonaisudsta Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 1 Palvelukulttuuri vs. kontrollikultturi • Testaustiimeillä on joko palvelu- tai kontrollirooli • Palveluroolissa – Testaustiimi tuottaa laatuinformaatioon liittyviä palveluja kehityshankkeen muille osapuolille – Kontrolloi itse oman palvelunsa laatua ja relevanttisuutta • Kontrolliroolissa – Testaustiimi kontrolloi tuotteen laatua – Testaustiimi kontrolloi muiden (ohjelmoijien...) käyttämää prosessia – Hyväksyy/hylkää tuotteen julkaisun • Testaustiimien pitäisi olla tiukasti palveluroolissa, mutta usein käytännössä toimivat myös kontorolliroolissa • Kontrollirooli kuluu projektipäälikölle/projektin omistajalla Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Testauksen palveluroolista • Testaajien ei pidä ottaa kontrolliroolia yksinkertaisesti koska testaajat eivät kykene siihen – Testaajat näkevät projektista liian pessimistisen kuvan, eivät tiedä esimerkiksi että jokin tuotteen osa on vielä keskeneräinen – Projektin johtaminen helpon testattavuuden näkökulmasta ei sekään ole optimaalista • Joskus projekti tai prosessi tuottaa jatkuvasti huonoa laatua, silti tilanteen korjaaminen ei ole testaajien tehtävä • Testaajan valta yrityksessä perustuu tiedon tuottamisen taitoon ja vapauteen kommunikoida suhteellisen riippumattomasti ohi virallisten raportointikäytäntöjen – Testaajat eivät ole korkella hierarkiassa, mutta taitonsa osoittaneita testaajia (testauspäälikköä) kuunnellaan Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 2 Testaus- ja kehitysprojektin suhde • Testausprojektia kannattaa ajatella rakenteena joka auttaa jäsentämään kehityksen aikana syntyvää uutta tietoa tuotteesta ja sen tekemisestä ja sen perusteella tekemään päätöksiä siitä mitä tehdään seuraavaksi ja tulevissa iteraatioissa. • Kehitysprosessista on hyvä pitää mielessä ainakin – Myöhäisiä muutoksia tulee aina, niin suunnitelmiin kuin tuotteeseenkin – Kehitysprojekti on tasapainoilua laajuuden, luotettavuuden, ajan ja rahan välillä – Projektipäälikkö valitsee ja kustomoi käytettävän prosessin ja testaus mukautuu siihen • Iteratiiviisuus on testauksenkin näkökulmasta paras malli • Sovita testausprosessi käytäntöihin joita kehittäjät käyttävät Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Elinkaarimallin vaikutuksia • Vesiputousmaiset (sisältäen V-mallin) – Testit suunnitellaan vaatimus- ja suunnitteludokumentteja vasten – Loppuvaiheessa kun koodi on valmis ajetaan testit – Virheitä ja muutoksia löytyy, mutta tyypillisesti budjetissa ja aikataulussa ei ole enää joustovaraa – Tradeoff laadun ja toimitusajan/rahan välillä • Ketterä (ja iteratiivinen) – Laatua pidetään koko ajan korkeana testaten jokainen uusi piirre sitä mukaan kun se toteutetaan – Tuote voidaan julkaista milloin tahansa – Tradeoff laajuuden ja ajan välillä – “Build quality in” -ajattelu Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 3 Liiketoimintamallin vaikutuksia • Sopimusperustainen: tuotetta tehdään yhdelle asiakkaalle sopimuksen määrittelemänä – Testaamisen tärkein tavoite on varmistaa että sopimuksen vaatimukset täytetään – Sovitut piirteet, riittävä laatu, implisiittiset vaatimukset – Testaus spesifikaatiota vastaan • Markkinaperustainen: tuotetta tehdään markkinalle jossa asiakkaat tekevät ostopäätöksen vasta kun tuote on valmis – Kehityksen aikana tavoitteena varmistaa että tuote myy markkinoilla • Tilanne elää koko ajan, muutkosia tulee, time-to-market – Testauksen rooli selvästi osa kehitysprojektia – Testaus keskittyy eri asiakkaiden odotuksiin sekä yleiseen laatuun – Tutkiva testaus Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Käytännön ohjeita (1) • Tarjoa testausresursseja projektille varhaisessa vaiheessa – Yleisesti ymmärretään että testaajien pitäisi olla mukana jo projektin alussa • Vaatimusten laadun varmistaminen: ymmärrettävyys, yksikäsitteisyys, testattavuus • Vaihetuotteiden testaus sitä mukaa kun niitä valmistuu • Testattavuus-ominaisuudet, saatava mukaan työmäärän arviointiin • Koodikattavuus- ja analysointityökalut vaativat kehittäjien panosta testauksessa, tämä resurssi budjetoitava • Testausautomaatio vaatii kehittäjien tukea ja käytäntöjä, resurssi budjetoitava • Testaa testausympäristösi ja -työkalut varhaisessa vaiheessa – Älä kuitenkaan • Lähetä testaajaa projektikokouksiin kuunteluoppilaaksi • Lähetä ohjelmointitaidoiltaan heikkoa testaajaa kehitysprojektin kokouksiin (maine menee...) Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 4 Käytännön ohjeita (2) • Testattavuusominaisuudet ja -tuki – Selvitä kehitystiimille mitä oma tiimisi tarvitsee voidakseen työskennellä tehokkaasti – Ominaisuuksia tuotteessa, ohjelmoijien aikaa – Pidä huolta että resurssit tarpeillesi budjetoidaan • Ole mukana neuvottelemassa buildien aikataulusta – Testausprojekti rytmitetään buildien mukaan – Kommunikoi todellinen kykysi aikataulun suhteen • Esimerkiksi jos ympäristön virittäminnen vaatii puoli päivää joka buildin yhteydessä ja perustoiminnallisuuden testaus päivän, ei ole mieltä testata kerran päivässä valmistuvaa buildia • Kaikki buildit eivät mene testaukseen, ok kunhan asiasta sovitaan – Suunnittele testausprosessi sen mukaan mitä sovitte – Resurssoi tiimisi kehityshankkeen tahdin ja tarpeen mukaisesti Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Käytännön ohjeita (3) • Selvitä mitä testausta kehittäjät tekevät – Yksikkötestauksen laatu ja määrä – Savutestaus osana build-prosessia ? – Mukauta testausprojekti vastaavasti • Hyväksy build testattavaksi savutestillä (smoke test) – Testaa nopeasti perustoiminnallisuus, ja hylkää build liian epäkypsänä ellei savutesti mene läpi – Savutestauksen taso sovittava kehityksen kanssa • Mielellään koko savutestaus on julkinen, ohjemoijat tietävät mitä testataan, näkevät mahdolliset testiskriptit etc. • Savutestauksen tekevät ohjelmoijat tai testaajat riippuen siitä kumpi on käytännöllisempää • Yhdistelmä automatisoituja testejä ja nopea (tutkiva) manuaalinen testaus Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 5 Käytännön ohjeita (4) • Buildin hylkääminen – Savutesti epäonnistuu – Aiemmat bugit palanneet, mahdollinen konfiguraatiovirhe – Et kykene resurssoimaan testausta tai sinulla on perusteltu syy miksi resurssiesi käyttö muuhun (saman projektin) tarpeeseen hyödyttää projektia enemmän • Tuotteen uudelleensunnittelu – Jos jossakin tuotteen osassa uusia bugeja syntyy koko ajan lisää vanhoja korjatessa on ehdotettava projektipäälikölle isompaa korjausta – Bugiraporttitilastot ovat tärkeitä asian todentamiseksi – Projektipäälikkö tekee päätöksen tilanteen hoitamiseta tavalla tai toislla, testauspäälikön rooli on tarjota palveluna tietoa oikean päätöksen tekemiseksi Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Käytännön ohjeita Tiedon saanti • Projektin dokumentit eivät ole riittäviä testauksen perustaksi, tietoa on hankittava muualta • Organisoi tiedonhankinta rutiinitoiminnaksi, ja ota se huomioon resurssoinnissa • Erityisesti lisätiedon saanti kehittäjiltä on oltava rutiininomaista – Ohjelmioijat suunnittelevat ja lisäävät ominaisuuksia itsenäisesti eivätkä dokumentoi niitä • Esimerkiksi virheenkäsittelykoodista usein jopa 80% on tällaista • Tiedonhankintaa kannattaa hajauttaa kaikille eikä dedikoida siihen yhtä testaajaa täyspäiväisesti Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 6 Käytännön ohjeita Testaus ja muuttuva tuote • Tärkein periaate: koska testausprojekti on johdannainen kehitysprojektista, suunnittele muutoksia varten! • Kehitä testejä sitä mukaa kuin tarvitset niitä • Vältä raskasta testaukseen liittyvää dokumentaatioa (eism. manuaalisia testiskriptejä) • Tee testeistä niin riippumattomia käyttöliittymästä kuin mahdollista, käyttöliittymä muuttuu varmimmin • Testiautomaatiossa panosta testien ylläpidettävyyteen • Mallinna käyttäjien tuotteelta saamat hyödyt ja suunnittele monimutkaiset testit tämän perusteella – Tuote muuttuu jatkuvasti mutta käyttäjien tavoitteet ovat vakaampia – Esimerkiksi testin toteutus ja testidata erilliset, toteutus muuttuu, data pysyy Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Käytännön ohjeita Testauksen määrä • Yleispätevää ohjetta riittävälle testauksen määrälle ei ole olemassa – ‘Tarpeeksi informaatiota hyvän päätöksenteon tueksi’ – Kaksi testaussykliä (bugien löytäminen ja bug fixien varmistaminen) ei ole riittävä määrä – Testaussyklejä pitää voida käynnistää joustavasti tarpeen mukaan • Jotta voit arvioida riittävän testauksen tason – – – – Tiedät mitkä ovat tärkeimmät mahdolliset ongelmat (riskit) Tiedät miten ongelmat saadaan esille jos ne tuotteessa ovat Testausstrategia on monipuolinen, ei putkinäköä Testausstrategia toteutettiin ja tulokset raportoitiin selkeästi • Opi aiemmasta: vakava bugi jäi tuotteeseen, miksi ? – Väärä testauksen kohdennus, väärin suoritettu testaus, tietoinen riskinotto (projektipääliköltä) Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 7 Käytännön ohjeita Työn estimointi • Kehitysprojektin alussa tarvitaan myös arvio testaustyön määrästä ja resursseista – Lähtökohtana tuotteen laajuus, buildien määrä ja rytmi, tuotteen riskiprofiili ja laatuvaatimukset – Estimointiperusteena aiemmat hankkeet – Kaksi estimaattia projektipäälikön käyttöön (ohjaavat hankkeen trade-offien hallinnassa) • Minimi: testaus tärkeimpien riskien suhteen ja kevyt yleistestaus koko tuotteelle • Normaali testauksen taso • Arvioita päivitetään hankkeen aikana • Pyri saamaan arviot testauksen tehtävistä niiltä testaajilta jotka tulevat suorittamaan ko. tehtävän – Tarkempi arvio, sitoutuminen Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Käytännön ohjeita Sisäinen työn organisointi • Kierrätä testaajia eri ohjelman osien väillä – – – – Vaihtelevuutta työhön Testaajat oppivat monipuolisemmiksi Riskinhallintaa, ei henkilöriippuvuutta Eri testaajat testaavat eri tavoilla: kaikkiin tuotteen osiin eri testausnäkemyksiä • Kierrätä testaaja eri tyyppisissä työtehtävissä – Pitkälti samat edut kuin edellä – Seuraa suoritumista ja mentoroi • Käytä ‘buginmetsästäjää’ – – – – Kokenut, innokas tutkiva testaaja Alustava tutkiva testaus, testaustrategia ja kohdentaminen NR bugien selvittäminen Matalariskiset alueet, matalariskisyyden varmistaminen Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 8 Käytännön ohjeita Sisäinen seuranta • Säännölliset tilanneraportit – Muodostavat säännöllisen informaatiolähteen projektin johdolle – Selvittävät testaustiimille miten työ edistyy – Kommunikoivat testaustiimin tarpeet kehittjäille • Sisältö – Yhteenveto testauksen kattavuudesta, tuotteen laatuarvio, yhteenveto bugiraporteista, statistiikat – Suositeltavat toimenpiteet – Lähiaikoina saavutettavat testauksen tavoitteet , päivämäärät – Ongemalliset tavoitteet, mitä tarvitaan – Testaustyön resurssi ja muut tarpeet Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Sisäinen seuranta ... • Yhteenveto tilanneraportissa: – Miten suuri osuus tuotteesta on testattu – Miten suuri osa suunnitellusta testauksesta on suoritettu – Miten paljon vakavia ongelmia on löydetty ja mikä on arvio jäljelläolevien määrästä – Arvio testauksen kattavuudesta ja luotettavuudesta • Onko testattu alue todennäköisesti siivottu vakavista virheistä vai ei ? • Eo. tekijät yhdessä, ja erityisesti niiden kehittyminen hankkeen aikana mahdollistaa hyvien päätösten teon projektitasolla • Viikkotason raportointi oltava kevyttä, statistiikat automaattisesti • Milestone - raportit raskaampia Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 9 Testaustiimin johtaminen Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Tiimin kehitys • Tehokkaasti yhteen toimiva tiimi ei synny hetkessä vaan se tarvitsee aikaa ja useita projekteja • Tiimin kehittyminen: FIRO (Schutz 1954) – – – – Inclusion phase - do I fit in ? Honeymoon - individuals feel included, roles unclear Control - role seeking, competition, conflicts Idyllic - roles are found, nice atmosphere, no complete trust – Affection - team goals accepted, individuals trust each others, efficient cooperation Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 10 Tiimin kehitys • Tiimin vetäjän toiminta eri vaiheissa – Alussa kontrolloivaa vallankäyttöä – Keskivaiheilla enemmän tilaa tiimin jäsenille, valvova rooli – Kehittyneessä tiimissä vetäjä on fasilitaattori tiimin sisällä ja edustaja ulospäin • Minkä tahansa ison muutoksen jälkeen (uuden tyyppinen projekti, uusia työkaluja tai -tapoja, uusi tiimin jäsen) mennään osittain takaisin lähtöruutuun • FIRO on ‘teoreettinen’ malli tiimin toiminnasta – Auttaa ymmärtämään miten tiimi toimii ja mihin se kykenee sekä miten sitä pitää johtaa • Lukuisia muita tiimimalleja, ehdottomasti opiskelun paikka mikäli tiiminvetäjänä työskentelee Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Miten keskinkertaisuutta rakennetaan ? • • • • Prosesseilla jotka eivät jätä tilaa luovuudelle Testaajat vaihdettavissa olevia standardiresursseja Työn standardointi niin että kuka tahansa voi sen tehdä Testaajien arviointi mittareilla jotka heijastavat rutiinityöstä suoriutumista • Testaajien pitäminen erillään kehittäjistä testaamassa spesifikaatiota vastaan • Eo. keinoilla saadaan aikaiseksi toimivalta näyttävä testaustiimi jonka kontribuutio kehitystyölle on kyseenalainen Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 11 Miten huipputiimi rakennetaan? • Kohtele ja arvioi tiimin jäseniä itsenäisinä, luovina ammattilaisina joilla on omat vahvuutensa ja mielenkiinnon kohteensa – Arvioinnin kohteita: miten toimii tiimin jäsenenä, miten hyvin itsenäisesti osaa suunnitella työtä, missä tilanteissa on vahvoilla, missä tarvitsee apua, miten osaa kommunikoida ja auttaa kehittäjien kanssa.. – Älä laske löytyneiden bugien määrää • Ole kiinostunut testaajien työstä – Lue bugiraportteja, anna palautetta – Osallistu testaamiseen, näet mitä todellisuudessa tapahtuu, saat auktoritettia • Kierrätä töitä, anna vastuuta • Anna aikaa ja rohkaise oppimiseen – Teknologia, taidot, sovellusalue Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY Ajankäyttö • Älä allokoi testaajaa useaan kehitysprojektiin samanaikaisesti – Harva kykenee hoitamaan oman ajankäyttönsä ja toimimaan pirstaleisessa ympäristössä • Älä suostu projektipäälikön (tai muiden) epärealistisiin vaatimuksiin – Itsesi ja tiimisi jaksamisen vuoksi – Velvollisuutesi on antaa mahdollisimman realistinen kuva siitä mihin testaustiimisi kykenee • Kontrolloi tiimisi jäsenten ajankäyttöä, estä tai paikkaa ‘ohivedot’ Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 12 Rekrytointi • Uuden jäsenen rekrytointi on tärkein tiimin kyvykkyyteen vaikuttava päätös • Älä palkkaa drop-outteja kehityksestä • Suunnittele tarkkaan mitä taitoja rekryytiltä haluat – Varmista haastatteluissa kandidaatin taidot – Älä haastattele yksin, ota joku testaajista mukaan – Veto-oikeus kaikilla haastatteluun osallistuneilla • Etsi henkilöitä joilla on erilaiset taustat • Auta rekrytoitu alkuun – Osoita mentori, varaa omaa aikaasi – Ensimmäisten työtehtävien tavoitteena tutustuttaa ympäristöihin ja testattaviin tuotteisiin • Dokumenttien testaus, korjattujen bugien uudelleentestaus – Sijoita mahdollisimman varhaisessa vaiheessa olevaan hankkeeseen Ohjelmistotestaus -09 © Antero Järvi, Tuomas Mäkilä It-laitos / TY 13
© Copyright 2024