12. Testausprosessin parantaminen

Transkriptio

1 12. Testausprosessin parantaminen Seuraavaksi käsitellään testausprosessin mittaamista ja kehittämistä. Ideana on parantaa tuotteiden laatua parantamalla prosessia, joka ne tuottaa. Mika Katara: Ohjelmistojen testaus, Mukailtu lähteestä [Craig&Jaskiel 02] Testausorganisaatioita vaivaa sama ongelma kuin muitakin organisaatioita: on vaikea saada ihmiset tekemään asioita toisin kuin he ovat tottuneet tekemään Kun muutostarpeita esitetään, organisaation edun ajattelemisen sijaan pohditaan helposti vain mitä voitettavaa/hävittävää minulla on Tärkeimmät tehtävät testausprosessia kehitettäessä: Niiden osa-alueiden identifiointi, joilla parannettavaa on Parannusten toteuttaminen juuri näillä alueilla Mika Katara: Ohjelmistojen testaus,

2 Testausprosessin kehittämisen askeleet Selvitä testausprosessin (koko prosessi tai jokin osa-alue) tämän hetkinen taso Aseta tavoitteet Selvitä vaatimukset tavoitteiden saavuttamiseksi Vaatimusten pitäisi olla realistisia, täsmällisiä ja mitattavia Priorisoi vaatimukset Aloita prosessinparannusprojekti samoin kuin mikä tahansa ohjelmistokehitysprojekti Tavoitteena on riittävien resurssien varmistaminen Laadi suunnitelma, jossa kuvataan askeleet tavoitteiden saavuttamiseksi Suunnitelmaan kuuluu aikataulu, budjetti, riskit yms. Mika Katara: Ohjelmistojen testaus, Toteuta muutokset vähitellen Resursseja ei tarvita kerralla niin paljon Tulosten analysointi helpompaa Käytä pilotointia Mittaa tulokset Vertaa mittaustuloksia suunnitelmaan Mikäli tarpeen, aloita jälleen ensimmäisestä askeleesta Mikäli prosessia aiotaan kehittää, on syytä huolehtia siitä, että tarvittaville toimenpiteille saadaan kaikkien osapuolten hyväksyntä Hyväksyntä voidaan saavuttaa esim. mittareiden avulla, palautetta keräämällä ja hyödyntämällä, koulutuksella sekä organisaation sisäisillä sponsoreilla Mika Katara: Ohjelmistojen testaus,

3 12.1 Laatujärjestelmän ISO-sertifiointi International Organization for Standardization ISO 9000 sarjan standardeista ohjelmistotuotannon kannalta merkittävin on 9001 sekä sen soveltamisohje Syitä sertifikaatin hankkimiseen: Laatuprosessien parantaminen Vertailukohdan asettaminen parannusta ajatellen Markkinasyyt joillakin teollisuuden aloilla sertifiointi on käytännössä edellytys kauppojen syntymiselle, päämiehen vaatimus edellytys julkishallinnon kilpailutuksiin osallistumiselle useilla aloilla Mika Katara: Ohjelmistojen testaus, ISO 9001 sertifiointi on raskas ja aikaa vievä prosessi Koko organisaation sijasta vain jokin sen tietty osa voidaan sertifioida Auditoinnit ovat jatkuva menoerä Testausprosessin parantamiselle ISO 9001 sertifiointi voi toimia ponnahduslautana Sertifioinnin kannalta tärkeintä on kehittää dokumentoidut ja toistettavat menettelytavat asioiden tekemiseen Mika Katara: Ohjelmistojen testaus,

4 ISO 9001 sertifioinnista on ohjelmistoteollisuudessa ristiriitaisia kokemuksia Toisille se toimii markkinointikikkana, jolla on vähän vaikutusta tuotteiden lopulliseen laatuun Toisaalta, mikäli organisaatio on valmis panostamaan prosessien parantamiseen ja motivaatiota sertifiointiin löytyy, ISO 9001 voi olla juuri se mitä tarvitaan lähtölaukauksen antamiseksi Mika Katara: Ohjelmistojen testaus, CMM Capability Maturity Model Organisaatiokeskeinen laatujärjestelmän arviointimalli Uusin versio CMMI (CMM Integrated) CMMI:n askeleittainen versio vastaa vanhaa CMM:ää CMMI:n jatkuva versio vastaa ISO/IEC standardia (Spice) Taustalla Software Engineering Institute (SEI) SEIn taustalla USA:n puolustushallinto CMM on kehys, joka koostuu viidestä kypsyystasosta Jokainen taso sisältää kaikki edelliset tasot Evaluointiprosessin avulla organisaatio voi selvittää millä tasolla se tällä hetkellä on Mahdollistaa vertailun eri organisaatioiden välillä Mika Katara: Ohjelmistojen testaus,

