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.
Friday, 27 October 2006 Page 3
Tekninen testausTekninen testaus
Käsiteltävät asiat
Tehokas ohjelmistotestausTehokas ohjelmistotestaus
Testaus ohjelmistokehityksen osana
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
Friday, 27 October 2006 Page 4
Tekninen testausTekninen testaus
Käsiteltävät asiat
Tehokas ohjelmistotestausTehokas ohjelmistotestaus
Testaus ohjelmistokehityksen osana
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
Friday, 27 October 2006 Page 5
Ohjelmistokehityksen kolminaisuus
Vaatimukset
Tekninen suunnittelu ja toteutus
Testaus
Friday, 27 October 2006 Page 6
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ä
Friday, 27 October 2006 Page 7
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ä
Friday, 27 October 2006 Page 8
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
Friday, 27 October 2006 Page 9
Kehitys- ja testausprosessit muodostavat palautesilmukan
KehitysprosessiKehitysprosessi
TestausprosessiTestausprosessi
Testi-tulokset
Kehitys-tuotteet
Friday, 27 October 2006 Page 10
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
Friday, 27 October 2006 Page 11
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
31 kirjattua virhettä
Osa C
12 kirjattua virhettä
Osa D
24 kirjattua virhettä
Osa B
10 kirjattua virhettä
Osa B
0 kirjattua virhettä
Osa C
0 kirjattua virhettä
Osa D
0 kirjattua virhettä
Friday, 27 October 2006 Page 13
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.
Friday, 27 October 2006 Page 14
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ää.
Friday, 27 October 2006 Page 15
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
Friday, 27 October 2006 Page 16
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
Friday, 27 October 2006 Page 17
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.
Friday, 27 October 2006 Page 18
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
Friday, 27 October 2006 Page 19
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?
Friday, 27 October 2006 Page 20
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
Friday, 27 October 2006 Page 21
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”
Friday, 27 October 2006 Page 22
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.
Friday, 27 October 2006 Page 23
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
Friday, 27 October 2006 Page 24
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.
Friday, 27 October 2006 Page 25
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.
Friday, 27 October 2006 Page 26
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)
Friday, 27 October 2006 Page 27
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...”
Friday, 27 October 2006 Page 28
Mustalaatikko- vs. lasilaatikkotestaus
? y = 2xx = 2 y = 4 x = 2 y = 4
Tuntematon vs. tunnettu yhtälö
Mustalaatikko Lasilaatikko
Friday, 27 October 2006 Page 29
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
Friday, 27 October 2006 Page 30
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
Friday, 27 October 2006 Page 31
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
Friday, 27 October 2006 Page 32
Testaustarve – Tuoteperheen testaus
KOMPONENTEISTA SOVELLUKSIA
SOVELLUKSET KEHIKOIHIN
kustomoinnit
konfiguraatiot
uudet ominaisuudet
KOKOONPANOJEN VALMIUSASTEET
”release-ready baseline”
”release-stabilizing baseline”
”development baseline”
palvelu-komponentit
Friday, 27 October 2006 Page 33
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
Friday, 27 October 2006 Page 34
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
Friday, 27 October 2006 Page 35
Järjestelmän testattavuuden riskitilanne
Testattava järjestelmä
Testaus-järjestelmä
Liiketoiminta-suunnittelija
Liiketoiminta-suunnittelija
Ohjelmisto-suunnittelijaOhjelmisto-suunnittelija
TestisuunnittelijaTestisuunnittelija
Ohjelmisto-kehittäjä
Ohjelmisto-kehittäjä
Testien kehittäjäTestien kehittäjä
Friday, 27 October 2006 Page 36
Tavoiteltava testattavuus
Liiketoiminta-suunnittelija
Liiketoiminta-suunnittelija
Ohjelmisto-suunnittelijaOhjelmisto-suunnittelija
TestisuunnittelijaTestisuunnittelija
Ohjelmisto-kehittäjä
Ohjelmisto-kehittäjä
Testien kehittäjäTestien kehittäjä
Testattava järjestelmä
Testaus-järjestelmä
Friday, 27 October 2006 Page 37
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)
Friday, 27 October 2006 Page 38
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
Friday, 27 October 2006 Page 39
Tekninen testausTekninen testaus
Käsiteltävät asiat
Tehokas ohjelmistotestausTehokas ohjelmistotestaus
Testaus ohjelmistokehityksen osana
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
Friday, 27 October 2006 Page 40
Testauksen kahdet kasvot
Liiketoiminta-suuntautunut
testaus
Teknologia-suuntautunut
testaus
“Yleistestaaja”
“Tekninen testaaja”
“Hyväksymistestaaja”
“Järjestelmä-kritiikki”
“Ohjelmoinnintuki ja tehostus”
Friday, 27 October 2006 Page 41
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.
Friday, 27 October 2006 Page 42
V-malli – testauksen tasot
Yksikkö-testaus
Integrointi-testaus
Järjestelmä-testaus
Hyväksymis-testaus
Ohjelmointi
Tekninen suunnittelu
Määrittely
Vaatimukset
Friday, 27 October 2006 Page 43
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
Friday, 27 October 2006 Page 44
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
Friday, 27 October 2006 Page 45
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
Friday, 27 October 2006 Page 46
Järjestelmätestaus
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
Friday, 27 October 2006 Page 47
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
Friday, 27 October 2006 Page 48
V-malli – testauksen tasot
Yksikkö-testaus
Integrointi-testaus
Järjestelmä-testaus
Hyväksymis-testaus
Ohjelmointi
Tekninen suunnittelu
Määrittely
Vaatimukset
Testien ajaminen ja korjaustyö
Testien suunnittelu
Friday, 27 October 2006 Page 49
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.
Friday, 27 October 2006 Page 50
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
Friday, 27 October 2006 Page 51
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ä”
Friday, 27 October 2006 Page 52
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)
Friday, 27 October 2006 Page 53
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
Friday, 27 October 2006 Page 54
Testaustasot
Yksikkö-testaus
Integrointi-testaus
Järjestelmä-testaus
Hyväksymis-testaus
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...”
Friday, 27 October 2006 Page 55
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
Friday, 27 October 2006 Page 56
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)
Friday, 27 October 2006 Page 57
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)
Friday, 27 October 2006 Page 58
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
Friday, 27 October 2006 Page 59
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
Friday, 27 October 2006 Page 60
Suunnittelu ja hallinta
Testaussuunnittelu
• Tavoitteet ja laaturiskit
• Aikatauluraamit
• Lähestymistapa
• Resurssointi
Hallinta
• Seuranta
• Korjaustoimenpiteet
• Eskalointi ja ongelmanratkaisu
• Testauksen laadun arviointi
• Viestintä sidosryhmille
Friday, 27 October 2006 Page 61
Valmistelu
Vaatimuskatselmointi
Testattavuuskatselmointi
Testausvaatimusten tunnistaminen
Ympäristöjen valmistelu
Aineistojen valmistelu
Tiedon kerääminen
Friday, 27 October 2006 Page 62
Määrittely
Riskien tunnistaminen
Testitapausten määrittely
Testitapausten priorisointi
Testiaineiston määrittely
Ympäristöjen pystyttäminen
Testien automatisointi
Friday, 27 October 2006 Page 63
Suoritus
Julkaisut testaukseen
Aloitustestit
Testiaineistojen alustaminen
Testien suoritus
Uusintatestaus
Uudelleentestaus
Testitapausten ja automaation ylläpito
Testauksen tulosten kirjaaminen
Havaintojen käsittely
Friday, 27 October 2006 Page 64
Lopetus
Testattavuusyhteenveto
Testauksen tulosten yhteenveto
Testauksen kokemusten yhteenveto
Testauksen materiaalien päivitys ja paketointi
Testausryhmän purkaminen
Friday, 27 October 2006 Page 65
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ö
Friday, 27 October 2006 Page 66
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”
Friday, 27 October 2006 Page 67
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)
Friday, 27 October 2006 Page 68
Iteratiivinen vs. Inkrementaalinen
Friday, 27 October 2006 Page 69
Laatuperuste inkrementaalisellekehitykselle
vesiputous
inkrementaalinen
toiminnalliset ominaisuudet
ei-toiminnal-liset ominai-suudet
julkaisu
Friday, 27 October 2006 Page 70
Tasot, vaiheet ja tyypit
Hyväksymistestaus
Järjestelmätestaus
Integrointitestaus
Yksikkötestaus
uusinta
uusinta
Friday, 27 October 2006 Page 71
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
Friday, 27 October 2006 Page 72
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.
Friday, 27 October 2006 Page 73
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ä.
Friday, 27 October 2006 Page 74
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
Friday, 27 October 2006 Page 75
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.
Friday, 27 October 2006 Page 76
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
Friday, 27 October 2006 Page 77
Keskeinen osaaminen testauksessa jakehittämisessä
Sovellus-alue
Teknologiat
Testaus
Viestintä jayhteistyö
Sovellus-alue
Teknologiat
Kehittä-minen
Viestintä jayhteistyö
Friday, 27 October 2006 Page 78
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
Friday, 27 October 2006 Page 79
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.
Friday, 27 October 2006 Page 80
Testauksen organisointi
Hyväksyntä / toimitus
Integrointi
KehitysTestausosaamisen
kasvattaminen
Tieto muutoksista, läheisyys
Riippumattomuus, toinen näkökulma
Työnjako: oikea tekijätavoitteeseen
Friday, 27 October 2006 Page 81
Case-esimerkki testausprosessista
Friday, 27 October 2006 Page 82
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
Friday, 27 October 2006 Page 83
Toivottu muutos
aika
läpimenoaika
Järjestelmätestauksen läpimenoaika
työmäärä
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)
Friday, 27 October 2006 Page 84
Toivottu muutos riskitilanne
työmäärä
aika
läpimenoaika
Järjestelmätestauksen läpimenoaika
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)
Friday, 27 October 2006 Page 85
Vaihtoehtoinen toivetila resurssoinnissa
työmäärä
aika
läpimenoaika
Järjestelmätestauksen läpimenoaika
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)
Friday, 27 October 2006 Page 86
Esimerkki: testausprosessi A
Ohjelmatestauksentestijaksot
Ohjelmatestauksenuusintatestijaksot
Integrointitestauksentestijaksot
Integrointitestauksenuusintatestijaksot
Sovellus-testaus
Testauksensuunnittelu ja
valmistelu
Järjestelmä-testauksen testijaksot
Testauksensuunnittelu
Testaajat
Toteuttajat
Ohjelmatestaustaso
Integrointitestaustaso
Järjestelmätestaustaso
Friday, 27 October 2006 Page 87
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
Friday, 27 October 2006 Page 88
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.
Friday, 27 October 2006 Page 89
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
Friday, 27 October 2006 Page 90
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
Friday, 27 October 2006 Page 91
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
Friday, 27 October 2006 Page 92
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
Friday, 27 October 2006 Page 93
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ä
Friday, 27 October 2006 Page 94
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
Järjestelmä-testaus
Järjestelmä-testiympäristö
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ö
Koko sovellus, liittymä-järjestelmät
Loppukäyttäjä Vaatimusten täyttyminen Testausryhmä Testausryhmä Testausryhmä
Hyväksy-mistestaus(vaihe)
Järjestelmä-testiympäristö
Koko sovellus, liittymä-järjestelmät
Loppukäyttäjä Vaatimusten täyttyminen Asiakas Testausryhmä Testausryhmä
Friday, 27 October 2006 Page 95
Tekninen testausTekninen testaus
Käsiteltävät asiat
Tehokas ohjelmistotestausTehokas ohjelmistotestaus
Testaus ohjelmistokehityksen osana
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
Friday, 27 October 2006 Page 96
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
Friday, 27 October 2006 Page 97
Virhe – Vika - Häiriö
Ihminen tekee virheen…
…joka aiheuttaa vian ohjelmistoon…
…joka voi aiheuttaa häiriön ohjelmiston toiminnassa
Friday, 27 October 2006 Page 98
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ö
Friday, 27 October 2006 Page 99
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 %
Friday, 27 October 2006 Page 100
[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ä
Friday, 27 October 2006 Page 101
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
Friday, 27 October 2006 Page 102
Odotetut tulokset testauksessa
Näyttää mielestäni ihan hyvältä...
Oikeanlainen toiminta pitää kyetätunnistamaan - joskus se vaatii
analysointia etukäteen.
Friday, 27 October 2006 Page 103
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ä
Friday, 27 October 2006 Page 104
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öä
Friday, 27 October 2006 Page 105
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”
Friday, 27 October 2006 Page 106
Toimiiko kirjasinkoko Open Officessa?Mikä on oraakkelisi?
Friday, 27 October 2006 Page 107
No, entäs WordPad?
Friday, 27 October 2006 Page 108
Vertaa WordPadia Wordiin
WordPad Word
Friday, 27 October 2006 Page 109
Vertailun helpottaminenMuutosten korostus helpottaa havainnointia
WordPad Word
Friday, 27 October 2006 Page 110
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ä
Friday, 27 October 2006 Page 111
Testattava kohde ja testioraakkeliLähde: Mukaillen Doug Hoffman
Testattava järjestelmä
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
Friday, 27 October 2006 Page 112
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
Friday, 27 October 2006 Page 113
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.
Friday, 27 October 2006 Page 114
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ä
Friday, 27 October 2006 Page 115
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
Virheraporttiosoitetaan kehittäjälle
Virheraporttiosoitetaan kehittäjälle
Friday, 27 October 2006 Page 116
Alitiloja tarvitaan
Avoin
• Uusi
• Avoin
• Uudelleenavattu
Ratkaistu
• Korjattu
• Ei toistettavissa
• Ei korjata
• Kuten suunniteltu
• Kaksoiskappale
• Ulkoinen
• Lykätty
Friday, 27 October 2006 Page 117
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
Friday, 27 October 2006 Page 118
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
Friday, 27 October 2006 Page 119
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ä
Friday, 27 October 2006 Page 120
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.
Friday, 27 October 2006 Page 121
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.
Friday, 27 October 2006 Page 122
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.
Friday, 27 October 2006 Page 123
Tyypillistä sisältöä virheraportille
IDOtsikko tai yhteenvetoVakavuusPrioriteetti KategoriaYmpäristö ja/tai alustaKuvausMuita hyödyllisiä kenttiä kuten
• Koonti• Kuka löysi ja koska• Omistaja
Friday, 27 October 2006 Page 124
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
Friday, 27 October 2006 Page 125
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.
Friday, 27 October 2006 Page 126
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
Friday, 27 October 2006 Page 127
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
Friday, 27 October 2006 Page 128
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
Friday, 27 October 2006 Page 129
Tasainen testaustahti
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
Friday, 27 October 2006 Page 130
Lisää tekijöitä korjauksiin
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
Friday, 27 October 2006 Page 131
Korjauksen onnistumisen korostaminen
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
Friday, 27 October 2006 Page 132
Kehittäjät seuraavan projektin kimppuun
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
Friday, 27 October 2006 Page 133
Lisäihmisiä testaukseen
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
Friday, 27 October 2006 Page 134
Testaajien flunssa-aalto
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
Friday, 27 October 2006 Page 135
Kehittäjät takaisin korjaushommiin
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
Friday, 27 October 2006 Page 136
Uusien havaintojen määrä aidosti laskussa
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
Friday, 27 October 2006 Page 137
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
KriittinenVakavaNormaaliVähäinen
Friday, 27 October 2006 Page 138
Testauksen laadun arviointiVirheiden vakavuus löytäjittäin
0
50
100
150
200
250
Tiina Mikko Jari Marko Minna
KriittinenVakavaNormaaliVähäinen
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
Friday, 27 October 2006 Page 139
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
KriittinenVakavaNormaaliVähäinen
Virheraporttien ratkaisut ratkaisijoittain
0
5
10
15
20
25
30
Kalle Matti Kaisa
KorjattuKuten suunniteltuUlkoinenToisintoEi toistuLykättyEi korjata
Friday, 27 October 2006 Page 140
Tekninen testausTekninen testaus
Käsiteltävät asiat
Tehokas ohjelmistotestausTehokas ohjelmistotestaus
Testaus ohjelmistokehityksen osana
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