Testaus elinkaaressa Järjestelmätestaus Järjestelmätestaus Tarkoittaa koko järjestemän laajuuteen kohdistuvaa testausta, koko järjestelmän toiminnan näkökulmasta Järjestelmän ei tarvitse olla valmis vaan testataan se mitä on siihen mennessä aikaansaatu Yleensä sekä käyttäjän- että tekninen näkökulma Liian huonolaatuista koodia ei kannata järjestelmätestata, resurssien hukkaanheittoa. 1
Järjestelmätestauksen kohdentaminen 1/3 Toiminnallinen testaus Perinteinen ohjelman toiminnallisuuden testaus vaatimuksia vastaan Voidaan hyödyntää aiemmin esitettyjä testaustekniikoita ja menetelmiä Konfiguraatiotestaus Testataan toimivuus eri laitealustoilla Yhdistelmiä yleensä paljon alustojen priorisointi, ns. edustajalaitteet Testausjärjestelyjen rakentaminen yleensä aikaavievää erityiset testilaboratoriot Myös ulkopuolisten testauspalvelujen käyttö Järjestelmätestauksen kohdentaminen 2/3 Yhteensopivuustestaus Testataan toimivuus muiden ohjelmistojen ja standardien suhteen (vrt. konfiguraatiotestaus) Tiettyjen standardien täyttyminen voi olla markkinoillepääsyn ehto erityisesti kuluttajatuotteissa Certified for Windows, Symbian signed, Java verified Suorituskykytestaus Tässä esimerkkinä ei-toiminnallisten vaatimusten testauksesta Testataan järjestelmän suorituskykyä, esim. muistinkulutusta, skaalautuvuutta, vasteaikoja Testaukseen käytetään erityisiä mittausohjelmistoja 2
Järjestelmätestauksen kohdentaminen 3/3 Käytettävyystestaus Testataan ohjelman käytön helpoutta ja soveltuvuutta määriteltyyn tehtävään käyttäjän näkökulmasta Kaksi lähestymistapaa Haastattelut ja käytön seuranta Testaus käytettävyysstandardeja ja ohjeita vastaan Osittain kvalitatiivista (miltä tuntuu?), osittain kvantitatiivista (esim. mitataan suoritusaikoja) Muita järjestelmätestauksen kohdentamiskeinoja Lokalisointi- ja dokumenttitestaus Turvallisuustestaus Tietoturvatestaus Muiden ei-toiminnallisten vaatimusten testaus RISKIPERUSTAINEN TESTAUS H. Schaeferin näkemys riskiperustaisesta testauksesta Testaukseen käytettävissä olevat resurssit ovat aina niukat, paine saada nopeasti valmista On kyettävä priorisoimaan ja jättämään vähiten tärkeät testit pois Järjestelmätestaus on kallista ja siksi kohdennettava tehokkaasti (ROI ajattelu) Tavoitteena kyetä valitsemaan yrityksen liiketoiminnan kannalta mahdollisimman hyödylliset testitapaukset Järjestelmätestauksessa testausta ohjataan usein riskiperustaisesti Riskiperustaista testausta voidaan käyttää myös yksikkö- ja integrointitestauksessa, pääasiallisesti kuitenkin järjestelmätestauksen strategia Universaali strategia, soveltuu kaikentyyppiseen järjestelmätestaukseen 3
Mikä riski on? Mikä riski on? Riski = Vahingon suuruus * Todennäköisyys Vahingon suuruus Suora rahallinen menetys Asiakkaiden menetys Brandin ja laatuimagon heikkeneminen Ihmishengen menetys, katastrofit... (suuruus ~ Toteutumisen todennäköisyys Yleinen arvio tilastojen perusteella: koko, monimutkaisuus Täsmäarvio: mitä tiedämme tuotteesta ja sen laadusta ennen järjestelmätestausta Erittäin vaikea arvioida 4
Riskiperustaisen testauksen kulku Riskien tunnistaminen Vaatii monipuolista näkemystä tuotteesta ja liiketoiminnasta Yksi tekniikka on pitää aivoriihi-tyyppisiä kokouksia Testaajia, kehittäjiä, käyttäjiä, tuotepäälikkö, markkinointi, tekninen tuki... 1) Etsitään riskejä järjestelmän käyttötilanteesta ja yrityksen liiketoiminnasta Riskin seuraus tunnetaan Löytyneet riskit on kohdennettava järjestelmän toimintoihin, osiin tai laadullisiin ominaisuuksiin Toteutumistodennäköisyyden arvioimiseksi mietitään miten järjestelmä voisi aiheuttaa riskin toteutumisen 5
Riskien löytäminen... 2) Etsitään riskejä järjestelmästä Mietitään mitä järjestelmän jostain ongemasta seuraisi Koko järjestelmästä, osajärjestelmistä, järjestelmän liitynnöistä ympäristöön Käydään läpi toiminnot ja laatuattribuutit Laatuattribuutteja: luotettavuus, yhteensopivuus, käytettävyys, suorituskyky, ylläpidettävyys, turvallisuus, skaalautuvuus... Riskistrategia Riskistrategia Arvioidaan ja priorisoidaan riskit Valitaan riskitaso jonka ylittävät riskit on testattava Huomioidaan testauksen kustannukset eri riskeille Testauksen kohdentaminen Tehdään testaussuunnitelma Resurssoidaan ja organisoidaan testaus 6
Riskien arviointi Yksinkertainen menetelmä Riskin todennäköisyys Käytetään karkeaa asteikkoa esim. 1-3 (matala, keskimääräinen, korkea) Arviointi perustuu tietoon ko. järjestelmän osan laadusta (aiempi testaus), tai yrityksen/yleiseen tietoon vastaavien järjestelmien laadusta kehityksen tässä vaiheessa Riskin seurauksen vakavuus Arvioidaan samoin karkealla asteikolla esim. 1-3 Joskus halutaan että riittävän vakava seuraus pakottaa testauksen todennäköisyydestä riippumatta Lasketaan yhteen jokaisen riskin todennäköisyys ja seuraus Saadaan viisiportainen riskien prioriteettiarvio 2...5 Yhteenlasku ei teoreettisesti oikein, mutta toimii Riskien arviointi Monipuolisempi menetelmä Todennäköisyyden arviointi Arvioidaan virheen esiintymisen todennäköisyyttä kehittämiseen liittyvien tekijöiden kautta Monimutkaiset osat, jatkuvasti muuttuneet osat Kehittäjien lukumäärä, kokemus ja -vaihtuvuus Uusi teknologia, työkalut, metodi tai sovellusalue Kiire, huono asiakassuhde tai projektinjohto Hajautettu kehitys, uudet alihankkijat... Seurauksen arviointi Näkyvyys asiakkaalle Vahingon suuruus Altistumisen yleisyys Annetaan painokertoimia edellisille tekijöille (esim. 1-3-10) Riskit arvioidaan em. tekijöiden suhteen asteikolla 1-5 Lasketaan kokonaisriski Todennäköisyys * vahinko 7
Riskien arviointi Monipuolisempi menetelmä Korkeat riskit - läpikotainen testaus Keskitason riskit - normaali testaus Matalat riskit - kevyt testaus tai ei testausta Tärkeää käyttää tilannekohtaista harkintaa, ei noudattaa orjallisesti riskilaskennan tulosta Monipuolisempi menetelmät eivät tuo useinkaan lisäarvoa Oleellista että näkökulma primääristi on käyttäjän / muiden joihin ohjelma vaikuttaa ja rahalliset arviot ovat näistä johdettuja Usein ihmisillä taipumus aliarvioida sellaisten riskien todennäköisyyttä joilla on suuret negatiiviset seuraukset ja yliarvioida myönteisten tapahtumien todennäköisyyksiä Riskien arviointi Esimerkki. (H. Shaefer) 8
Riskien raportointi ja seuranta Riskien seuranta jatkuvaa ja ohjaa testauksen kohdentamista HYVÄKSYNTÄTESTAUS Tavoite: osoittaa että tuote on sopimuksen mukainen Tavoitteena ei löytää enää virheitä, demonstraatio Joskus hyväksymistestauksen suunnitelma ja jopa testitapaukset ovat osa sopimusta Hyväksymistestaus perustuu asiakasvaatimuksiin Alihankintasuhteessa nämä hyväksymistestit voivat olla luonteeltaan kuitenkin integrointitestejä Perinteisesti hyväksymistestaus sijoittuu hankkeen loppuun Ketterässä kehityksessä myös hyväksymistestaus jakaantuu iteraatioille Hyväksytään piirre kerrallaan 9
Hyväksyntätestauksen toteutus Testataan kokonaista valmista tuotetta Testaajat loppukäyttäjiä (jos mahdollista) Testiympäristö lähellä todellista käyttöympäristöä Todelliset tietokannat, muut kytkeytyvät järjestelmät vai emulaatio tyngillä Testidata todellista vai generoitua Laitteiston konfiguraatio, laitteiston muu kuormitus Joskus erilaisia käyttöympäristöjä useita, konfiguraatiotestauksen tekniikat Virheiden raportointi ja korjaus Ei automaattisesti korjaukseen Neuvottelukysymyksiä, korjataanko vai siedetäänkö, mihin hintaan, seuraavaan versioon... MoSCoW priorisointi Yleinen priorisointitapa vaatimuksille, voidaan käyttää riskeillekin, etenkin hyväksyntätestauksessa Vaatimuksen toteutumisen testaamisen kohdentaminen asiakkaan prioriteetin mukaan Luokitellaan vaatimukset kategorioihin Must test - not negotiable Should test - agreed on, but not critical Could test - nice to have Won t test - to future releases Sovitaan hyväksyntätestauksessa taso jolloin katsotaan tuote valmiiksi toimitukseen Esim. Must 100%, Should 80%, Could 0% 10
Ylimpien testaustasojen synergiat Yksikkö- ja integrointitestauksen yhdistämisesen keinot ja hyödyt olivat ilmeisiä, ainakin niin kauan kuin kyse on kehittämistä tukevasta testauksesta Eri testaajien välillä on kuitenkin vaikea löytää synergiamahdollisuuksia Kehittäjät, testaajat, asiakkaat, ulkoistettu testaus Korkean tason integrointitestaus ja järjestelmätestaus Erilliset testaajat huolehtivat suurempien integrointien testauksesta, käyttäen samaa testiympäristöä ja järjestelyä kuin kehittäjät Korkean tason integrointitestaus hyödynnettävissä osana järjestelmätestausta Järjestelmätestaus ja hyväksymistestaus Mahdollista mikäli loppukäyttäjät osallistuvat järjestelmätestaukseen Usein yhdistyy ketterässä kehityksessä Luontevaa kun järjestelmätestaus on tehtävä aidossa ympäristössä 11