2. ausprosessi (Artikkelit) Nykyisin useimpien prosessimallien lähtökohta on, että testaus on oleellinen osa ohjelmistotuotantoprosessia. Itse asiassa huolellinen testaus vie helposti 50% tai enemmän käytettävistä resursseista. Vain äärimmäisen harvoin laadukas ohjelmisto voidaan toteuttaa ilman systemaattista testausta. Johtopäätös: testaus on tarvitsee oman hallittavan systemaattisen prosessin. ausprosessin vaatimukset aus on systemaattinen ohjelmistotuotantoprosessin osavaihe. Siihen tarvitaan testaussuunnitelma, jotta tiedetään, mitä testataan, milloin testataan ja kuka testaa. mittaamista, jolla seurataan prosessin etenemistä, seurantaa, jotta tiedetään, miten hyvin projektissa on kyetty seuraamaan testaussuunnitelmaa ja hallintaa, jotta testiryhmä voi keskittyä testaamiseen. 1 2 Perinteinen testausprosessimalli (vesiputousmalli) Perinteinen malli pitää testausta yhtenä vesiputousmallin osavaiheena: määrittely: ohjelman vaatimusten selvitys, suunnittelu: arkkitehtuurin ja yksityiskohtien suunnittelu, toteutus ja yksikkötestaus: suunnitelmien toteuttaminen ja toteutuksen verifiointi. (järjestelmä)testaus: toteutuksen validointi. Mallia käytetään erityisesti pienissä projekteissa. Vesiputousmallin ongelmia iprosessi on viimeinen osavaihe, joten projektin myöhästyessä karsitaan keskimääräisesti eniten testauksesta. Karsittu testaus vaikuttaa ohjelmiston laatuun. Kaikkia ominaisuuksia ei saada testattua riittävällä tarkkuudella. auksessa havaitut virheet saattavat olla seurausta suunnitteluvirheistä tai vaatimusmäärittelyn puutteista. Tällaisten virheiden korjaus on kallista ja vie paljon aikaa. Kaikkia löydettyjä virheitä ei ehkä voida korjata. 3 4 ausprosessimalli V-malli V-mallissa testaus ei ole enää erillinen työvaihe, vaan se on integroitu kaikkiin prosessin osavaiheisiin. Jokaisen ohjelmistotuotantoprosessin työvaiheen yhteydessä suunnitellaan testipaketti, jolla analysoidaan seuraavasti: käyttäjävaatimukset hyväksymistestauksessa, järjestelmävaatimukset järjestelmätestauksessa, arkkitehtuurisuunnitelma integrointitestauksessa, moduulisuunnitelma yksikkötestauksessa. V-mallin neljä osavaihetta V-malli määrittelee samalla testauksen neljä osavaihetta: Yksikkötestauksessa testataan pienimmät jakamattomat ohjelman yksiköt. Oliopohjaisessa testauksessa nämä voivat olla olioita, mutta usein ne ovat olioryppäitä. Integrointitestauksessa testataan, että yksikkötestauksen jakamattomat yksiköt toimivat yhteistyössä. aus on pääosin rajapintojen testausta, sillä yksiköiden toiminnallisuus on pääosin testattu yksikkötestauksessa. 5 6 #" $
V-mallin neljä osavaihetta II Integrointitestauksen päätyttyä ohjelmisto on verifioitu. Siinä ei ole ilmeisiä syntaksivirheitä. Tämän jälkeen on kaksi validointivaihetta: Järjestelmätestauksessa ohjelmisto testataan osana koko järjestelmää. Kaikki vaadittavat sisäiset ja ulkoiset ohjelmisto- ja laitteistokomponentit ovat mukana järjestelmässä. Hyväksymistestauksessa asiakkaan edustajat tarkastavat, että järjestelmä vastaa sille asetettuja vaatimuksia. aus tehdään ensin valvotusti alfa-testauksena ja sen jälkeen valvomatta betatestauksena. 7 V-mallin ratkaisut vesiputousmallin ongelmiin iprosessi on mukana prosessin alusta alkaen, joten projektin myöhästyessä siitä ei voida karsia sen enempää kuin muista prosessin osavaiheista. Laatu varmistetaan sekä valmistelemalla testaus että tarkastamalla ensin kunkin testipaketin vaatima osavaihe. Tarkastuksilla karsitaan suurin osa vaatimusmäärittelyn ja suunnittelun virheistä, joten virheet eivät kasaudu toteutukseen. Vaikeimmat validointiin liittyvät virheet saadaan karsittua minimiin tarkastuksilla. 8 Tuotosten tarkastus Tuotosten tarkastukselle on kolme tyyppiä: 1. Sisäinen tarkastus. Varmistetaan, että tuotos on tehty sovittujen standardien mukaan ja että se on sisäisesti yhtenäinen, täsmällinen ja täydellinen. 2. Ulkoinen tarkastus taaksepäin. Varmistetaan, että tuotos täyttää edellisessä osavaiheessa sille asetetut ehdot. 3. Ulkoinen tarkastus eteenpäin. Varmistetaan, että tuotos tarjoaa riittävästi rakennetta seuraavan osavaiheen aloittamiseksi. V-mallin kaaviokuva N L C & ) & B ; ;, + *, B +,, B +,, %, B, + *, %,,, %,,, + + 5 5, <,,,,, + + 5 7,, + 5 7,, ^ FG HJI9K9II9L MON P9HEN HJI QKEI9N LRES9TJKUN QKEI9N SEP9IWV6SULXEK 89&,, /.<(5 &(') *(+ *(-.&(? ;(; /.><(5 @6' <(<(1(1 /,*(A /, *(-.>; <(' /? =>3(:(< <(-/? <(<(1(1 /, *(-.>; YEZ[ \(Z] _] D9C &(5 C(.>/+ *(+ /, &(') *(+ *(-.& *(+ /, 01 *(2(' 3(/1 /, *(+ /, 465 /5 *(+ /, 893(3(: ;(<(+ D9C &(5 C(.>/+ *(+ ;(<(+ &(') *(+ *(-.& *(+ ;(< 01 *(2(' 3(/1 /, *(+,;(<(+ 4E5 /5 *(+ ;(<(+ 9 10 Yleinen testauksen osavaiheprosessi Analyysi: Mitä testataan? Jokaisen osavaiheen testausprosessi on varsin samanlainen. Prosessissa on neljä askelta: 1. Analyysi: mitä testataan? 2. Suunnittelu: miten testataan? 3. Ajoitus: koska testataan? 4. Suoritus ja evaluointi: mitä tapahtui? Tavoitteena on osoittaa, että järjestelmä toteuttaa sille asetetut vaatimukset ja järjestelmä toimii riittävän oikein. 11 Analyysissa selvitetetään tavoite: mihin tässä testivaiheessa pyritään, lähestymistapa: minkä tyyppistä testausta tehdään resurssit ja rajoitteet: mitä on käytettävissä, aikataulu: milloin testaus toteutetaan, testattavat kohteet: mitä tarkalleen testataan, testattavat ominaisuudet: mihin keskitytään, seuraavien vaiheiden tehtävät: miten toimitaan ja riskit: mikä voi mennä pieleen. Tuloksena saadaan testaussuunnitelma. 12 #"
Suunnittelu: miten testataan? ien suunnittelu II aussuunnitelma määrittelee yleiset testauksen suuntaviivat ja vaatimukset. Suunnittelussa suuntaviivat ja vaatimukset jalostetaan testipaketeiksi, testitapauksiksi ja testiskripteiksi. Työvaiheen tuloksena saadaan joukko testisuunnitelmia (test design specification): Yleensä jokaista testipakettia kohti on testisuunnitelma. Siinä kuvataan testipaketilla testattavat ominaisuudet, testien tunnistus ja testien hyväksymis- ja hylkäämiskriteerit. 13 Dokumenttilista jatkuu: jokaista testisuunnitelmaa (eli testipakettia) kohti joukko testitapausten kuvauksia (test case specification): testin kohde, syötteet, tulosteet, ympäristövaatimukset, erityisvaatimukset, riippuvuudet muihin testeihin jokaista testisuunnitelmaa kohti joukko testiskriptien kuvauksia (test procedure specification): miten testit suoritetaan, skriptikielen kuvaus. Skriptikieli on erityinen ohjelmointikieli, jonka avulla kirjoitetaan testit suorittava testiajuri. 14 Ajoitus: koska testataan? Suoritus ja evaluointi: mitä tapahtui? ipaketeilla, pakettien testitapauksilla ja testiskripteillä voi olla keskinäisiä riippuvuuksia. Kun paketit on suunniteltu, nämä riippuvuudet voidaan selvittää ja päättää sen perusteella testitapausten suoritusjärjestys. Meillä voi esimerkiksi olla testitapaus, joka epäonnistuessaan tekee muiden testitapausten suorituksen tarpeettomaksi. Tällöin luonnollisesti testitapauksen suoritus ajoitetaan ensimmäiseksi. 15 Suorituksessa skriptikielillä kirjoitetut testiajurit ajetaan. Kukin testiajuri ottaa vastaan testitapauksen syötteet, muokkaa syötteet ohjelman vaatimaan muotoon, suorittaa testin, vastaanottaa tulokset ja tulkitsee tulokset haluttuun muotoon. iajuri lähettää tulkitut tulokset oraakkelille, joka päättää, menikö testi läpi. 16 ien evaluointi: oraakkeli Oraakkeli tarkistaa automaattisesti jokaisen testin kohdalla, täyttikö se suunnittelussa päätetyt hyväksymiskriteerit. Sen siis tulee tietää, mitä testitapauksen pitäisi palauttaa. Aina oikeaa tulosta ei tiedetä etukäteen. Tällöin oraakkelin pitäisi päätellä oikea tulos. Oikean tuloksen päättely on usein vaikeaa, jopa mahdotonta. Kaikille testitapauksille ei yksinkertaisesti löydy oraakkelia. 17 ien suorituksen ja arvioinnin dokumentit Työvaiheesta saatavat dokumentit ovat: testiloki (test log): sisältää kronologisen kuvauksen testin etenemisestä. Jokaisesta suoritetusta testistä tulee tulla automaattinen loki. vikaraportti (test incident report / bug report) niistä testeistä, jotka eivät menneet läpi. Se sisältää viitteen vastaavaan testilokiin, oraakkelin mukaan odotetun tuloksen ja saadun tuloksen. ien suoritus ja arviointi on automaattista. Kerran ajetut testit on voitava suorittaa uudestaan ilman manuaalisia toimintoja. 18 #" `
Vielä muutama testausdokumentti IEEE Standard for Software Documentation Edellä esitellyt dokumentit ovat IEEE:n standardin 829-1998 mukaiset (kaaviokuva on seuraavilla kalvoilla). Standardi määrittelee lisäksi kaksi muuta dokumenttia: itapausten toimitusdokumentti (test item transmittal document): dokumentti sisältää tiedot (fyysisistä) testitapauksista ja niiden toimittamista testauspaikalle. ien yhteenvetoraportti (test summary report): dokumentti kokoaa yhteen testauksen tulokset. 19 Design Project Doc Case Plan Design Item Doc Proc Design Item Item Transmittal 20 IEEE Standard for Software Documentation II auksen vastuu Log Proc Incident Execution Item Transmittal Log Incident auksen vastuu voi vaihdella työvaiheen ja organisaation mukaan. Yleisimmät vaihtoehdot ovat seuraavat: aus on koodaajien vastuulla. Kukin testaa oman koodinsa. Tätä käytetään yksikkötestauksessa, mutta ei juuri sen jälkeen. Koodaaja sokeutuu helposti omille virheilleen. Vaihtoehto sopii yksikkötestaukseen, sillä yksikkötestauksessa testattavat osat ovat pieniä ja kohtuullisen helposti hallittavia. Lisäksi yksikkötestauksen teoria on varsin kattava. Summary 21 22 auksen vastuu II aus on projektiryhmän jäsenten tehtävä. Kukaan ei omista koodia, vaan kaikki testaavat toistensa osia ristiin. Tätä käytetään muun muassa ketterissä prosessimalleissa. Vaihtoehto toimii hyvin, jos resursseja on riittävästi. Valitettavan usein kuitenkin testaukseen tarkoitetut resurssit jäävät suunnitteluun ja toteutukseen. aus on ulkopuolisen testausryhmän vastuulla. Tämä on paras vaihtoehto, sillä se karsii koodaajan osuuden testauksesta. Vaihtoehto toimii erittäin hyvin, mutta se on myös kallein. Sitä käytetään erityisesti järjestelmätestauksessa. 23 ausryhmä Ulkopuoliseen testausryhmään kuuluu: ausryhmän päällikkö, joka vastaa tehtäviltään pitkälti projektipäällikköä. aajat, jotka eivät ole vain hyviä ja koodaajia. Hyvä testaaja osaa rikkoa, löytää virheitä. Kaikista ei ole tähän. Päätestaaja, joka tuntee testiympäristön ja testattavan sovellusalueen. Päätestaaja toimii sekä testaajana että teknisenä tukena. Mielellään loppukäyttäjien edustaja, sihteeri, laitteistoasiantuntija, ym. Yleensä valitettavasti ei. 24 #" a
ausprosessin hallinta ausprosessin hallinta on pitkälti samanlaista kuin koko ohjelmistoprosessin hallinta, mutta yhdellä oleellisella erolla: austa ei voi tehdä, jos ei ole testattavaa. Näin ollen testausprosessin aikataulutus ja hallinta riippuu testattavan ohjelmiston prosessin hallinnasta. V-mallin käyttö auttaa hiukan, mutta siitä huolimatta testausprosessi on astetta dynaamisempi kuin koko ohjelmistoprosessi. 25 Käytännön neuvoja hallintaan Koska testausprosessin hallinta muistuttaa yleistä prosessinhallintaa, niin se on jo tullut tutuksi ohjelmistotuotantokurssilla. Samojen asioiden toistamisen sijaan esittelen tässä muutamia käytännön neuvoja, jotka helpottavat testausprosessin hallintaa. Neuvot perustuvat erinomaiseen kirjaan: C. Kaner, J. Bach, B. Pettichord. Lessons learned in software testing. A context-driven approach. ISBN 0-471-08112-4. 26 auksen suhde projektinhallintaan aus on palvelua aajat tarjoavat palveluita projektille: Virheiden etsintä. Virheiden raportointi. Vaatimusten validointi. aus ei ole ohjausta. aajien tehtävä ei ole ohjata tai neuvoa ohjelmistoprojektia kohti parempia työmenetelmiä. Kun ohjaus ja palvelu erotetaan toisistaan, testaajien on helpompaa käyttää osaamistaan ydintehtävään: haluttuun testaukseen. auksen suhde projektinhallintaan II ausprosessi on oma prosessi. aus on itsenäisempi työvaihe kuin muut prosessin osavaiheet. Siitä seuraa, että testausprosessin hallinta on itsenäisempää kuin esimerkiksi suunnitteluprosessin hallinta. Jokaisella projektilla on projektipäällikkö, joka vastaa projektin aikataulusta ja hallinnasta. Projektipäälliköllä on ylin vastuu myös testausprosessista, mutta testiryhmän päälliköllä pitää olla lopullinen päätösvalta päättää testauksen aikataulusta ja suoritusjärjestyksestä. 27 28 auksen aikataulu aukselle on varattava tarpeeksi aikaa Tunnetusti vaatimukset muuttuvat projektin aikana. Vaatimusten muutokset heijastuvat eniten testaukseen, sillä testauksen tehtävänä on validoida vaatimukset. Jos testauksen aikataulu on tiukka, muuttuneiden vaatimusten validoinnille ei riitä tarpeeksi resursseja. Tuloksena on tuote, jonka laatua ei ole tarkastettu tarpeellisella tarkkuudella. aajat projektissa aajien pitää olla mukana koko projektin elinkaaren ajan. Koska testaus ei ole pelkkää testitapausten suorittamista, testaajien rooli ei ole pelkkää testausta. aajia tarvitaan koko elinkaaren ajan mm. suunnittelemaan testitapauksia, osallistumaan tarkastuksiin, tuomaan esille vaikeasti testattavia piirteitä vaatimuksista ja auttamaan koodaajia kirjoittamaan testattavaa koodia. 29 30 #" b
Savutestit Savutestejä (smoke tests) tulee käyttää ennen varsinaista testausta. Savutesti on testipaketti, jolla tarkistetaan testattavan osan perustoiminta. Jos savutesti ei mene läpi, testausta on turha jatkaa, sillä testattava osa ei ole riittävän stabiili. Savutestaus sopii erityisesti lyhyen syklin prosessimalleihin. Tällöin uutta versiota testattaessa edellisten syklien testeistä voidaan valita osajoukko, jonka pitää mennä läpi. Tätä sanotaan regressiotestaukseksi. aus projektissa aus adaptoituu projektiin eikä päinvastoin Vaikka testaus on tärkeää, se on kuitenkin vain yksi osa koko prosessia. Jos testiryhmän käyttävä testausprosessi ei sovi projektin käyttämään ohjelmistoprosessiin, testausprosessia pitää muuttaa. Jos projektiryhmän käyttävät suunnittelu- ja toteutustavat eivät ole testattavissa testausprosessin mukaisin keinoin, testausprosessia pitää muuttaa. aus on palvelua ja yhteistyötä, ei ohjausta. 31 32 Paritestaus Paritestausta kannattaa yrittää. Paritestauksessa kaksi testaajaa työskentelee yhdessä samojen testitapausten parissa. Samoin kuin pariohjelmointi, paritestaus saattaa olla tehokkaampaa kuin kahden testaajan työskentely yksin. Paritestauksessa molemmat ideoivat testejä ja keskustelevat niistä. Näin testien kattavuudesta tulee luultavasti parempi kuin yksin testattaessa. Paritestaus auttaa myös motivaatioon. Yksin testeistä vastaaminen voi olla erittäin raskasta. Käytännön neuvoja testausryhmän hallintaan Seuraavassa testausryhmä tarkoittaa projektiryhmästä erillistä ryhmää testaajia, joka toimii vuodesta toiseen yhdessä useassa projektissa. Motivoitunut testausryhmä on testauksen tärkein resurssi. Automaatio, testaustyökalut, hienot testausprosessit ja hallintamenetelmät eivät ole minkään arvoisia, jos testausryhmällä on motivaatio-ongelmia. 33 34 Lopuksi: Jos... Niin... Jos luovuus ei mielestäsi kuulu testaukseen; Jos pyrit tarkkaan rajattuun testausprosessiin; Jos standardoit työt sellaisiksi, että jokainen voi tehdä jokaisen tehtävät samoilla työtavoilla; Jos etäännytät työntekijäsi heidän työnsä tuloksista etkä anna heidän vaikuttaa korjaukseen; Jos kerrot työntekijöillesi, että heidän työnään on raportoida virheistä eikä keskustella niistä projektiryhmän jäsenten ja sidosryhmien kanssa; Jos et ota huomioon testausryhmän jäsenten persoonallisuuksia, toiveita ja jännitteitä; 35 Älä odota heidän antavan kaikkeaan edes silloin, kun projektin onnistuminen riippuu siitä; Älä odota heidän kehittävän testausprosessia; Alä odota heitä vapaaehtoisesti ylitöihin; Älä odota heidän suunnittelevan nerokkaita vaikeita kriittisiä virheitä löytäviä testejä; Älä odota heidän yrittävän parhaansa mukaan selittää löydettyjä virheitä projektiryhmälle; Äläkä varsinkaan odota heidän olevan lojaaleja. If you declare there shall be no heroes in your company, you won t get any. 36 #" c