SOFTWARE TEST PROCESS DEVELOPMENT OHJELMISTOTESTAUSPROSESSIN KEHITTMINEN Jussi Kasurinen

SOFTWARE TEST PROCESS DEVELOPMENT OHJELMISTOTESTAUSPROSESSIN KEHITTÄMINEN Jussi Kasurinen, Ohjelmistotekniikan laboratorio

Miksi tutkia ohjelmistotestausta Ohjelmistotestaus on läsnä kaikessa ohjelmistotuotannossa. Usein testaustoimintaa rajoittaa joko raha, aika, henkilöstömäärä tai muu saatavilla oleva resurssi. Kuitenkin jo 15% ”optimaalisista” resursseista riittää perustason testaukseen. Yhdysvalloissa puutteellinen testaus aiheuttaa vuosittain 59. 5 miljardin dollarin tappiot tuotannonmenetyksinä ja vikavastuina (arvio Jussi Kasurinen, Ohjelmistotekniikan laboratorio LUT Tietotekniikka 2002).

Mitä ovat MASTO ja ESPA? ESPA oli 3 -vuotinen akateeminen yhteistyöprojekti Aalto-yliopiston ja Lappeenrannan teknillisen yliopiston kesken. Tavoite tutkimuksessa oli tutkia ohjelmistojen testaamista kaikilla organisaation eri tasoilla: MASTO Lappeenrannassa keskittyi testausprosessiin ja organisaation komponentteihin. SQUID Aallossa tutki itse testaustyötä yksittäisen testaajan ja projektin näkökulmasta. Nyt arvioitava väitöskirjatyö perustuu MASTO-projektissa tehtyyn Jussi Kasurinen, Ohjelmistotekniikan laboratorio LUT tutkimukseen Tietotekniikka Ohjelmistoja tuottava yritys Organisaation taso, jokaisella yrityksellä on yksi Projektitaso, yrityksellä voi olla Pof these useita. Projecese

Mitä on testaus? ISO/IEC 29119 Perinteinen mielikuva: testaustoiminta… Ohjelmistoprosessi … On kaikki toimenpiteet alkaen määrittelystä päättyen tuotteen lopettamiseen, joilla vaikutetaan testaustoimintaan. Määrittely Suunnittel u Toteutus Testaus aloitetaan Varsinaisesti jossain testaus on täällämain … määritellen mitä, missä, kuka, tuo vaihe miksi, miten ja millä välineillä, tuossa organisaation ja projektien tasolla. Testaus on lopetettu tässä vaiheessa Jussi Kasurinen, Software Engineering Lab. LUT Information Technology Ylläpito Eli kaikki mitä tälle välille mahtuu

Testausprosessi siinä muodossa, missä se pitäisi ymmärtään, on ohjelmiston tekemisen kaikki ne työvaiheet ja työsuoritteet, jotka liittyvät tuotteen laadun varmistamiseen ja toiminnallisuuksien testaamiseen. Verifiointi – Ohjelma on tehty oikein Validointi – Ohjelma on suunniteltu oikeanlaiseksi Tässä väitöskirjatyössä 1. Tunnistettiin ne prosessin osa-alueet ja komponentit, jotka vaikuttavat käytännön testaustyöhön, 2. Arvioitiin yleisen testausstandardin soveltuvuutta käytännössä sekä 3. Kehitettiin työkalu yrityksen omien testausprosessien Jussi Kasurinen, Ohjelmistotekniikan laboratorio LUT kehityskohteiden löytämiseen. Tietotekniikka

Testausprosessi ja sen komponentit Tutkimuksen mielenkiinnonkohteet Julkaisu 2; “Software Test Automation in Practice: Empirical Observations” Julkaisu 5; “How Test Organizations Adopt New Julkaisu 3; “A Study on Agility and Testing Practices and Methods? ” Processes in Software Organizations” Julkaisu 2; “Software Test Automation in Practice: Empirical Observations” Julkaisu 4; “Test Case Selection and Prioritization: … Julkaisu 7; “A Self-Assessment Framework for Finding Improvement Objectives with ISO/IEC Julkaisu 6; “Exploring Quality Concepts in 29119 Test Standard” Software Organizations” Julkaisu 1; “Analysis of Problems in Testing Practices”

