Dokumentaatiota voi tehdä monella tavalla ja monesta syystä. Byrokraattisten asiakasorganisaatioiden kanssa työskennellessä saattaa mieleen hiipiä ajatus, että dokumentaatiota tehdään koska asiakas haluaa sellaista. Myös laatujärjestelmät saattavat asettaa vaatimuksia dokumentaatiolle, jota sitten tehdään laatujärjestelmän itsensä takia. Joskus dokumentointi saatetaan kokea uuvuttavana ja turhana, ja tällöin helposti käy niin, että dokumentti tehdään vain jonkun muun toiveen täyttämiseksi arkistoihin pölyyntymään.
Toisaalta dokumentointiin voi ottaa myös toisenlaisen näkökulman. Millaisia asioita on tarpeen kirjata muistiin, jotta en unohtaisi, mitä on sovittu? Millaisia asioita on tarpeen kirjata muistiin, jos joku muu joutuukin yllättäen ottamaan projektista kopin? Millaisia asioita on tarpeen kirjata muistiin, jos asiakkaan kanssa täytyy jälkikäteen vääntää kättä siitä, onko sovitut asiat tehty vai ei? Entä kun sovitaan muutoksista, miten dokumentaatio saadaan pysymään ajantasalla?
Suunnitteludokumentaatio
Esimerkiksi testaussuunnitelman tarkoitus voi olla kuvata asiakkaalle käytettävä testausprosessi, tai asettaa reunaehdot muille projektin osapuolille siitä, millaisten asioiden on toteuduttava jotta testaaja voisi tehdä työnsä. Itse olen kuitenkin kokenut, että ellei joku näitä asioita erikseen pyydä, on turha odottaa että kukaan muu kuin testaaja itse koskaan lukisi koko dokumenttia. Siksi se kannattaa pitää kevyenä ja kirjoittaa siitä näkökulmasta, että se parhaalla mahdollisella tavalla tukee testaajan työskentelyä.Testaussuunnitelma voisi siis sisältää seuraavanlaisia tietoja:
- Mistä löytyy oleellinen dokumentaatio (vaatimukset, käyttötapaukset, visuaaliset suunnitelmat yms.) johon testauksen on perustuttava? Jos dokumentaatiota ei ole, se voi kertoa lyhyesti, millaista tuotetta ollaan tekemässä, kenelle ja miksi. Dokumentissa voi olla myös listaus projektin vastuuhenkilöistä, joilta kysyä apua ongelmatilanteissa tai mielipidettä asioiden merkittävyydestä, mikäli nämä asiat eivät ole muuten ilmeisiä.
- Hahmotelma testauksen strategiasta, hyödyllisistä menetelmistä ja työkaluista.
- Pohdintaa riskeistä, joiden realisoitumisen mahdollisuuksia testauksella on syytä minimoida, sekä korkean tason jaottelua näkökulmista, joista testausta on tarpeen tehdä. Ideoita testauksen suunnitteluun löytyy esim. James Bachin ja Michael Boltonin kehitelemästä FEW HICCUPPS-mallista ja James Bachin heuristisesta testausstrategiamallista.
Tärkeää testauksen suunnittelussa on tavoitteiden asettaminen testaukselle. Tavoitteita on hyvä tarkastella uudelleen projektin edetessä, ja sitä kautta tarvittaessa myös päivittää testaussuunnitelmaa. Tekemistä on suunnattava prioriteettien ja riskien näkökulmasta paitsi testauksen alkaessa myös matkan varrella.
Testausvaiheen dokumentaatio
Testauksen aikana syntyvästä dokumentaatiosta keskeisimpiä ovat bugiraportit. Aina niitäkään ei kaikkia tarvitse dokumentoida, vaan jotkut asiat voi hoitaa esim. suullisesti. Käytännössä monet bugit ovat kuitenkin sellaisia ettei niitä ole mahdollista heti korjata, ja silloin huolellinen dokumentointi on tarpeen jotta kehittäjä osaisi vaikkapa viikon kuluttua korjata ongelman ja mahdollisesti toinen testaaja tarkistaa korjauksen onnistumisen. Neuvoja bugiraportointiin löytyy esim. Cem Kanerin Bug Advocacy-mallista.Bugiraporttien lisäksi voi olla tarpeen tehdä muistiinpanoja tai pieniä ohjeita hankalista asioista. Ne voivat olla esim. uusia checklistejä, lyhyitä käyttöohjeita asioihin jotka ovat itselle olleet vaikeita, huomioita toiminnoista jotka kaipaavat erityistä huomiota testaajalta esim. siksi että tuntuvat erityisen herkiltä hajoamaan muiden muutosten myötä, tai uusia ajatuksia alueista, joita testaajan olisi tarpeen tutkia enemmän kuin testaussuunnitteluvaiheessa on tullut ajateltua.
Näiden dokumenttien ensimmäinen hyöty on se, että testaajana voit antaa dokumentoitavan ajatuksen unohtua ja keskittyä siihen tehtävään, joka sinulla oli oikeasti työn alla. Kun sinulla on taas aikaa miettiä, mitä lähtisit tutkimaan seuraavaksi, tai joudut välillä siirtymään toisen projektin pariin ja sitten palaamaan taas nyt käsillä olevaan, kaivat vain esiin muistiinpanosi ja käyt hommiin käsiksi.
Toinen hyöty on se, että joskus voit joutua siirtämään projektisi toiselle henkilölle. Ei ole mahdollista luoda sellaista dokumentaatiota, jonka joku toinen pystyisi lukemaan ja sisäistämään, ja joka täydellisesti korvaisi kokemuksen tuotteesta ja projektista, mutta on paljon asioita, joiden löytyminen dokumentaatiosta helpottaa merkittävästi kärryille pääsemistä.
Lisäksi joskus asioiden merkitystä on helpompi arvioida, kun niihin ottaa vähän etäisyyttä. Kiinnostava bugi on aina hauskaa päästä raportoimaan, mutta joskus kysymys on asioista, joilla ei oikeasti ole merkitystä loppukäyttäjien kannalta, ja silloin voi olla parempi olla käyttämättä kehittäjän aikaa asiasta keskustelemiseen. Havainnon voi silloin vain kirjata itselleen ylös ja antaa asian hautua jonkin aikaa, onko tässä asia jonka tarkempaan tutkimiseen on syytä panostaa, ja miten se suhtautuu merkittävyydessään muihin tarjolla oleviin tehtäviin.
Testausvaiheen materiaali muodostuu tehtävänannoista, testaukseen käytettävistä aineistoista, työkaluista, sekä matkan varrella opituista asioista.
Analysointi
Jotta tekemistä voisi suunnata uudelleen ja lopputuloksista antaa relevantteja raportteja, on omaa työtä analysoitava jollain tapaa. Tähän voi käyttää esimerkiksi nk. proof-menetelmää, jota voi käyttää jokaisen testisession päätteeksi oman työn suuntaamiseen, mutta myös apuna siirrettäessä vastuu testauksesta toiselle. Menetelmässä arvioidaan testausta viidestä näkökulmasta: kuinka käytit ajan, mitä löysit, tarvitsetko apua tai työkaluja, onko vielä lisää tehtävää ja oliko tehtävänanto järkevä,Raportointi
Suhteellisen yksinkertainen mutta vaikuttava ja informatiivinen tapa raportoida testausta on jaotella testauksen kohde muutamiin toiminnallisiin ja ei-toiminnallisiin osa-alueisiin, joihin liittyen testaaja tai projektitiimi antaa omat laatuarvionsa. Ei-toiminnallisia osa-alueita voivat olla esim. yleinen toimivuus, käytettävyys, luotettavuus, suorituskyky, turvallisuus ja ylläpidettävyys.Laatuarvioita annetaan kolmiportaisin asteikoin, joita voidaan käyttää useampia yhtä aikaa arvion parantamiseksi. Laadun (hyvä / ei hyvä muttei kelvotonkaan / selkeästi keskeneräinen) lisäksi arvioidaan esitettävien käsityksien perusteluja (olenko varma väitteestä testattuani hyvin / olenko testaillut jonkin verran / oletanko vain) sekä tarvittaessa mielikuvaa ko. kokonaisuuden stabiiliudesta (eli kuinka luotettava nyt annettu laatuarvio olisi huomenna tai viikon päästä).
Testikattavuutta kannattaa pohtia siitä näkökulmasta, minkä tyyppiset asiat ovat merkityksellisiä, ja mistä raportointi on tärkeää. Ihmiset ovat erehtyväisiä, joten aina on riski että jokin testausta vaativa osa-alue on unohtunut kokonaan tarkastelusta.
Ei kommentteja :
Lähetä kommentti