1. No category

CT60A4150
OHJELMISTOTESTAUKSEN
PERUSTEET
Jussi Kasurinen ([email protected])
Kevät 2015
NOPEA KERTAUS VIIME
KERROISTA
ERILAISIA T YÖKALUT YYPPEJÄ
 Millä työkaluilla testausta sitten tehdään?
 Suurin osa ohjelmistojen testauksesta tehdään täysin samoilla
työvälineillä kuin itse ohjelmistokehitys.
 Poislukien jotkin toimialakohtaiset työvälineet, kuten
protokollayhteensopivuuksien tarkastamiseen tarkoitetut testerit.
 Testaajien tärkeimmät työkalut ovat kehitysympäristö,
sekä kommunikointivälineet joilla ilmoittaa havaituista
ongelmista eteenpäin.
 Erilaisia – nimenomaan testausta varten – kehiteltyjä
työkaluja:
 Testausautomaatiotyökalut
 Vikatietokannat
 Tyngät (stub), tynkägeneraattorit
 Analysaattorit, debuggerit
 Dokumenttipohjat, dokumentointityökalut
 Testausympäristöjen tukityökalut
SWEBOKIN T YÖKALUT
Testiympäristöt, testipedit
Testigeneraattorit
Kaappaus/Toistotyökalut
Testioraakkelit/vertailutyökalut
Kattavuudenarviointi ja kattavuuden
määrittely
Jäljittimet
Regressiotestaustyökalut
Luotettavuuden arvioinnin työvälineet
CT60A4150 Ohjelmistotestauksen
perusteet
TESTAUKSEN
SUUNNITTELU JA
DOKUMENTOINTI
TESTAUKSEN SUUNNITTELUSTA
Testaustyöhön liittyy siis kaikenlaista,
kuten
Työkalut
Menetelmät
Tehtävät eri työvaiheissa
… ja kaikki pitäisi koordinoida yhdessä
varsinaisen ohjelmistokehityksen
kanssa.
SUUNNITTELU JA DOKUMENTOINTI
 Aiemmassa ”testaus hyvin lyhyesti”-esimerkissä
sivuttiin tavallisimpia testaukseen liittyviä
asioita:
 3 tahoa; esimiehet, testausta tekevät ja kehittäjät.
 3 dokumenttia tai tietolähdettä; testaussuunnitelma,
testitapaukset ja yhteenveto eli testiraportti.
 Tutkimustiedon mukaan kaikilla on jonkinlainen
yleinen suunnitelma (testausstrategia) ja
projektikohtainen suunnitelma
(testaussuunnitelma).
 Lisäksi kaikki seuraa ainakin jotain mittaria, oli
se sitten jäljellä oleva aika, raha tai
koodinkattavuus tai mikä tahansa.
SUUNNITTELU JA DOKUMENTOINTI
YLEISESTI
Yleisellä tasolla testauksen ohjaamista ja
johtamista varten dokumentoidaan seuraavia
asioita:
 Miksi testausta tehdään
 Miten testausta tehdään projektin eri vaiheissa
 Kuinka testausta johdetaan
 Kuka testausta johtaa
 Millä työvälineillä testaus tapahtuu
 Kuka tekee testaustyön
 Miten testausta seurataan ja varmennetaan että kaikki
tehtiin oikein
 Miten toimintaa kehitetään
DOKUMENTOINNISTA
 Kuten ohjelmistotuotannossa yleensä, dokumentoinnilla on
merkittävä osuus testauksessa
 Dokumentteja syntyy paljon
 Niiden kirjoittamiseen kuluu huomattavan paljon aikaa
 Dokumenttien ja varsinaisten testien synkronointi voi
muodostua ongelmaksi
 Dokumentoinnin tarkoituksena on saada tieto
suunnittelijoiden/testaajien korvien välistä muotoon, jota muutkin
voivat käyttää  vrt. UML, jolla suunnittelijan korvien välistä
viedään tietoa kehittäjille.
 Osa dokumenteista voi olla myös asiakkaan vaatimia.
 Kun asiat kirjataan ylös, huomataan yleensä puutteita ja
väärinkäsityksiä, lisäksi projektin edetessä dokumentit
vanhenee.
 Dilemma: miten dokumentoida kaikki tarpeelliset asiat, mutta ei
mitään turhaa?
 Miten paljon aikaa dokumenttien hallitsemiseen pitäisi käyttää?
