ohjelmistojen testaus - jyväskylän...

Ohjelmistojen testausMaaret Pyhäjärvi <[email protected]>

Tekijä mainittava, Maaret Pyhäjärvi & Erkki Pöyhönen

http://creativecommons.org/licenses/by/2.5/

Friday, 27 October 2006 Page 2

Kurssin tavoitteet

Tavoitteet:

• Ymmärrät mitä kuuluu ohjelmistotestaukseen ja sen haasteisiin

• Tiedostat että testaus voidaan jakaa monella tapaa eri osapuolille

• Tunnet testauksen perusmallit ja käsitteet

• Osaat lähteä suunnittelemaan ja suorittamaan testausta

• Olet tietoinen testausperiaatteiden, prosessien, käytäntöjen ja saatavillaolevien työkalujen kirjosta ja tiedät, mistä hakea lisää tietoa.


Tekninen testausTekninen testaus

Käsiteltävät asiat

Tehokas ohjelmistotestausTehokas ohjelmistotestaus

Testaus ohjelmistokehityksen osana


Virheiden raportointi ja käsittelyVirheiden raportointi ja käsittely

Loppukäyttäjänäkökulman testausLoppukäyttäjänäkökulman testaus

Testaustekniikoiden perusteetTestaustekniikoiden perusteet

Testauksen suunnitteluTestauksen suunnittelu

Mitä testaus on ja miksi se on tärkeää

Tekninen ja loppukäyttäjänäkökulma

Testattavuuden merkitys

V-malli ja peruskäsitteet

V-mallin soveltaminen todellisissa projekteissa

Testauksen jakaminen eri roolien kesken

Virheet, viat, häiriöt ja laatu

Vian tunnistaminen testatessa

Mitä ja miksi raportoidaan

Vikaraporttien käsittely

Järjestelmätestauksen tavoitteet ja rajaukset

Hyväksymistestauksen tavoitteet ja rajaukset

Loppukäyttäjänäkökulman testitapausten suunnittelu ja dokumentointi

Automaation rooli

Arvoaluetestaus: ekvivalenssiluokitus ja raja-arvoanalyysi

Kattavuustekniikat: koodikattavuus ja vaatimuskattavuus

Vaatimus- ja riskiperusteinen testaus

Tutkiva testaus

Testaussuunnitelman laatiminen

Testaussuunnitelman ja testitapausten suhde

Testauksen raportointi

Yksikkö- ja integrointitestauksen tavoitteet ja rajaukset

Yksikkö- ja integrointitestitapausten suunnittelu ja dokumentointi

Ylläpitotestauksen rooli ja rajaus

Automaation rooli
























Automaation rooli




Tutkiva testaus







Automaation rooli


Ohjelmistokehityksen kolminaisuus

Vaatimukset

Tekninen suunnittelu ja toteutus

Testaus


Mitä testaus on?

Testaus on kohteen teknistä tarkastelua, jossa empii risesti etsitään laatuun liittyvää tietoa, jolla on arvoa projektin s idosryhmille . – Cem Kaner

Testaus on ohjelman suorittamista tarkoituksena löytää virheitä – GlenfordMyers

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ä


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ä


Mitä testaus ei ole

Testaus ei ole

• vaihe ohjelmistokehityksessä

• toimintaa, jota vain erikseen nimetyt testaajat tekevät

• sarja helppoja ja suoraviivaisia toimintoja

• samojen asioiden toistamista kerta toisensa jälkeen

• samanlaista erilaisissa tilanteissa ja asiayhteyksissä

• vain toiminnallisuuksien läpikäymistä, vaan myös ei-toiminnallisten ominaisuuksien arviointi

• vastuussa laadusta, vain laatutiedon tuottamisesta

• laatutakuu ohjelmistolle


Kehitys- ja testausprosessit muodostavat palautesilmukan

KehitysprosessiKehitysprosessi

TestausprosessiTestausprosessi

Testi-tulokset

Kehitys-tuotteet


Testaus on...

osa ohjelmistokehitystä (tai puolet ohjelmistokehityksestä)

osa tuotteen tai palvelun elinkaarta ideasta toteutuksen kautta käyttöön

osa jokaista ohjelmamuutosta ja ympäristömuutosta

osa tuotannon valvontaa

osa valmisohjelmistojen hankintaa

Osa ongelmaan tarjotun ratkaisun kokeilemista

Osa loppukäyttäjäkokemusta ja -palautetta


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ä”

Ohjelmoijan 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

odotuksiaFriday, 27 October 2006 Page 12

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



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ä ja niitä ei voida täysin välttää

Testaus on keino pureutua virheisiin ja auttaa luomaan riittävä laatu.

Testaus on keino pureutua virheisiin ja auttaa luomaan riittävä laatu.


Ohjelmistojen perusominaisuudetLähde: Frederick Brooks. 1987. No Silver Bullets. In My thical Man-Month

Monimutkaisuus

Mukautumiskyky

Muuttumiskyky

Näkymättömyys

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 ovatvirheettömiä

• Nykyiset ohjelmistoprojektit käyttävät40 - 50 % työmäärästä vältettävissäolevaan korjaustyöhön


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.


Laatuodotukset vs. Laatukokemukset

Odotus• Käyttäjien ja asiakkaiden uskomukset järjestelmän tarjoaman laadun

tasosta• Kohtuuttomat odotukset ovat tyypillisesti oire vaatimusten keräämisen,

liiketoiminta-analyysin tai muutostenhallinta-aktiviteettien epäonnistumisesta

• Testaus ei voi suoraan vaikuttaa kohtuuttomiin vaatimuksiin testausprosessissa

Kokemus• Mielipiteet yhdistettynä käyttäjien ja asiakkaiden järjestelmän kanssa

saadun kokemuksen myötä syntyneisiin yleisiin tyytyväisyyden ja tyytymättömyyden tasoihin

Odotusten ja kokemusten yhdistäminen � tyytyväinen asiakas


ISO 9126-1 laatuominaisuudet

ISO/IEC9126

Toiminnallisuus

LuotettavuusSiirrettävyys

Ylläpidettävyys

Suorituskyky

Käytettävyys

Kuinka helppoaohjelmistonkäyttö on?

Kuinka tehokasohjelmisto on?

Kuinka helppoaohjelmiston

muuttaminen jaylläpitäminen on ?

Kuinka helppoaohjelmisto on siirtää

toiseen ympäristöön?

Onko vaadittavatoiminnallisuus tarjolla

ohjelmistossa?

Kuinkaluotettava

ohjelmisto on?


ISO9126 Laatuominaisuudet

Mukautuvuus, Asennettavuus, Rinnakkaisuus, Korvattavuus

Kuinka helppoa ohjelmisto on siirtäätoiseen ympäristöön?

Siirrettävyys

Analysoitavuus, Vaihdettavuus, Vakaus, Testattavuus

Kuinka helppoa on ohjelmistonmuuttaminen ja ylläpitäminen?

Ylläpidettävyys

Ajan käyttö, Resurssien käyttöKuinka tehokas ohjelmisto on?Suorituskyky

Ymmärrettävyys, Opittavuus, Käytönhelppous, Houkuttelevuus

Kuinka helppoa ohjelmiston käyttö on?Käytettävyys

Kypsyys, Vikasietoisuus, ToipumiskykyKuinka luotettava ohjelmisto on?Luotettavuus

Soveltuvuus, Tarkkuus, Yhteistoiminta, Turvallisuus, Yhteensopivuus

Onko vaadittava toiminnallisuus tarjolla ohjelmistossa?

Toiminnallisuus

AliominaisuudetTarkoitusLaatu-ominaisuus


Erilaisten laatuominaisuuksien painottuminen

Perinteisesti paino toiminnallisuudella

Kasvanut paino käytettävyydellä

• Ohjelmistot tulossa yleisemmiksi

