tehokas ohjelmistotestaus

Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Tehokas ohjelmistotestaus

Maaret Pyhäjärvi ja Erkki Pöyhönen

Julkaisuversio 1.12005-01-06

tekijä mainittava http://creativecommons.org/licenses/by/1.0/fi/


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ä [email protected] ja

[email protected]


1 - Tehokas ohjelmistotestaus

Tehokas ohjelmistotestaus

Testitapaukset ja testien suorittaminen

Virheraportointi ja virheasian ajaminen

Testaus ohjelmisto-kehityksen osana

Katselmoinnit testaustoimintana

Testaustekniikat

Testausvälineet ja testauksen automatisointi

Testauksen suunnittelu ja hallinta

Testausprosessin muuttaminen


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


1 – Tehokas ohjelmistotestaus

Käsiteltävät asiat

Testaus ja laatu

Riskiperus-teinen testaus

Testauksen monipuolisuu

s

Keskeiset haasteet


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.

Testaus on keino pureutua virheisiin ja auttaa luomaan

riittävä laatu.


Ohjelmistojen perusominaisuudet

Lä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ää.

Perusominaisuudet tekevät virheiden syntymisestä

ohjelmistotuotantoprosessissa tosiasian, jota ei hyvistä pyrkimyksistä

huolimatta kokonaan voida välttää.


Joitakin kuuluisia virheitä

• 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


Mitä ohjelmistovirheet maksavat?

• 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


VaatimuksetAnalyysi & suunnittelu

KoodausKehityksen

aikainen testausHyväksymis-

testaus

Parannatuotetta

Tuotanto40-100x

30-70x15-40x

10x3-6x

1x

50%

Virheen kustannus kertautuu

Lähde: Barry Boehm. 1981. Software Engineering Economics

Laatuvipu

Boehm, 2001: Kustannuskerroin 5:1 ja kustannuksia voidaan hallita hyvillä arkkitehtuurikäytännöillä


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

Virheiden löytäminen ei helppoa – tehokas löytäminen vielä vaikeampaa!

Virheiden löytäminen ei helppoa – tehokas löytäminen vielä vaikeampaa!

Virheetöntä ohjelmistoa ei ole –

kysymys on siitä ovatko virheet

haitaksi käytölle.


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


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.


Testaus ja laadunvarmistus

Testaus suppeasti

Testaus ”testaus-ammattilaiselle”

Laadunvarmistus


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


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ä


Kehitys- ja testausprosessit muodostavat

palautesilmukan

KehitysprosessiKehitysprosessi

TestausprosessiTestausprosessi

Testi-tulokset

Kehitys-tuotteet


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


Testausprojekti 2 Testausprojekti 2

Testauksen tavoite ei ole vain löytää virheitä

Osa A

100 kirjattua virhettä

Osa A


Osa C


Osa D


Osa B


Osa B


Osa C


Osa D



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ä


Laatukolmio / Projektikolmio

Resur

ssit

Aika

Sisältö

LaatuMäärä

Laatu

Määrä

•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


Testauksen monet odotukset

• 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”Testauksella ei ole yhtä roolia, vaan

oikeastaan nippu siihen kohdistettuja odotuksia

Testauksella ei ole yhtä roolia, vaan oikeastaan nippu siihen kohdistettuja

odotuksia


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


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.

Testausta tehdään projekteissa kaikkien osapuolien toimesta ja

työnjako on vaihteleva.


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




Testaus ja laatu



s

Keskeiset haasteet


Testaus on vaikeaa (1/2)Lähde: James Bach.

• 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


• ...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.


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


Ohjelmistotestauksen laajuus

loppukäyttäjänäkökulmastaPalvelut

Ympäristöt

Ohjelmisto

Järjestelmä:•Uusi koodi

•Vanha koodi•Sovelluskehys

Dokumentaatio:•Toteutuksen

aikainen•Asiakas-

dokumentaatio

Laitteisto & Verkko

Käyttöjärjestelmä

Muut ohjelmistot

AsennusTekninen

tukiPäivitykset


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.


Riittävä laatu

Nolla virhettä

Auttavasti toimiva

