Tehokas ohjelmistotestaus

1. Tehokas ohjelmistotestaus Maaret Pyhäjärvi ja Erkki Pöyhönen Julkaisuversio 1.1 2005-01-06 tekijä mainittavahttp://creativecommons.org/licenses/by/1.0/fi/

2. Tiedoksi lukijalle • Tämä materiaali on edelleen työn alla • Varsinainen julkaisu tapahtuu testauskirjan julkaisun yhteydessä tai jälkeen • Materiaalin hyödyntäminen on vapaata • Erityisesti haluamme tukea yleishyödyllisen ohjelmistotestauksen opetuksen jäsentymistä tarjoamalla materiaalimme vapaasti muokattavaksi pohjamateriaaliksi • Uskomme että kirjallinen materiaali on noin 20 % vastaavasta koulutuksesta puhuttuna • Lisää materiaalia löytyy pään sisältä • Kysyttävää? • Ota yhteyttä maaret.pyhajarvi@iki.fi ja erkki.poyhonen@nokia.com

3. 1 - Tehokas ohjelmistotestaus Tehokas ohjelmistotestaus Testaustekniikat Testaus ohjelmisto-kehityksen osana Testauksen suunnittelu ja hallinta Virheraportointi ja virheasian ajaminen Testausvälineet ja testauksen automatisointi Katselmoinnit testaustoimintana Testausprosessin muuttaminen Testitapaukset ja testien suorittaminen

4. Oppimistavoitteet • Ymmärrät mitä ohjelmistotestaus on, kenelle se kuuluu ja miksi sitä tehdään • Tiedät miksi kaikkea ei voi testata ja miksi testaus on haastavaa • Omaat käsityksen ohjelmistolaadun ja testauksen suhteesta ja laadun arvioinnin haasteista • Ymmärrät että tehokkaan testauksen tulee perustua riskiin • Käsität miksi tehokkuutta tavoitellessa ensin pitää saavuttaa tulokset ja sitten vasta optimoida tulosten saavuttamiseen käytettävää aikaa

5. Käsiteltävät asiat Testaus ja laatu Riskiperus-teinen testaus Testauksen monipuolisuus Keskeiset haasteet 1 – Tehokas ohjelmistotestaus

6. Käsiteltävät asiat Testaus ja laatu Riskiperus-teinen testaus Testauksen monipuolisuus Keskeiset haasteet 1 – Tehokas ohjelmistotestaus

7. Ohjelmistot yhä kriittisempiä perustoiminnallemme • Ohjelmistoja kaikkialla – sekä itsenäisinä että osana järjestelmiä • Ohjelmistot ja järjestelmät yhä monimutkaisempia • Järjestelmät integroituvat • Fakta: ohjelmistoissa on virheitä Testaus on keino pureutua virheisiin ja auttaa luomaan riittävä laatu.

8. Ohjelmistojen perusominaisuudetLähde: Frederick Brooks. 1987. No Silver Bullets. In Mythical Man-Month • Ohjelmistojen perusominaisuudet tekevät ohjelmistokehityksestä haastavaa • Monimutkaisuus • Mukautumiskyky • Muuttumiskyky • Näkymättömyys Perusominaisuudet tekevät virheiden syntymisestä ohjelmistotuotantoprosessissa tosiasian, jota ei hyvistä pyrkimyksistä huolimatta kokonaan voida välttää.

9. Ariane 5 avaruussukkulan räjähdys Liian suuren numeron lukutyypin muuntaminen, 1996 Pentium prosessori, jakolaskualgoritmi Virhe taulukon sisällön kopioinnissa, testaamatta piisiruun, 1994 Patriot- ohjus Pyöristysvirhe, 1991 Therac-25, Röntgenlaite Säteilyn yliannostuksia potilaille hoidon aikana, 1985-1987 Mars-luotain menetettiin Paunojen (lbs) ja kilogrammojen sekoittuminen, 1999 NASA Mariner 1 , Venus- luotain Piste pilkun tilalla FORTRAN DO-silmukassa, 1962 Urbaani legenda mutta ohjelmistovirhe kuitenkin Denverin lentokenttä Tietokoneistettu matkalaukkujen käsittely epäonnistuu, 1995 NASA Spirit Rover Marsissa Muistin jumiutuminen 18 päivän jälkeen, testattiin maassa vain 9 päivää, 2004 Joitakin kuuluisia virheitä