• Käytettävyys pitää olla sisäänrakennettuna kuten kaikki laatu

• Käytettävyys = Käyttöliittymä + toiminnallisuuden logiikka

Kasvanut paino suorituskyvyllä

• Erityisesti käyttäjämäärien skaalaamisessa

Tietoturvan paino lisääntymässä

• Uusi ”Y2K” onkin ”buffer overflow”


Tosielämän testaushaasteita -pohdintatehtävä

Vastaat toimitusten testauskokonaisuuksista organisaatiossa, jossa samoista

komponenteista rakennetaan monenlaisia tuotteita konfiguraatioiden kautta. Organisaatio on julkaissut vuosi sitten tietoturvaohjelmistotuotteen, joka suojaa työasemakäyttöjärjestelmiä erilaisista tietoturvauhilta.

Tuotehallinta tulevaisuutta pohtiessaan on miettinyt mahdollisuutta käyttääsamaa ohjelmistopakettia tuettujen käyttöjärjestelmien laajentamisen kautta palvelinkäyttöjärjestelmien suojaamiseen. Tarvittava muutos toteutuksessa vaatii parin konfigurointitiedoston muuttamista.

Miten paljon ja millaista testausta ehdottaisit organisaation sijoittavan uuteen julkaisuun? Mieti myös miksi.


Testaamisen laajuus loppukäyttäjänäkökulmasta

Palvelut

Ympäristöt

OhjelmistoSovellus:•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, mukaanlukienpalvelinkonfiguraatiot jotka eivät ole hallinnassasi.

• Testata jokainen tapa, jolla käyttäjä saattaisi yrittää käyttää sovellusta.


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-lisuudenuusintatesti

(Leveystesti)

Erikoistunut toiminnalli-suudenuusintatesti

(Syvyystesti)


Testauksen keskeiset näkökulmat

Tekninen näkökulma”järjestelmä ei

toimi, jos...”


toimi, jos...”

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

”ei voi ratkaista ongelmaa /

tehostaa toimintaa, jos...”


”ei voi ratkaista ongelmaa /

tehostaa toimintaa, jos...”


Mustalaatikko- vs. lasilaatikkotestaus

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

Tuntematon vs. tunnettu yhtälö

Mustalaatikko Lasilaatikko


Testaus vs. Vian jäljitys

Vian jäljitys

Dynaaminen (lasilaatikko)

testausVian eristäminen

Testaus Ohjelmointi

Tavoite: Tunnistaa häiriöt ja virheet

Tavoite: Paikallistaa virheet, poistaa virheet


Mitä “testaus” tekee?

Kehittäjät muuntavat ajatuksia koodiksi

Kehityksen aikainen

ohjelmisto virheineen

Asiakas tarvitsee

ohjelmistoa

Tyytyväinen asiakas

Tuottava liiketoiminta

Tärkeät ihmisetHälysuodatin

Mukautettu ideasta, kiitokset Towo Toivola, F-Secure

Laatu-suodatin

Virhe-suodatin

Tavoitteet:1) Oikea 20 % - ”Vaatimusten testaus”2) Tuloksen etukäteisoptimointi tekijöiden kautta – ”Laadun varmistus, prosessien testaus”

Tavoitteet:1) Virheiden havaitseminen ja poistaminen2) Virheiden estäminen testi-ideoiden viestinnän kautta

Tavoitteet:1) Tehokas näkyvyys projekti- ja liiketoimintajohdolle


Kysymyksen asettelu testauksessa

VakavaTestitapaus

Koitammekohdistaanäitä…

…löytääksemmenäitä…

…jakertoaksemmejos on muuta jamillä tasollatiedämme.

VAATIMUKSETRISKITKOODI

YMPÄRISTÖT

MITÄMILLOINKUKAKUINKAMIKSI

a. Estää käyttäjän tavoitteita JA meidän mahdollisuuksia korjata

tilanne ilman merkittävääkustannusta

b. Korjaaminen voi olla merkittävätyömäärä ja aiheuttaa uusia

virheitäb. Estää tekemästä niitä asioita

joita pitäisi projektissa

c. Estää käyttäjää tekemästäasioita joita pitäisi MUTTA on helppo korjata kanavan kautta

Kattavuus?

B

PM

T

U

a

b

c

Aika

1 2 3 4 5

x x

x

x x

V3 V2D1


Testaustarve – Tuoteperheen testaus

KOMPONENTEISTA SOVELLUKSIA

SOVELLUKSET KEHIKOIHIN

kustomoinnit

konfiguraatiot

uudet ominaisuudet

KOKOONPANOJEN VALMIUSASTEET

”release-ready baseline”

”release-stabilizing baseline”

”development baseline”

palvelu-komponentit


Kokoonpanot ovat järjestelmiä

Järjestelmätestaus tarkoittaa asiakkaan kokonaiskokemuksen huomioimista, joka koostuukaikista osista käyttöympäristöissään.

Testataksesi järjestelmän, joudut sen pilkkomaan palasiksi, mutta valmistellessasi palastasijoudut miettimään vaikutuksia kokonaisuuteen.

Järjestelmätestaus tarkoittaa asiakkaan kokonaiskokemuksen huomioimista, joka koostuukaikista osista käyttöympäristöissään.

Testataksesi järjestelmän, joudut sen pilkkomaan palasiksi, mutta valmistellessasi palastasijoudut miettimään vaikutuksia kokonaisuuteen.

Käyttäjäsovellus HallintatuoteTaustajärjestelmä

Sovel-lukset

Kompo-nentit

MIBitKonfigu-raatiot

Kiinnik-keet

Tilannetieto

Etähallinta

Paketit (sw)

Päivityk-set

Talon taustajärjestelmätSW / OS / HW / NW

FFFF

UUUU

RRRR

PPPP

SSSS

SSSS


Testattavuuden määritelmä

Testattavuudella tarkoitetaan

• kykyä suorittaa kustannustehokasta testausta (Gelperin)

• ominaisuuksia jotka vaikuttavat muutetun ohjelmiston varmistamisentyömäärään (ISO9126)

• mahdollisuuksia, jotka muut osapuolet antavat testaaville osapuolille

Testattavuus voi kohdistua:

• testattavaan järjestelmään

• testauksen pohjana oleviin vaatimuksiin, määrittelyihin ja dokumentaatioon


Järjestelmän testattavuuden riskitilanne

Testattava järjestelmä

Testaus-järjestelmä

Liiketoiminta-suunnittelija


Ohjelmisto-suunnittelijaOhjelmisto-suunnittelija

TestisuunnittelijaTestisuunnittelija

Ohjelmisto-kehittäjä


Testien kehittäjäTestien kehittäjä


Tavoiteltava testattavuus



Ohjelmisto-suunnittelijaOhjelmisto-suunnittelija

TestisuunnittelijaTestisuunnittelija



Testien kehittäjäTestien kehittäjä


Testaus-järjestelmä


Järjestelmän testattavuuden keskeisimmät tekijät

Hallinta

• Helppo testata

• Liittymä, jota kautta käyttö mahdollista

• Kyky käyttää järjestelmän osia hallitusti (syötteet, tapahtumien käynnistys, metodikutsut, GUI-elementtien käyttö, rajapinnat, dedikoitu testausliittymä)

• Kyky tuottaa syötteitä ja saavuttaa ohjelmiston tiloja.

Näkyvyys

• Helppo tulkita tuloksia

• Kyky seurata testattavan ohjelmiston tiloja ja syötteistä seuraavia tuloksia.

• Virhetilanteen syiden jäljittäminen helppoa, tapahtumien suhteet selvät

• Lasilaatikko, jonka sisälle nähdään (tulokset, tilat, ominaisuudet, järjestelmän vuorovaikutus, resurssien käyttö, virheet)