Riittävä laatu / Tilanneohjattu

laatu


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


Vaatimus, hyöty, kustannus ja riski

VaatimusVaatimus

HyötyKustan

-nusMitä

Miten

Riski

Rajoite


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


Riskianalyysi testausnäkökulmasta

Riskianalyysi

Järjestelmäriskit(Liiketoiminta & tekninen)

Riski-analyysin tyyppi

Keskeiset aktiviteetit

Tulokset

Projektiriskit

Aikatauluvaikutusten tunnistaminen

Vastatoimet

Tunnista virheen todennäköisyys

Tunnista virheen vaikutus

Testauksen prioriteetit


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


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

Täsmällisessä kielenkäytössä: häiriö on tapahtuma; vika on

ohjelmiston tila, jonka aiheuttaa ihmisen tekemä virhe


Virhe – Vika - Häiriö

Ihminen tekee virheen…

…joka aiheuttaa vian ohjelmistoon…

…joka voi aiheuttaa häiriön ohjelmiston toiminnassa


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ö


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 %


Priorisointisääntö

Priorisoi testejä siten että koskatahansa lopettaessasi testauksen,

olet tehnyt parasta mahdollistatestausta saatavilla olevan

ajan ja resurssien puitteissa.

Priorisoi testejä siten että koskatahansa lopettaessasi testauksen,

olet tehnyt parasta mahdollistatestausta saatavilla olevan

ajan ja resurssien puitteissa.


Uudelleentestaus vs. uusinta-testaus

Testi löytää virheen

Korjattu ja uudelleentestattu

Uusia virheitä syntyy korjauksen vaatimien muutosten seurauksena.

Perustoiminnal-lisuuden uusintatesti

(Leveystesti)

Erikoistunut toiminnalli-suuden uusintatesti

(Syvyystesti)


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)


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.


Uusintatestaus projektissa

Uusien ominaisuuksi

en testaus

Uusintatestaus

Työmäärä

Aika




Testaus ja laatu


Testauksen monipuolis

uus

Keskeiset haasteet


Ohjelmistokehityksen kolminaisuus

Vaatimukset

Tekninen suunnittelu ja toteutus

Testaus


Testauksessa monta puolta

Testauksen hallinta –

Suunnittelu ja seuranta

Testaus-toiminta -Määrittely ja suoritus

Projekti-tiedustelu –

ennakoiva testaustoiminta


Testauksen keskeiset näkökulmat

Tekninen näkökulma”järjestelmä ei toimi, jos...”

Tekninen näkökulma”järjestelmä ei toimi, jos...”

Käyttäjän näkökulma

”ei voi ratkaista

ongelmaa / tehostaa

toimintaa, jos...”

Käyttäjän näkökulma

”ei voi ratkaista

ongelmaa / tehostaa

toimintaa, jos...”


Testaustasot

Yksikkö-

testaus

Integrointi-testaus

Järjestelmä-testaus

Hyväksymis-testaus


Useita testauksen tasoja

• Yksikkötestit keskittyvät virheisiin, jotka syntyvät koodia kirjoittaessa, kuten raja-arvovirheet käyttäjän syötettä kelpuutettaessa.

• Integraatiotestit keskittyvät alhaisen tason suunnitteluun, erityisesti virheiden tarkastukseen yksiköiden välisissä rajapinnoissa ja muissa integroinneissa.

• Järjestelmätestit tarkistavat toteuttaako järjestelmä kokonaisuutena korkean tason suunnitelman, mukaan lukien suorituskyvyn riittävyyden tuotanto-olosuhteissa sekä useiden järjestelmien integroinnin.

• Hyväksymistestit tehdään tavallisesti asiakkaiden / käyttäjien toimesta varmistamaan, että tuote täyttää liiketoimintavaatimukset.


Toteuttaja vs. Testaaja työmäärän kohdistuminen

Uusien ominaisuuk-sien testaus

Uusintatestaus

Uusien ominaisuuksi

en testaus

Uusintatestaus

Toteut-taja

Testaa-ja

Valmistelu

Julkaisu testaukseen / järjestelmätestauksen aloitus


