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 tulisi kestää?
  Jotta voidaan varmistaa, että testissä otetaan huomioon kaikki olennaiset näkökohdat, testivaatimukset tulisi määritellä mahdollisimman yksityiskohtaisesti ja konkreettisesti. Samalla on kuitenkin otettava huomioon käytettävissä oleva aika sekä tarvittavat resurssit, jotta testien laajuus ja kesto pysyvät realistisissa rajoissa.

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 kirjaavat tulokset. Testit suorittavat yleensä erikoistuneet testaajat, jotka tuntevat kyseiset testausmenetelmät tai -prosessit tai joilla on laaja-alaista osaamista testattavasta alasta. Näin voidaan varmistaa, että kaikki merkitykselliset näkökohdat otetaan huomioon ja että testit ovat luotettavia.
  Lisäksi voi kuitenkin olla järkevää ottaa mukaan myös muita henkilöitä. Näitä voivat olla esimerkiksi kehittäjät tai alan asiantuntijat, mutta myös ne, jotka tulevat käyttämään tuotetta sen valmistuttua.
  Vinkkimme: Testaajien tulee ehdottomasti olla riippumattomia. Tämä tarkoittaa, että tuotteen kehittäjä ei saisi olla vastuussa sen testaamisesta. Vaikka kehittäjä testaa tuotetta säännöllisesti kehitysvaiheen aikana, riippumaton testaus estää virheiden huomaamatta jäämisen ”ammattisokeuden” 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ä.

• Perinteiset projektit järjestetään yksittäisiin projektivaiheisiin, jotka toteutetaan tietyssä järjestyksessä. Siksi jo projektisuunnitteluvaiheessa määritellään testivaihe ja laaditaan kattava testaussuunnitelma, jossa määritellään kaikki suoritettavat testit.
• Hybridiprojektit ovat vähemmän jäykästi määriteltyjä kuin perinteiset projektit, koska niissä yhdistyvät perinteiset ja ketterät menetelmät. Valitusta yhdistelmästä riippuen nämä projektit mahdollistavat siis myös testaushallinnassa suuremman joustavuuden.
• Agile-projektit käyttävät iteratiivista lähestymistapaa, jossa vaatimukset toteutetaan pienissä sprinteissä. Testaus on tärkeä osa näitä sprintejä, sillä ketterissä lähestymistavoissa painopiste on tuotteen jatkuvassa tarkistamisessa ja parantamisessa. Siksi tässä käytetään usein lyhyitä testisyklejä, jotka mahdollistavat nopean palautteen ja virheiden varhaisen korjaamisen.

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.

Päätelmä

Hyvä testaushallinta tukee laadunvarmistusta ja projektituloksen parantamista. Siksi riittävistä testeistä ei pidä missään nimessä luopua.
Nykyaikainen projektinhallintaohjelmisto voi auttaa sinua integroimaan testaushallinnan projekteihisi. Ohjelmisto auttaa esimerkiksi perinteisissä projekteissa suunnittelemaan testausvaiheen tai ketterissä projekteissa noudattamaan testausvaihetta kussakin sprintissä. Myös testien dokumentaatio voidaan tallentaa ohjelmistoon, ja siitä voidaan välittömästi johtaa tarvittavat toimenpiteet. Näin voit ohjata parannusten toteuttamista suoraan samassa järjestelmässä.

Haluatko tutustua myPARMiin demossa? Varaa sitten tapaaminen kanssamme nyt!