Järjestelmän testattavuuden muita tekijöitä

Vakaus

• Muutosten laajuus ja muutostapahtumien tiheys

• Vaikuttaa testien ylläpitotarpeeseen

Yhdenmukaisuus

• Samanlaiset osat käyttäytyvät samalla tavalla

• Mahdollistaa testien uudelleenkäytön eri osissa

Luotettavuus

• Järjestelmä tekee mitä oli tarkoituskin

• Testien toistaminen samoissa tilanteissa tuottaa samat tulokset, eli saman tilanteet voidaan saada aikaan

Dokumentaatio

• Tieto siitä kuinka järjestelmän piti toimia
























Automaation rooli




Tutkiva testaus







Automaation rooli


Testauksen kahdet kasvot

Liiketoiminta-suuntautunut

testaus

Teknologia-suuntautunut

testaus

“Yleistestaaja”

“Tekninen testaaja”

“Hyväksymistestaaja”

“Järjestelmä-kritiikki”

“Ohjelmoinnintuki ja tehostus”


Testaustasot ja vaiheet

Testaustaso – Jatkuvaa testaustoimintaa tietyn tyyppisen testaustavoitteen ja testauskohteen ympärillä.

• Testaustoiminnasta tekee oleellisesti jatkuvaa vaatimus uusintatestauksesta muutoksen osalta.

• Taso ei ole välttämättä sama asia kuin vaihe.

Testausvaihe - Testaustason sisäinen tai useiden testaustasojen yhteinen tehtäväkokonaisuus, joka on tyypiltään kertaluonteinen eikäjatkuva.


V-malli – testauksen tasot

Yksikkö-testaus

Integrointi-testaus

Järjestelmä-testaus

Hyväksymis-testaus

Ohjelmointi

Tekninen suunnittelu

Määrittely

Vaatimukset


Testaustasojen tyypilliset merkitykset

Yksikkötestaus

Integrointitestaus

Järjestelmätestaus

HyväksymistestausTestauksen

kohteena olevan

kokoonpa-non laajuus

osa

kokonaisuus

Ympäristöjen edustavuus kaikkiosa

Tyypillinen organisointi

Asiakas/käyttäjä

Testaaja

Toteuttajat yhdessä

Kukin toteuttaja


Yksikkötestaus

Yksikkötestauksella tarkoitetaan koodin toteutukseen kohdistuvaa teknistätestausta

• Keskittyy virheisiin, jotka tyypillisesti syntyvät koodia kirjoittaessa

Yksikkö voi olla:

• Tehtävänanto : ”Koodaan ja testaan tämän ominaisuuden”

• Komponentti, moduuli, luokka : ”toteutan kaikki toiminnallisuuden näihin kooditiedostoihin”

Laajuuden tulkinnassa paljon vaihtelua

• Usein näkee suurissa hankkeissa jaettavan yksikkötestaustaso kahteen osaan, yksikkö- ja komponenttitestaukseen

• Tällöin yksikkötestaus kohdistuu kooditiedostolaajuuteen ja komponenttitestaus vastaa kehittäjän omalle komponentilleen tekemää osajärjestelmätestausta ennen integrointia kokonaisjärjestelmään


Integrointitestaus

Integrointitestauksella tarkoitetaan kaiken tasoisten osajärjestelmien yhdistämiseen kohdistuvaa teknistä testausta

Integrointitestaus usein vaikea erottaa yksikkötestauksesta, koska integrointi voi sisältää ohjelmointitehtäviä

• Usein toimiva perussääntö: enemmän kuin yksi toteuttaja �integrointitestaustarve

• Arkkitehtuuri apuna integrointitestaustarpeiden tunnistamisessa

Testaus kohdistuu integroitavaksi valittujen osajärjestelmien laajuuteen

• Integrointitestauksessa osajärjestelmien liittymän näkökulma



Järjestelmätestauksella tarkoitetaan kokonaisjärjestelmän laajuuteen kohdistuvaa testausta

• Voi sisältää sekä teknisen että käyttäjän näkökulman

Testaus kohdistuu kulloinkin olemassa olevaan kokonaisjärjestelmän laajuuteen

• Laajuus kasvaa uusien integrointien myötä

• Järjestelmätestauksessa kokonaisjärjestelmän näkökulma


Hyväksymistestaus

Hyväksymistestauksella tarkoitetaan testausnäkökulmaa, jossa tarkastellaan järjestelmää sen todelliseen ympäristöönsäsoveltuvuuden kannalta

Sopimuspohjainen hyväksymistestaus

• Voi olla juuri ennen tuotantoon siirtoa tai keskellä järjestelmätestausta

• Etenkin monitoimittajaympäristössä hyväksymistestaus liittyy laskunmaksuun eikä voida odottaa tuotantoon siirtoa

• Voi toistua jokaisen uuden alijärjestelmän versioasennuksen jälkeen

Alpha- ja betatestaus, pilotointitestaus

• Virhetilanteiden löytäminen, joita on vaikeaa tai kallista löytäälaboratorio-olosuhteissa – todellisten ympäristöjen monimuotoisuuden toistaminen haaste


V-malli – testauksen tasot

Yksikkö-testaus

Integrointi-testaus


Hyväksymis-testaus

Ohjelmointi

Tekninen suunnittelu

Määrittely

Vaatimukset

Testien ajaminen ja korjaustyö

Testien suunnittelu


V-mallin ydin

Pienempien osien testaaminen ennen järjestelmään liittämistä on hyvälähestymistapa.

Testaukselle on useita eri näkökulmia.

Testaus voi alkaa suunnittelulla heti kun korkeimman tason vaatimukset on tunnistettu.


Erityisesti huomioi (1/2)

Suunnittele testit perustuen jokaisen suunnitteluvaiheen tuotokseen, mutta suorita testit siinä järjestyksessä joka on kaikkein järkevin

• Testauksen vaiheistus voi olla erilainen kuin tasot peräkkäisinä vaiheina

• Pyri saamaan oikea näkökulma, jolla löydetään tärkeät virheet, mukaan suoritukseen mahdollisimman aikaisin

Uusintatestauksella entistä suurempi painoarvo kun lisätään uusia ominaisuuksia olemassa oleviin järjestelmiin

• Selvitä minkä testaustason näkökulmasta uusintatestausriski on taloudellisinta hallita


Erityisesti huomioi (2/2)

Suunnitteluvaiheen tuotos ei välttämättä ole dokumentti

• Dokumentti on vain yleinen viestinnän väline

V-mallia käytetään usein perusteluna sellaisten tehtävien tekemisen puuttumiselle, jotka ”olisi pitänyt jo tehdä”’

• Jos näet jonkun muun valmistelevan samoja testejä kuin sinun oletetaan tekevän, miksi tekisit?

Hyväksymistestauksen suunnittelun vaatiminen ennen muita aiheuttaa vaihtelevia reaktioita

• ”He testaavat vain nämä, joten emme mekään muuta testaa”

• ”He testaavat nämä joten meidän ei tarvitse tehdä sitä”


Koska testitapaukset suunnitellaan?

Katselmoi ennemmin kuin määrittele testitapauksia

virheellisiin tai puutteellisiin vaatimuksiin pohjaten.

Vertaiskatselmointien virheenpoistoteho 60 % Perspektiivipohjaisesti

suunnattujen teho 35 % enemmän.

��20 % virheistä menee läpi testaukseen saakka.

Virheet eivät ole tasa-arvoisia. 80 % vältettävissäolevasta korjaustyöstä tulee

20 %:sta koodia.

Katselmoi ennemmin kuin määrittele testitapauksia

virheellisiin tai puutteellisiin vaatimuksiin pohjaten.

Vertaiskatselmointien virheenpoistoteho 60 % Perspektiivipohjaisesti

suunnattujen teho 35 % enemmän.

