CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen Kevät 2015

Transkriptio

1 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen Kevät 2015

2 KERTAUS EDELLISESTÄ CT60A4150 Ohjelmistotestauksen perusteet

3 ERILAISIA MITTAREITA (ISO/IEC 29119) Eli: Toistettava, tarkka, vertailukelpoinen ja taloudellinen. Erilaisia mittareita: Raakadataan perustuvat Työn suunnitteluun perustuvat Projektin tilaan perustuvat Järjestelmän kattavuuteen perustuvat Testituloksiin liittyvät Järjestelmän luotettavuuteen perustuvat Testauksen tehokkuuden mittarit

4 RE: GARVININ LAATUMÄÄRITELMÄT Määrittelemätön tai koettu laatu, joka on käyttäjän kokema tunne korkeasta laadusta. Tämän määritelmän mukaan laatu on joukko hienovaraisia, ei mitattavissa olevia tekijöitä jotka käyttäjä tunnistaa tuotteesta jossa ne ovat läsnä. Tuotepohjainen laatu, joka tarkoittaa laatua, joka perustuu tarkkaan asetettuihin mittareihin, kuten vikatilojen keskimääräiseen tapahtumistiheyteen tai virheellisten syötteiden määrään virheettömiin verrattuna

5 RE: GARVININ LAATUMÄÄRITELMÄT Käyttäjäpohjainen laatu, joka on ns. havaitun laadun määritelmä, jossa tuote täyttää kaikki käyttäjän sille asettamat tarpeet ja toimii käyttäjän näkökulmasta juuri niin kuin halutaan. Valmistuspohjainen laatu, joka tarkoittaa laatua, joka on todennettavissa sillä että tuote on valmistettu tarkasti, tehty korkealaatuisista tarkkaan määritellyistä osista ja koottu oikein. Arvopohjainen laatu tarkoittaa laatumääritelmää, jossa tuotteen laatu perustuu sen toiminnalliseen arvoon. Periaatteessa tämä määrittely yhdistää osittain kaikkia muita määritelmiä, ja huomioi esimerkiksi sen että käyttäjillä on korkeammat odotukset tuotteilta jotka ovat kalliita. Vastaavasti halvoissa tuotteissa voidaan hyväksyä vikatiloja, käytettävyysongelmia tai halvan tuntua paljon kalliita enemmän.

6 MITÄ ON OHJELMISTON LAATU? // MISTÄ TUNNISTAA LAADUKKAAN TUOTTEEN? Mitä on korkea laatu? 10 vastaajaa, 10 eri vastausta. Edes samaa ohjelmaa tekevät ihmiset eivät osaa sanoa mikä on heidän tuotteensa absoluuttinen hyvä laatu. Voiko väärin suunniteltu tuote olla laadukas? Voiko kaatuileva tuote olla laadukas?

7 TESTAAJAN ROOLISTA ORGANISAATIOSSA CT60A4150 Ohjelmistotestauksen perusteet

8 TESTAAJA JA OHJELMISTOPROJEKTI Testaaja on aina kuitenkin vain yksi jäsen koko projektitiimissä. Työ on osa ryhmän tuotosta testaaminen on ryhmätyötä. Useimmiten tavoitteena olisi tienata rahaa testauksen organisointiin liittyy useita muitakin asioita kuin mitä oma tiimi tekee ja tietää.

9 SOSIOTEKNOLOGINEN JÄRJESTELMÄ

10 YLEISESTI Kaikki ryhmän jäsenet ovat ihmisiä. Osa ihmisistä vain on laiskoja, epärehellisiä ja/tai tyhmiä. Kukaan ei myöskään tiettävästi osaa lukea ajatuksia. tai pysty käyttämään dokumentteja joihin ei merkitty niitä perusjuttuja, kyllähän sä ne tiedät. Vrt. lähdekoodin kommentointi

11 MITÄ SIIHEN BUGIRAPORTTIIN SITTEN PITÄISI KIRJOITTAA? (KANER, KATARA) Selkeä, kuvaava otsikko auttaa löytämään raportin bugikannasta Selosta kuinka häiriön saa toistettua, sisällytä kaikki askeleet Kuvaile, mitkä askeleet ovat ja mitkä eivät ole tärkeitä bugin kannalta, ja miten tulokset vaihtelivat eri testiajoissa Analysoi ongelmaa ja kerro, miten se voidaan toistaa pienimmällä määrällä askelia Raportin pitää olla helposti ymmärrettävä Sävyn pitää olla neutraali Vain yksi bugi per raportti Jos toistamiseen tarvitaan tiedosto, liitä se raporttiin tai kerro mistä se löytyy