Yleistä tutkimuksesta ja testauksen tilasta Väitöstutkimuksessa haastateltiin 65 ohjelmistoalan ammattilaista 31 eri organisaatiosta. Nauhoitetut teemahaastattelut Teemakyselyt Max. Min. Mediaani Yrityksen työntekijämäärä 350 000 4 315 Ohjelmistokehittäjien ja testaajien määrä haastatellussa organisaatiossa. Testausautomaation määrä testauksesta (%). 600 0* 30 90 0 10 (26% ka) Ketterien menetelmien määrä projekteista (%). 100 0 30 Nykyisten testausresurssien määrä verrattuna 100 ihannemäärään (%). Kuinka suuri %-osuus projektista käytetään Jussi Kasurinen, Software Engineering Lab. LUT Information 70 päätoimiseen testaamiseen. Technology 10 75 (70% ka) 0** 25 (27% ka) * 0 = kaikki hankittu alihankintana ** 0 = testaukselle ei erikseen varata aikaa

Tärkeimmät asiat testauksessa, jotka vaikuttavat lopputuotteen laatuun • Asiakas ja ohjelmistotuottaja luottavat toisiinsa. – • Työmenetelmät, jotka noudattelevat ISO/IEC 29119 –mallin periaatteita. – • Tietoa ei pimitetä, sitä voidaan tarvittaessa luovuttaa vapaasti ja kaikilla on käytössä paras mahdollinen tieto. Työstä tuleva palaute vaikuttaa jatkoprojekteihin ja muutoksia voidaan tarvittaessa tehdä. Halutun laadun määrittely – Organisaatio on määritellyt millaista laatua halutaan tuottaa ja viestinyt sen selvästi kaikille Jussi Kasurinen, Ohjelmistotekniikan laboratorio LUT osapuolille. Tietotekniikka

Yleisen testausstandardin soveltuvuus käytännössä • • • Malli on kattava, mutta liian täynnä yksityiskohtia erityisesti hallinnon tasolla. Yleisimpiä ongelmia palautteen käyttäminen ja määritellyt hallintotason tehtävät. Organisaatiot eivät yleisesti ottaen kehitä toimintaansa parantaakseen tilannettaan vaan korjatakseen vikoja. • • Kehitystä tapahtuu, kun viat muuttuvat sietämättömiksi. Vaikka palautetta annettaisi, ei siihen reagoida jos prosessi on “siedettävässä kunnossa. ” Jussi Kasurinen, Ohjelmistotekniikan laboratorio LUT Tietotekniikka

Työkalu testauksen kehityskohteiden löytämiseen Yhdistelmä Test Improvement model (TIM)-mallin kypsyystasoista ja ISO/IEC 29119 –mallin prosesseista. Kaksi päätuotosta: 4 3 Yleinen kypsyystaso ja eroavaisuudet standardin mallista. Prosessinkehityskohteet ja käytännön ajatuksia Kypsyystasot TIM-mallista mahdollisesti hyödyllisistä tavoista kehittää testaustoimintaa. Prosessit ISO/IEC 29119 - 2 mallista 1 Yksilöllinen arviointi jokaiselle testauksen työvaiheelle 0 OTP TMP TPP TMCP TCP STP DTP Yleinen arvio kypsyystasosta Jussi Kasurinen, Ohjelmistotekniikan laboratorio LUT Tietotekniikka

Yhteenveto Päätutkimuskohteena testausprosessit yleisesti, testausprosessien komponentit sekä testaustoiminnan kehittäminen. Testausresurssien määrä monesti lähes riittävä, ”hyväksyttävä”, menetelmien hyödyntäminen tehotonta. Organisaatiot muuttavat toimintaansa korjatakseen vikoja, eivät parantaakseen tehokkuuttaan. Tutkittu ISO/IEC 29119 testausmalli havaittiin olevan pätevä, mutta sisältävän Jussiteoreettisesti Kasurinen, Ohjelmistotekniikan laboratorio LUT Tietotekniikka muutostarpeita sekä olevan vaikea käyttää