Artikkelin on kirjoittanut Maaret Pyhäjärvi. Tämä teos on lisensoitu Creative Commons Nimeä-Epäkaupallinen 4.0 Kansainvälinen -käyttöluvalla.
Creative Commons -käyttölupa

Testaus on investointi laatutietoon. Varsin yleinen laatutiedon muoto on havainnot – huomiot siitä että jokin ei ehkä toimi ihan niinkuin sen toivoisi. Testaajat puhuvat usein bugeista tai virheistä – jostain sellaisesta, johon reagoimalla saadaan ongelma käsiteltyä. Usein niitä on myös monta, ja aina ei ole ihan selvää kuka viime kädessä hoitaa havainnon käsittelystä seuraavan askeleen. Niinpä keskeistä testausasiaa on havaintokirjausten laatiminen.

Havaintokirjaustietokannat tutuksi

Monella projektilla on käytössään jonkinlainen sovittu kanava havaintojen raportointiin. Testauksen vähänkin vakiinnuttaessa jalansijaa organisaatiossa, kanavaksi usein muotoutuu havaintokirjaustietokanta. Monet testaajat ovat tottuneet Quality Centerin Defects -osioon tai Jiraan tässä tarkoituksessa. Työkalujen valikoima on laaja ja tällä alueella on käytössä erityisen paljon kotikutoisia järjestelmiä, jotka tukevat juuri sitä oman organisaation tapaa ja tietotarvetta. Asiakasorganisaatioiden testausta tarkasteltaessa tulee usein vastaan organisaatioita, joissa näitä tietoja kerätään excel-taulukoihin. Havaintoja myös lähetellään sähköpostilla tai välitetään suusanallisesti tai kerätään seinälle post-it lappuina – tärkeää on että tieto kulkee ja palautteeseen voidaan reagoida. Jos listat alkavat kasvaa pidemmiksi ja asioita ei ehditä käsitellä välittömästi, usein työkalut muodostuvat lähes välttämättömiksi listojen ja käsittelyvaiheiden hallitsemiseksi.

Jokainen yksittäinen havainto tarvitsee käsitellä. Jotkin johtavat korjauksiin, jotkin ohjeistuksen parantamiseen ja jotkin henkilökohtaisiin oivalluksiin siitä mitä organisaatio pitää ja ei pidä tärkeänä. Käsittely on usein ryhmätyötä, jossa eri osapuolet tuovat näkemyksensä yhteiseen pöytään. Joskus taas ryhmätyö hoituu enemmän ketjuna kuin aitona yhdessä tekemisenä: yksi raportoi (havaintokirjaus on avoin), toinen miettii ratkaisun (havaintokirjaus on ratkaistu) ja alkuperäinen raportoija tarkistaa ratkaisun (havaintokirjaus on suljettu). Jos ratkaisu ei ollutkaan riittävä, esim. korjaus ei poistanut ongelmatilannetta, ketju palaa alkuun. Monen organisaation tilanteissa havaintojen käsittelyn ketju pitenee eri osapuolien tuodessa kokonaisuuteen oman panoksensa. Käsittelyketjun hallinnassa havaintokirjaustietokannat ovat usein varsin keskeinen työväline.

HavaintojenElinkaari

Kuva. Havaintojen elinkaari lyhyimmillään

 

Hyvät havaintoraportit

Lähtökohtaisesti havaintoraportit ovat tekijöidensä näköisiä. Havaintokirjauksien selkiyttäminen ja kirjallisesti viestiminen niin että lukevat osapuolet – aikataulusta ja ajankäytöstä kenties päättävä projektipäällikkö, ohjelmiston muuttamista toteuttava toteuttaja – ymmärtävät mitä sanotaan on haastavaa. Havaintokirjauksia kirjoitetaan useille yleisöille, ja usein tunnistettavissa oleva piirre on että epäselvästi ilmaistut havaintokirjaukset, joista puuttuu oleellisia tietoja jäävät reagoimatta. Testaajan vastuuna on myös tarkistaa tärkeiden asioiden suhteen, että viesti tärkeydestä meni perille eikä luottaa toisen osapuolen lukevan asiaa havaintokirjauksesta. Useita esimerkkejä löytyy tilanteesta, jossa tuotantoon siirryttäessä pahoja bugeja on ollut havaintotietokannassa tunnettuina ja korjaamattomina mutta ei ymmärrettyinä.

Testaaja, joka ei osaa raportoida havaintoja on kuin jääkaapin valo, joka on päällä vain silloin kun kaapin ovi on kiinni. –Kaner, Bach, Pettichord. Lessons Learned in Software Testing. 2001.

