Projektityö

Projektityö 1.10.2010 Testaussuunnitelma ja testaus Katselmoinnit ja tarkastukset Ohjelmistojen toteutuksesta Loppuraportti, projektikertomus, lopputapaaminen Projekti CD. Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) 1

Testauksen perusteita ja tavoitteita Testaus tarkoittaa suunnitelmallista prosessia, jossa käytetään ohjelmaa tai sen osaa ja tavoitteena on löytää virhe. Ohjelmissa arvioidaan yleensä olevan ohjelmoinnin jälkeen yksi virhe muutamaa kymmentä ohjelmariviä kohden. Testaus näyttää, että ohjelmiston toiminnot toimivat määrittelyjen mukaan ja että tehokkuusvaatimukset saavutetaan. Testitapaukset pitäisi olla mahdollista jäljittää asiakkaan vaatimuksiin (joko suoraan tai epäsuoraan). Testaussuunnitelmaan taulukko, joka osoittaa testitapausten kattavuuden verrattuna vaatimusten määrittelyyn. Osa testitapauksista testaa myös niitä asioita, mitä ohjelma EI SAA tehdä. 2

Hyvän testin ominaisuudet Löytää hyvin todennäköisesti virheen. Testaajan tulisi ymmärtää hyvin ohjelmisto ja miettiä, kuinka ohjelmisto voisi tehdä virheen. Hyvä testi ei ole tarpeeton. Aika ja resurssit ovat rajallisia. Eri testeillä tulisi olla omat tarkoituksensa. Hyvä testi on lajinsa paras. Joskus ehditään suorittamaan vain osa isommasta testijoukosta. Ei ole liian yksinkertainen eikä mutkikas. Sarja testejä saattaa toimia yhtenäkin mutta voivat tuoda sivuvaikutuksia. 3

Testaus ja projektin vaiheet 1/2 Testitapauksia voi alkaa kirjata ylös testaussuunnitelmaan samalla, kun vaatimuksia kerätään tai hyväksytään projektin toimesta toteutettavaksi. Toteutussuunnitelman valmistuessa myös yksityiskohtaisia yksikkötestitapauksia voi alkaa muodostamaan. (järjestelmä)testauksesta täytetään testiraportti, joka myös kuuluu pakollisiin projektin tuotoksiin. Raportti toimitetaan myös toimeksiantajalle. 4

Testaus ja projektin vaiheet 2/2 Inkrementaalinen ohjelmistokehitys Testaus suunnitellaan ennen inkrementin toteutusta. Inkrementin testaussuunnitelma voi olla yksi luku isossa testaussuunnitelmassa tai sitten oma erillinen dokumentti. Testauksen tulokset raportoidaan vapaamuotoisesti. Ongelmat korjataan viimeistään seuraavassa inkrementissä. Lopuksi isompi järjestelmätestaus. Iteratiiviset menetelmät Koodin jatkuva testaus (yksikkötestaus) ja palaute asiakkaalta. Testauksen suunnittelu tehdään iteraatioittain. Yleisperiaatteet voidaan kuvata projektisuunnitelmassa / testaussuunnitelmassa / iteraatioiden suunnitelmissa. 5

Testauksen riittävyyden arviointi Tarvittavan testauksen määrää on yleensä vaikeaa arvioida. Varsinkin järjestelmätestauksessa testausta voidaan jatkaa kunnes aika ja/tai rahat loppuvat. Usein testauksen lopettaminen on kompromissi tuotteissa olevien vikojen aiheuttamien kustannusten ja markkinoilta myöhästymisen aiheuttaman tuoton menetyksen väliltä. Testauksen lopettamiselle tulisi asettaa aina hyväksymiskriteerit, jotka määritellään testaussuunnitelmassa. Kumulatiivinen löydettyjen virheiden ja korjattujen virheiden tarkastelu. Erilaisilla mutkikkuus- (kompleksisuus-) ja kattavuusmitoilla voidaan arvioida tarvittavan testauksen määrää. 6

Testauksen suunnittelu Määrittely dokumentti Kokemus tarkastus listat Suunnittelu dokumentti Laatujär jestelmän ohjeistus Vanha tes taussuun nitelma Testauksen suunnittelu Testisuun nitelma TESTAUS Testira portit 7