10. Suuria summia Ariane 5 (kehitys 7 mrd $ + kuorma 500 M$) Intel Pentium jakolaskuvirhe (400 M$) Denverin lentokenttä (250-500M$ + 1 M$ / viiv. päivä) Kuolema tai vammautuminen Therac-25 (3 kuollutta, 3 vakavasti vammautunutta) Patriot-ohjus (28 kuollutta, 100 loukkaantunutta) Hyvin vähän tai ei mitään Pienet epämukavuudet Ei näkyvää tai fyysistä vaikutusta Ohjelmisto ei ole “lineaarinen” Pienellä syötteellä voi olla hyvin suuri vaikutus Boehm & Basili. 2001. Defect Reduction top-10 list: 80 % vältettävissä olevasta korjaustyöstä aiheutaa 20 % virheitä 80 % virheistä tulee 20 % moduuleista, ja noin puolet moduuleista ovat virheettömiä Nykyiset ohjelmistoprojektit käyttävät 40 - 50 % työmäärästä vältettävissä olevaan korjaustyöhön Mitä ohjelmistovirheet maksavat?

11. Vaatimukset Analyysi & suunnittelu Koodaus Kehityksen aikainen testaus Hyväksymis-testaus 50% Tuotanto 40-100x 30-70x 15-40x Parannatuotetta 10x 3-6x 1x Virheen kustannus kertautuuLähde: Barry Boehm. 1981. Software Engineering Economics Laatuvipu Boehm, 2001: Kustannuskerroin 5:1 ja kustannuksia voidaan hallita hyvillä arkkitehtuurikäytännöillä

12. Muutamia esimerkkejä virheistäLähde: James Whittaker • Excel Scenarios • Word Tab Stops • Word Find-Replace • Word Footnotes • Powerpoint WordArt • Powerpoint Tables • Varoitus: kaataa käyttöjärjestelmän, ei vain sovellusta • Calculator Math library Virheetöntä ohjelmistoa ei ole – kysymys on siitä ovatko virheet haitaksi käytölle. Virheiden löytäminen ei helppoa – tehokas löytäminen vielä vaikeampaa!

13. Laatu ja testaus • Laatu on arvoa jollekin osapuolelle • Virhe on mitä tahansa joka muodostaa uhan arvolle. • Testauksessa kyseenalaistetaan järjestelmän laatu arviointitarkoituksessa • ”ei uskota ennen kuin kokeillaan” • Illuusioiden kumoaminen on kaikkien osapuolien etu • Testaus tekee tietoiset päätökset laadun suhteen mahdollisiksi • Testauksessa kerätään todisteita ja tehdään sen perusteella päätelmiä: ohjelmiston arviointi kerätyn todistusaineiston perusteella

14. Ohjelmiston laatu Standard Glossary of Software Engineering Terminology [IEEE610.12]: Laatu: (1) Taso, jolla järjestelmä, komponentti tai prosessi täyttää sille määritellyt vaatimukset. (2) Taso, jolla järjestelmä, komponentti tai prosessi täyttää asiakkaan tai käyttäjän tarpeet tai odotukset.

15. Testaus ja laadunvarmistus Testaus suppeasti Testaus ”testaus-ammattilaiselle” Laadunvarmistus

16. Ohjelmistotestauksen kenttä • Ohjelmistotestauksella tarkoitetaan ohjelmistojärjestelmien testausta • Järjestelmässä mukana ohjelmisto • Ohjelmiston/laitteiston suhde vaihteleva • Ohjelmistotestauksen kannalta järjestelmän muut tarvittavat osat (laitteisto, muut ohjelmistot) ovat osa ympäristöä • Ympäristön testaaminen voi olla keskeinen osa ohjelmistotestausta • Ohjelmistotestausta tarvitaan usealla tasolla • Pienet palat ennen suurempia kokonaisuuksia • Kullakin osapuolella omat vastuunsa

17. Mitä testaus on? • Testaus on kohteen teknistä tarkastelua, jossa empiirisesti etsitään laatuun liittyvää tietoa, jolla on arvoa projektin sidosryhmille. – Cem Kaner • Sisältää: • sen varmistamisen että testauksen kohde toimii kuten odotettu • erojen löytämisen ja ratkaisemisen odotettujen ja todellisten tulosten välillä • puolueettoman tiedon tarjoamisen päätöksentekoon järjestelmän tilasta laadun suhteen • laadun parantamisen tukemisen • Oleellista onnistuneelle testaukselle kuitenkin yleisesti halu nähdä virheitä