12 MIKSI KAIKKIA VIRHEITÄ EI KORJATA? (KANER, KATARA) Kehittäjä ei saa bugia toistettua Bugin toistaminen vaatii erikoista temppuilua Toistaminen ei ole mahdollista näillä tiedoilla ja lisätietojen kaivaminen vaatii paljon työtä Kehittäjä ei ymmärrä raporttia Epärealistinen vika Korjaaminen vaatii paljon työtä (rahaa tai aikaa) Korjaaminen on riskialtista Ei nähtävissä olevaa vaikutusta käyttäjille

13 MIKSI KAIKKIA VIRHEITÄ EI KORJATA? (KANER, KATARA) Ei tärkeä; kukaan ei välitä, jos tämä ei toimi Tai sopimuksessa ei vaadita tämäntyylisiin ongelmiin puuttumista Kyseessä ei ole bugi vaan ominaisuus, joskus myös ihan oikeasti. Johto ei välitä tämän kaltaisista bugeista Projekti on vaiheessa jossa tietyn tason alle jääviä bugeja ei korjata Kehittäjä ei pidä testaajasta tai ei luota häneen tms. henkilökohtaiset syyt (Projekti myytiin halvalla jotta saadaan myytyä huolto- ja ylläpitosopimus kovaan hintaan.)

14 KOMMUNIKOINTI OIKEASSA ORGANISAATIOSSA Testitapaukset ja testiraportit voivat päätyä projektissa melkein kenen tahansa käyttöön. Kirjoitusasun tulisi olla tarkka, selkeä ja ymmärrettävää ilman merkittävää työkokemusta. Koska ohjelmistoala on hyvin kansainvälistä, voi tuotetut dokumentit kuten käyttöohjeet tai testitapausten kuvakset myös päätyä sellaisten ihmisten käsiin, jotka eivät äidinkielenään puhu samaa kieltä. Tämän vuoksi myös sanontoja, murresanoja tai sananparsia tulisi välttää. Asiakas ei välttämättä ymmärrä ammattisanastoa! Ohjelmistoprojektien asiakas ei ole ohjelmistoalan ammattilainen, joten heiltä ei myöskään voida odottaa kykyä ymmärtää ammattitekstiä.

15 KOMMUNIKOINTI OIKEASSA ORGANISAATIOSSA Tiimien koko kasvattaa kertyvän dokumentaation ja kommunikointitarpeen määrää eksponentiaalisesti. Yleisesti arvioiden, yli kymmenen henkilön ryhmä tarvitsee sisäisen koordinaattorin huolimatta siitä miten ammattitaitoinen ja kokenut ryhmä on. Esim. agilet mallit toimii useimmiten juuri koska ryhmäkoot pidetään pieninä. Normaalissa organisaatiossa tieto kulkee ihmiseltä toiselle pitkälti kahden askeleen verran, eli päivittäin tavattaville ihmisille, ja ihmisille joita nämä henkilöt tapaavat päivittäin. Kaikkea muuta tiedonvaihtoa varten tarvitaan jonkinlainen järjestely.

16 KOMMUNIKOINTI OIKEASSA ORGANISAATIOSSA Ihmiset lopettavat nopeasti seuraamasta tiedotteita joita lähetetään liian usein. Tärkeän tiedon jakamista varten henkilöihin pitää ottaa erikseen yhteyttä. Mikäli jokin projektin toiminto tuottaa liikaa yhteydenottoja, katoaa tämän toiminnot tärkeätkin viestit kommunikaatiotulvaan.

17 MUUTAMA OIKEA ESIMERKKI Eräässä yrityksessä kolme ohjelmoijaa käytti vuorollaan työviikon aikaa saman ongelman ratkaisemiseen, koska kenellekään ei tullut mieleen kysyä muilta asiasta. Toisessa organisaatiossa paljastui että iso osa uuden tuotteen ongelmista tiedettiin etukäteen mutta kukaan ei katsonut olevansa oikea henkilö huomauttamaan niistä. Eräässä tutkimuksessa huomattiin, että tärkein ero opiskelijan ja ammattimaisen pelintekijän välillä on siinä, että ammattilainen kyselee muiden mielipiteitä, testauttaa ideoitaan muilla ja suunnittelee asiat pidemmälle ennen varsinaisen tekemisen aloittamista.

18 MISTÄ KOOSTUU OHJELMISTOALAN AMMATTILAINEN? (SWEBOK)

19 MUITA TESTAUSTYÖHÖN VAIKUTTAVIA TEKIJÖITÄ Tapakulttuurit Liiketoimintamallit Asiakkaan rooli Ulkoistaminen, ostetut komponentit Protokollat, standardit Lainsäädäntö Kriittisyysaste

20 TAPAKULTTUURIT Joissain kulttuureissa ei vain ole kohteliasta väittää vastaan. Tai mitenkään kritisoida esimiehen päätöstä. Tai kieltäytyä, tai sanoa Ei. Kommunikointi, tietokatkokset Myös muu kulttuuri vaikuttaa; mitä vihreä väri merkitsee sinulle?