Jos testaaja pystyy kertomaan että käytti ohjelmaa ja se ei toiminut ilman tarkempaa kuvausta, vaihtoehtojen kirjo on vielä liian laaja ratkaistavaksi. Testaajan odotetaan kertovan tarkemmin missä ympäristössä testasi, millä testiaineistolla, mitä nappeja painoi ja mitä näki ja odotti näkevänsä. Ja vielä tarkistavan, että jos asian tekee toistamiseen, tapahtuuko se uudelleen. Havaintokirjaukseen tarvitaan sellaiset tiedot, joiden avulla ongelma on paikallistettavissa, sillä ilman paikallistamista ongelman korjaaminen on vaikeaa ellei mahdotonta. Joskus paikallistamiseen riittää että kerrotaan mihin aikaan ongelma nähtiin – tarkemmat tiedot selvittelyn alkuun saamiseksi löytyvät tällä perusteella lokeilta.

Hyvä käytäntö usein on kirjoittaa havaintoraportti askel askeleelta käyttötilanne kuvaten. Otsikkoon kuvataan mahdollisimman selkeästi mikä ja missä on ongelmana yhden rivin tiivistelmänä. Pelkän otsikon avulla tehdään päätöksiä havaintokirjaukseen reagoinnista, eli sen selkeys on tärkeää. Kuvauksessa kerrotaan mitä teki askeleittain. Askeleiden päätteeksi kerrotaan mikä oli ongelma ja mitä itse pitäisi odotettuna toimintana ja miksi. Usein otsikon ja kuvauksen lisäksi täytettävänä on vaihteleva joukko erilaisia kenttiä kuten prioriteetti ja vakavuus sekä erilaisia havainnon luokittelutietoja. Ja kuvaruutukaappaus usein kertoo enemmän kuin mitä pelkillä sanoilla voi ilmaista.

Paremmat havaintoraportit

Hyvä kirjaaminen vaatii pohjatyötä. Cem Kanerin Bug Advocacy -kurssilta löytyy mainio tiivistelmä pohjatöistä:

  • Toista (Replicate it). Varmista että tiedät itse miten voit saada ongelman toistumaan uudelleen. Jos et tiedä, etsi tilannetta sen perusteella mitä olit tekemässä. Ja jos et saa selville, kerro se raportissasi että korjaaja ei odota asian toistuvan helposti ja tietää sen vaativan huomiota.
  • Eristä (Isolate it). Sen sijaan että kerrot kaikki askeleet ja arvot, testaa lisää selvittääksesi mikä on minimitapa nähdä kuvaamasi ongelma. Ehkä jotain tietoa ei tarvitsekaan täyttää? Tai ehkä on oleellista että jokin tieto on täyttämättä? Ehkä toiminnallisuutta pitää käyttää tiettyä reittiä päästäkseen kiinni tähän ongelmaan etkä olisi nähnyt ongelmaa jos olisit käynnistänyt toiminnon toisesta mahdollisesta paikasta? Ymmärrä ongelma ja sen laajuus, jotta osaat raportoida sen.
  • Isonna (Maximize it). Älä tyydy ongelman ensimmäiseen ilmentymään, vaan tutki lisää. Onko kenties jatkossa tästä ongelmasta laajempia seurauksia? Jos esimerkiksi tallennettiin tiedot puutteellisesti, mitä tapahtuu kun puutteellisia tietoja koittaa käyttää?
  • Yleistä (Generalize it). Valitse raportointia varten tapa, joka korostaa havainnon merkitystä. Valitset yleensä jonkin esimerkin, mikä on esimerkki, jossa ongelma näyttäytyy pahimmassa mahdollisessa valossa? Entä onko ongelma vain tietyssä ympäristössä, tietyllä käyttäjällä, tietyllä aineistolla, vai yleisemmin kaikilla?
  • Ulkoista (Externalize it). Aseta ongelma kokonaiskehikkoon sen tärkeyden ja korjauskustannuksen osalta. Kuinka merkittävästä ongelmasta on kyse kokonaiskuvaa tarkastellen?
  • Lopuksi sano se selkeästi ja asiallisesti (And say it clearly and dispassionately). Kun käytössäsi on riittävät tiedot, kirjoitat havaintokirjauksen neutraalisti. Jos tietojen pohjalta asia on oleellinen ja tämä välittyy lukijalle, on odotettavissa korjaus. Jos asia on oleellinen mutta tiedot eivät välittyneet, saattaa olla hyvä täydentää kirjallista raporttia vielä keskustelulla.

Nähtyäsi ongelman, aikaa voi kulua merkittävässä määrin ennen kuin olet pisteessä jossa kirjaat havaintokirjauksen tietokantaan. Panostaminen kannattaa, jos nopealla toiminnalla saa aikaan hämmennystä mutta ei etuja. Testauksen tarkoituksena on tuottaa tieto, johon voi reagoida. Monenlaiset syyt silti ohjaavat projekteissa siihen että reagointia viivästetään seuraaviin projekteihin – tai hyväksytään ohjelmiston kummallisuuksina.