18. Kehitys- ja testausprosessit muodostavat palautesilmukan Kehitysprosessi Kehitys-tuotteet Testi-tulokset Testausprosessi

19. Miten testaus tuottaa lisäarvoa • Löytämällä virheitä, jotka korjataan • Järjestelmän laatu paranee • Jopa kyetään estämään joitain virheitä syntymästä • Löytämällä virheitä, joita ei korjata • Vältetään yllätyksiä • Testataan tuotteen riskit pois yksi kerrallaan • Tuotetaan projektille ajoissa hyödyllistä ja tarkkaa tietoa

20. Testauksen tavoite ei ole vain löytää virheitä Testausprojekti 2 Testausprojekti 2 Osa A 100 kirjattua virhettä Osa B 0 kirjattua virhettä Osa A 31 kirjattua virhettä Osa B 10 kirjattua virhettä Osa C 0 kirjattua virhettä Osa D 0 kirjattua virhettä Osa C 12 kirjattua virhettä Osa D 24 kirjattua virhettä

21. Testauksen arvokkain tulos • Testauksen tärkein tulos on faktat hankkeen / järjestelmän todellisesta tilasta • Riskien ja tavoitteiden konkretisointi • Hankkeen riskit • Hankkeen tavoitteiden saavuttamisen todennäköisyys • Tieto ei aina ole helposti arvotettavissa • Faktat ovat kriittisiä johdolle • Monesti faktat saadaan viestittyä vasta kun mitään ei enää ole tehtävissä

22. Määrä Laatu Sisältö Resurssit Aika Laatu Määrä Laatukolmio / Projektikolmio • Tärkeät päätökset laatukolmion nurkkien prioriteeteistä tehdään hankkeen alussa • Päätöksiä ohjaa liiketoiminnan luonne ja organisaation kyvyt ja hankkeen reunaehdot • Kaikki muutokset hankkeen kuluessa ovat kalliita • Kaikki vaikuttavat kaikkeen – muutat yhtä ja sitten säädät muita nurkkia

23. Yritysjohdon näkökulma – ”Hyvin testattu tuote antaa paremman katteen” Asiakkaan näkökulma – ”Laadukas sovellus järkeistää työtä ja parantaa palvelua” Markkinoinnin näkökulma – ”Laatusertifikaatti parantaa myyntiä” Toteuttajan näkökulma – ”Koodistani ei löydy virheitä” Testaajan näkökulma – ”Tarkoitukseni on löytää virheitä” Projektipäällikön näkökulma – ”Testaus on 35 % työstä” Loppukäyttäjän näkökulma – ”Työni helpottuu” Testauksen monet odotukset Testauksella ei ole yhtä roolia, vaan oikeastaan nippu siihen kohdistettuja odotuksia

24. Toteuttaja testaajana • Suhteellisen halpa virheidenkorjaus • Toteuttaja löytää virheitä joita testaajan on vaikea löytää • Toteuttaja saattaa nähdä suoraan missä virhe on, sen sijaan että virhettä tarvitsisi koittaa toistaa • Toteuttaja ei tarvitse selittää virhettä toiselle • Toteuttaja ei tarvitse käyttää aikaa selvittääkseen kuinka ohjelman on tarkoitus toimia ja paperityön välttäminen on mahdollista

25. Erillinen, riippumaton testaaja • Ohjelmistokehitys tiimityötä • Erilaisten osaamisten summa • Löytää tyypillisesti erilaisia virheitä, seuraa eri näkökulmia • Sokeus omille virheille • Riippumattomuus ei korvaa ohjelmiston tuntemusta Testausta tehdään projekteissa kaikkien osapuolien toimesta ja työnjako on vaihteleva.

26. Käyttäjä vs. Testaaja • Käyttäjän virheiden löytäminen testaajaa tehottomampaa • Kuka tahansa voi vahingossa osua virheisiin, tavoitteellisuus ja tehokkuus luonnehtivat testaajaa • Tehokas testaus • Sisäisesti tehokas: virheitä löytyy nopeammin kuin tavallisessa käytössä • Ulkoisesti tehokas: Löydetyt virheet ovat merkittäviä kokonaisuuden kannalta • Erilaiset keinot eri vaiheissa omaavat eri tehokkuuden

