Ohjelmistokehitysprojekteja on perinteisesti viety läpi vesiputousmalliin perustuen. Projekti kulkee prosessimaisesti eteenpäin ja työn aikataulu, työvaiheet ja tapahtumapisteet suunnitellaan alusta loppuun mahdollisimman tarkasti. Vesiputousmallissa testauksen painopiste keskittyy usein projektin loppuun, mikä tekee testauksesta raskaan toteuttaa. Deadlinen kolkutellessa ovella testauksesta usein tingitään ja samalla laiminlyödään myös asetetut laatutavoitteet.

Ketterillä menetelmillä, kuten scrumilla, on ollut jo vuosia vakiintunut paikkansa ohjelmistokehityksessä. Ketterän kehitysmallin ehdottomia etuja on se, ettei koko hanketta tarvitse suunnitella kerralla, vaan se rakentuu pala kerrallaan. Alussa tehdään peruslinjaukset ja asetetaan päivämäärät, joita kohti projektin aikana on tarkoitus pyrkiä, mutta työtapa mahdollistaa myös matkan varrella syntyneiden uusien ideoiden jatkokehittämisen.

Scrum-mallilla toteutettu ohjelmistokehitysprojekti vaatii ympärilleen toimivan tiimiin, joka muodostuu ohjelmistokehittäjistä, testaajista ja asiakkaan edustajista. Kehitystiimissä on yleensä 2-5 asiantuntijajäsentä niiltä osa-alueilta, joihin projekti liittyy. Koodarien lisäksi mukana saattaa olla esimerkiksi tietoturva-asiantuntija tai web-designer. Kehitystiimin tielle tulevien esteiden purku kuuluu puolestaan scrum masterille.

Sekä toimittajan että asiakkaan puolelta mukana on myös program owner. Toimittajan program owner pitää huolta hankkeen linjausten toteutumisesta. Asiakasta edustava program owner puolestaan toimii eräänlaisena siltana kehitysprojektin ja asiakkaan liiketoiminnan välillä. Jos määrittelyihin tulee muutostarpeita projektin aikana, on asiakkaan program ownerin tehtävä pitää huolta siitä, että myös muutoksissa otetaan huomioon asiakkaan liiketoiminta.

Testaus on ketterästi kehitetyssä projektissa yhtä tärkeässä roolissa kuin vesiputousmallissakin. Testaustaakkaa helpottaa kuitenkin se, ettei kaikkien palasten testausta tarvitse suorittaa kerralla, vaan se toteutetaan kehitystyön tavoin pätkissä.

Yleisenä ohjenuorana voi sanoa, että mitä enemmän ohjelmistoa on testattu, sitä laadukkaampi siitä tulee. On kuitenkin muutamia tekijöitä, jotka vaikuttavat oleellisesti onnistuneen lopputuloksen todennäköisyyteen.

Ensimmäisenä voisi nimetä standardiratkaisujen hyödyntämisen kehitystyössä aina, kun se on järkevää. Ne ovat useaan kertaan testattuja, jo käytössä olevia ratkaisuja, joissa ilmenneitä virhetilanteita on saatu jo poistettua. Mitä monimutkaisempaa ympäristöä lähdetään kehittämään, sitä todennäköisemmin standardiratkaisujen hyödyntäminen edesauttaa toivottuun lopputulokseen pääsemistä.

Hyvä tuote saa alkunsa asiakkaan edustajan tekemistä laadukkaista määrittelyistä. Niiden pohjalta muodostetaan testimäärittelyt ja ns. happy case eli määritellään se, miten ohjelmisto toimii optimitilanteessa. Hyvä testaaja pystyy tutkimaan kaikkien testitilanteiden ulkopuolisia tapauksia ja pyrkii rikkomaan toteutetun toiminnallisuuden. Mikäli siinä epäonnistutaan, ollaan kehitystyössä todennäköisesti onnistuttu. Oman kokemukseni pohjalta sanoisinkin, että riittävä määrä testausympäristöjä ja data muodostavat yhdessä laadukkaiden määrittelyjen kanssa perustan onnistuneelle kehitysprojektille.

Viimeisenä on syytä mainita, että myös testaus ja laadunvalvonta ovat yhteistyötä toimittajan ja asiakkaan välillä. Toimittaja kantaa toki niistä päävastuun, mutta ohjelmiston lopullinen laatu täytyy pystyä arvioimaan asiakkaan suorittamassa hyväksymistestauksessa. Joskus unohdamme, että tietokoneet ja järjestelmät toimivat ihmisten kirjoittamien koodien mukaan ja kehitysvaiheessa mukaan saattaa päätyä inhimillisiä virheitä. Siksi laadukas testaus on avainasemassa missä tahansa ohjelmistokehitysprojektissa.



Markku Kestikievari, Senior Consultant