5 Ideana kypsyystasoissa on se, että tason kasvaessa pitäisi tuotekehityksen riskien pienentyä ja tuottavuuden ja tuotteiden laadun kasvaa Testausprosessin parantamisen kannalta on valitettavaa, että CMM:n kaksi ensimmäistä tasoa jättävät testauksen vähälle huomiolle Mika Katara: Ohjelmistojen testaus, CMM:n taso 1: Initial process Tälle tasolle pääsevät kaikki Ohjelmistoprosesseja muutetaan usein tarpeiden mukaan ilman kurinalaisuutta Yksilöt sekä heidän motivaationsa, tietonsa ja taitonsa vaikuttavat onnistumiseen Kriisitapauksissa johtajat tyypillisesti hylkäävät suunnitellut toimintatavat koodaus ja testaus tehdään niin kuin sillä hetkellä näyttää parhaalta Mika Katara: Ohjelmistojen testaus,

6 CMM:n taso 2: Repeatable process Panostus projektin johtamiseen Kurinalaiset prosessit Projektin aikataulut ovat realistisia pohjautuen vaatimuksiin sekä kokemuksiin aikaisemmista projekteista (Joidenkin) projektien taustalla toistettava prosessi Mika Katara: Ohjelmistojen testaus, CMM:n taso 3: Defined process Koko organisaation kattavat prosessit sekä johto- että suoritusportaan tehtäviä varten Kaikkien projektien taustalla on toistettava prosessi Erityispanostus dokumentoinnissa Mika Katara: Ohjelmistojen testaus,

7 CMM:n taso 4: Managed process Tasoilla 3 ja 4 käyttöönotettuja mittareita käytetään ymmärtämään ja säätämään prosesseja ja tuotteita kvantitatiivisesti CMM:n taso 5: Optimizing process Prosessin parannus on jatkuvaa Kvantitatiivinen palaute projekteista ja tuotteista Mika Katara: Ohjelmistojen testaus, CMM on hyvin prosessikeskeinen, eikä kaikkia sen vaatimuksia välttämättä kannata toteuttaa kaikissa organisaatioissa ellei tavoitteena ole ensisijaisesti jonkin tietyn tason saavuttaminen esim. markkinointisyistä Erityisesti pienten firmojen voi olla jopa parempi olla toteuttamatta kaikkia tason viisi vaatimuksia Mika Katara: Ohjelmistojen testaus,

8 Mitä CMM:n tasot voisivat merkitä testauksen kannalta: Tasolla 2 testauspäälliköiden pitäisi määritellä testauksen ja virheiden etsimisen tavoitteet ja käynnistää organisaation sisällä prosessi testauksen suunnittelua varten Tasolla 3 aloitetaan systemaattinen testausprosessi testauspäälliköiden pitäisi koota testiorganisaatio testaussuunnitelmat pitäisi integroida ohjelmistokehityksen elinkaareen testiprosesseja pitäisi tarkkailla ja säätää tarvittaessa Mika Katara: Ohjelmistojen testaus, Tasolla 4 laatu-/testauspäälliköiden pitäisi perustaa koko organisaation kattavat ohjelmat tarkastuksia, teknistä koulutusta, kattavuusmittausta ja ohjelmiston laadun mittausta varten Tasolla 5 testauspäälliköiden pitäisi soveltaa prosessin ohjausta virheiden välttämiseksi ja keskittyä laadunohjaukseen liittyviin tehtäviin Mika Katara: Ohjelmistojen testaus,

9 Organisaatiot etenevät CMM:n tasoilla yleensä askel kerrallaan 1 2, 2 3, 3 4, 4 5 Jotkin askeleet ovat työläämpiä kuin toiset Toisaalta myös saavutetut hyödyt vaihtelevat eri askelien välillä Ylimmillä tasoilla saattaa ongelmaksi tulla prosessien jäykkyys, jos pienetkin muutospyynnöt on vietävä suuren koneiston läpi Mika Katara: Ohjelmistojen testaus, TPI Mukailtu lähteestä Tim Koomen, Martin Pol: Test Process Improvement, Addison-Wesley, 1999 Test Process Improvement Malli on yrityslähtöinen ja sen tarkoituksena on olla käytännönläheinen ja koeteltu tapa testausprosessin kehittämiseen Tavoite on kunnianhimoinen, koska yhden mallin pitäisi kattaa kaikki organisaatiot koosta, osaamistasosta ja käytetyistä tekniikoista riippumatta TPI ja CMM TPI on terminologialtaan CMM-yhteensopiva CMM:n käyttö ei kuitenkaan ole edellytys TPI:n käytölle Toisin kuin CMM, TPI keskittyy pelkästään testaukseen Mika Katara: Ohjelmistojen testaus,