27. Käsiteltävät asiat Testaus ja laatu Riskiperus-teinen testaus Testauksen monipuolisuus Keskeiset haasteet 1 – Tehokas ohjelmistotestaus

28. Sinun on ennakoitava käyttäjän... Aineisto Taidot Toiminta Odotukset Ympäristö …tutkiaksesi tuotetta, joka on… Näkymätön Epävakaa Herkkä Monimutkainen Tuntematon Testaus on vaikeaa (1/2)Lähde: James Bach.

29. ...käyttämällä prosessia, joka on usein... Loputon Epäselvä Negatiivinen Ikävystyttävä Työläs …löytääksesi ongelmia, jotka ovat Odottamattomia Testaus on vaikeaa (2/2)Lähde: James Bach.

30. Vaihtoehtoja on loputtomasti • Toiminnallisuudet vs. syötteet vs. tilat • Erilaiset ympäristöt • Sisäiset vs. ulkoiset tekijät • Ominaisuudet vs. odotukset • Testauksen aikaiset versiot vs. toimitusversiot

31. Palvelut Asennus Tekninen tuki Päivitykset Ohjelmisto • Järjestelmä: • Uusi koodi • Vanha koodi • Sovelluskehys • Dokumentaatio: • Toteutuksen aikainen • Asiakas-dokumentaatio Ympäristöt Muut ohjelmistot Käyttöjärjestelmä Laitteisto & Verkko Ohjelmistotestauksen laajuus loppukäyttäjänäkökulmasta

32. Täysin kattava testaus on mahdotonta • Testataksesi kaiken, sinun täytyisi: • Testata jokaisen muuttujan jokainen mahdollinen syöte. • Testata jokainen mahdollinen yhdistelmä syötteitä ja muuttujia. • Testata jokainen mahdollinen toimintoketju ohjelman läpi. • Testata jokainen laitteisto/ ohjelmistokonfiguraatio, mukaanlukien palvelinkonfiguraatiot jotka eivät ole hallinnassasi. • Testata jokainen tapa, jolla käyttäjä saattaisi yrittää käyttää sovellusta.

33. Riittävä laatu Nolla virhettä Auttavasti toimiva Riittävä laatu / Tilanneohjattu laatu

34. Riski • Menetyksen tai vaurion mahdollisuus • Joku tai jokin, joka luo mahdollisen vaaran • Riskiin liittyy: • Menetys: ei-toivottu vaikutus • Todennäköisyys: toteutuminen on epävarmaa • Tavoitteet: mihin menetys kohdistuu • Sidosryhmät: menetyksestä kiinnostunut osapuoli

35. Mitä Riski Miten Vaatimus, hyöty, kustannus ja riski Vaatimus Hyöty Kustan-nus Rajoite

36. Kuinka riski ymmärretään testauksessa • Elintärkeää tietoa testaukselle – järjestelmäriskit • Liiketoimintariski • Tekninen riski • Vaikutus myös testauksen menestykseen ja saattaa muuttaa järjestelmäriskejä • Projektiriski • Projektiriskit ovat helpompia keksiä ja käsittää, mutta eivät ole testauksen sisällön keskeisin ohjausmekanismi

37. Riskianalyysi testausnäkökulmasta Riskianalyysi Riski-analyysin tyyppi Järjestelmäriskit (Liiketoiminta & tekninen) Projektiriskit Tunnista virheen todennäköisyys Tunnista virheen vaikutus Aikatauluvaikutusten tunnistaminen Keskeiset aktiviteetit Testauksen prioriteetit Vastatoimet Tulokset

38. Miksi riski on oleellinen testauksessa? • Johto ajattelee riskien ja hyötyjen kautta • Riskejä voidaan käyttää perustelemaan lisärahoitusta asiakkaalta • Riskin ottaminen tarkoittaa tyypillisesti parempaa sijoituksen tuottoa • Sama laadun kanssa, sillä riskien vaikutusten lieventäminen aiheuttaa kustannuksia • Täysin kattava testaus on mahdotonta tai ainakin epäkäytännöllistä • Kaiken testauksen pitäisi perustua riskiin