Esimerkki Käyttötapaus: koululainen osallistuu Majava-kilpailuun. Ennen kilpailuviikkoa koulun opettaja on rekisteröinyt koulunsa kilpailujärjestelmään ja saanut kilpailutunnukset eri ikäryhmille. Kilpailu suoritetaan opettajan valvonnan alaisena koulussa. Koululainen valitsee järjestelmän etusivulta kilpailemaan -linkin, ja syöttää avautuvalle sivulle seuraavat tiedot: Etunimet, Sukunimi, Syntymäaika, Sukupuoli, Luokka, Tunnus (saa opettajalta). Tiedot syötettyään koululainen valitsee Jatka, minkä jälkeen hän voi tarkistaa omat tietonsa. Hän näkee myös oman opettajansa nimen. Koululainen voi palata muuttamaan tietojaan tai sitten aloittaa kilpailemisen siinä kategoriassa, mihin hänen syöttämänsä kilpailuavain hänet liittää. 8

Esimerkki - Mitä pitää muistaa testata? Raja-arvot (syntymäaika, luokka-aste, tunnus,...) Täsmääkö kilpailuavain, luokka-aste ja ikä? Antaako järjestelmä järkevät virheilmoitukset puuttuvista/virheellisistä tiedoista? Pääseekö tietoja muuttamaan? Virheelliset syötteet (väärä kilpailutunnus, virheelliset nimet,...)? Voiko samalla nimellä ja syntymäajalla kirjautua useampi kilpailija? Montako samanaikaista kilpailusuoritusta järjestelmä kestää? 9

Testauksen dokumentointi 1/2 Testaussuunnitelmasta selviää mitä testejä tehdään ja milloin, miten ne järjestetään ja millaisia lopputuloksia odotetaan. Määritelkää testauksen lopettamiskriteerit. Esim: varatun ajan päättyminen 100% testitapauksista tehty ja analysoitu 100% löydetyistä vioista on korjattu ja kaikkien korjausten jälkeen järjestelmä toimii vaatimusten mukaisesti Kaikki löytyneet virheet tulisi raportoida ja analysoida. Raporttiin virheen kuvaus, miten vakavasta virheestä on kysymys, milloin virhe löydettiin, olisiko se voitu löytää aiemmin, milloin virhe oli tehty ja miten se olisi voitu estää. 10

Testauksen dokumentointi 2/2 Ilman raportteja on mahdotonta saada selville testaukseen käytettyä aikaa ja laatujärjestelmän kehityskohteita. Yksi suositeltava tekniikka on testauspäiväkirjan käyttö. Päiväkirjaan kirjataan kaikista löytyneistä virheistä: miten se korjattiin, korjaukseen käytetty aika ja virheen / korjauksen vaikutus järjestelmän/moduulin toimintaan. Testausraportin muodon saa valita vapaasti. Raportista on nähtävä selkeästi, mitkä testit menevät hyväksyttävästi läpi. Vastaus: kaikki! 11

Testaussuunnitelma (mukailtu IEEE829) TTY:n pohja: www.cs.tut.fi/~projekti/dokumentit/test-sisalto.txt. 1. Johdanto 2. Testausympäristö 3. Henkilöstö- ja koulutusvaatimukset 4. Vastuualueet 5. Vaadittava tulosaineisto 6. Erikoisominaisuudet 7. Testauksen tehtäväjärjestys ja testausmenettely 8. Testaustapaukset 9. Testauksen kriteerit, vaatimukset ja hyväksyntä 10. Riskien hallinta 11. Aikataulu ja työmäärät 12. Testauksen hyväksyntä 12

Katselmoinnit ja tarkastukset https: //projectwiki.cs.uta.fi/wiki/reviews_and_inspections 13

Yksinkertaistettu näkemys ohjelmiston toteutuksen suunnittelusta Määrittely Tuote asiakkaan kannalta Arkkitehtuurisuunnittelu Jako moduuleiksi, rajapintojen määrittely Moduulisuunnittelu 00 11 00 11 00 11 000 111 00 11 000 111 000 111 000 111 Moduulien suunnittelu ja toteutus Järjestelmää ositetaan kunnes jokainen osa on riittävän pieni kuvattavaksi ohjelmistotason välineillä. 14

Yleistä toteutuksen suunnittelusta Määrittelystä toteutukseen siirryttäessä näkökulma muuttuu toteutustekniseksi: järjestelmää ositetaan kunnes jokainen osa on riittävän pieni kuvattavaksi ohjelmistotason välineillä. Tavallisesti tämä tehdään kahdessa vaiheessa: Arkkitehtuurisuunnittelussa ohjelmisto jaetaan moduuleiksi ja moduulien väliset rajapinnat määritellään. Moduulisuunnittelussa suunnitellaan moduulien sisäinen toteutus. Arkkitehtuurisuunnittelu on toteutuksen tärkein vaihe: siinä tehdyt huonot ratkaisut kostautuvat myöhemmin korkeina toteutus- ja ylläpito kustannuksina. Hyvässä arkkitehtuurissa yksittäinen moduuli on tavallisesti helppo korvata. 15

