docTestaajanKommunikoin..
download 
Report 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