��20 % virheistä menee läpi testaukseen saakka.

Virheet eivät ole tasa-arvoisia. 80 % vältettävissäolevasta korjaustyöstä tulee

20 %:sta koodia. Testitapaukset •vaiheittaisessa testauksessa (off-synch)

•jatkuvassa testauksessa (in-synch)


Kaksi tapaa ajatella koska testitapausten pitää olla valmiita

Testitapaukset syötteenä

• Tee niin ajoissa kuin mahdollista

• Muuta tarvittaessa

• Käytä testimäärittelyä ankkuroimaankoska homma on tehty

• Auttaa suojaamaan kiireisessäympäristössä

• Auttaa ihmisiä jotka vaativat aikaakonseptien sisäistämiseen

Pääasialliset haasteet:

• Testien kohdistus ja arvo

• Oikea dokumentointitaso

Testitapaukset tuloksena

• Aloita heti alussa

• Valmistaudu muuttamaan rakennetta

• Näytä jatkuvasti, hae kommentteja japalautetta.

• Käytä aktiivisesti oppimistyökaluna: mitä tiesin, miten se on muuttunut?

• Tarkentuu ja muuttuu koko projektinläpi

• Pääasialliset haasteet:

• Priorisointiosaaminen

• Oppimisosaaminen


Testaustasot

Yksikkö-testaus

Integrointi-testaus


Hyväksymis-testaus


toimi, jos...”


toimi, jos...”


”ei voi ratkaista ongelmaa / tehostaa

toimintaa, jos...”


”ei voi ratkaista ongelmaa / tehostaa

toimintaa, jos...”


Testaustyyppi

Testaustyyppi – Ryhmä testausaktiviteettejä, joilla on yhteisiäominaisuuksia joiden perusteella ne voidaan tunnistaa omana luokkanaan, ja jotka on ryhmitelty arvioimaan yhtä tai useampaa toisiinsa liittyvää laatuominaisuutta.

• Voi sijoittua yhdelle tai useammalle testaustasolle ja testausvaiheeseen.

• Kaikki eivät aina tarpeellisia - käytännössä testaustyypit muodostavat tarkastuslistan mahdollisesti katettavista asioista

Testaustyypit jakaantuvat toiminnallisiin ja ei-toiminnallisiin


Toiminnallisen testauksen testaustyyppejä

Toiminnallisuustestaus (functionality testing,

feature testing)

Yhtäaikaisuustestaus (concurrency testing)

Asennustestaus (installation testing)

Alustatestaus (platform testing)

Aloitustestaus (build verification testing, smoke testing)

Konfiguraatiotestaus (configuration testing)

Yhteensopivuustestaus (compatibility testing)

Rinnakkaistestaus (end-to-end testing)

Rajapintatestaus (interface testing)

Poikkeustilannetestaus (recovery testing)

Lokalisointitestaus (localization testing)

Dokumentaation testaus (documentation testing)

Aineiston laadun testaus (data quality testing)

Alfatestaus (alpha testing)

Betatestaus (beta testing)

Muuntotestaus (conversion testing)

Tuotantotestaus (production testing, operational

testing)

Standardien testaus (standards testing)


Ei-toiminnallisen testauksen testaustyyppejä

Luotettavuustestaus (reliability testing)

Suorituskykytestaus (performance testing)

Kuormitustestaus (load testing)

Rasitustestaus (stress testing)

Paljoustestaus (volume testing)

Kestävyystestaus (endurance testing)

Tietoturvatestaus (security testing)

Käyttöturvallisuuden testaus (safety testing)

Käytettävyystestaus (usability testing)

Esteettömyystestaus (accessibility testing)

Palautettavuustestaus (recoverability testing)

Tuettavuustestaus (supportability testing)

Ylläpidettävyystestaus (maintainability testing)

Siirrettävyystestaus (portability testing)

Koodin laadun testaus (code quality testing)


Testausprosessi Muokattu: Pol & Van Veenendaal. TMap.

Valmistelu Määrittely Suoritus Lopetus

Suunnittelu ja hallinta (projektinäkökulma)

Strateginen suunnittelu ja hallinta (elinkaarinäkökulma)

Testausstrategia Yleistestaussuunnitelma

Testitapaukset


Strateginen suunnittelu ja hallinta

Missio ja strategia

Organisaation yhteinen toimintatapa

Projektin ulkopuolinen testaustoiminta

• Alustan versioiden hyväksymistestaus

• Automaatioarkkitehtuurin ylläpito

• Välinetuki ja hyötyjen arviointi

• Koulutus

• Testausprojektin vertailu


Suunnittelu ja hallinta

Testaussuunnittelu

• Tavoitteet ja laaturiskit

• Aikatauluraamit

• Lähestymistapa

• Resurssointi

Hallinta

• Seuranta

• Korjaustoimenpiteet

• Eskalointi ja ongelmanratkaisu

• Testauksen laadun arviointi

• Viestintä sidosryhmille


Valmistelu

Vaatimuskatselmointi

Testattavuuskatselmointi

Testausvaatimusten tunnistaminen

Ympäristöjen valmistelu

Aineistojen valmistelu

Tiedon kerääminen


Määrittely

Riskien tunnistaminen

Testitapausten määrittely

Testitapausten priorisointi

Testiaineiston määrittely

Ympäristöjen pystyttäminen

Testien automatisointi


Suoritus

Julkaisut testaukseen

Aloitustestit

Testiaineistojen alustaminen

Testien suoritus

Uusintatestaus

Uudelleentestaus

Testitapausten ja automaation ylläpito

Testauksen tulosten kirjaaminen

Havaintojen käsittely


Lopetus

Testattavuusyhteenveto

Testauksen tulosten yhteenveto

Testauksen kokemusten yhteenveto

Testauksen materiaalien päivitys ja paketointi

Testausryhmän purkaminen


Testausprosessi ja sidosryhmät

Julkaisun-hallinnan

ryhmä

Kehitysryhmä

Johtoryhmä

Testausryhmä

Testaus-päällikkö

Testaajat

Suoritatestejä

Seuraa tuloksia(virheraportointi /

testien tilat)

Testilabra

Toimitavirheraportit

Toimitatoimitusseloste

Julkaisekoontiin

(lähdekoodi)

Julkaisetestaukseen

(ajettava ohjelma)

Määrittelejulkaisunsisältö

Raportoitestauksentilannetta

Määrittelejulkaisunsisältö


Ohjelmistokehityksen elinkaarimallit

Ohjelmistokehityksen elinkaarimallit (käytetään myös nimeäohjelmistoprosessimalli) kuvaavat hankkeen/projektin kehityksen organisointia

• Aktiviteetteja ja vaiheita

Oleellisesti kolme hyvin erilaista perusrakennetta:

• Vesiputousmalli – ”tarvittava kokonaisuus kerralla vaiheistetussa toteutuksessa”

• Iteratiivinen ja inkrementaalinen – ”tarvittava kokonaisuus toteutuserissä”

• Ketterä – ”inkrementaalinen muutos- ja ihmiskeskeisin arvoin”


Ohjelmistoprosessi vaikuttaa testauksen mahdollisuuksiin

Haluttomuus korjata virheitä usein testauksen suunnittelun sisäänrakennettu ongelma

• Laadun lähtötaso oletetaan todellista paremmaksi

• Testaus ”vesiputouksen” viimeinen vaihe

Testaajat suosittelevat muutoksia (virhekorjauksia) myöhään projektissa ja jokainen suositeltu muutos on ylihinnoiteltu ehdotusajankohdan takia

Ainoa mahdollinen kompromissi testausvaiheessa on aika (nyt ja virheellistä) vs. testaus (toimita myöhään)


Iteratiivinen vs. Inkrementaalinen


Laatuperuste inkrementaalisellekehitykselle

vesiputous

inkrementaalinen

