Testien hallinta projekteissa

Projektin tulosten tarkastelu järjestelmällisesti

Mikä on testien hallinta?

Testien hallinta sisältää testien suunnittelun, suorituksen, seurannan ja dokumentoinnin, jotta varmistetaan, että lopputuote on virheetön, käyttäjäystävällinen ja täyttää tuotteelle asetetut vaatimukset.

Testien hallinnan tavoitteisiin kuuluvat näin ollen:

1. Virheiden tai puutteiden varhainen havaitseminen lopputuotteessa, jotta ne voidaan korjata.
2. Mahdollisten parannuskohteiden tunnistaminen tuotteen käyttäjäystävällisyyteen liittyen.
3. Varmistaminen, että kaikki tuotteelle asetetut vaatimukset on täytetty.
4. Riskien vähentäminen, jotka voivat syntyä virheellisestä tuotteesta.
5. Hyväksyntä valmiille tuotteelle.

Testien hallinnan prosessi

1. Suunnittelu

Ensin luodaan testisuunnitelma, joka määrittelee testien laajuuden, keston, päivämäärät ja resurssit. Tämä testisuunnitelma sisältää myös valitun testistrategian. Sopiva strategia riippuu projektin ja testattavan tuotteen erityisvaatimuksista. Esimerkkejä:

• Alhaalta ylös: Komponentit testataan erikseen ennen niiden yhdistämistä suuremmiksi yksiköiksi ja nämä suuremmat yksiköt testataan ennen kokonaistuotteen kokoamista. Tämä soveltuu erityisesti monimutkaisille tuotteille.
• Ylhäältä alas: Toisin kuin edellisessä strategiassa, tässä koko tuote testataan ensin ennen kuin se jaetaan pienempiin yksiköihin, jotka testataan sitten erikseen. Tämä tekee tästä strategiasta hyvin soveltuvan vähemmän monimutkaisille tuotteille.
• Hybridistrategia: Tämä strategia yhdistää eri testistrategioiden elementtejä, kuten alhaalta ylös ja ylhäältä alas. Tällä tavoin strategiaa voidaan käyttää erityisen joustavasti ja se sopii keskikokoisille monimutkaisille tuotteille.
• Musta laatikko: Tässä strategiassa tuotetta tarkastellaan kuin mustaa laatikkoa, jossa testaajilla ei ole tietoa sisäisestä toiminnasta. He testaavat tuotetta yksinomaan ulkopuolelta näkyvien toimintojen perusteella.
• Valkoinen laatikko: Toisin kuin mustan laatikon strategiassa, testaajilla on tietoa tuotteen sisäisestä toiminnasta. Tämä tarkoittaa sitä, että he testaavat yksittäiset komponentit ja toiminnot yksityiskohtaisesti.

2. Määrittely ja valmistelu

Seuraava vaihe on määrittää testien vaatimukset ja valmistella testiympäristö sekä testidata:

• Määritä tavoitteet: Mitä testeillä pyritään saavuttamaan? Esimerkiksi halutaanko löytää virheitä vai tarkistaa käytettävyyttä? Mitkä ovat hyväksymiskriteerit?
• Määritä tuotteen vaatimukset: Mitä määrityksiä lopputuotteen pitäisi täyttää? Esimerkiksi mitkä ovat vaatimukset toimintojen, turvallisuuden tai käytettävyyden suhteen?
• Luo testitapaukset: Tavoitteiden ja vaatimusten perusteella voidaan nyt luoda tarkkoja testitapauksia, jotka määrittelevät, mitkä testit suoritetaan ja miten ne suoritetaan.
• Määritä testiympäristö: Missä ympäristössä testit suoritetaan? Suurilla projekteilla voi olla omia testilaboratorioitaan, mutta usein testaajat työskentelevät omilla työasemillaan tai kokoushuoneissa, joissa heillä on kaikki tarvittava testejä varten. Esimerkiksi ohjelmistotuotteen tapauksessa määrität tällä kohdalla, mitä käyttöjärjestelmää tai selainta pitäisi käyttää.
• Testin kesto: Kuinka kauan testien pitäisi kestää?
  Jotta testit huomioivat kaikki relevantit näkökohdat, testien vaatimukset tulisi määritellä mahdollisimman yksityiskohtaisesti ja tarkasti. Samanaikaisesti on kuitenkin otettava huomioon käytettävissä oleva aika sekä tarvittavat resurssit, jotta testien laajuus ja kesto pysyvät realistisissa puitteissa.

3. Suoritus ja dokumentointi

Nyt varsinaiset testit suoritetaan. Testitapaukset suoritetaan testisuunnitelman mukaisesti. Tarkka dokumentointi on tässä vaiheessa tärkeää, jotta testejä voidaan toistaa ja mahdollisia virheitä voidaan jäljittää helpommin. Testien tulokset tulisi myös kirjata, jotta voidaan tehdä johtopäätöksiä tuotteen laadusta.