10 TPI:n arkkitehtuuri: Avainalueet Testauksen kypsyysmatriisi Tasot Tarkistuspisteet Parannusehdotukset Mika Katara: Ohjelmistojen testaus, Jokainen avainalue määrittelee 1-4 kypsyystasoa asteikolla A, B, C tai D, kypsyyden mukaan kasvavassa järjestyksessä Jokainen taso olettaa edelliset tasot kuten CMM:ssä Tasolle A ei kuitenkaan pääse automaattisesti, erillinen aloitustaso (starting level) kuvaa tätä tilannetta Mika Katara: Ohjelmistojen testaus,

11 Tarkistuspisteet määrittelevät organisaation tason (A-D) avainalueen sisällä Esim. raportoinnin avainalue: vikojen raportointi edistymisen raportointi sekä vikojen priorisointi järjestelmän ja organisaation riskien havaitseminen ja parannusehdotusten esittäminen, mittareilla vahvistettuna parannusehdotukset liittyvät ohjelmistoprosessin parantamiseen Mika Katara: Ohjelmistojen testaus, Avainalueiden tasoilla on riippuvuuksia toisiinsa, esim. testausstrategian avainalueen taso A vaatii, että spesifiointitekniikat sekä sitoutuminen ja motivaatio ovat myöskin tasolla A Vaikka tarkistuspisteitä voidaan käyttää sen selvittämiseksi mitä kunkin avainalueen sisällä pitäisi kehittää, on tätä tarkoitusta varten myös tasokohtaisia parannusehdotuksia ehdotukset ovat siis vain ehdotuksia, eivät edellytyksiä jollekin tasolle pääsemiseksi Mika Katara: Ohjelmistojen testaus,

12 Avainalueet (20 kpl) Testausstrategia (A-D) strategian täytyy keskittyä löytämään tärkeimmät virheet mahdollisimman aikaisin ja halvalla määrittelee mitkä testit kattavat vaatimukset ja laaturiskit kokonaisstrategian laatuun vaikuttaa eri testaustasojen strategioiden laatu ja yhteensopivuus Testausprosessin elinkaarimalli (A-B) suunnittelu, valmistelu, määrittely, suoritus ja viimeistely parantaa ennustettavuutta mahdollistaa testausprosessin säätämisen Mika Katara: Ohjelmistojen testaus, Testauksen aikainen mukaantulo ohjelmistokehitykseen (A-D) vaikka testit ajettaisiin vasta kehitysvaiheen lopulla, testausprosessin täytyy alkaa jo paljon aikaisemmin Laskelmointi ja suunnittelu (A-B) mitä pitää tehdä, koska ja millä resursseilla (ihmiset) perusta resurssien allokoinnille Testien spesifiointitekniikat (A-B) testitapausten laadun ja syvyyden arviointi testitapausten uudelleenkäytettävyys Staattisen testauksen tekniikat (A-B) esim. tarkistuslistojen käyttö Mika Katara: Ohjelmistojen testaus,

13 Metriikat (A-D) testausprosessin kannalta tärkeät mittarit kuvaavat prosessin etenemistä ja testikohteen laatua kun prosessia parannetaan, mittareita käytetään arvioimaan toimenpiteiden vaikutusta Testaustyökalut (A-C) mm. parempi motivaatio testaajilla vs. manuaalinen testaus Testiympäristö (A-C) Testaajien työympäristö (A) motivaatio, kommunikaatio, työn tehokkuus Sitoutuminen ja motivaatio (A-C) sekä johto- että suoritusporras (resurssien allokointi yms.) Mika Katara: Ohjelmistojen testaus, Tietotaito ja koulutus (A-C) testaustiimin koostuminen ihmisistä joiden tiedot ja taidot täydentävät toisiaan, esim. sovellusalueen ja organisaation tuntemus, ohjelmointi- ja sosiaaliset taidot kouluttaminen paikkaa puutteita Menetelmien laajuus (A-C) käytettyjen menetelmien pitäisi olla toisaalta riittävän laajoja kattamaan kaikki käyttötarpeet ja toisaalta tarpeeksi yksityiskohtaisia ettei samoja asioita joudu miettimään aina kun menetelmää sovelletaan Kommunikaatio (A-C) sekä testiryhmän sisällä, että sidosryhmiin sen ulkopuolella kuten kehittäjät, asiakkaat, käyttäjät mm. edistymisestä ja laadusta tiedottaminen Mika Katara: Ohjelmistojen testaus,