Mikä on ”järjestelmä”

{JärjestelmäJärjestelmä

SovellusSovellus

Muut sovellukset (ohjelmistot)

Muut sovellukset (ohjelmistot)

Järjestelmäohjelmistot(käyttöjärjestelmä)

Järjestelmäohjelmistot(käyttöjärjestelmä)

LaitteistoLaitteisto

Halli

ttu

ym

päri

stö

Halli

ttu

ym

päri

stö

=


Testaus vs. Vian jäljitys

Vian jäljitysDynaaminen (lasilaatikko)

testausVian eristäminen

Testaus Ohjelmointi

Tavoite: Tunnistaa häiriöt ja virheet

Tavoite: Paikallistaa virheet, poistaa virheet


Toiminnallinen ja ei-toiminnallinen testaus

• Toiminnallinen testaus on ohjelmiston tarjoamien toimintojen testaamista yksittäisinä toimintoina, toimintoryhminä sekä yhdistettynä ohjelmiston aineiston kanssa.

• Ei-toiminnallinen testaus kohdistuu nk. ei-toiminnallisiin ominaisuuksiin, jotka vaikuttavat ohjelmistoon liittyvään kokonaislaatu-kokemukseen, mutta eivät ole liitettävissä suoraan toimintoon tai toimintoryhmään ohjelmistossa, kuten käytettävyys, suorituskyky ja luotettavuus.


Staattinen ja dynaaminen testaus

• Staattisessa testauksessa ei ajeta koodia– Tietokoneeseen perustumattoman testaamisen

prosessi– Katselmoinnit, tarkastukset, staattinen analyysi

• Dynaamisessa testauksessa ajetaan koodia– Testausta perinteisessä merkityksessä– Tietokoneeseen perustuvat testaustekniikat– Tämän suorituspohjaisen testauksen perinteet

ovat ajattelussa, että ohjelmat on kirjoitettu vain koneella ajamista varten eikä ihmisten luettavaksi (Myers 1979)


Mustalaatikko- vs. lasilaatikkotestaus

? y = 2xx = 2 y = 4 x = 2 y = 4

Tuntematon vs. tunnettu yhtälö

Mustalaatikko Lasilaatikko


Mustalaatikko- ja lasilaatikkotestaus

• Mustalaatikko (toiminnallinen, käyttäytymiseen pohjautuva, aineistovetoinen, syöte-tulos-vetoinen)– Testaus perustuu syötteisiin ja vastaaviin tuloksiin– Sisäistä käyttäytymistä ja rakennetta ei huomioida– Etsitään tilanteita, joissa ohjelma ei toimi määrittelynsä

mukaisesti Täysin kattava syötetestaus (sallitut ja ei-sallitut syötteet,

toimintosarjat)

• Lasilaatikko (rakenteeseen pohjautuva, logiikkavetoinen)– Testaus perustuu ohjelman logiikan tietämiseen– Ainutlaatuisia polkuja ohjelman läpi äärimmäisen paljon– Ohjelma voi olla vastaamatta määrittelyä, puuttuvia polkuja,

aineistoherkkyysvirheitä Täysin kattava polkutestaus


Positiivinen ja negatiivinen testaus

• Positiivinen testaus on testausta, joka kohdistuu käyttäjän normaalitoiminnan aikana tarvitsemien ominaisuuksien testaamiseen.

• Negatiivinen testaus on testausta, jossa testataan järjestelmän ominaisuuksia, jotka hoitavat virhe- ja poikkeuskäsittelyä.


Todennus ja kelpuutus

• Todennus– Järjestelmän tai komponentin arviointiprosessi

sen selvittämiseksi, täyttävätkö annetun kehitysvaiheen tuotokset vaiheen alussa asetetut ehdot (BS7925-1)

– ”Järjestelmän tekeminen oikein”

• Kelpuutus– Ohjelmistokehityksen tuotosten oikeellisuuden

arviointi asiakastarpeiden ja –vaatimusten suhteen (BS7925-1)

– ”Oikean järjestelmän tekeminen”

• Testauksessa voi olla molempia näkökulmia– Perinteisesti paino todennuksessa


Sisäinen ja ulkoinen muutos

• Sisäinen muutos – ohjelmistokehitystä– Uusia ominaisuuksia– Muutoksia– Korjauksia

• Ulkoinen muutos – ympäristö muuttuu– Uusi laitteisto– Uusi käyttöjärjestelmä

Testausta tarvitaan molempien suhteenTestausta tarvitaan molempien suhteen


Idea Projekti

Tuotanto

Testaus

Vaatimustenhallinta

Testaus elinkaariprosessina


Erilaisia osaamisia testauksessa

idea projekti

tuotanto

tekninen näkökulma

Käyttäjä-näkökulma

Toimin-nallinen

Ei-toiminnalline

n


Testauksen tehokkuus

• Ulkoinen tehokkuus (effectiveness)– Tehdään oikeaa asiaa ja valitaan oikeat asiat tilanteeseen

mahdollisimman hyvän lopputuloksen saavuttamiseksi. – Valitut keinot oikeat; soveltuvuus

• Sisäinen tehokkuus (efficiency)– Juoksunopeustehokkuus - "sama työ lyhyemmässä

ajassa". – Valittuja keinoja käytetään tehokkaasti; suorituskyky;

hyötysuhde

• Tehokkuutta tavoitellessa ensin pitää saavuttaa tulokset ja sitten vasta optimoida tulosten saavuttamiseen käytettävää aikaa – Ulkoinen tehokkuus ensisijaisen tärkeä

• Testattavuus on testauksen mahdollisuuksia tehdä testausta tehokkaasti


Ulkoinen vs. sisäinen tehokkuus

Korkea sisäinen, alhainen ulkoinen tehokkuuskulut ok, mutta

tulokset eivät

Molemmat alhaisia korkeat kustannukset,

vähäiset tulokset

Alhainen sisäinen, korkeaulkoinen tehokkuus

Virheitä löytyy, muttase maksaa liikaa

Molemmat korkeita Tavoite, johon pyrkiä

Ulkoinen tehokkuus

Sisäinen tehokkuu

s

Tekniikat

TyökalutProsessin paranta-minen


??? ???

Mutta voit olla täällä.

Testaus laadun arvioinnissa

Ohjelmiston laatu

Alhainen

Korkea

Alhainen

Testien

laatuKorkea

Paljon virheitä

Vähän virheitä

Luulet olevasi täällä...




Testaus ja laatu

Riskiperustei-nen testaus


s

Keskeiset haasteet


Testaus käytännössä

• Riskiperusteinen testaus tarkoittaa testauksen suuntaamista riskiin perustuen– Osia ja näkökulmia jätetään testaamatta

• Tilannetekijäohjattu testaus tarkoittaa testauksen toimintatapojen suuntaamista tilannetekijöihin perustuen– Kustannukset ja soveltuvuus ohjaavat jokaisen

toimintatavan valintaa– Riski on oleellinen osa toimintatavan

tarpeellisuuden ja toteutustavan arviointia


Testaushaasteiden jako

Testauksen hallinta –

Suunnittelu ja seuranta

Testaus-toiminta -Määrittely ja suoritus


Testauksen hallinnan haasteet (1/3)

• Raportointi: Testaus tekee tietoiset päätökset laadun suhteen mahdollisiksi. Kuinka testaus raportoi työstään niin että tieto otetaan vastaan ja käytetään?

• Viestintä: Testaukseen tarvitaan tietoa testattavista asioista, ja tämä tieto on luonteeltaan jatkuvasti muuttuvaa. Miten viestintä ja yhteistyö hoidetaan tarvittavan tiedon saamisen kannalta?

• Lähtötaso: Testausta tehdään useiden osapuolien toimesta eri tasoilla. Kuinka huolehditaan kunkin osapuolen tarvitsemasta lähtötasosta laadun suhteen?

• Työmääräarviointi: Testauksessa on paljon tehtäviä ja tarpeellista toistoa. Kuinka etukäteen tiedetään kuinka paljon aikaa ja resursseja tarvitaan työhön jota ollaan tekemässä?



• Testaustyypit: Monenlainen testaus voi olla tarpeen. Miten tietää mitä kaikkea testausta voidaan yleensäkään tarvita?

• Logistiikka: Testaus on osa ohjelmistokehitystoimintaa ja sen tulee rytmittyä tukemaan ohjelmistokehitystä. Kuinka testaajat käyttävät työmääränsä oikea-aikaisesti oikeassa paikassa hyödyn maksimoimiseksi?

• Lopettaminen: Kaikkea ei voi testata. Kuinka päättää koska testaus voidaan lopettaa eli koska testausta on tarpeeksi?

• Missio: Testausta käytetään moneen tarkoitukseen ja sille on monenlaisia odotuksia eri osapuolilta. Mitä vaatimuksia testaukselle kohdistuu?



• Opettaminen ja ohjaus: Testaus on haastavaa. Kuinka auttaa testaajia tulemaan hyviksi työssään ja miten tunnistaa hyvä testaaja?


Testaustoiminnan haasteet (1/3)

• Edustus: Testaajat toimivat edustajina jollekin näkökulmalle. Kuinka testaajat aidosti edustavat tätä näkökulmaa?

• Kattavuus: Testattavaa on paljon. Kuinka päätetään mitä testataan ja mitä ei?

• Riski: Testejä on kaikkiaan liikaa kullekin ajanhetkelle. Kuinka tiedetään mitkä testit ovat parhaita suoritettavaksi juuri nyt?

• Tukirakenteet: Testauksessa tarvitaan muutakin kuin testattava kohde. Mitä ympäristöjä ja välineitä tarvitaan?

• Hyönteismyrkky: Testattava kohde tulee immuuniksi samoille testeille ja virheiden löytäminen vaatii testien muuttamista. Kuinka testejä muutetaan tehokkaasti?



• Testattavuus: Järjestelmän ja vaatimusten rakenteet vaikuttavat kykyyn tehdä testausta. Kuinka järjestelmä voidaan rakentaa siten että testaaminen on mahdollista ja tehokasta?

• Oppiminen: Testattavat järjestelmät ovat monimutkaisia. Kuinka opimme järjestelmän toiminnan?

• Suoritus: Testien suorittamiseen on useita vaihtoehtoisia tapoja. Mikä on tehokkain tapa suorittaa tarvittavat testit?

• Virheraportointi: Testaus löytää virheitä. Kun löydämme virheen, kuinka toistamme sen ja raportoimme sen tehokkaasti?



• Arviointi: Kaikki virheet eivät ole itsestään selviä. Kun virhetilanne tulee kohdalle, kuinka testaaja tunnistaa sen?

• Dokumentaatio: Testauksesta pitää jäädä jälki vähintään löydettyjen ja käsiteltyjen virheiden osalta. Mitä dokumentaatiota tarvitaan ja mihin tarkoituksiin?


Ihmisluonnon rajoitteet testauksessa

• Kyky edustaa haluttua näkökulmaa on rajoittunut– Muistin rajoitteet– Vinoumat

• Aikomukset ovat tärkeitä– Ihmisluontoon kuuluu vääristää tulokset ja tulkinnat

odotusten ja toivomusten mukaan– Samasta syystä odotetut tulokset testauksessa

korostuvat

• Opettelemalla ymmärtämään omia vinoumiaan oppii paremmaksi testaajaksi

• Opettelemalla ymmärtämään muiden vinoumia saa viestinsä paremmin läpi


Esimerkkejä vinoumistaLähde: Kaner, Bach, Pettichord. 2002. Lessons Learned in Software Testing.

• Tulkinta – tulevien testitulosten tulkinta siten että ne vahvistavat nykykäsitystä järjestelmästä

• Vahvistus – vahvistavat tulokset saavat suuremman painoarvon

• Saatavuus – helposti muistettava käyttäjän toiminnallisuus tuntuu todennäköisemmältä

• Etusija – ensimmäiset havainnot tuntuvat tärkeämmiltä

• Lähiaika – Viimeisin havainto tuntuu tärkeämmältä• Läheisyys – Tuttujen käyttäjien mielipiteillä on

enemmän painoarvoa• Edustavuus – Oletetaan pienten ongelmien syiden

olevan pieniä ja suurien suuria• Kehysvaikutus – Reaktio virheraporttiin riippuu sen

muotoilusta, riippumatta sen sisällöstä ja merkityksestä


Vinoumat vaikuttavat toimintaan (1/2)

• Esimerkki: Palkitseminen– 10 000 € palkkio, joko huomenna tai vuoden

päästä– Ei ole olemassa vaihtoehtoa, ettei sitä tulisi– Haluaisimme silti saada palkkion

mahdollisimman pian

• Esimerkki: Laskun maksaminen– 10 000 € lasku, joka pitää maksaa joko

huomenna tai vuoden päästä– Jos odotamme, emme voi mitenkään välttää

sen maksamista– Haluaisimme välttää laskun maksamista niin

pitkään kuin mahdollista


Vinoumat vaikuttavat toimintaan (2/2)

• Esimerkki: Yksikkötestauksen käytäntöjen parantaminen– Poistaa enemmän virheitä aiemmin

projektissa ja tuloksena on lopulta paljon pienemmät työmäärät myöhemmässä virheiden jäljittämisessä, korjauksessa ja testauksessa

– Olemme kohtuullisen varmoja siitä, että jokainen yksikkötestaukseen tällä viikolla laitettu lisätunti tulee tuottamaan 8-12 tunnin työmäärän säästön tulevaisuudessa

– Tuotto tapahtuu vasta kuukausia myöhemmin, projektin loppuvaiheilla


”Alusta”

Prosessi

Haasteisiin vastaaminen

Missio

Strategia Käytännöt

OsaaminenTestaus-

välineet ja -ympäristö

Mittarit

Tavoitteet

Odotukset

Konteksti,mahdollisuudet

Testaus-tasot Testaus-

tyypit

Laatu-kriteerit

Riskit

Viestintä&yhteistyö

Testauksenydin

Mahdol-listajat

Tavoitteet

Välineet

Koulutus-tarve

Testaus-tekniikat

Kustannus/hyöty

Testauksen rytmitys


Yhteenveto

• Testaus on haastavaa toimintaa, jossa useat näkökulmat ovat tarpeen

• Testausta tekevät niin erilliset testaajat kuin kaikki muut ohjelmistokehityksessä mukana olevat

• Testaus tuottaa tietoa kehityksen muuttuvasta tilanteesta riskiperusteisesti


Linkkejä ja vinkkejä

• Esimerkkejä ohjelmistovirheistä löytyy uutisryhmästä – comp.risks

• Esimerkkejä Microsoftin ohjelmistoissa olevista virheistä löytyy kirjoista– James Whittaker. 2002. How to Break Software.– James Whittaker. 2003. How to Break Software

Security.


Hyviä testaustiedon lähteitä verkossa

• Stickyminds – Forum for testing– http://www.stickyminds.com/

• ”Better Software”-lehti, ilmestyi ennen nimellä ”Software Testing and Quality Engineering”

– http://www.bettersoftware.com/• Cem Kaner’s website

– http://www.kaner.com/• James Bach’s website

– http://www.satisfice.com/• Rex Black’s website

– http://www.rexblackconsulting.com/

• Karl Wiegers website– http://www.processimpact.com/

• Tulevaisuudessa suomenkielistä materiaalia

– http://www.testauskirja.com• Testauksen sertifiointia

– http://www.bcs.org.uk/iseb/– http://www.istqb.org/

• Software Testing Hotlist– http://www.io.com/~wazmo/qa/#

test_tools • Brian Marick’s Website

– http://www.testing.com/• Bret Pettichord’s Website

– http://www.pettichord.com/• TestingEducation Promotion site

– http://www.testingeducation.org/• Suomalainen

testausosaamisyhteisö– http://www.pcuf.fi

/sytyke/kerhot/testaus/ • Suomalainen testaajien

keskusteluryhmä– http://groups.yahoo.com/groups/fi

-testaus/• SoftaTest Moodle

– http://softatest.moodle.fi/

tehokas ohjelmistotestaus

Documents