Wednesday 21 July 2010

Testaustyön riittävyys

Meillä on projektit sellaisia pienehköjä kehitysprojekteja, joissa on yleensä 2-3 kehittäjää ja ne kestävät noin 1-4 viikkoa per projekti. Sitten meillä on sellaisia mammuttiprojekteja, jotka vievät koko tulosyksikön henkilöresurssit ja kestävät 6-9 kuukautta. Eli kehittäjät puskevat kovalla syötöllä koko ajan tavaraa ulos ja asiakkaalle.

Tähän soppaan kaadetaan testaaja. Testattavaa on vaikka kuinka paljon, mutta sitä ei aina ole mahdollista laskuttaa, jos sitä ei ole asiakkaalle myyty. Asiakkaalle on myyty ainoastaan kehitystestaus ja hän hoitaa itse testuaksen. Tämä malli on hyvin järkevää pienissä projekteissa ja asiakaskohtaisissa mutoksissa. Testaajat siis sijoitetaan suuriin projekteihin, joissa on paljon testtattavaa ja joka on laskutettavaa.

Ah, tullos tilanne, jossa viikon aikana ei tulekaan mitään testattavaa ominaisuutta tai käyttöliitymänäyttöä tms. jolloin testaaja kyselee pitkin toimistoa, olisiko kenelläkään testattavaa. JA KAIKILLA ON!!!! Testattavaa on simppeleistä käyttöliittymätestauksista aina monimutkaisiin integraatio hässäköihin ja suorituskykytesteihin, joita kukaan kehittäjä ei osaa/ehdi tehdä projektin puitteissa. Ja tämän ajan testaajan täytyisi tehdä 100% laskutettavaa työtä ja samalla pysyä kärryillä uusimmissa työkaluissa ja tekniikoissa (sekä testaus- että kehitysrintamalla).

Miten tästä siis selvitään?

Testaukselle pitäisi asettaa jonkinmoinen "puskuri", joka on laskuttamatonta työtä (esim. 5 tuntia viikossa) Tämän määrä vaihtelee 5-25% välillä riippuen viikosta. Tähän voidaan siis ympätä hankalat "testauksettomat" projektit, joita on todellisuudessa pakko testata, mutta niitä ei voi asiakkaalta laskuttaa. Lisäksi tähän voidaan lukea esim. työkalututoriaalit, webinaarit, blogien lukeminen (nykypäivänä helkkarin tärkeä *wink*) ym. ei suoranainen testaus, mutta testaukseen liittyvä.

Tällätavoin laatu paranee sekä yleisellä tasolla (ihmsiet ymmärtävät testauksen tärkeyden ja osaavat myydä sitä asiakkaalle) ja testausresurssitasolla (henkilökohtainen tieto-/taitotaso nousee ja tietämys alan suunnasta lisääntyy). Tämä maksaa kuitenkin yritykselle, joten sen kannattavuus kannattaa laskea tarkkaan.

Vaihtoehtona on tietenkin peukaloiden pyörittäminen ja se, että testaaja ei voi merkata tunteja joita ei voi laskuttaa...

Pureskelkaapa sitä...

Tuesday 6 July 2010

Suorituskykytestaus integraatioprojektissa

Projektipäällikkö pyysi minua tekemään suorituskykytestaussuunnitelman integraatioprojektiin. Ongelma on vain se, että meiltä puuttuu kokonaan NFR:t. En ole koskaan aiemmin tehnyt suorituskykytestaussuunnitelmaa, joten nyt pitäisi sellaisen tekemiseen paneutua.

Ensiksi täytyy löytää vastaus kysymykseen "Miksi testaamme suorituskykyä?". Tässä tapauksessa varmaankin pyritään ensikädessä luomaan ne raamit, missä järjestelmä tällä hetkellä on. Tämän takia täytyisi siis siis rajata se alue, jossa suorituskykytestit tehdään ja selvittää arvio sielttä liikkuvista massoista. Jos suorituskyvyssä ilmenee ongelmia, niin ne on helpompi paikata ennen kun niistä muodostuu tuontannollisia ongelmia. Lisäksi tulevaisuuden kannalta tulee selvittää millaisia pullonkauloja saattaa olla tiedossa ja missä vaiheessa tuotteen elinkaarta.

Pullonkaula saattaa vääristää end-to-end prosessin kaikkien komponenttien suorituskykyä. Jos yhdessä kohdassa on pullonkaula, se tulee eristää ja poistaa. Tämä voi lisäksi vapauttaa yhden pullonkaulan aiheuttamia lisäpullonkauloja edempänä prosessissa.

Toinen kysymys mihin tarvitaan vastaus on "Miten testaamme suorituskykyä?". Integraatioprojektissa testaus kannattaa suorittaa työkalulla, joka pytyy muodostamaan halutun määrän sanomia halutussa ajassa ja lähettämään niitä haluttuun end-pointiin.

Lisäksi täytyy tietää, millaisilla testeillä testaamme suorituskykyä.