DOKUMENTTIEN YLEINEN JÄRJEST YS
TESTAUSPOLITIIKAN SISÄLTÖÄ
 Testauksen tavoitteet, eli yleisesti määrittely mitä
testaustoiminnalla oikeasti halutaan saavuttaa ja
mitä periaatteita testauksessa tulee noudattaa.
 Testausorganisaation rakenne, eli kuka tekee
testausta, kuka vastaa testauspolitiikan
laatimisesta, kenellä on päätösvalta testausta
koskevissa asioissa.
 Testausprosessi, eli lyhyt kuvaus siitä miten
testausta tehdään tai kuka päättää prosessin
määrittelemisestä.
 Testaajia koskevat koulutusvaatimukset , eli mitä
organisaatio vaatii testausta tekevien ihmisten
koulutustaustaksi, ja miten koulutus tai sitä
vastaavien tietojen hankkiminen on organisoitu.
TESTAUSPOLITIIKAN SISÄLTÖÄ
Standardit ja seurattavat määritelmät, eli
mitä standardeja tai muita tuotetta tai
toimitapoja koskevia määritelmiä
testaustyössä pitää noudattaa.
Testauksen laadun mittaustapa, eli
määritelmä sille, miten testauksen laatu tai
kustannustehokkuus mitataan tai
todennetaan organisaatiossa.
Testauksen kehittämistapa, eli miten
organisaatiossa tehdään testauksen
toimitapoja kehittävää toimintaa.
TESTAUSSTRATEGIA
 Yleisten riskien hallintaan tarvittavat
toimenpiteet ja menetelmät, joilla tiedossa
olevia ongelmia tai projektin riskejä voidaan
välttää.
 Aloitusehto testaukselle, eli yleisellä tasolla
asettaa raja sille, missä vaiheessa testaus
aloitetaan ja millä ehdoilla testattava ohjelman
voidaan palauttaa takaisin korjattavaksi.
 Testausryhmän itsenäisyysaste, eli määrätä se,
mistä asioista testausta tekevät henkilöt saavat
päättää itse ja missä asioissa heidän
mielipiteensä ohittaa esimerkiksi muun
organisaation päätösvallan.
TESTAUSSTRATEGIA
Testausorganisaation rakenne, eli todeta
ketkä kaikki kuuluvat testausorganisaatioon
ja kuka on kenenkin esimies, erityisesti
silloin jos organisaatio poikkeaa siitä, joka
on määritelty testauspolitiikassa.
Dokumentointimenettely, eli mitä kaikkia
dokumentteja testaukseen liittyen tehdään,
kuka niitä ylläpitää ja mitä niihin tulisi
vähintään merkitä.
Testivaiheet, eli mitä kaikkia työvaiheita
testauksen aikana tapahtuu.
TESTAUSSTRATEGIAN SISÄLTÖÄ
 Testaustekniikat, eli millaisia testausmenetelmiä
testaamisessa tulisi käyttää
 Testitapausten valinta- ja priorisointikriteerit, eli
millä perusteella kaikkien testitapausten
joukosta valitaan kaikista tärkeimmät tapaukset,
mikäli käy niin että kaikkia suunniteltuja
testitapauksia ei ole mahdollista toteuttaa.
 Kustannustehokkuus tai kokonaishinta tavallisimmat
optimoitavat asiat, rajoitteet aika tai raha.
 Testiympäristö, eli millainen järjestelmä
testausta varten rakennetaan, kuka sen
rakentaa, kuka sitä ylläpitää ja mitä
testaustekniikoita käytetään missäkin
järjestelmässä.
TESTAUSSTRATEGIAN SISÄLTÖÄ
 Uudelleentestaus, määritellä ne kriteerit joiden
pohjalta aiemmin onnistuneiksi todetut
testitapaukset pitää lähettää
uudelleentestattavaksi.
 Testauksen lopetusehdot, eli määritelmä sille
millä ehdoilla voidaan todeta, että testattava
kokonaisuus toimii oikein, täyttää kaikki
vaatimukset ja on valmis käyttöönottoa varten.
 Suunnitelma poikkeamien hallintaan, eli
