CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015
ILMOITUSASIAA Projekti 2:n lyhyt kuvaus Nopassa. Harjoituksissa tehtäviä joiden tuotoksia voi hyödyntää projektin toteutuksessa. Nina Korjuksen pruju valmis; käykää katsomassa Nopan Muu materiaali - sivulta. Esimerkiksi dokumenttimalleja vaikkapa projekti 2:sta varten.
NOPEA KERTAUS EDELLISESTÄ
TESTAUKSEN PROSESSIMALLIT CT60A4150 Ohjelmistotestauksen perusteet
SEM kalvoista: What is a process? Process defines who does, what does, when does and how does. New or changed requirements Software Process New or changed system 6
PROSESSI Tapahtumaketju, jossa määritellään Kuka tekee Mitä tekee Milloin Ja miten. Alkaa tarpeesta tai esitiedoista, Päättyy tulokseen. Prosessimalli; useita prosesseja, jotka tukevat, täydentävät ja ohjaavat toisiaan.
TESTAUKSEN PROSESSIMALLIT Erilaisia testaukseen liittyviä prosessimalleja: Toiminnan tilan määrittely (miten tehdään) Toiminnan kehittäminen (miten tehtäisi paremmin) Yleinen kehitysmalli (testaus-vetoinen tuotekehitys) Osaamisen todentaminen (auditoinnit, sertifikaatit, henkilökohtainen tai organisaation) Tänään puhutaan näistä tavallisimmista.
OHJELMISTOTESTAUKSEN YLEINEN TOIMINTAMALLI, ISO/IEC 29119 Kuten viimekertainen puhe dokumenteistakin mainitsi, on järkevää puhua testausorganisaatiosta kolmella eri tasolla. Koko yrityksen tai organisaation taso Yhden projektin taso Yhden työntekijän/testausvaiheen taso Tällä tavalla ajateltuna testausorganisaatiosta voidaan sanoa löytyvän seuraavia asioita:
ISO/IEC 29119, HALLINNON PROSESSIT Organisaatiotason prosessi (organizational test process) kuvaa yleisen, koko organisaation tason toimintaa, eli työtehtäviä joita tehdään kun ylempi johto määrittelee, korjaa tai uudelleenarvioi testausstrategian tai testauspolitiikan toimivuutta. Testauksen hallintaprosessi (test management process) sisältää kaikki projektitason testauksen valvonnan, ohjauksen ja hallinnan. Projektin testauspäällikkö (tai laatupäällikkö) valvoo että testien suunnittelu, testauksen valvonta ja toiminnan raportointi sujuvat ilman ongelmia.
ISO/IEC 29119, PROJEKTIN PROSESSIT Testauksen suunnitteluprosessi (test planning process) tarkoittaa niitä työtehtäviä, joita tehdään kun koko projektin testaustoimintaa suunnitellaan. Määritellään tarvittavat testitapaukset ja yleisesti määritellään millä työkaluilla, millä menetelmillä ja miten projektissa testataan. Testauksen valvonta- ja ohjausprosessi (test monitoring and control process) sisältää työtehtävät, joissa testauksen etenemistä arvioidaan. Jos työ jää aikataulusta jälkeen, ylittää budjetin tai ei tule saavuttamaan sille asetettuja tavotteita, voidaan testaussuunnitelmaa muuttaa. Testauksen valmistumisprosessi (test completion process) joka sisältää kaikki testauksen raportointia koskevat työvaiheet ja asiat. Myös kaikki lopetusta koskevat hallinnolliset vaiheet ja tarkastukset.
ISO/IEC 29119, TEKEMISEN PROSESSIT Staattiset testauksen prosessit (static test process) joissa järjestelmää testataan tai arvioidaan suorittamatta ohjelmaa, arviointien tai läpikäyntien tai analyysien avulla. Myös dokumenttien testausta ja arviointia, päivittämistä ja täydentämistä. Poistettu standardista, ei kuitenkaan tarkoita etteikö tätä todellisuudessa tehtäisi. Dynaamiset testauksen prosessit (dynamic test processes) joka sisältää kaiken muun testitapauskohtaisen toiminnan jossa ohjelmaa käytetään tai muutetaantestausta varten. Käytännössä tämä prosessi sisältää kaiken käytännön testaustyön, eli testitapausten suorittamisen, testilaitteiden konfiguroinnin ja virheiden etsimisen raportointia varten esimerkiksi debuggerin avulla.
AMMATTITESTAUKSEN SERTIFIKAATIT JA STANDARDIT ISTQ-B-osaamissertifikaatti ISO/IEC 29119 prosessimalli Arviointimalleja TMMi (CMMi) SPICE (Testing SPICE) Test Process Improvement, TPI + useita muuta, mutta tässä ehkäpä eniten käytetyt viralliset ja/tai standardoidut mallit.
TMMI (JA CMMI) Taso 1, Aloitustaso: Tällä tasolla organisaatio tekee testausta mutta ei toimi hallitusti tai pyri järjestelmälliseen työn organisointiin. Tällä tasolla ei ole omia testaustoiminnan huomioalueita. Taso 2, Hallittu: Tällä tasolla testausta tehdään hallitusti, systemaattisesti ja pyrkien pitämään toiminnan käynnissä myös tapauksissa joissa kaikki ei mene etukäteen tehtyjen suunnitelmien mukaisesti. Tällä tasolla testauksen huomioalueita ovat Testauspolitiikka ja testausstrategia Testauksen suunnittelu Testauksen hallinta ja seuranta Testitapausten suunnittelu ja suorittaminen Testausympäristöt
TMMI (JA CMMI) Taso 3, Määritelty: Tällä tasolla testaus on kokonaan integroitu osaksi kehitystoimintaa, ja organisaatio tekee normaalin testaustoiminnan lisäksi myös esitestausta ja suunnittelee ohjelmistojaan ottaen huomioon myös testattavuuden tarpeet. Tällä tasolla testauksen huomioalueita ovat Testausorganisaatio Testaajien koulutusohjelma Testien elinkaari ja integraatio Ei-toiminnalliset vaatimukset Vertaisarviointi
TMMI (JA CMMI) Taso 4, Mitattu: Tällä tasolla testaus toteutetaan aiempien tasojen mukaisesti järjestelmällisesti ja perustuen organisaation määritelmiin sille miten testaus pitää organisoida. Tällä tasolla mukaan tuodaan testauksen mittaaminen, eli työn etenemistä mitataan, testauksen tehokkuutta arvioidaan ja testausprosessia pyritään valvomaan ja kehittämään. Tämän tason huomioalueita ovat Testausmittarit Ohjelmiston laadun arvioiminen Edistynyt vertaisarviointi
TMMI (JA CMMI) Taso 5, Optimointi: Tämä on TMMi-mallin kehittynein taso, ja kuten aiemmat tasot, se perustuu siihen että aiemmat tasot toteutetaan onnistuneesti. Tällä tasolla testaus toimii ja kehittää itseään jatkuvasti hyödyntäen neljännen tason mittareita. Työ tehdään kokonaisuutena joka perustuu yrityksessä sovittuihin malleihin ja joka on toiminnaltaan määriteltyä ja organisoitua. Tasolla viisi huomioalueita ovat Virheiden estäminen Testausprosessin optimoiminen Laadunvalvonta.
TEST PROCESS IMPROVEMENT (TPI) Sidosryhmien sitouttaminen Osallistumisaste Testausstrategia Testiorganisaatio Kommunikointi Raportointi Testausprosessin hallinta Arviointi ja suunnittelu Mittaaminen Virheiden hallinta Dokumenttien hallinta Metodien käyttö Testaajien ammattimaisuus Testitapausten suunnittelu Testaustyökalut Testiympäristöt
TEST SPICE JA SPICE SPICE (Software Process Improvement and Capability determination) ISO/IEC 15504-standardi Yhdistää ISO/IEC 12207-elinkaarimallin tavan määritellä miten ohjelmistotuotteen elinkaari on määritelty sekä Bootstrap Trillium CMM Best Practiceja.
SPICE JA TEST SPICE Viisi prosessiryhmää Asiakas/toimittaja (customer/supplier) Kehitystyö (engineering) Tukitoimet (supporting) Hallinto (management) Organisaatio (organization) Näiden sisällä arvioidaan eri prosessien kypsyystasoa. Tavoitteena tietää Miten hyvin organisaatio toimii Miten organisaatiota voisi parantaa
SPICE JA TEST SPICE OK, no miksi Test SPICE? SPICE on mallina hyvin geneerinen. Tarkempia versioita mm. ydinturvatekniikalle, autovalmistajille, lääketieteen teollisuudelle. Yllättäen, Test SPICE erikoistunut nimenomaan laadunvarmennukseen ja testaustoiminnan arviointiin. Lähestymistapa ja arviointikäytännöt yhteisiä, alakohtaiset attribuutit. Esimerkiksi Test SPICE näyttää seuraavalta:
TEST SPICE
ISTQB-SERTIFIKAATTI Kaupallinen, erillisistä sertifiointikoulutuksista hankittavissa oleva osaamissertifikaatti. Ajatuksena se, että kaikkialla suoritetaan sama koe samasta aineistosta omalla äidinkielellä tai englanniksi. Perustason dokumentit myös Suomeksi. Myös Suomessa yksi tavallisimmista yrityspuolen testauskoulutuksista.
ISTQ-B Foundation-tason tenttiaineisto saatavilla netistä. Perustaso (Foundation level) Jatkotaso (Advanced level), sisältäen kokonaisuudet seuraavista aiheista: Testauksen johtaminen (Test manager) Testianalyytikko (Test analyst) Tekninen testianalyytikko (Technical test analyst) Ammattilaistaso (Expert level), sisältäen kokonaisuudet seuraavista aiheista: Testausprosessin kehittäminen (Improving the test process) Testauksen hallinta (Test management) Testausautomaatio Turvallisuustestaus Vilkaistaan sertifikaatin sisältöä
TDD TEST DRIVEN DEVELOPMENT
TESTAUSVETOINEN OHJELMISTOTUOTANTO Toisin kuin muut esitellyt mallit, TDD ei ole pelkkä testauksen tekemisen, vaan koko ohjelmiston valmistamisen malli! Ajatuksena toteuttaa yksikkö- ja integrointitason testit ennen ohjelman tekemistä. Teoriana täydellinen testitapausluettelo. Agilen testaaminen lähestymistapa; ei suunnittelua tai määrittelyä, vaan testitapaus edellä tekemistä.
TESTAUSVETOINEN OHJELMISTOTUOTANTO
KÄYTÄNNÖN HUOMIOITA PROSESSIMALLEISTA
HUOMIOTA ERILAISISTA PROSESSIMALLEISTA Erilaisia prosessimalleja ja arviointimalleja on useita. Samoja asioita, eri järjestyksissä. Mallin käyttöönotto ei aina pelkästään positiivinen asia. Omat agendat Yhteensopivuusongelmat Jokin ulkoinen tai keinotekoinen tavoite, kuten sertifikaatti. Lähtökohtaisesti mallin pitäisi mukautua yritykseen, ei toisin päin! Usein ongelmana joko Liian nopea mallin käyttöönotto ajattelematta sitä, mikä voisi toimia. tai se, että mitään ei muuteta vaikka asiat menee aina pieleen.
Software Engineering Methodsin kalvot Joskus prosessimallit ei vain toimi tai ne on käyttöönotettu vääristä syistä. Metodimessiaat Luotetaan prosessimalliin, ei työntekijöihin. Keskitytään byrokratiaan, ei tekemiseen. Siirtyvä maalitaulu HUOMIOTA ERILAISISTA PROSESSIMALLEISTA Tarve ammattimaistaa työntekoa. Sertifikaatti asiakkaita, ei omaa työtä varten. Seurannan ja tarkkailun työkalu.
TOIMINNAN KEHITTÄMINEN Aikaisemmassa luennossa on puhuttu siitä, miten organisaatiolla on omat Työkalut Prosessimallit Testaussuunnitelmat Samoin projektista riippuen saatetaan käyttää erilaisia testausmenetelmiä. Entä jos nykyinen malli ei vain toimi? Toiminnan arviointi? Toiminnan kehittäminen.
TESTAUST YÖN KEHITTÄMINEN Huomioiden pohjalta voidaan väittää, että spontaani toiminnan kehittäminen on harvinaista. Status Quo on arvokas, sitä ei haluta vaarantaa. Ei korjata ehjää konetta. Ei kyllä edes vähän viallistakaan. Toiminnan kehittäminen nähdään kustannuksena ja riskinä, jota ei pienistä syistä kannata ottaa:
MALLI KEHITTÄMISELLE (TAI OIKEAMMIN KEHITTÄMÄTTÄ OLEMISELLE)
YLEISEN TESTAUSSTANDARDIN (ISO/IEC 29119) SOVELTUVUUS KÄY TÄ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.
MITÄ TÄSTÄ LUENNOSTA PITÄÄ MUISTAA? Kahdenlaisia malleja Toiminnan arviointia (miten meillä menee) Toiminnan kehittämistä (miten menisi paremmin) Osaamissertifikaatti virallista taitojen osoittamista varten. Myös malleja ihan ohjelmistotuotannon rakentamiseen testauksen ympäriltä (TDD).