toiminnalliset ominaisuudet

ei-toiminnal-liset ominai-suudet

julkaisu


Tasot, vaiheet ja tyypit

Hyväksymistestaus


Integrointitestaus

Yksikkötestaus

uusinta

uusinta


Testausaktiviteettien rytmitys (1/2)

Testien suoritus tarvitsee version ohjelmistosta

Testausryhmä saa ohjelmiston testaukselle tehtyjen julkaisujen kautta (koonnit ja julkaisut)

Ohjelmistoversion sisältö ohjaa ja rajaa tehtävää testausta

• Riskien toteutumisen arviointi vaatii pääsyn sopivaan toiminnallisuuteen

• Tärkeimmät löydettävissä olevat virheet riippuvat toteutuksen vaiheesta ja kypsyydestä

• Testauksen syvyyden pitäisi peilata riskejä, joiden selviämisajankohtaa ei voi määrittää projektin alussa


Testausaktiviteettien rytmitys (2/2)

Joissain asioissa ajoissa valmistelu ja suunnittelu voi olla liian ajoissa

• Muutos mitätöi suunnitelman

• Muutoksen aiheuttama lisätyö luo haluttomuutta muuttaa testauksen suuntaa

Tavoitteena oikea-aikainen suunnittelu: Tee testauksen suunnittelu juuri ajoissa ilman, että hukkaat aikaisen työn avainhyödyt.


In-synch vs. off-synch testaus

Tarvittavien valmistelujen kesto asettaa aktiviteettien rytmin

• In-synch testaus koostuu testaustehtävistä jotka voidaan tehdä samassarytmissä kuin jossa kehitys etenee, jatkuvaan tyyliin.

• Off-synch testaus tarkoittaa tyypillistä näkymää suunniteltuun javalmisteltuun testaukseen, jonka valmistelu ja suorittaminen vie liikaaaikaa ollakseen luonnollisesti integroitu kehityksenpäivittäiseen/viikottaiseen rytmiin.

Rytmin huomioiminen

• Tuo rakennetta lyhyen aikavälin suunnitteluun muistuttaen eri aikaväleistäjoilla asioita tehdään testauksessa

• Tuo joustoa pitkän aikavälin suunnitteluun ottaen kantaa tehtäviin joita ei kannata suunnitella erillisinä.


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


Keskeinen osaaminen testauksessa jakehittämisessä

Sovellus-alue

Teknologiat

Testaus

Viestintä jayhteistyö

Sovellus-alue

Teknologiat

Kehittä-minen

Viestintä jayhteistyö


Testaaja vs. KehittäjäLähde: Mukaillen Bret Pettichord. 2000.Testers and D evelopers Think Differently

Testaaja Kehittäjä

Asiantuntemuksentarve

Mallinnuksessakeskittyy

Ajatellessakeskittyy

Yksitoikkoisuus jaristiriidat

Pystyy aloittamaan nopeastiYleisosaaja

SovellusaluetietämysTietämättömyys on tärkeää

Perusteellinen ymmärrysErikoisosaaja

Tietämys sisäisestä rakenteestaSyvällinen osaaminen on tärkeää

Mallintaa käyttäjän toimintaaKeskittyy mahdolliseen

epäonnistumiseenKeskittyy ongelman vakavuuteen

Mallintaa järjestelmäsuunnitteluaKeskittyy mahdolliseen toimintaan

Keskittyy ongelman mielenkiintoisuuteen

KäytännöllinenEmpiirinen havainnointi

Epäuskoinen

TeoreettinenKuinka suunniteltu toimimaan

Halukas uskomaan

Sietää yksitoikkoisuuttaSopeutuu ristiriitatilanteissa

Raportoi ongelmia

Automatisoi yksitoikkoisuuttaVälttää ristiriitatilanteita

Ymmärtää ongelmia


Kuka haluaa olla testaaja?Lähde: Erkki Pöyhönen. 2004.

Itsenäisesti ajattelevaa, laatusuuntautunutta henkilöä, jolla on laaja liiketoiminta- ja

teknologiaymmärrys sekä loistavat ihmissuhdetaidot haetaan epäkiitolliseen

työhön, jossa on huonot ylenemis-mahdollisuudet, palkka alle keskipalkan ja

alhainen status organisaatiossa. Pakollisena vaatimuksena kyky työskennellä jatkuvan

paineen alaisena ja tuottaa jatkuvasti hyviätuloksia riittämättömään tietoon perustuen.

Itsenäisesti ajattelevaa, laatusuuntautunutta henkilöä, jolla on laaja liiketoiminta- ja

teknologiaymmärrys sekä loistavat ihmissuhdetaidot haetaan epäkiitolliseen

työhön, jossa on huonot ylenemis-mahdollisuudet, palkka alle keskipalkan ja

alhainen status organisaatiossa. Pakollisena vaatimuksena kyky työskennellä jatkuvan

paineen alaisena ja tuottaa jatkuvasti hyviätuloksia riittämättömään tietoon perustuen.


Testauksen organisointi

Hyväksyntä / toimitus

Integrointi

KehitysTestausosaamisen

kasvattaminen

Tieto muutoksista, läheisyys

Riippumattomuus, toinen näkökulma

Työnjako: oikea tekijätavoitteeseen


Case-esimerkki testausprosessista


Yleinen toimintatapa

työmäärä

aika

Asiakkaan tehtävät (määrittely)

Suunnittelijan tehtävät (toteutus, testaus, normaali virheenkorjaus)

Järjestelmätestausryhmän tehtävät

Suunnittelijan ylimääräiset tehtävät (korjaukset/täydentäminen)

läpimenoaika

Järjestelmätestauksen läpimenoaika


Toivottu muutos

aika

läpimenoaika


työmäärä






Toivottu muutos riskitilanne

työmäärä

aika

läpimenoaika







Vaihtoehtoinen toivetila resurssoinnissa

työmäärä

aika

läpimenoaika







Esimerkki: testausprosessi A

Ohjelmatestauksentestijaksot

Ohjelmatestauksenuusintatestijaksot

Integrointitestauksentestijaksot

Integrointitestauksenuusintatestijaksot

Sovellus-testaus

Testauksensuunnittelu ja

valmistelu

Järjestelmä-testauksen testijaksot

Testauksensuunnittelu

Testaajat

Toteuttajat

Ohjelmatestaustaso

Integrointitestaustaso

Järjestelmätestaustaso


Esimerkki: Toteuttajan testausvuo prosessissa A

Tes

taaj

at /

Asi

akas

Tot

eutta

jaits

ekse

enT

oteu

ttaja

tyh

dess

ä

Testauk-sen

suun-nittelu

Rajatuntoiminnallisuuden

toteutusOhjelmatestijakso

Integrointitesti-jakso

Sovellustestijakso

Sovellus-testauksen

testitapausjaksonmäärittely

Järjestelmä-testijaksot

Integrointi-testauksen

uusinta-testijakso

Ohjelma-testauksen

uusinta-testijakso

Yhteistestaus?

Muitatoteutettavia

toiminnallisuuksia?

Ei

Kyllä

Kyllä

Ei

Hyväksy-täänkö?

Korjaus/Muutos

Ei

Kyllä

Korjaus/Muutos

Korjauksia/muutoksia?

Liittymä-muutoksia?

Kyllä

Suoritettujärjestelmä-

testausEi

Kyllä

Ei

Määrittelyn mukaisetominaisuudet toteutettu

Testaussuunniteltu

Uustuotannon järjestelmätestaus

YlläpitoUustuotannon toteutus


Ohjelmatestaus - yleistä

Yksittäisen suunnittelijan tekemien osien testaaminen

Tavoitteet:

• Kattaa toteutuksen rakenteen eri haarat (lasilaatikkotestaus)

• Varmistaa oman toteutuksen määritysten mukaisuus (mustalaatikkotestaus)