määritellä menettely, jolla voidaan raportoida ja
hoitaa ennalta-arvaamattomia ongelmia.
TESTAUSSTRATEGIASTA
Testausstrategioita voi olla useita!
Esim. “uusi versio päätuotteesta”
“Lisätään uusi ominaisuus olemassa olevaan”
“Poistetaan vikoja myynnissä olevasta
tuotteesta.”
“Räätälöinti uudelle asiakkaalle”
…jne.
Testauspolitiikka on koko organisaatiolle
sama.
ORGANISAATION TESTAUSTAPOIHIN
VAIKUTTAVIA ASIOITA
 Testaustyötä tekevien ja sitä johtavien henkilöiden
tietotaito ja näkemykset nykytilaan
 Nykyiset tavat tehdä testausta ja niiden
toimivuudesta aiemmin kerätty tieto.
 Organisaatiolle määritellyt tavoitteet, visiot ja
missio
 Tietoturvakäytännöt
 Projektinhallintakäytännöt
 Laatuvaatimukset, laatukäytännöt
 Aiemmat testausstrategiat
 Aiemmin kerätty palaute tuotteista ja projekteista
 Aiemmin tuotetut testaussuunnitelmat
TESTAUSSUUNNITELMA
Päätestaussuunnitelmasta puhutaan kun
suunnitelma koskee koko projektia.
Vaihe- tai osatestaussuunnitelma koskee yhtä
tasoa tai menetelmää.
TESTAUSSUUNNITELMAN SISÄLTÄMIÄ
ASIOITA
 Projektin kuvaus. Yleiset tiedot projektista, testausta
koskevista päivämääristä sekä tarvittavat yleistiedot siitä
mitä projektissa olisi tarkoitus tehdä.
 Kuvaus testattavasta tuotteesta. Kuvaus siitä mitä
projektissa on tarkoitus testata, kuvaus testattavan
tuotteen pääkomponenteista ja komponenttien välisistä
yhteyksistä. Kuvaus siitä mitä komponentit tekevät, ja
mitä koko laitteen itsessään olisi tarkoitus tehdä (tai olla
tekemättä) sekä ohjeet siitä, mistä eri komponentteja
koskevaa lisätietoa on saatavilla.
 Testien laajuus. Kuvaus siitä, mitkä osat tuotteesta
testataan, sekä lista niistä testausta koskevista
rajoitteista tai ongelmista, jotka jo etukäteen tiedetään.
TESTAUSSUUNNITELMAN SISÄLTÄMIÄ
ASIOITA
 Käytetty testausstrategia . Testaussuunnitelmassa tulisi joko
mainita se, mitä lähestymistapaa käytetään tai määritellä
projektia varten testausstrategian mukaisesti kuka, milloin,
missä ja miten tuotetta olisi tarkoitus testata .
 Aikataulu ja työnjako. Aikataulu testaustoiminnalle, sisältäen
kaikki asetetut deadline-päivämäärät, sovitut katselmoinnit ja
välitavoitteet.
 Riskikartoitus, toimintasuunnitelma . Jos tuotteeseen liittyy
jotain merkittäviä riskejä, tai tuotteelle on olemassa erillinen
vaatimusmääritelmä, niin lista niistä asioista, joilla eri
vaatimukset on tarkoitus todentaa tai riskit välttää, tulisi liittää
mukaan.
 Tätä suunnitelmaa voidaan jatkossa käyttää pohjana testitapauksia
suunnitellessa ja valittaessa.
 Henkilöstölistaus. Kuvaus siitä, ketä kaikkia testaustiimiin
kuuluu, ja kuka vastaa minkäkin osan testaamisesta, ja mitä
taustatietoja testaajien pitäisi tietää ennen testaamaan
ryhtymistä.
TESTAUSSUUNNITELMA, SPACEDIRTMALLI
S Scope = Laajuus, eli määritelmä siitä mitä
kohteita testataan ja mitä osia ei testata.
P People = Ihmiset, eli millaista koulutusta
testaajilta vaaditaan, mitkä ovat testaajien
vastuut ja millä aikataululla testausta tehdään.
A Approach = Lähestymistapa, eli mitä
testausmenetelmiä käytetään mihinkin
työvaiheeseen.
C Criteria = Kriteerit, eli mitkä ovat testauksen
aloitus-, lopetus-, keskeytys- ja jatkamiskriteerit.
E Environment = Ympäristö, eli millainen
testausympäristö testausta varten tulee
rakentaa.
TESTAUSSUUNNITELMA, SPACEDIRTMALLI
D Deliverables = Tuotokset, eli mitä
testausprosessi tuottaa kehitysprosessien
käyttöön.
I Incidentals = Satunnaiset, eli mitä
erikoisominaisuuksia tai poikkeuksia
testaukseen liittyy, ja kenellä on
auktoriteetti muuttaa testaussuunnitelmaa.
R Risks = Riskit (riskit ja torjunta)
T Tasks = Tehtävät (testauksen tehtävät,
jotka kuuluvat testausprosessiin)
TESTITAPAUKSET, MISSÄ VIAT OVAT?
 Uusi koodi: Uusi koodi sisältää