21 LIIKETOIMINTA JA -MALLIT Yrityksen tapa toimia, hankkia asiakkaita ja tehdä rahaa. Miten vahva vikavastuu yritykselle jää? Miten paljon voidaan olettaa saavan voittoa? Mitä projektilta halutaan? Potkitaan tuote ulos halvalla ja nopeasti, korjataan mistä ymmärtävät valittaa. Nyt tehdään runko, myöhemmin tehdään sisältö. Tämä tehdään vain siksi että saadaan rahaa. Esimerkiksi tutkimus pelintekijöistä; raha vai maine?

22 ASIAKAS Millainen asiakas on? Tavoiteltu käyttäjäkunta joka maksaa tuotteen hankkimisesta. Tavoiteltu käyttäjäkunta joka maksaa tuotteen käyttämisestä. Tavoiteltu käyttäjäkunta joka maksaa tuotteen käyttämisestä, jos pitää siitä riittävän paljon tai haluaa lisäominaisuuksia. Yksittäinen suuri organisaatio, esimerkiksi suuryritys, joka ostaa omaan käyttöönsä rakennetun tuotteen tai ohjelmistokomponentin ja maksaa sen kehityskustannukset. Organisaatio, joka ostaa valmiin tuotteen ja maksaa kohtuullisen summan sen muokkaamisesta yritykselle hyödylliseen käyttöön.

23 ASIAKAS Eräässä tapauksessa testauksen suurin ongelma oli siinä, että asiakas joka maksoi koko työn ei antanut organisaation tehdä mitään testaustyötä kohdeympäristössä johon järjestelmä oli tarkoitus asentaa! Voiko asiakas olla tunkeileva? Milloin asiakasta pitäisi kuunnella? Milloin taas pitäisi minimoida featuritis

24 ULKOISTAMINEN Ulkoistaminen ja testaus liittyvät läheisesti toisiinsa, sillä testaustoimintoja voidaan joko ostaa ulkoa, tai ulkoa ostettujen moduulien testaus joudutaan tekemään osana sisäistä testausta. Yllättävää kyllä, ulkoistettujen toimintojen tai ulkoa tuotujen osien käyttämistä ei kuitenkaan pidetä kovin merkittävänä ongelmana esimerkiksi laadulle; Yrityksissä tehdyn tutkimuksen pohjalta useimmat yritykset toteuttavat testausvaiheet ulkoa tuoduille komponenteille aivan kuin se olisi omaa lähdekoodia. Ainoana erona vain se että havaitut viat raportoidaan eteenpäin eri kanavaa pitkin. Joissain yrityksissä ainoa varsinainen ongelma on komponentin korjauttaminen projektin ulkopuolella; välillä oli epäselvää mitä vikailmoituksiin sai laittaa ja mitä ei. Yleisesti ottaen ulkoa tuotuja komponentteja pidettiin kuitenkin varsin positiivisena asiana, koska ne poistivat omalta kehitystiimiltä tarpeen luoda käsin jokin ominaisuus, joka projektiin tarvittiin.

25 ULKOISTAMINEN Ulkoistaminen ja testaus liittyvät läheisesti toisiinsa, sillä testaustoimintoja voidaan joko ostaa ulkoa, tai ulkoa ostettujen moduulien testaus joudutaan tekemään osana sisäistä testausta. Yllättävää kyllä, ulkoistettujen toimintojen tai ulkoa tuotujen osien käyttämistä ei kuitenkaan pidetä kovin merkittävänä ongelmana esimerkiksi laadulle; Yrityksissä tehdyn tutkimuksen pohjalta useimmat yritykset toteuttavat testausvaiheet ulkoa tuoduille komponenteille aivan kuin se olisi omaa lähdekoodia. Ainoana erona vain se että havaitut viat raportoidaan eteenpäin eri kanavaa pitkin. Joissain yrityksissä ainoa varsinainen ongelma on komponentin korjauttaminen projektin ulkopuolella; välillä oli epäselvää mitä vikailmoituksiin sai laittaa ja mitä ei. Yleisesti ottaen ulkoa tuotuja komponentteja pidettiin kuitenkin varsin positiivisena asiana, koska ne poistivat omalta kehitystiimiltä tarpeen luoda käsin jokin ominaisuus, joka projektiin tarvittiin.

26 ULKOISTAMINEN Toinen tapa, miten ulkoistaminen vaikuttaa testaukseen ja testaustyön tekemiseen on ulkoa ostetut palvelut: Ylimääräiset testaajat Testaustyökalut Asiantuntijakonsultit. Kutakuinkin jako isoihin ja pieniin toimijoihin: Suuret yritykset, joilla on rahaa ja resursseja hankkia mitä he haluavat eivät nähneet tämän ulkoistamisen muodon tuottavan mitään ongelmaa, mutta Pienemmissä yrityksissä rajallinen määrä ohjelmistolisenssejä, huonosti tavoitettava asiantuntija-apu tai halvimmalla mahdollisella tarjouksella teetetty työ.