Koteloitu moduuli, sen rajapinta ja toteutus Rajapinta Operaatiot: op1() op2() : : Moduulin nimi Tietorakenteiden määrittely Operaatioiden toteutus Wikipedia: Moduuli tarkoittaa tietokoneohjelman itsenäistä osaa, jolla on syöttötiedot, tulostiedot ja oma toiminnallinen tehtävä (funktio). Ohjelma voidaan koota moduuleista, jolloin puhutaan modulaarisesta ohjelmasta ja modulaarisesta ohjelmoinnista. 16

Suunnittelun eteneminen Suunnittelun eteneminen on luonteeltaan iteratiivista ja hierarkkista. Eri vaihtoehtoja on kokeiltava ja ositusta mietittävä, kunnes lopputulos on tyydyttävä. Kärsivällisyys arkkitehtuurisuunnittelussa palkitaan toteutusvaiheessa ja ylläpidon yhteydessä. Suunnitteluun liittyviä tehtäviä ovat mm. seuraavat: 1. Mietitään ratkaisun yleiset periatteet. 2. Suunnitellaan moduulirakenne: Monet moduuleista toteuttavat jonkin sovellusalueen abstraktion, joka on löydetävissä suoraan määrittelystä. Tekninen toteutus tuo mukanaan lisäksi ohjelmistomaailman abstraktioita. 3. Määritellään mitä tietoa moduulit sisältävät. 17

4. Suunnitellaan moduulien rajapinnat: funktiot ja niiden parametrit, poikkeukset, funktioiden sivuvaikutukset, tehdyt oletukset, ei-toiminnalliset vaatimukset (esim. suoritusaika) jne. 5. Määritellään moduulien näkyvyys: mitä muita moduuleja moduuli tarvitsee toiminnassaan. 6. Testataan ratkaisuja tutkimalla, millaisia kutsusekvenssejä ohjelman toiminnot aiheuttavat moduulien välillä. 7. Suunnitellaan moduulien sisäinen toteutus. 8. Varmistetaan kriittisimpien toteutusratkaisujen toimivuus esimerkiksi prototyypillä. 9. Suunnittelun dokumentointi. 18

Toteutussuunnitelman sisältö TTY:n pohja: www.cs.tut.fi/~projekti/dokumentit/test-sisalto.txt. 1. Johdanto 2. Järjestelmän yleiskuvaus 3. Arkkitehtuurin kuvaus (arkkitehtuuri yleisellä tasolla) 4. Moduuli (luokka /prosessi / yksikkö / pakkaus) kuvaukset 5. Valmisosat ja erityiset tekniset ratkaisut 6. Hylätyt ratkaisuvaihtoehdot 7. Jatkokehitysajatukset 8. Vielä avoimet asiat Mahdolliset liitteet: käyttöliittymän täsmällinen määrittely, virhekoodit, virheilmoitukset, koodaustyyliohje, tiedostojen nimet ja tarkoitus,... 19

Toteutussuunnitelman sisällöstä Suunnitelman tulee vähintään kaksi UML-kaaviota: arkkitehtuurin kuvaava komponenttikaavio (esittää järjestelmän fyysisten koodimoduulien väliset suhteet) tai pakettikaavio (kuvaa luokkien muodostamat ryhmät, itseasiassa luokkakaavio, jossa luokat voivat koostua luokista) ja luokkakaavio järjestelmän kaikista luokista. Tarvittaessa myös: Toteutuskaavio (esittää järjestelmän ohjelmisto- ja laitteistokomponenttien väliset suhteet). Varmista, että jokainen vaatimusmäärittelyn vaatimus toteutetaan. Varmista, että vähintään jokainen rajapintafunktio kuvataan suunnitelmassa tarkasti. Olihan tietokanta jo määritelty? Sekvenssikaavioita? 20

Kirjallisuutta Haikala ja Märijärvi, Ohjelmistotuotanto. Sivut 305 334. Koskimies ja Mikkonen: Ohjelmistoarkkitehtuurit. Talentum 2005. Pressman, Software Engineering. Sivut 207 385 ja 499-626 (WWW!) Ohjelmistotuotanto, TJOT Koskimies, Oliokirja. Sommerville, Software Engineering 7. Sivut 239 388. UML-ohjeet/kirjallisuus (löytyy paljon verkosta). http://www.cs.tut.fi/~ohar/ 21