4. Arviointi

Seuraava vaihe on arvioida testien tulokset, jotta virheet ja puutteet voidaan analysoida ja korjata. Kun ne on korjattu, testaus voidaan sitten toistaa.

5. Päätös

Tässä vaiheessa testausaktiviteetit saadaan päätökseen, ja testitulokset esitetään projektiryhmälle. Testiasiakirjat säilytetään ja niitä käytetään viitteellisenä tulevia projekteja varten sekä oppimiskokemuksia varten.

Kuinka määrität oikean testausjakson projekteille?

Optimaalinen testausjakso projektissa tulisi suunnitella huolellisesti. Liian lyhyt testausjakso voi johtaa virheelliseen lopputuotteeseen, kun taas hyvin pitkä testausjakso ei takaa 100 prosentin virheettömyyttä ja on samalla taloudellisesti epätarkoituksenmukainen. Kun määrität testausjaksoa, harkitse seuraavia tekijöitä:

• Projektin koko: Suuret projektit vaativat yleensä pidemmän testausjakson, kun taas pienemmissä projekteissa jakso voi olla lyhyempi.
• Testien laajuus: Jos tarvittavat testit ovat hyvin laajoja, esimerkiksi siksi, että paljon erilaisia toimintoja on testattava uudessa ohjelmistossa, tarvitaan myös pidempi testausjakso.
• Monimutkaisuus: Sama pätee monimutkaisuuteen. Jos hyvin monimutkaisia toimintoja on testattava, testausjakson tulisi olla pidempi kuin vähemmän monimutkaisille toiminnoille.
• Käytettävissä olevat resurssit: Testausjakson tulisi myös sopeutua käytettävissä oleviin resursseihin. Esimerkiksi jos vain muutama työntekijä on käytettävissä, testausjaksoa tulisi pidentää, jotta kaikki tarvittavat testit voidaan suorittaa. Toisaalta, jos henkilöstöä on enemmän, jaksoa voidaan lyhentää. Sama pätee muihin resursseihin, kuten testejä varten tarvittaviin teknisiin laitteisiin.
• Testidatan saatavuus: Jos tarvitaan erityistä testidataa esimerkiksi tuotteen pitkäaikaiseen testaukseen tai jos erityinen testidata on saatavilla vain tietyinä aikoina muiden tekijöiden, kuten muiden toimintojen valmistumisen, vuoksi, tulisi varata riittävästi aikaa sen luomiseen tai hankkimiseen.

Vinkkimme: Harkitse tarkasti eri tekijöitä määrittääksesi optimaalisen aikataulun projektillesi. Hyödynnä aiemmista projekteista saatuja kokemuksia. Tällä tavoin voit varmistaa, että sinulla on tarpeeksi aikaa testata kaikki toiminnot perusteellisesti ja löytää mahdolliset virheet. Samalla testausjakso pysyy realistisena eikä viivästytä projektia liian pitkän jakson vuoksi.

Kuka vastaa testeistä?

Testaushallinnassa on yleensä erilaisia rooleja:

• Testauspäällikkö: Testauspäällikkö koordinoi kaikkia testauksen alueen toimintoja. Hän laatii testisuunnitelman, järjestää resurssit ja valvoo etenemistä.
• Testisuunnittelija: Testisuunnittelijat vastaavat testitapausten ja testiasiakirjojen luomisesta. He analysoivat vaatimuksia ja suunnittelevat testiskenaarioita.
• Testaajat: Testaajat suorittavat testit ja dokumentoivat tulokset. Itse testit suorittavat yleensä erikoistuneet testaajat, jotka tuntevat kyseiset testimenetelmät tai menettelytavat tai joilla on laaja tietämys testattavasta alueesta. Tämä varmistaa, että kaikki olennaiset näkökohdat otetaan huomioon ja testit ovat merkityksellisiä.
  Lisäksi voi olla hyödyllistä saada muita ihmisiä osallistumaan. Nämä voivat olla esimerkiksi kehittäjiä tai osaston asiantuntijoita, mutta myös niitä, jotka käyttävät tuotetta sen valmistumisen jälkeen.
  Testaajien tulisi aina olla riippumattomia. Tämä tarkoittaa sitä, että tuotteen luoja ei saisi olla vastuussa sen testaamisesta. Vaikka luoja testaisi säännöllisesti tuotetta sen kehityksen aikana, riippumaton testaus estää virheiden huomaamisen ”toiminnallisen sokeuden” vuoksi.
• Testausohjaaja: Testausohjaaja seuraa testien etenemistä ja varmistaa, että kaikki testit suoritetaan suunnitelman mukaisesti. Hän vastaa myös siitä, että kaikki asiakirjat ovat täydellisiä ja ajan tasalla.
• Testiraportoijat: Joissakin yrityksissä on myös testiraportoijia, jotka laativat testiraportteja, esittävät tulokset ja suosittelevat parannuksia.