• Varmistaa, että lähettävän sovelluksen yllättäväkin toiminta osataan käsitellä oikein.


Integrointitestaus - yleistä

Kokonaissovellukseksi yhdistäminen ja testaaminen vaiheittain

Tavoitteet:

• Sovellusosien rajapintojen testaaminen

• Sovellusten välisten rajapintojen testaaminen

• Järjestelmän integroiminen ja ongelmien löytäminen mahdollisimman pienellä integroimisasteella

• Kuormitustestausta mahdollisuuksien mukaan


Integrointitestausvaihe on tarpeen

Yhdistettäessä kaksi osasovellusta kokonaissovellukseksi

Ajantasasovelluksen ja eräajosovelluksen toimiessa yhdessä

Kahden ajantasa- tai eräsovelluksen välisessä yhteistoiminnassa

Palvelurajapinnoille

Kahden toteuttajan yhdistäessä omat toteutetut osansa yhteen

Jokaista rajapintatoteutusta sekä rajapintamuutosta tehdessä

Muutettaessa toteutusta tavalla, joka voi vaikuttaa mihin tahansa yhteentoimivuuteenmuun toteutuksen osan, osasovelluksen tai sovelluksen kanssa


Sovellustestaus (vaihe) - yleistä

Testaustasot leikkaava testausvaihe

Tavoitteet

• Yleisimpien toimintaketjujen testaaminen

• Ympäristöriippuvuuksien varmistaminen

Kestoltaan lyhyt

Testausvastuu siirtyy järjestelmätestaajille vaihee n jälkeen

• Toteuttajan roolina virheenkorjaus ja uusintatestaus


Esimerkki: Järjestelmätestaus A

Testauksen

suunnittelu

Testauksen

valmistelu

Testijakson

valmistelu

Testijakson

suorittaminen

Testijakson

analysointi

Testauksen

hyväksyminen

Toistetaan kunnes testijaksot on käyty läpi

� Testausympäristö

suunniteltu (laitteisto

ja liittymät)

� Testausorganisaatio

� Testausaikataulu

� Testausapuvälineet

� Testausmenettelyt

� Testikirjanpito

� Lopetus- ja

hyväksymiskriteerit

� Lähtöaineisto

� Testauskohteet

� Suoritettavat

testijaksot nimetty

� Testausympäristö

toteutettu

� Ohjelmisto siirretty

testiympäristöön

� Tietovarastot luotu ja

alustettu

� Testaus perehdytetty

� Testijaksojen sisältö

suunniteltu ja

testitapaukset

määritelty

� Testiaineisto

jaksoittain luotu/

varattu

� Liittymät

� Ohjelmaversiot

päivitetty

� Testikannat

palautettu /

testiaineisto valmiina

testauksen

suoritukseen

� Testitapaukset

jaksolle täydennetty

� Testausryhmälle

tiedotetty

� Jaksot testattu

� Havainnot kirjattu

� Testauspalaverit

pidetty

� Havainnot luokiteltu

ja kirjattu virhelistalle

� Kattavuus ja

ohjelmiston sekä

testauksen laatu

arvioitu

� Korjaustoimet

päätetty

� Jatkotoimet päätetty

� Testaus hyväksytty

� Testausraportit

laadittu

� Testausmateriaali

valmisteltu

uudelleenkäyttöä

varten


Esimerkki testaustasojen konkretisoinnista

Testaustaso Vastuu Suorittamassa Testitapausten syvyystaso

Testitekniikat Dokumentit pohjana

Käyttöliittymä-testin selainyhdistelmät

Yksikkötestaus Toimittaja Toimittaja 1-2 Toimintotestaus (sekä mustalaatikko että lasilaatikkonäkökulmasta)

Arvoaluetestaus

Teknisen ratkaisun määrittely

Yksi

Integrointitestaus Toimittaja Toimittajan testausryhmä

1-4 Vaatimuspohjainen testaus Tilamallipohjainen testaus Satunnaistestaus Arvoaluetestaus (all-pairs kriteerillä)

Rasitustestaus (ongelmat)

Toiminnallinen määrittely

Kaikki, prioriteetti-järjestyksessä testausstrategian mukaisesti

Järjestelmätestaus Asiakas Asiakkaan testausryhmä

3-4 Skenaariotestaus Vaatimuspohjainen testaus Arvoaluetestaus Rasitustestaus (kokonaisuus ja hyväksyntä)

Riskitestaus

Tavoitemäärittely Kaksi yleisintä


Termi Ympäristö Osa Näkökulma Kohteet Vastaa Suunnittelee Suorittaa

Yksikkö-testaus

Kehitys-ympäristö

Yksikkö, osasovellus, toteutettavayksittäinentoiminnallisuus

Tekninen, yksityiskohtainen

Osasovelluksen osalta:

• Toiminnallisuus• Virhetilanteiden

käsittely• Raja-arvot• Lopettaminen• Tulokset• Algoritmit ja

laskenta• Syötteet• Vuorovaikutus• Tapahtumat

Kehittäjä Kehittäjä Kehittäjä

Integrointi-testaus

Integrointi-testiympäristö

Osasovellustenvälinen rajapinta

Tekninen, rajapinta-keskeinen

Rajapinnan osalta:

• Toiminnallisuus• Virhetilanteiden

käsittely• Raja-arvot• Lopettaminen• Tulokset• Algoritmit ja

laskenta• Syötteet• Vuorovaikutus• Tapahtumat

Rajapinnantoteutuksen jamuuttamisentoimeksiantanutkehittäjä

Vaiheistus: Kehittäjät jatestausryhmäyhdessä

Testitapaukset: Kehittäjät yhdessä

Kehittäjä

Versio-testaus(vaihe)

Järjestelmä-testiympäristö

Sovellus, liittymä-järjestelmätsovelluksen kannalta

Sovelluksenperustoimin-nallisuus

Perustoiminnallisuuskokonaisuutena

Toimittajanprojektipääl-likkö

Vaiheistus: Kehittäjät jatestausryhmäyhdessä

Testitapaukset: Testausryhmä

Kehittäjät



Koko sovellus, liittymä-järjestelmät

Päästä päähäntoiminnallisuuskäyttö- jatoiminta-ympäristössä

Vaatimusten täyttyminen

Virheettömyys

Testausryhmä Testausryhmä Testausryhmä

Pilotointi Tuotanto-ympäristö


Loppukäyttäjä Vaatimusten täyttyminen Testausryhmä Testausryhmä Testausryhmä

Hyväksy-mistestaus(vaihe)



Loppukäyttäjä Vaatimusten täyttyminen Asiakas Testausryhmä Testausryhmä
























Automaation rooli




Tutkiva testaus







Automaation rooli


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 %


[Boehm 1981]

VaatimuksetAnalyysi & suunnittelu

KoodausKehityksen

aikainen testausHyväksymis-

testaus

Parannatuotetta

Tuotanto40-100x

30-70x15-40x

10x3-6x

1x

50%

Virheen kustannus kertautuu

Laatuvipu

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


Laatukustannukset

Arvioinnin kustannukset

Estämisen kustannukset Asiakkaan ja

loppukäyttäjän maksamat

laatu-kustannukset

Virhe-kustannukset

Sisäiset virhe-

kustannukset

Ulkoisetvirhe-

kustannukset

Toteutusorganisaation kustannuksia


Odotetut tulokset testauksessa

Näyttää mielestäni ihan hyvältä...

Oikeanlainen toiminta pitää kyetätunnistamaan - joskus se vaatii

analysointia etukäteen.


Vaaditaanko testitapaukseen odotettu tulos?

Miksi ei vain katsota mitä ohjelmisto

tekee ja arvioida sitä samalla?

• Alitajuinen halu saada testi menemään läpi

• Väärä tulos voidaan tulkita oikeaksi