27 ULKOISTAMINEN Tavallisin ongelma ulkoistamisen yhteydessä ei kuitenkaan ollut heikko laatu tai rajattu pääsy komponenttien lähdekoodiin, vaan yksinkertaisesti kommunikointi. Koska monissa tapauksissa ulkoistettujen toimintojen tarjoajalla ei ollut varsin hyvää kuvaa toteutettavasta järjestelmästä, johti tämä ongelmiin joiden ratkaiseminen vei projektilta omaa työaikaa. Asioista sopiminen, korjauksien ja muutoksien teetättäminen ja yksityiskohtien viilaaminen veivät usein aikaa, koska ulkoa tulevat työntekijät eivät tiedä asioista samalla tapaan kuin omat työntekijät.

28 ULKOISTAMINEN Käytännössä tämä siis tarkoittaa sitä, että ulkoistamisen vaikutukset testauksen kannalta ovat varsin epätavalliset; Arvaamalla ulkoistettujen toimintojen ja projektin ulkopuolella tehdyn työn pitäisi olla ongelma, mutta näin ei ole. Ulkoa tuodut toiminnalliset kokonaisuudet olivat yleisesti jopa positiivinen, työmäärää vähentävä asia. Testauksen kannalta ulkoistamisen suurin ongelma onkin johtamisessa ja asioiden hallinnassa Jos kaikkea ei tehdä sisällä pitää suunnitelmat ja määritelmät olla hyvin yksityiskohtaisia ja selkeitä.

29 LAIT JA VIRANOMAISET Viides asia, joka voi vaikuttaa testauksen toteuttamiseen mutta ei suoranaisesti liity itse organisaation omaan toimintaa on lait ja viranomaisten rooli projekteissa. Esimerkiksi tietyt tietotekniikan alat, kuten lääketieteen sovellukset, ydinvoimaloiden järjestelmät tai puolustusalan projektit sisältävät jo itsessään tiukat salassapitovelvoitteet. Lisäksi tietysti joillain aloilla kuten ydinvoimatekniikalla ja autoteollisuudella on omat laadunvalvontamenetelmät joilla laatua voidaan valvoa ja mitata, sekä erillisiä viranomaisia kuten Säteilyturvakeskus, jotka tarkastavat että järjestelmiin toteutetut tuotteet täyttävät tietyt kriteerit.

30 LAIT JA VIRANOMAISET Testauksesta ja laadunvarmennuksesta pitää olla tietyt työvaiheet joissa kirjataan ylös viranomaisten vaatimuksia varten tarvitut asiat, sekä projektissa itsessään noudattaa tarkkaa dokumentointikäytäntöä jotta testaustyö ja laadunvarmennus voidaan myöhemmin tarkastuksessa osoittaa oikein tehdyksi. Lisäksi toimintaan voi vaikuttaa ihan suoraan lainsäädäntö, kuten esimerkiksi asiakkaiden tai käyttäjien yksilön suojaa koskeva lainsäädäntö tai muut henkilötietoja koskevat lait.

31 LAIT JA VIRANOMAISET Eräässä ohjelmistohankkeessa lainsäädäntö aiheutti hankalan ongelman. Yritys, joka valmisti sairaalan käyttöön ohjelmaa, sai vaatimuksen hyväksymistestata ohjelmaa oikeassa käyttöympäristössä oikeilla potilailla ennen laajempaa käyttöönottoa. Testit tehtiin ja aineisto kerättiin, mutta lainsäädäntö esti sairaalaa luovuttamasta mitään käyttäjätestejä koskevaa tietoa yritykselle. Koska asianajajat katsoivat kerättyjen tietojen kuuluvan potilastietosuojan piiriin, ei testituloksia voitu antaa eteenpäin ohjelmaa viimeistelevälle yritykselle. Lopputuloksena testit tehtiin koska niin oli sovittu, mutta testituloksia ei käytetty mitenkään ohjelman viimeistelemisen apuna koska se olisi ollut laitonta.

32 RE: MITÄ PITÄISI JÄÄDÄ MIELEEN

33 MITÄ TÄSTÄ LUENNOSTA PITÄÄ MUISTAA? Testaus ei tietenkään ole muovikupla jossa voidaan piilotella ja toimia miten halutaan. Kommunikointitaidot ryhmän sisällä. Ulkopuolelta tulevat asiat vaikuttavat hyvin paljon siihen, miten ja miksi testaus organisaatiossa tapahtuu niin kuin se tapahtuu!