14 Raportointi (A-D) testaus on laadun mittaamista ja tietoa laadusta täytyy välittää eteenpäin Virheiden hallinnointi (A-C) johdolle pitää tarjoa keinot virheen elinkaaren selvittämiseen laatutrendien selvittäminen ja analysointi, jonka avulla voidaan antaa perusteltuja neuvoja laadun parantamiseksi Testwaren hallinnointi (A-D) ylläpidettävyyden ja uudelleenkäytettävyyden varmistaminen vaativat hallinnointia testwaren versionhallinta Testausprosessin johtaminen (A-C) Mika Katara: Ohjelmistojen testaus, Arviointi (A-B) arvioidaan kaikkia vaihetuotteita kuten vaatimuksia ja toiminnallista suunnittelua tarkoituksena löytää virheet ennen varsinaista testausta Matalan tason testaus (yksikkö- ja integrointitestaus) (A-C) tavoitteena virheiden löytäminen mahdollisimman aikaisin virheen tekee, löytää ja korjaa yleensä sama ihminen tehokasta, koska kommunikointia ei tarvita paljon Mika Katara: Ohjelmistojen testaus,

15 Testauksen kypsyysmatriisi Kypsyysmatriisi liittää avainalueet ja tasot toisiinsa Matriisissa kuvastuu mm. se, että toisilla avainalueilla kypsyminen tapahtuu luonnostaan nopeammin kuin toisilla Avainalueita tarkastellaan yhtenä kokonaisuutena: mikäli jokin avainalue on tasolla A, koko testausprosessi on korkeintaan tasolla A, vaikka suurin osa avainalueista olisikin jo tasolla B täytyy kuitenkin muistaa, että kaikilla avainalueilla ei ole edes mahdollista päästä D-tasoon asti Mika Katara: Ohjelmistojen testaus, Kypsyys / Avainalue A B C D 2. A B 3. A B C D 4. A B Mika Katara: Ohjelmistojen testaus,

16 Aluksi matriisia käytetään organisaation tilan arvioimiseen värittämällä ne solut vasemmalta oikealle, jotka määrittelevät sen hetkisen kypsyyden kullakin avainalueella A B C D 2. A B 3. A B C D 4. A B Mika Katara: Ohjelmistojen testaus, Sen jälkeen identifioidaan epäkypsin avainalue ja keskitytään sen parantamiseen: A B C D 2. A B 3. A B C D 4. A B Mika Katara: Ohjelmistojen testaus,

17 Koska eri avainalueiden väleillä on riippuvuuksia, voidaan joutua ensin parantamaan jotain muuta avainaluetta Jotta esim. metriikoissa päästäisiin tasolle A, täytyy sitoutuminen ja motivaatio saada ensin tasolle B TPI kokonaisuutena Vaikuttaa järkevältä, koska perustuu teollisuudesta saatuihin kokemuksiin Hyvin prosessikeskeinen, sopineen paremmin isoon kuin pieneen organisaatioon Vaikka menetelmää ei käyttäisikään puhdasoppisesti, sen pohjalta saa varmasti ideoita oman testausprosessin parantamiseen malli ei ainoastaan vastaa kysymykseen mitä, vaan myös kysymykseen missä järjestyksessä kannattaa edetä Mika Katara: Ohjelmistojen testaus, Mallista ehkä hieman paistaa läpi se, että sen synnyinmaassa Hollannissa tehdään testauksen osalta paljon enemmän palveluliiketoimintaan kuin tuoteliiketoimintaan liittyvää testausta Saksalaisten autonvalmistajien konsortio on tehnyt mallista oman versionsa Tämä helpottaa testausprosessien parantamista tilanteessa, jossa valmistajat käyttävät yhteisiä alihankkijoita Tim Koomen kertoi seuraavan jutun EuroSTAR konferenssissa: jos näkee tienposkessa uuden auton, joka on jättänyt matkateon kesken, on noin 50% mahdollisuus, että kyseessä on softabugi Mika Katara: Ohjelmistojen testaus,