todennäköisemmin virheitä kuin aikaisemmin
käytetty ja testattu koodi.
 Uudet ominaisuudet: Osat joihin on lisätty uusia
ominaisuuksia voivat olla tehtyjen muutosten
vuoksi nyt viallisia.
 Uusi teknologia: Uuden tai huonosti tunnetun
teknologian tuominen ohjelmaan voi aiheuttaa
virheitä.
 Muutettu koodi: Osat joihin on tehty muutoksia,
oli ne miten pintapuolisia tahansa, voivat
muutosten vuoksi olla rikkoutuneita ja ne pitää
testata kuin uusi koodi.
TESTITAPAUKSET, MISSÄ VIAT OVAT?
 Viime hetken korjaukset: Eli ns. ”purkkapatentit” pitää
tarkastaa ja mikäli projektilla on edelleen resursseja
käytettävänä, poistaa ja korvata hyviä ohjelmointitapoja
noudattavalla ratkaisulla.
 Vältetään teknistä velkaa
 Ulkopuolelta tuotu koodi: Osat jotka on valmistettu
kehitystiimin ulkopuolella voivat toimia eri tavalla kuin
alun perin odotettiin ja aiheuttaa ohjelmassa sisäisiä
ongelmia.
 Uusi asiakas tai markkina-alue: Vaikka tuote on
edellisellä asiakkaalla tai edellisellä käyttäjäkunnalla
toiminut ongelmitta, ei uusi käyttäjäkunta
automaattisesti ole samaa mieltä.
 Uudet työntekijät: Ohjelmointikokemuksen määrä tai
kokemus osana ryhmää työskentelemisestä voi johtaa
järjestelmänsisäisiin yhteensopivuusongelmiin.
TESTITAPAUKSEN LAATIMINEN
 Mihin osiin järjestelmää testitapaus vaikuttaa.
 Kuka testitapauksen on suunnitellut.
 Mistä testitapausta koskien löytyy lisätietoa.
 Kuka voi päättää testitapauksen muuttamisesta tai
hylkäämisestä.
 Konteksti, miten testitapaus liittyy järjestelmään
yleisesti.
 Tavoite, mitä testitapauksella halutaan tarkastaa
ja saavuttaa.
 Syötteet ja työvaiheet; mitä järjestelmään tulee
antaa syötteinä ja miten järjestelmän pitäisi tähän
reagoida.
TESTITAPAUKSEN LAATIMINEN
 Lopputulos; miten järjestelmän pitäisi olla muuttunut, mitä
tietoja on tallennettu, minne, ja miltä tulostietojen pitäisi
näyttää.
 Ympäristön vaatimukset; millaisessa testausympäristössä
testitapaus pitää suorittaa, mitä testausympäristöä
testitapauksessa käytetään.
 Erikoisehdot; jos testitapaukseen liittyy jotain erikoisehtoja
kuten esimerkiksi poikkeus - tai virhetilan mallinnusta, mitä
ne ovat.
 Riippuvuudet; mihin testitapauksiin tai mistä testitapauksista
tämä testitapaus on riippuvainen.
 Laatuehdot; millä ehdoilla tapausta voidaan pitää
onnistuneena.
 Rajoitteet; missä tapauksissa tapaus voidaan sivuuttaa mikäli
se ei toteudu onnistuneesti, missä tapauksissa tätä
testitapausta ei huomioida ongelmaksi.
TESTIRAPORTTI
 Yhteenveto tehdyistä testeistä, eli kootusti tiedot kaikista
projektissa käytetyistä testausmenetelmistä projektin kaikissa
vaiheissa.
 Muutokset alkuperäiseen suunnitelmaan, eli mitä kaikkea
alkuperäisestä testaussuunnitelmasta jouduttiin muuttamaan,
miksi näin tehtiin ja mitä tilalla tehtiin.
 Testauksen lopetuskriteerit, eli mitkä projektin testauksen