Käyttäjämäärätestaus (Performance): Integraatiotestauksessa on harvoin kysymys käyttäjän/käyttäjien suorittamasta toiminnasta vaan kahden järjestlemän keskenäisestä kommunikoinnista. Integraatiotestauksessa ei tarvitse siis ottaa huomioon käyttäjämäärätestausta sellaisenaan, vaan käyttäjien sijaan lisätäänkin kommunikoivia järjestelmiä (lähteitä/threadeja). Pyritään siis etsimään se kohta, jolloin lähteiden määrä alkaa aiheuttaa hitautta tai sovelluksen toiminta muuttuu.

Massatestaus (Volume): Intergaatio testauksessa on tärkeä tietää, kuinka paljon sanomia järjestelmä pytyy käsittelemään kerrallaan. Lisäksi on tärekää, että pyritänkö luomaan suorituskykytesti niin, että syötetään yhdestä lähteestä sanomia samanaikaisesti vai useasta yhtäaikaa. Tässä pyritään siis selvittämään,e ttä suoriutuuko järjetelmä vaadituista arvoista. Tässä tapauksessa emme tiedä, mitä vaatimuksia on, joten tämä jää tällä kertaa pimentoon.

Kuormitustestaus (Stress): Integraatiotestauksessa on tärkeää löytää ne tilanteet, jolloin sanomien/tapahtumien määrä on siis suuri, että se vaikuttaa järjestelmän käyttäytyimiseen. Tässä testauksessa voidaankin ottaa arvioitu sanomamäärä ja lisätä sitä 20% joka kierroksella (mahdolliseseti lisätä säikeiden määrää aina välillä). Pyritään lisäämään niin kauan, että järjestelmä ei enää toimi.

Yhtäaikaisuus (Concurrency): Integraatiotestauksessa yhtäaikaiset käyttäjät ei ole oleellisia, mutta yhtäaikaiset (toisensa kumoavat) tapahtuman ovat. Pyritään siis luomaan testi, jolla luodaan yhtaisiaisia, toisensa kumoavia toimintoja. Tällä voidaan selvittää esim. jonoihin kasaantuvia ristiriitaisia tapahtumia.

Suorituskykyä testatessa voidaan yhdistää sekä sanomien määrällä että lähteiden määrällä testausta, jolloin voidaan saada erilaisia testituloksia. Integraatiotestauksessa täytyy myös pyrkiä siihen, että testidata on tuotantoa vastaavaa.

Monday 5 July 2010

Kuinka haastattelen uutta testaajaa?

Olen huomenna joutumassa tulikokeeseen saralla, josta minulla ei ole minkäänlaista kokemusta: joudun haastattelemaan kahta mahdollista testaajaa ja valitsemaan heistä pätevämmän (tai ehdottamaan molempia mukaan, jos molemmat ovat järkevä ottaa mukaan).

Nyt minun pitäisi yrittää löytää ne kysymykset, millä saan kaivettua tarvittavan testausosaamisesta kertovan tiedon. Koska en muualta löytänyt informaatiota (suomeksi) kuinka testaajia kannattaa haastatella, kirjoitan siitä pienen muistion tänne.

Ensimmäiseksi haastateltavan tulisi omin sanoin kertoa omasta testauskokemuksestaan. Tässä tulisi tulla ilmi seuraavaa:
- projektimallit (SCRUM, Waterfall, jne)
- testaustasot (yksikkötestaaja, systeemitestaaja)
- tekniikat (manuaalinen, automaatio, suorituskyky)
- metodit (tutkiva, kokemuspohjainen, testitapauspohjainen)

Jos hakija ei itse huomaa kertoa näitä asioita, häneltä voi kysyä näitä asioita.

Lisäksi on hyödyllistä tiedustella seuraavia asioita (riippuen mahdollisesta tulevasta roolista):
- testaustyökalut (mitä ja miten on käyttänyt, minkälaisissa ympäristöissä)
- testauksen suunnittelukokemus (testitapaukset, -suunnitelmat, automaatioarkkitehtuurit)
- koodauskokemus (skriptaus, valkolaatikkotestaus)
- testauksen hallinta (raportointi, jne)

Jos hakijalla on olemassa testausta tukevaa koulutusta, sitä voi tiedustella, jos se ei ole tullut ilmi. Lisäksi mahdolliset sertifikaatit ja todistukset testausalalta (ja IT-alalta yleensä) tulee tiedustella. Lisäksi kaikki mahdolliset esimerkit luoduista testitapauksista ja/tai testiskripteistä ovat hyviä kertomaan taidoista.

Jos hankitaan testausryhmän jäsentä ryhmään, jossa painotetaan erilaisuutta testaustaidoissa, -kokemusessa ja -näkökulmissa, täytyy haastattelija pystyä arvioimaan testaajan sopeutuminen testauryhmään ns. kovien kykyjen lisäksi. Testaus on ennen kaikkea sosiaalinen prosessi, jossa testaajan tulee voida antaa kritiikkiä kehittäjille. Tästä jöhtuen hyvät kirjalliset ja suulliset taidot (käytettävillä kielillä) ovat tärkeät.

Näiden lisäksi voidaan tutkia erikoisosaamiseen liittyviä asioita lyhyillä kokeilla esim. testitapaussuunnitelijalle: "Muodosta kaksikymmentä testitapausta MS-Wordin fontti näytöltä."