TestaajanKommunikoin..

Transcription

TestaajanKommunikoin..
Virheraportointi
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
You Are What You Write
• Bugiraportit ovat monen testaajan ensisijainen
tuotos
• Raporttien lukijat ja käyttäjät muodostavat
näkemyksensä testaajasta pääasiassa niiden
perusteella
– Kehittäjät, managerit, laatuinsinöörit
• Kehittäjät ovat riippuvaisia bugiraporttien
informaatiosta
– Hyvä raportointi auttaa ohjelmoijia työssään, heikot
raportit lähinnä tuovat ajanhukkaa
– Testaaja joka kirjoittaa heikkoja raportteja menettää
uskottavuutensa eikä bugiraportteihin enää reagoida
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
1
VIRHERAPORTOINTI
• Tavoiteita:
– Toimiva kommunikaatio testaajien ja kehittäjien välillä (joskus itselleen
kommunikointia, silti hoidettava järjestelmällisesti)
– Näkyvyys etenemiseen
• Alussa toiminnallisuuden seuranta, lopussa virheiden seuranta
• Virhetrendit oleellisia julkaisupäätöksen tukena
• Keinoja:
– Virheraportti (bugiraportti)
• Testaajan näkemys siitä mikä on tuotteessa on vialla ja mikä on sen merkitys
• Laajuus vaihtelee tarpeen mukaan
– Virheraporttien hallinta
• Muodollisuuden ja järjestelmällisyyden tarve kasvaa hankkeen koon ja
osapuolien määrän kasvaessa
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Bugiraportti - miksi?
• Miksi
–
–
–
–
–
Virhettä ei ole olemassa jos raporttia ei kirjoiteta
Virheen dokumentointi, ei vain muistinvarainen
Virhetrendien muodostuminen
Testauksen irroittaminen ajasta ja paikasta, joustavuus
Testaajan arvokkaan osaamisen välittäminen intressiryhmille
• Mitä
– Ei spekuloi vian korjaamistavoilla tai vian syillä
– Auttaa vian lokalisoinnissa
– Motivoi kehittäjiä korjaamaan tärkeät bugit (testaajalla parempi ymmärrys
virheiden vakavuudesta kuin kehittäjillä)
• Kustannustehokkuus
– Hyvän raportin kirjoittamisen työmäärä on yleensä selvästi pienempi
vihreen korjauksen työmäärä
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
2
Bugiraportti - mitä sisältää
(laaja versio)
•
•
•
•
Yksiöivä tunniste, raportoija, luontipäivämäärä
SUT (ohjelma tai komponentti)
Versiointitieto, testikonfiguraatio
Raportin tyyppi
•
•
Toistettavuus
Vakavuus
– Ohjelmointivirhe, suunnitteluvirhe, dokumentointi ei vastaa toimintaa, ehdotus...
– Testaajan näkemys virheen vakavuudesta tuotteen käytön tai liiketoiminnan
näkökulmasta, virheen seuraus
– Ei korjaamisen prioriteetti, vaan käsittelyn prioriteetti
•
Prioriteetti
•
Vaikutus asiakkaisiin
•
Ongelman kuvaus
•
Avainsanat
– Projektipäälikkön / ohjelmoijan tärkeys virheen korjaamiselle
– Tekninen tuki täydentää
– Ytimekkäästi, yhdellä rivillä
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
... bugiraportti - mitä sisältää
•
Ongelman kuvaus ja toistaminen askel askeleelta
•
•
Suositeltu korjaus
Vastuu selvittämisestä
•
Status
•
Päätös (projektipäälikkö)
– Yksityiskohtaien
– Projektipäälikkö allokoi
– Avoin, suljettu, roskis
– Odottaa, varmistettu, ei voida toistaa, korjattu, skeduloitu korjaukseen, lykätty
korjausta, tarvitaan lisää tietoa, duplikaatti ...
– Päätöstä vastaavan buildin versionumero
•
Päätöksen testaaja
•
•
Bugiraportin versiohistoria
Vapaamuotoiset kommentit
– Yleensä sama joka löysi bugin
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
3
Bugiraportin elinkaari
• Kun raportti luodaan
järjestelmään, se on tilassa open
• Kun kehittäjä ottaa raportin
käsiteltäväkseen, sen tilaksi
tulee assigned
• Hyväksytysti korjattu (tai
muuten tavoin käsittelystä pois
siirretty) bugi siirretään tilaan
closed
• Alitiloja closed tilalle: fixed,
ignored, dublicate, triage, NR...
Ohjelmistotestaus -09
Open
accept
resolve
reassign
resolve
Assigned
© Antero Järvi, Tuomas Mäkilä
Closed
reopen
It-laitos / TY
Bugiraporttien käyttökohteet
• Nostavat esiin vikoja ja auttavat kehittäjiä selvittämään vian syyt
• Nostavat esiin ongelmia spesifikaatioissa ja dokumentaatiossa
• Antavat yleiskuvan tuotteen valmiusasteesta ja laadusta kehityksen
aikana
• Toimivat lähtökohtana tuotteen seuraavan version kehitykselle
• Taustatietoa käyttäjämanuaalien laatimiseen ja käyttäjäkoulutukseen
• Tukevat teknista asiakastukea korjaamattomien bugien ilmentyessä
asiakkaalla
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
4
¬(Bugirapottien käyttö)
• Älä käytä bugiraportteja ohjeilmoijien suoriutumisen
mittaamiseen
– Suuri määrä ohjelmoijalle osoitettuja korjaamattomia bugeja, hidas
ohjelmoija ?
– Seuraus mittaamisesta: kehittäjät puolustautuvat bugiraportteja
vastaan
• Design bugi ei ole bugi
• Samankaltaiset bugit ovat dublikaatteja
• Vaikeasti toistettavia bugeja ei saisi raportoida
• Älä käytä bugiraportteja testaajien suoriutumisen
mittaamiseen
– Testaajien palkitseminen löydettyjen bugien määrällä johtaa
väistämättä huonompaan testaukseen, kehittäjien kuormittamiseen
turhilla bugeilla ja huonompilaatuiseen bugiraportointiin
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Bugiraportointityökalut, esim.
Bugzilla
• Käytetyin Open Source projekteissa, vastaavia työkaluja useita
• www.bugzilla.org
• Hyvästä bugiraportoinnista voi oppia paljon tutkimalla laadukkaiden
Open Source hankkeiden raporttikantoja
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
5
Bugitrackerista issuetrackeriksi
• Bugitrackeria voi käyttää myös laajemmin
ohjelmistotyön tarpeisiin
• Trackeriin voi tallentaa tiedot
– Vaatimuksista
– Työtehtävistä
– Jne…
• Myös testitapaukset voi kerätä trackeriin
– Tapaukset voi kätevästi linkittää vaatimuksiin
– Trackerit tarjoavat mekanismit tapausten
kategorisointiin
– Testitapauslistojen generoiminen on helppoa
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Kehittäjien motivointi
• Kaikkia raportoituja bugeja ei koskaan korjata
– Aikaa on rajallisesti ja priorisointi tapahtuu viimekädessä kehittäjien
toimesta (toimeenpanovalta)
– Testaaja voi vaikuttaa merkittävästi siihen mitkä bugit tulevat korjatuiksi
• Testaajan on motivoitava kehittäjiä korjaamaan tärkeät bugit
(myyntityötä)
– Tutki bugi kunnolla ja raportoi selkeästi
– Korkea vakavuusluokka
– Esitä konkreettisesti mitä haittaa bugista on: miten tuotteen normaali
käyttö häiriytyy, miten yleisesti häiriö esiintyy, mitä dataa se korruptoi ...
– Tee bugin toistettavuudesta helppoa
• Change contorl board, CCB:lle, kirjoitetaan erilaisia bugiraportteja
kuin kehittäjille
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
6
Huonon suunnittelun raportointi
• Ovatko ohjelman vaikeaselkoisuus, epäjohdonmukaisuus, kapea
soveltuvuusalue, yhteentoimimattomuus jonkun sovelluksen kanssa
jne. bugeja jotka pitäisi raportoida?
• Usein katsotaan että sovelluksen design on tehty ja kiinnitetty
aikaisemmassa vaiheessa, eikä testaajilla ole edes osaamista sen
arviointiin.
• Toisaalta monia asioita on vaikea ja ymmärtää ennen kuin sovellusta
pääsee käyttämään, joten on yleistä että vasta testaajilla on
mahdollisuus arvioida suunnittelupäätösten seurauksia
• Testaajien ammattitaito ei ole suunnattu sovellusten suunnitteluun,
mutta ei ole käyttäjienkään, ja testaajat katsovat sovellusta käyttäjien
näkökulmasta. Mikä on testaajan mielestä huonoa suunnittelua on sitä
myös käyttäjän mielestä.
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Bugit joita ei voi toistaa
• ... ohjelma toimii väärin, muttet kykene toistamaan virhettä
– Non-Reproducible bug (NR bug)
• Monissa yrityksissä NR bugit jätetään käsittelemättä
• NR bugit kannattaa silti raportoida, ja tehdä selväksi että kyseessä on
NR bugi
– Ohjelmoijalle tilanteen syy voi joskus olla helposti pääteltävissä, ja itse
virhe löytyä koodista suoraan
– Kun NR bugeja kertyy enemmän nähdään niistä yhdessä jokin
säännönmukaisuus joka johtaa virheen lähteille
• NR bugit ovat oikeasti toistettavia, testaaja ei vain tiedä miten
– Viivästetty virheen näkyvyys (muistin ylivuoto, karannut pointteri...)
– Bugi näkyy vain ensimmäisellä suorituskerralla asennuksen jälkeen
– Bugi voi olla riippuvainen monimutkaisesta muiden tehtävien
suoritusjärejestyksestä
– Bugi voi olla riippuvainen syötteistä joita ei päästä kontrolloimaan
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
7
Kommunikoinnista kehittäjien
kanssa
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Tavoitteena yhteispeli
• Kehittäjien (ohjelmoijien) ja testaajien välille
syntyy helposti jännitteitä
– Ohjelmoijat näkevät testaajat työnsä kritisoijina
– Testaajat näkevät ohjelmoijat koodauskoneina joiden
tehtävä on reagoida bugiraportteihin välittömästi
• Testaaja on kommunikoinnissa aloitteellinen joten
vastuu hyvästä yhteispelistä on pääosin testaajalla
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
8
Miten kehittäjä ajattelee
• Paras tapa testaajalle oppia miten ja mitä kehittäjä ajattelee
on toimia kehittäjän työssä
• Yleistyksiä kehittäjien ajattelutavasta
– Kehittäjät erikoistuvat johonkin systeemin osaan ymmärtävät vain
pinnallisesti muita. Testaaja on koko järjestelmän yleistuntija
– Kehittäjät näkevät systeemin malliensa kautta: jäsentävät
komponenttien riippuvuuksia, laatua, virheiden leviämistä. Testaaja
jäsentää järjestelmää sen toiminnallisuuden kautta.
• Bugiraportit testaavat kehittäjien käsitystä systeemistä
– Ohjelmointityö on vaativaa ja monimutkaista, joten kehittäjät eivät
halua tulla häirityiksi asioilla jotka he kokevat vähemmän tärkeiksi.
– Kehittäjät painiskelevat vaikeiden tilanteiden kanssa: epämääräiset
ja muuttuvat vaatimukset, bugiset työkalut ja komponentit
• Testaajat ja kehittäjät ajattelevat eri tavalla
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Palvele kehittäjiä, rakenna
luottamusta
• Tee yhteistyötä kehittäjien kanssa alusta asti
– Selvitä millaista palautetta kehittäjät tarvitsevat sunnitelmista, design
dokumenteista, vaatimuksista
– Ole selvillä siitä mitkä ovat kehittäjille vakavia ongelmia ja keskity
auttamaan niiden ratkaisemisessa
• Tuota palveluja
– Testaa kolmannen osapuolen komponentteja jotta kehittäjät voivat tehdä
informoidun päätöksen niiden käytöstä
– Testaa prototyyppejä, sisäisiä julkaisuja
– Rakenna testausympäristöjä kehittäjille omaan testaukseen
– Katselmoi vaatimusdokumentteja testattavuuden näkökulmasta
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
9
Raportoi kehittäjiä kunnioittaen
•
•
•
•
•
•
Säästä kehittäjien aikaa: raportoi vain oleellinen bugista ja sen oireista, miten
se toistetaan.
Raportoi siitä mitä havaitset, älä arvaile bugin syitä. Testaaja on ohjelman
käytön asiantuntija, ei sen sisäisen rakenteen.
NR bugin kyseessä ollessa raportoi miten yritit toistaa virhettä. Yritä
kommunikoida että teit työn perinpohjaisesti mutta työssä tarvitaan sisäistä
ohjelman tuntemusta ja kehitystyökaluja.
Kerro huonot uutiset suoraan, mielellään ensin kehittäjille ja sitten laajemmin.
Älä teeskentele että tiedät mitä et tiedä. Raportoi se minkä tiedät varmaksi.
Älä liioittele tai vähättele asioita raportoinnissa. Shoot straight!
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
Julkinen vai yksityinen
virheraportti?
• Julkinen virheraportti näkyy kaikille, myös esimiehille, yksityinen vain
toteuttajalle jonka kirjoittamaa koodia testataan.
• Julkinen silloin kun
–
–
–
–
Toteuttaja ei tiedossa tai virheen vaikutusalue usean toteuttajan koodi
Virheen syy voi olla monimutkainen
Virheraportteja käytetään edistymisen/laadun seurantaan
Virhe liittyy julkseen tuoteversioon
• Yksityinen raportointi kustannustehokkaampi silloin kun mahdollista
– Pienet raportointikustannukset, suoraviivainen korjaus
• Jos testaaja tekee liian herkästi julkisia virheraportteja nousee
kehittäjien kynnys antaa varhaisia versioita testattavaksi.
• Selvät kehittäjien tiedossa olevat pelisäännöt.
Ohjelmistotestaus -09
© Antero Järvi, Tuomas Mäkilä
It-laitos / TY
10