Huomioi

• muistin rajoitteet

• vinoumat

• heuristiikat oikealle toiminnalle

• moniulotteinen oraakkeli

Usein suositellaan että odotetut

tulokset pitäisi ennustaa osana testien suunnittelua ennen testien ajamista

• Ei näin suoraviivaista: kannattaa miettiä onko itsellä/muilla kyky tunnistaa oikea tulos

• Testitapaus voi olla parempi testitapaus vaikka siitä puuttuisi odotettu tulos!

Kirjaa asiat, jotka eivät ole itsestään selvyyksiä


Odotetut tulokset – kolikon toinen puoli

Kokeillaan testitapausta videollehttp://viscog.beckman.uiuc.edu/grafs/demos/15.html

• Varmista syöttöjen määrä valkoiselta valkoiselle pelaajalle

• Odotettu tulos: Videossa on 14 tälläistä syöttöä


Oraakkelit – Miten tiedät toimiko se?

Oraakkeli on periaate tai mekanismi, jolla tunnistat ongelman.

Usein erehtyväisiä heuristiikkoja jotka ovat riittävän hyviäkäsillä olevaan ongelmaan

• Ei absoluuttista tapaa sanoa mikä on oikein

• Absoluuttinen tapa määrittää oikea on liian kallis

”Se toimii” tarkoittaa että ”se tuntui vastaavan jotain vaatimuksia jossain

määrin”

”Se toimii” tarkoittaa että ”se tuntui vastaavan jotain vaatimuksia jossain

määrin”


Toimiiko kirjasinkoko Open Officessa?Mikä on oraakkelisi?


No, entäs WordPad?


Vertaa WordPadia Wordiin

WordPad Word


Vertailun helpottaminenMuutosten korostus helpottaa havainnointia

WordPad Word


Eroista odotetun ja toteutuneen välillä

Millä eroilla on merkitystä?

Oraakkeliongelma korostaa ihmisen arviointikyvyn keskeistämerkitystä testauksessa

• Arviointikyky on keskeinen

• Testaus on oppimista, kognitiivinen toiminne, ei mekaanista

Riski helpottavana tekijänä

• Millä on merkitystä, kenelle, mikä luo arvoa?

• Läpi vs. ei läpi testille, ajattele ongelma vaiko eikö?

• Testien valinta paljastamaan vakavia virheitä

• Testin ohittaminen joilla ei oleteta löytyvän ongelmia tai joilla löytyy ongelmia joilla ei ole merkitystä


Testattava kohde ja testioraakkeliLähde: Mukaillen Doug Hoffman


Testioraakkeli

Syöte

Tulos

Odotettu tulos

Aineisto ennen

Ohjelman tila ennen

Ympäristö-syötteet

Aineisto jälkeen

Ohjelman tila jälkeen

Ympäristö-tulos

Mieti myös: diagnostiikka vaikuttaa järjestelmään

Mieti myös: diagnostiikka vaikuttaa järjestelmään


Virheraportoinnin tärkeys

Testauksen tarkoituksena tehdä havaintoja (virheitä, tietoa) ohjelmistosta

laadun parantamiseksi

Jos havaintotieto katoaa, laatu ei parane eikä projektin tilasta ole riittäväätietoa

Havaintotieto on konkreettinen perusta ohjelmiston laadun tilan arvioinnille

“Testaaja joka ei osaa raportoida virheitä, on kuin jääkaapin valo, joka on päällä vain oven ollessa kiinni”. – Kaner, Bach, Pettichord, 2002.

Painotus virheraportin sisältöön

• Raportointiin käytettävä aika vs. korjauksen tekemiseen käytettävä aika

• Jos erillisen testauksen on tarkoitus tukea kehitystä, muiden tekemän selvitystyön minimointi on hyvä tavoite


Ohjelmistossa on virhe jos:

Ohjelmisto ei tee jotakin mitä sen määrittelyjensä mukaan pitäisi tehdä

Ohjelmisto tekee jotain mitä sen määrittelyjensä mukaan ei pitäisi tehdä.

Ohjelmisto tekee jotakin mitä määrittelyissä ei ole mukana

Ohjelmisto ei tee jotakin mitä määrittelyissä ei ole mukana mutta pitäisi olla.

Ohjelmisto on vaikea ymmärtää, käyttää, hidas tai – testaajan mielipiteen mukaan – ei vain ole loppukäyttäjän mielestä oikein.


Miksi teemme tätä?

Ei raporttia = ei virhettä

Tuletko muistamaan missä oli vikaa vielä vuoden päästä?

Tuletko muistamaan, kuinka toistat sen kahden päivän kuluttua?

Kuinka muuten todistamme, että testasimme?

Viestintä: testausta tehdään myös kaukana kehityksestä


Yksinkertaistettu virheraportin elinkaari

Avoin

Ratkaistu

Suljettu

Testaaja löytää jakirjaa virheraportin

Virheraporttiosoitetaan kehittäjälle

Kehittäjä korjaavirheen

Virheraporttiosoitetaan testaajalle

Testaaja varmistaavirheen korjatuksi

Testaaja sulkeevirheraportin

Virhe löydetään

Virhe palaatakaisin

Virhe ei olekorjattu




Alitiloja tarvitaan

Avoin

• Uusi

• Avoin

• Uudelleenavattu

Ratkaistu

• Korjattu

• Ei toistettavissa

• Ei korjata

• Kuten suunniteltu

• Kaksoiskappale

• Ulkoinen

• Lykätty


Virhekorjausten varmistaminen

Kun toteuttaja sanoo virheen olevan korjattu, varmista että näin on

• Monia syitä väärinymmärrykselle

Tarkista korjatut virheet nopeasti

• Varmista, että et hidasta virheen sulkemista tai eteenpäinviemistä

Kun korjaus menee pieleen, puhu toteuttajalle

• Ystävällisesti ja avuliaasti!

Virheen löytäjän (testaajan) pitäisi sulkea virheraportti

• Muut eivät tiedä raportin yksityiskohtia ja mahdollisia aukkoja


Tiedosta käsittelykustannuksetLähde: Kaner, Bach, Pettichord. 2002. Lessons Learned i n Software Testing.

Raportin kirjoittaminen vie aikaa

Raportin lukeminen vie aikaa

• Projektipäällikkö

• Muutoshallintaraati

• Toteuttaja

Harkitse sopivaksi mitä käsitellään millä tavoin, sillä pienet ja ei-toistettavat asiat vievät myös aikaa

Myös virhekorjauksen varmistamiseen liittyy käsittelykustannus

• Seuraa riskin toteutumaa


Julkiset vs. yksityiset virheet

Julkinen = kirjattu jaettuun virhetietokantaan

Yksityinen = toteuttaja korjaa muistilappuun pohjautuen

Koska virheestä pitäisi tulla julkinen?

• Tasapainoteltavana tarve arvioida virheenpoiston tehokkuutta vs.virheraportoinnin kustannus

Testaajat voivat raportoida yksityisiä virheitä

Ohjelmoijat voivat raportoida julkisia virheitä


Virheen raportointi

Raportoi niin pian kuin mahdollista

Kuvaa virheet mahdollisimman selkeästi• Epäselvät raportit jätetään helposti huomiotta ja ne aiheuttavat

lisätyötä

Ole puolueeton ja neutraali virheitä raportoidessa

Seuraa virheraporttien etenemistä prosessissa

Virheraportin toistettavuus on tärkeää, testitapauksen toistettavuus ei välttämättä ole.

Virheraportin toistettavuus on tärkeää, testitapauksen toistettavuus ei välttämättä ole.


Hyvä virheen kuvaus

Minimaalinen

• Vain tosiasiat ja yksityiskohdat jotka ovat tarpeen

• Tarkat askeleet jotka näyttävät ongelman

Yksittäinen