lopetuskriteerit olivat, miten testausorganisaatio saavutti
kyseiset kriteerit tai vaihtoehtoisesti miksi asetettuja
kriteereitä ei saavutettu.
 Prosessia haitanneet tekijät, eli selitys sille mitkä asiat
haittasivat testauksen toteuttamista siten kuten se oli alun
perin määritelty, sekä lyhyt selitys miksi ne tekivät niin.
 Opitut asiat, eli mitä kaikkea organisaation voidaan sanoa
oppineen tämän projektin toteutuksesta koskien testaustyötä,
testausprosessia tai organisaation tapaa toimia.
TESTIRAPORTTI
Testausmetriikka, eli mitä kaikkea
projektista mitattiin, sekä koko projektin
ajalta relevantti mittausdata.
Muutokset riskianalyysiin, eli miten
riskianalyysi muuttui projektin aikana, mitä
uusia riskejä havaittiin ja miten niihin
reagoitiin.
Testausympäristön tila, eli selvitys siitä
mihin tilaan käytetty testiympäristö jäi,
miten ympäristö toimi projektin aikana.
TESTIRAPORTTI
 Testauksen lopputuotteet, eli mitä kaikkea
testauksen toimenpiteillä tuotettiin, ja mistä ne
ovat saatavilla.
 Uudelleenkäytettävät komponentit, eli lista
kaikista niistä osista tai toiminnoista kuten
testausautomaation sovelluksista, joita
projektin tuottamasta testausmateriaalista
voidaan käyttää muissa projekteissa.
 Suositukset muutoksille, eli kootusti lista
kaikista asioista, joita nykyisestä
toimintatavasta pitäisi muuttaa paremman
testaustoiminnan mahdollistamiseksi.
TESTAUKSEN DOKUMENTIT: CASE
ISO/IEC 29110
Organizational Test Documentation
Test Management Documentation
Dynamic Test Documentation
Test Completion Documents
DOKUM E NTTI EN VÄ LI SET Y H T E YDE T, I SO/ I E C 2 91 1 9 - MALLI
Organisaation
dokumentit
Test Policy
Organizational
Test Strategy
Organizational
Test Strategy
Testauksen johdon
dokumentit
Test Plan
(Sub-process)
Organizational
Test Strategy
Test Plan
(Project)
Test Plan
(Sub-process)
Test Plan
(Sub-process)
D O K U M E N T T I E N V Ä L I S E T Y H T E Y D E T, I S O / I E C 2 91 1 9 - M A L L I
Testauksen johdon
dokumentit
Testauksen tekemisen
dokumentit
Test Plan
(Sub-process)
Test
Specification
Test Environment Req.
Test Data Requirement
Test Env. Readiness Rep.
Test Data Readiness rep.
Perform
dynamic Test
Incident
Report
Test Execution
Documentation
Test Status Report
D O K U M E N T T I E N V Ä L I S E T Y H T E Y D E T, I S O / I E C 2 91 1 9 - M A L L I
Testauksen tekemisen
dokumentit
Test Status
Report
Testauksen hallinnan
ja raportoinnin
dokumentit
Test Completion
Report (subprocess)
Test Completion
Report (subprocess)
Test Completion
Report (project)
KONSEPTIEN VÄLISET YHTEYDET, ISO/IEC
29119 MALLI
KONSEPTIEN VÄLISET YHTEYDET, ISO/IEC
29119 MALLI
ESIMERKKEJÄ DOKUMENTEISTÄ
Katsotaan muutamia erilaisia
perusdokumenttityyppejä
ISO/IEC 29119 templaatit
http://qtp.blogspot.fi/2009/06/softwaretesting-documentation.html --> erilaisia
virallisia tai epävirallisia templaatteja
DOKUMENTOINNISTA
Tietysti käytetyt dokumentit pitää valita
projektin koon ja käyttötarpeen mukaan.
Tarpeeton dokumentti ei ole kuin hidaste.
Virheellisestä tiedosta on enemmän haittaa kuin
puuttuvasta dokumentista.
”Jos dokumentointikäytännöt on hidaste, ne ovat
ensimmäinen asia joka tiukan paikan tullen
hylätään.”
… ja niiden dokumenttien piti auttaa
vikojen jäljittämisessä ja
laadunvarmennuksessa?
MITÄ TÄSTÄ LUENNOSTA PITÄÄ MUISTAA?
Päädokumentit
Testisuunnitelma
Testitapaukset
Testausstrategia
Dokumenttien yleinen malli