Havaintokirjaukset ovat testaajan sormenjälki.  Niiden on tarkoitus auttaa reagoimaan sovelluksen ongelmiin. Jos reagointi on vaikeaa, voi miettiä havaintokirjausten selkiyttämistä ja kohdistamista oikealle yleisölle.

Havaintokirjauksiin liittyy merkittävä työpanos. Kun testaaja pysähtyy selvittelemään havaintokirjauksen arvoista asiaa, hän ei edistä testauksen kattavuutta vaan keskittyy tuottamaan tietoa kohdatusta ongelmasta. Tyypilliseen suoraviivaiseen havaintokirjaukseen vierähtää helposti 10 minuuttia. Joidenkin oireiden kanssa saattaa viettää päiviä ennen kuin pystyy asian kirjaamaan korjaukseen johtavalla tasolla. Kun havaintokirjauksia on paljon, niihin käytetty työmäärä on pelkästään kirjaamisen osalta merkittävä.

Jos kirjaukset ovat epäselviä ja jokaisen osalta tulee lisätietopyyntöjä, työpanos kasvaa. Ensin arvioidaan lähdetäänkö havaintoon yleensäkään tässä projektin vaiheessa reagoimaan eli onko ongelma tärkeä. Tässä työssä kaivataan argumentteja ongelman vakavuudesta ja ilmenemismuodoista, joita vähiten halutaan sovellukseen jättää. Sen jälkeen korjaaja koittaa saada kirjauksesta riittävät tiedot ongelman korjaukseen – perkaamalla (debugging) tarkemmin kohtaa jossa ongelma ilmenee. Jos tietoja puuttuu, havaintokirjaus palaa usein takaisin tekijälleen täydennettäväksi.

Havaintokirjausta laativa testaaja tasapainottelee itse käyttämänsä ajan – joka on pois testauksen edistämisestä – ja muiden käyttämän ajan välillä. Eri organisaatioilla on hyvin erilaisia odotuksia siitä mitä testaajan odotetaan selvittävän. Eräässä organisaatiossa vietiin testaajan rooli niin pitkälle, että se sisälsi myös korjattavan koodikohdan etsimisen. Yleensä kuitenkin ongelman toistokaavan kuvaaminen riittää. Ja joissain organisaatioissa ongelmasta mainitseminen on riittävää aloittamaan yhteisen selvityksen tarkemmin ongelman luonteesta.

Vaihtoehtoiskustannuksella tarkoitetaan tapaa ajatella kustannuksia tavalla, joka tiedostaa että jokaisella valinnalla on kääntöpuolensa: ajan käyttäminen yhteen asiaan on pois jostakin toisesta. Kun raportoimme useita pieniä ei-korjattavia ongelmia, raportointiaika on pois ajasta, jolla olisi voitu löytää yksi tärkeä ongelma. Kaikki tieto laadusta ja sen puutteista ei ole yhtä tärkeää. Pelkkä ongelman tunnistaminen ei vielä paranna laatua – vasta korjaus muuttaa tilannetta. Parhaat testaajat eivät ole niitä jotka löytävät eniten ongelmia, vaan niitä, jotka saavat löytämänsä ongelmat myös korjatuksi – oleellisuuden kautta.

Vastaavasti voi miettiä mikä on tehokkain tapa raportoida virheitä. Olisiko paritestaus kehittäjän kanssa, jossa suusanallisesti tiedot välittyvät ehkä toimivaa? Voisiko havainnon raportoida automaatiotestillä, joka menee läpi vasta kun korjaus on toteutettu? Tai sen sijaan että kerätään suuri joukko ongelmia korjaajan työjonoon voisiko havaintoja visualisoida havaintobudjetilla, jossa maanantain budjettiin ei kirjata uusia havaintoja post-it lapuilla ennen kuin edelliset löydökset on käsitelty tai korjattu? Tässä viimeisessä ajatuksena on korostus sille että suuri havaintomäärä aiheuttaa testaukselle väistelyä ja hidastaa etenemistä, ja ehkä kannattaa jatkaa vasta kun edellisiin on saatu reagoitua. Tarvitseeko ongelmia kirjata yleensäkään tietokantaan jos korjauksen saa huikkaamalla naapurille saman tien?

Havaintojen tilastoinnin vaaroista

Havaintokirjaukset houkuttavat usein laskemaan. Kuinka monta tärkeää, kuinka monta korjattua. Pahimmillaan tilastointia käytetään asettamaan testaajat ja kehittäjät vastakkainasetteluasemaan – yhden tavoitteena on löytää ongelmia ja toisen tavoitteena että ongelmia ei löytyisi. Määrät kertovat tekemättömästä, keskeneräisestä työstä – korjauksista ja niiden tarkistamisesta. Niitä ei pidä käyttää ihmisten arviointiin, etenkään irrotettuna kontekstistaan, jossa tehdään muutakin kuin kirjataan havaintoja.