• Vain yksi virhe per raportti

Selkeä ja yleinen

• Käytä askeleita jotka suoritetaan helposti ja osoita virheen yleisyys ja näkyvyys käyttäjälle mahdollisuuksien rajoissa.

Toistettavissa

• Eristä ja toista satunnaiselta vaikuttava käyttäytyminen.


Kaikkia virheitä ei korjata

Aikaa ei ole riittävästi

• Priorisoi korjaukset

Kyseessä ei ole oikeasti virhe

• Väärinymmärrykset, testivirheet tai speksimuutokset

Liian riskialtista korjata

• Yhden asian korjaaminen voi rikkoa monta muuta

Se ei ole korjaamisen arvoinen

• Esiintyy harvoin tai vähän käytetyissä ominaisyyksissa ja sillä on kiertoteitä.

Virheet raportoidaan heikosti.


Tyypillistä sisältöä virheraportille

IDOtsikko tai yhteenvetoVakavuusPrioriteetti KategoriaYmpäristö ja/tai alustaKuvausMuita hyödyllisiä kenttiä kuten

• Koonti• Kuka löysi ja koska• Omistaja


Virheen prioriteetti ja vakavuus Lähde: Kaner, Bach, Pettichord. 2002. Lessons Learned i n Software Testing.

Vakavuus on virheen vaikutus tai seuraus

• Ei muutu ellei virheen piiloseurauksista opita jotain uutta.

Prioriteetti ilmaisee koska yritys haluaa kyseisen virheen korjattavaksi

• Muuttuvat projektin edetessä

• Yleensä vakavilla ongelmilla on korkea korjausprioriteetti ja pienilläkosmeettisilla ongelmilla on matala korjausprioriteetti

Nämä kaksi asiaa eivät kuitenkaan ole samat

• Tyypillisesti testaaja käyttäjän edustajana päättää vakavuudesta, kun taas prioriteetti on projektitason tai jopa yritystason päätös


Esimerkki prioriteetin ja vakavuuden eroista

Vakavia virheitä joita ei kannata korjata:

• Virhe myöhäisessä vaiheessa projektia, jonka korjauskustannukset kokonaisuutena ylittävät mahdollisen haitan

• Virhe joka korruptoi tietoja jotka syötetään niin että koneen kello on 10 vuotta nykypäivästä jäljessä. Virheen näkyminen käytäntöön ei ole todennäköistä tältä osin ja se saatettaisiin jättää korjaamatta.

Kosmeettisia virheitä jotka kuitenkin pitää pikaisesti korjata:

• Virhe aloitusruudussa, jossa yrityksen logo on nurinpäin tai nimi väärin kirjoitettuna ei ole virheenä kovin vakava, mutta korjausprioriteetiltaan varmasti hyvinkin korkea useimmille yrityksille.


Otsikko tai yhteenveto

Kuvaa ongelman yhdellä rivillä

Parhaimmillaan antaa ajatuksen missä ja mitä ongelma on ilman kuvauksen lukemistakin

Jos ei voi antaa molempia, keskity ensisijaisesti vastaamaan kysymykseen mitä, sitten vasta missä

Hyvä kieliasu parantaa selkeyttä

Hyvä yhteenveto:

• Lyhyt riittävän yksityiskohtainen kuvaus josta lukija voi käsittää virhetilanteen

• Lyhyt ilmaus virheen rajoista tai riippuvuuksista

• Lyhyt ilmaus virheen vaikutuksesta tai seurauksista


Kuvaus

Pitäisi sisältää kaikki tarvittava tieto ongelman toistamiseenKenellä tahansa, jolla on perustietämys testattavasta järjestelmästä, pitäisi olla mahdollista toistaa virhe kuvaukseen pohjaten (sinä, toinen testaaja, kehittäjä, projektipäällikkö, ulkopuolinen)

• Aliarvioi lukijaa

Täydelliset ja selkeät askeleet ongelman toistamiseen• Kukaan ei osaa lukea ajatuksiasi• Jos joku tulee pyytämään lisätietoa, kuvauksesi ei ollut riittävä

Kaikki toistamiseen tarvittava tieto yhdessä paikassaJos mikä tahansa muutos mihin tahansa virheraportin kenttään tehdään, se kannattaa selittää kommentoiden kuvauksen perään


Avointen, ratkaistujen ja suljettujenraporttien trendi

Havaintoraporttien käsittelytrendi

0

100

200

300

400

500

600

700

800

#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21

Viikko

Mää

rä

Avoin

Ratkaistu

Suljettu

Trendikäyräntulkitseminen vaatiilisätietoa projektista

Trendikäyräntulkitseminen vaatiilisätietoa projektista


Tasainen testaustahti


0

100

200

300

400

500

600

700

800

#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21

Viikko

Mää

rä

Avoin

Ratkaistu

Suljettu


Lisää tekijöitä korjauksiin


0

100

200

300

400

500

600

700

800

#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21

Viikko

Mää

rä

Avoin

Ratkaistu

Suljettu


Korjauksen onnistumisen korostaminen


0

100

200

300

400

500

600

700

800

#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21

Viikko

Mää

rä

Avoin

Ratkaistu

Suljettu


Kehittäjät seuraavan projektin kimppuun


0

100

200

300

400

500

600

700

800

#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21

Viikko

Mää

rä

Avoin

Ratkaistu

Suljettu


Lisäihmisiä testaukseen


0

100

200

300

400

500

600

700

800

#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21

Viikko

Mää

rä

Avoin

Ratkaistu

Suljettu


Testaajien flunssa-aalto


0

100

200

300

400

500

600

700

800

#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21

Viikko

Mää

rä

Avoin

Ratkaistu

Suljettu


Kehittäjät takaisin korjaushommiin


0

100

200

300

400

500

600

700

800

#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21

Viikko

Mää

rä

Avoin

Ratkaistu

Suljettu


Uusien havaintojen määrä aidosti laskussa


0

100

200

300

400

500

600

700

800

#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21

Viikko

Mää

rä

Avoin

Ratkaistu

Suljettu


Projektin kokonaistilanteen arviointi

Avoimet vakavuusasteittain #21

KriittinenVakavaNormaaliVähäinen

Havaintojen jakauma #21

AvoinRatkaistuSuljettu

0

2

4

6

8

10

12

14

16

Käyttöliittymä Toiminto 1 Toiminto 2 Toiminto 3 Toiminto 4

Avoimet virheet alueittain ja vakavuusasteittain



Testauksen laadun arviointiVirheiden vakavuus löytäjittäin

0

50

100

150

200

250

Tiina Mikko Jari Marko Minna


Virheiden määrä löytäjittäin

0

50

100

150

200

250

Tiina Mikko Jari Marko Minna

Kirjattuja havaintoja

Havaintojen jakautuma löytötavoittain ja vakavuuksittain

Tot

eutt

ajan

test

aus

Tes

titap

aus

Tut

kiva

tes

taus

Val

mis

tele

mat

onte

stau

s

Pilo

ttik

äytt

ö

Asi

akas

VähäinenNormaaliVakavaKriittinen


Korjaustoiminnan onnistumisen arviointi

Uudelleenavatut virheraportit viikottain

0

5

10

15

20

25

30

35

40

45

#1 #3 #5 #7 #9 #11

#13

#15

#17

#19

#21

Uudelleenavattu

Avointen virheraporttien aukioloaika

0

2

4

6

8

10

12

<3pv <7 pv <2vk <1kk <2kk >2kk


Virheraporttien ratkaisut ratkaisijoittain

0

5

10

15

20

25

30

Kalle Matti Kaisa

KorjattuKuten suunniteltuUlkoinenToisintoEi toistuLykättyEi korjata
























Automaation rooli




Tutkiva testaus







Automaation rooli

ohjelmistojen testaus - jyväskylän...

Documents