Loppuraportti Loppuraportti kuvaa projektin johtamisen (hallinnon) ja projektin tekemän työn. Kertoo mitä kokemuksia projektista on saatu. Kuvaa projektin heikkoudet ja vahvuudet. Antaa näkökulmia muille, lukijoina usein (saman firman) projektipäälliköitä, yrityksen muut työntekijät, asiakkaan edustaja, yrityksen johto, kurssin luennoitsija... Antaa myös muille projekteille käsityksen siitä, mitä on tehty. Ryhmä tekee yhdessä. https://projectwiki.cs.uta.fi/wiki/final_report 22

Loppukertomus (1/2) Jokainen projekti kirjoittaa 4-10 sivun kertomuksen projektistaan ja liittää kuvaukseen mukaan tärkeimmät tilastot (mm. tuntitaulukko, lista tehdyistä dokumenteista ja koodirivien lukumäärästä). Kertomuksessa esitellään: Projektiorganisaatio, asiakas, projektin aihe. Kuinka projekti eteni, kokemuksia Kohdattuja ongelmia ja mukavia asioita. Projektin hallinta (kuinka käytönnössä toimittiin) Käytetyt työvälineet, työmenetelmät Valokuvia projektiryhmästä, näyttökuvia tuotteesta, muita omia juttuja. 23

Loppukertomus 2/2 Kaikkien projektien raportit julkaistaan laitossarjassa sähköisessä muodossa. Salaisissa projekteissa - keskustelkaa asioista toimeksiantajanne kanssa, mitä saatte julkaista. Kertomus toimitetaan luennoitsijalle helmikuun lopussa. Jokaisella ryhmällä pitää olla henkilö, jolta voin tarvittaessa kysyä ja tarkistaa asioita palautuksen jälkeen. Raportti jäädytetään maaliskuun lopussa ja tämän jälkeen se saa ISBN-numeron. https://projectwiki.cs.uta.fi/wiki/project_story. 24

Projekti CD ja viimeinen henkilökohtainen raportti Kun projekti on valmis, niin jokainen projekti tekee oman projekti CD:n. CD annetaan (ainakin) luennoitsijalle ja toimeksiantajalle. CD sisältää projektinne kaikki dokumentit ja ohjelmakoodit. Muistilista mitä levyltä pitäisi löytyä: https://projectwiki.cs.uta.fi/wiki/project_cd. CD:ssä pitää olla README.txt tiedosto, jossa lukee mitä CD sisältää ja mitä missäkin hakemistossa on. Mainitkaa myös tekijänoikeus / salattavuus asiat. Lopuksi voikin sitten palauttaa henkilökohtaisen raportin Moodleen. 25

Ryhmien palautekeskustelut Kun ryhmä on palauttanut projekti CD:nsä ja jokainen ryhmän jäsen on palauttanut viimeisen raporttinsa, voi ryhmä varata ajan (pakolliseen) palautekeskusteluun. Tilaisuudessa käydään läpi projektin kulkua ja loppuraportti luennoitsijan kanssa. Tarkoituksena on lopettaa projekti hallitusti. Tilaisuudessa voi esitellä ohjelmistotuotetta luennoitsijalle, mikäli esim. loppuesityksessä ei kaikki oleellinen ole tullut esille. Tilaisuuteen kuluu aikaa noin 30 minuuttia. Ryhmät varaavat ajan luennoitsijalta samoin kuin katselmoinneissa. Paikka esim. projektityöhuone. 26

Tietotekniikan liiton etiikan ohje Etiikka on filosofian osa-alue, joka tutkii oikeaa ja väärää, oikeudenmukaisuutta ja velvollisuutta ja muita näihin liittyviä käsitteitä. Ohjelmistoalalla on runsaasti eettisiä haasteita / ongelmia: tekijänoikeudet, luonnonsuojelu, tietosuoja, uuden teknologian tuomat mahdollisuudet,... Tärkeää on tunnistaa projektin asianosaiset (muut ryhmän jäsenet, yritys/oppilaitos, asiakas, yhteiskunta) ja pohtia erilaisten tekojen vaikutusta eri henkilöihin ja ryhmiin. Omien tekojen vaikutusten tiedostaminen. http://www.ttlry.fi/yhdistykset/osaamisyhteisot/ etiikan_tyoryhma/etiikan_ohjeet_v3/ 27