Tarvitsemasi roolit testauksen hallinnassa yrityksessäsi riippuvat yrityksen ja projektin koosta, mutta myös käytettävissä olevista resursseista ja taidoista. Koska testaajien tulisi olla riippumattomia, voi riittää, että sinulla on testauspäällikkö lisäksi testaajalle, joka ottaa myös testisuunnittelijan ja ohjaajan roolin.

Erot klassisten, hybridien ja ketterien projektien välillä

Projektinjohto lähestyy seuraamisen perusteella myös vaihtelee riippuen siitä, mikä projektinhallintatapa on käytössä.

• Klassisissa projekteissa on jaettu yksittäisiin projektivaiheisiin, jotka käsitellään kiinteässä järjestyksessä. Siksi testivaihe on jo määritelty projektin suunnitteluvaiheessa, samoin kattava testisuunnitelma, joka määrittelee kaikki suoritettavat testit.
• Hybridiprojektit ovat vähemmän tiukasti määriteltyjä kuin klassiset projektin, koska ne yhdistävät klassisia ja ketteriä menetelmiä. Riippuen valitusta yhdistelmästä näissä projekteissa on enemmän joustavuutta testauksen hallinnassa.
• Ketterissä projekteissa käytetään iteratiivista lähestymistapaa, jossa vaatimukset toteutetaan pienissä sprinteissä. Testit ovat näissä sprintsien tärkeä osa, koska ketterissä menetelmissä keskitytään jatkuvaan tarkasteluun ja tuotteen parantamiseen. Siksi ketterissä toimintamalleissa käytetään usein lyhyitä testausjaksoja, mikä mahdollistaa nopean palautteen ja varhaisen virheiden korjauksen.

Vaikeudet testauksen hallinnassa

Testauksen hallintaan liittyy erilaisia vaikeuksia. Esimerkkejä:

• Aikapula: Testaukselle ei usein ole paljon aikaa, mikä voi johtaa siihen, etteivät testit ole perusteellisia tai ne jopa jätetään kokonaan tekemättä. Erityisesti projektin viivästymisen uhkaessa houkutus jälkimmäiseen vaihtoehtoon on suuri. Tällaisissa tilanteissa, virheellinen tuote voi vahingoittaa mainettasi ja asiakassuhteitasi sekä aiheuttaa epämiellyttävää uudelleentyötä.
• Resurssipula: Aivan kuten aikapulan kanssa, resurssipula voi johtaa siihen, ettei testejä suoriteta tai niitä suoritetaan puutteellisesti. Hyvien testaajien löytäminen on vaikeaa taitojen ja henkilöstöpulan aikoina. Pidä tämä mielessä suunnitteluvaiheessa, jotta testit voidaan suorittaa asianmukaisesti myös henkilöstön ollessa vähäistä.
• Dokumentaation puute: Ilman riittävää dokumentaatiota testien toistaminen tai virheiden jäljittäminen voi olla vaikeaa. Samalla tämä vaikeuttaa oppien oppimista nykyisestä projektista tulevia projekteja varten.
• Muutokset projektin aikana: Projektin edetessä tuotteen vaatimukset voivat muuttua. Uusia toimintoja voi lisätä, niiden ominaisuudet voivat muuttua tai suunnitellut toiminnot voivat pudota pois. Tällaisissa tapauksissa suunniteltu testauksen hallinta ei enää sovi nykyisiin määrityksiin ja sitä on sopeutettava. Testejä on muutettava, testitapaukset on luotava uudelleen ja mahdollisesti testausjaksoa on pidennettävä tai löydettävä lisäresursseja. Vain tällä tavoin voit varmistaa, että testit ovat merkityksellisiä ja riittäviä.
• Vaikeudet yksittäisten komponenttien yhdistämisessä: Jos eri komponentteja, kuten ohjelmiston toimintoja, on kehittänyt eri kehittäjät tai tiimit, niiden integroiminen ja yhdessä testaaminen voi olla vaikeaa. Tässä tapauksessa varmista, että selkeä viestintä ja hyvä yhteistyö eri kehittäjien välillä estävät vaikeudet.

Yhteenveto

Hyvä testausjohtaminen tukee sinua laadunvarmistuksessa ja projektin tulosten parantamisessa. Siksi et missään tapauksessa saa tinkiä riittävistä testeistä.
Moderni projektinhallintasofta voi auttaa sinua integroimaan testausjohtamisen projekteihisi. Esimerkiksi ohjelmisto auttaa sinua aikatauluttamaan testivaiheen klassisissa projekteissa tai pitämään testivaiheen kunkin sprintsin aikana ketterissä projekteissa. Testien dokumentointi voidaan myös tallentaa ohjelmistoon, ja siitä voidaan heti johdattaa toimenpiteitä. Tällä tavoin voit ohjata parannusten toteutusta samassa järjestelmässä.

Haluaisitko tutustua myPARMiin demoesityksessä? Siinä tapauksessa voit varata ajan tapaamiseen vaikka samantien!