18 13. Kurssin loppukaneetti Haluaisitko mieluummin uusia ominaisuuksia vai että entiset toimisivat kunnolla? Pitääkö sijoittaa ominaisuuksien tekemiseen vai testaukseen? Vai kenties vaihtaa koko ohjelmistotuotantoprosessia? Hyvä testaus ei voi pelastaa huonoa ohjelmaa Huono testaus voi tuhota hyvän ohjelman hyvissäkin on nimittäin virheitä, eikä tarvita kuin yksi joka aiheuttaa häiriön väärään aikaan väärässä paikassa Paras keino pitää testauksen määrä kohtuullisena on tuottaa vähemmän virheitä Jos virheitä kuitenkin tehdään, ne pitää löytää mahdollisimman aikaisessa vaiheessa Mika Katara: Ohjelmistojen testaus, Testaus on paljon muutakin kuin vain testitapausten ajamista Testaus on laatuun liittyvän tiedon hankkimista Päinvastoin kuin joskus kuvitellaan, testaus on luovaa, hauskaa ja mielenkiintoista Aivan kuten koodaaminenkin, tavoitteena ei kuitenkaan ole rakentaminen vaan pikemminkin hajottaminen Testausta voidaan tehostaa niin pehmeillä kuin kovillakin lähestymistavoilla Parannetaan testaajien ja kehittäjien välistä kommunikaatiota sekä generoidaan osa testitapauksista automaattisesti käyttäen apuna suunnittelijoiden tuottamia UML-malleja Tehostuksen onnistumista voi mitata vaikkapa asiakkailta tulevien reklamaatioiden määrän muutoksella Mika Katara: Ohjelmistojen testaus,

19 Best practices? Valitettavasti pomminvarmoja toimintatapoja ei varsinkaan dynaamisessa testauksessa ole helppo löytää Vrt. käytä dokumenttitarkastuksia tai vältä moniperintää Testaus, ainakin ylemmillä tasoilla (järjestelmä, hyväksyntä), on hyvin kontekstiriippuvaista Se mikä toimii yhdessä tapauksessa ei välttämättä toimi toisessa Mika Katara: Ohjelmistojen testaus, Kirjallisuutta [Broekman&Notenboom 02] B. Broekman, E. Notenboom: Testing Embedded Software (2002) yksi näkökulma sulautettujen järjestelmien testaukseen, Multiple V -malli [Craig&Jaskiel 02] R. Craig, S. Jaskiel: Systematic Software Testing (2002) mukavasti kirjoitettu uuden sukupolven kirja [Fewster&Graham 99] M. Fewster, D. Graham: Software Test Automation (1999) testiautomaation perusteos [Haikala&Märijärvi 06] I. Haikala, J. Märijärvi: Ohjelmistotuotanto, 11. painos (2006) vielä toistaiseksi ainoa suomenkielinen ohjelmistojen testausta käsittelevä kirja, jossa testaukselle on omistettu yksi luku Mika Katara: Ohjelmistojen testaus,

20 [Jorgensen 02] P.C. Jorgensen: Software Testing: A Craftsman s Approach (second edition, 2002) analyyttisen koulukunnan näkemys testaukseen [Kaner et al. 02] C. Kaner, J. Bach, B. Pettichord: Lessons Learned in Software Testing: A Context-Driven Approach (2002) kontekstiohjatun koulukunnan 293 pientä oppituntia kaikesta mikä liittyy testaukseen, korostaa tutkivaa testausta, ei kannata lukea ensimmäiseksi [Myers et al. 04] G.J. Myers, T. Badgett, T.M. Thomas, C. Sandler: The Art of Software Testing (2004) klassikon uudistettu painos Mika Katara: Ohjelmistojen testaus, [Pezzè&Young 07] M. Pezzè, M. Young: Software Testing and Analysis: Process, Principles, and Techniques yhdistää testauksen kansanperinnettä ja formaalimpia lähestymistapoja [Utting&Legeard 07] M. Utting, B. Legeard: Practical Model- Based Testing A Tools Approach (2007) ensimmäinen mallipohjaisen testauksen käytännönläheinen oppikirja [Whittaker&Thompson 03] J. Whittaker, H. Thompson: How to Break Software Security (2003) avaimet käteen -paketti tietoturvatestauksen aloittamiseksi Mika Katara: Ohjelmistojen testaus,