39. Mikä on ”virhe”? • Virhe: Ihmisen toiminta joka tuottaa väärän tuloksen • Vika: Virheen ilmentymä ohjelmistossa • Tunnetaan myös bugina, ongelmana ... • Vika voi ajonaikana aiheuttaa häiriön • Häiriö: Ohjelmiston poikkeama odotetusta toimituksesta tai palvelusta Täsmällisessä kielenkäytössä: häiriö on tapahtuma; vika on ohjelmiston tila, jonka aiheuttaa ihmisen tekemä virhe

40. Virhe – Vika - Häiriö Ihminen tekee virheen… …joka aiheuttaa vian ohjelmistoon… …joka voi aiheuttaa häiriön ohjelmiston toiminnassa

41. Havainnot ja virheet • Havainnot ovat testauksen keskeisin tuotos • Neutraalimpi kuin ”virhe” • Virhe voi normaalissa kielenkäytössä tarkoittaa niin virhettä, vikaa kuin häiriötä • Vrt. Virheettömyys tavoitteena on itse asiassa häiriöttömyys • Erotetaan tekstissä selitteellä kun tarpeen korostaa eroa • Ihmiset tekemä virhe =virhe • Virhe ohjelmistossa = vika • Käytönaikainen virhe = häiriö

42. Virheettömyys vs. luotettavuus • Usein peräänkuulutetaan ”virheettömyyttä” ja tarkoitetaan käytön aikaista häiriöttömyyttä • Luotettavuus: todennäköisyys, että järjestelmässä ei ole häiriöitä tietyn ajan kuluessa tiettyjen olosuhteiden vallitessa • Mikään järjestelmä ei ole virheetön • Järjestelmä, jossa on virheitä voi olla luotettava • Vaikka virheitä olisi vähän kussakin osassa, järjestelmä ei välttämättä ole luotettava • Järjestelmän toiminta on eri kuin sen osien toiminta erikseen • Jos kukin osa on 90 % luotettava ja järjestelmä koostuu viidestä osasta, kokonaisjärjestelmän luotettavuus on 0,9^5=0,6 ~> 60 %

43. Priorisointisääntö Priorisoi testejä siten että koska tahansa lopettaessasi testauksen, olet tehnyt parasta mahdollista testausta saatavilla olevan ajan ja resurssien puitteissa.

44. Uusia virheitä syntyy korjauksen vaatimien muutosten seurauksena. Erikoistunut toiminnalli-suuden uusintatesti (Syvyystesti) Perustoiminnal-lisuuden uusintatesti (Leveystesti) Korjattu ja uudelleentestattu Testi löytää virheen Uudelleentestaus vs. uusinta-testaus

45. Uusintatestauksen ja testien toistettavuuden tarve • Kaiken testauksen pitäisi perustua riskille • Riskinhallinnan kysymys kuuluu: ”Onko olemassa riski, että ohjelmisto taantuu”? • Jos taantumisen katsotaan olevan vakava laaturiski, niin testien toistettavuus ja testauksen säännöllinen toistaminen on tärkeää • Todennäköisyys, että ohjelmistoinsinööri tahattomasti luo virheen muutosta tehdessään on 20 % ja 50 % välillä (Watts Humphrey, SEI)

46. Toteutuksen ja testauksen työt • Toteuttamisen ja testaamisen työmäärät eivät ole symmetrisiä • pieni muutos toteutuksessa voi aiheuttaa suuren työmäärän testaukseen • Testauksen työmäärä kasvaa projektin edetessä • Testauksen tulokset eivät pysy voimassa ajan kuluessa – ohjelmiston muuttuessa aiempien testien tulokset eivät välttämättä pidä paikkaansa.

47. Uusintatestaus projektissa Työmäärä Uusintatestaus Uusien ominaisuuksien testaus Aika

48. Käsiteltävät asiat Testaus ja laatu Riskiperus-teinen testaus Testauksen monipuolisuus Keskeiset haasteet 1 – Tehokas ohjelmistotestaus

49. Ohjelmistokehityksen kolminaisuus Vaatimukset Tekninen suunnittelu ja toteutus Testaus

50. Testauksessa monta puolta Testauksen hallinta – Suunnittelu ja seuranta Testaus-toiminta - Määrittely ja suoritus Projekti-tiedustelu – ennakoiva testaustoiminta