Riippumatta projektista, organisaatiosta tai lähestymistavasta dokumentaatiolle on aina paikkansa. Hyvä dokumentaatio on suuri apu, sillä se tarjoaa hyödyllisen tallenteen lähestymistavasta, laajuudesta, suunnitelmista, suunnitelmapiirustuksista sekä analyysi-, kehitys- ja testaustoimien tuloksista.
Tässä artikkelissa käsittelen seuraavia aiheita:
- Dokumentaation arvo
- Mallipohjien ja kopioinnin vaarat
- Testidokumentaation tyypit
- Ohjeita dokumentaation suunnitteluun
Aloitetaan.
Dokumentaation arvo
Rakenteisissa projekteissa asiakirjoja pidetään yleensä itsenäisinä toimitettavina tuotoksina. Ketterissä tai jatkuvan toiminnan ympäristöissä dokumentaatiota voidaan tuottaa enemmän tai vähemmän arvokkaana sivutuotteena.
Asiakirjojen kirjoittaminen saattaa olla teknisten kirjoittajien ensisijainen tehtävä, mutta useimmille ammattilaisille se on vaivalloista – olipa siitä kuinka paljon hyötyä tahansa. Vaikka asiakirjojen kirjoittaminen voi joidenkin mielestä olla tylsää, dokumentaation todellinen ongelma on se, että monissa yhteyksissä suurin osa dokumentaatiosta on yksinkertaisesti ajanhukkaa. Siitä on vähän hyötyä, se on vanhentunutta, epätarkkaa – tai kaikkea näitä.
Jokainen testauspäällikkö on kirjoittanut testaussuunnitelmia, joita ihmiset eivät lukeneet tai joihin he eivät sitoutuneet. Testaajat kirjoittavat valtavia määriä testisuunnitelmia, testiskriptejä ja raportteja, ja ainoa sidosryhmille hyödyllinen sisältö on alussa tai lopussa oleva yhden sivun yhteenveto.
Tämä johtuu yleisistä dokumentaatioon liittyvistä ongelmista, joita kohtaamme sekä suurissa että pienissä projekteissa. Jokaisen kirjoittamamme asiakirjan kohdalla meidän on vastattava useisiin kysymyksiin:
- Millainen asiakirja on kyseessä? Käytäntö tai strategia, lähestymistapa tai suunnitelma, suunnitelma tai toteutus taikka lopputulos ja sen tulkinta?
- Mikä on asiakirjan tavoite?
- Mitä sisältöä tavoitteen saavuttaminen edellyttää?
- Mitä tietolähteitä sisällön luominen edellyttää?
- Jos asiakirjan on muututtava ajan myötä, miten sitä ylläpidetään?
- Millaista yksityiskohtaisuuden tasoa tarvitaan?
Have an account? Log In
Mallipohjien ja kopioinnin vaarat
Jos projektissasi päätetään, että tietty asiakirja, esimerkiksi järjestelmän testaussuunnitelma tai riskirekisteri, tarvitaan, on houkuttelevaa etsiä internetistä valmis mallipohja tällaisia (ja monia muita) asiakirjatyyppejä varten.
Jotkin mallipohjat saattavat väittää noudattavansa jotakin standardia tai käytäntöä ja että niitä on ladattu ja käytetty tuhansia kertoja. Joskus mallipohja saattaa vaikuttaa sopivan tarkoitukseesi täydellisesti. Kuten tulemme näkemään, vaikka sisällysluettelo näyttäisi kattavalta, se voi aiheuttaa ongelmia.
Voi myös olla, että sinä tai joku muu yrityksessäsi on laatinut vastaavan asiakirjan aiempia projekteja varten. Saatat harkita tämän asiakirjan kopioimista ja uudelleennimeämistä, vanhaan projektiin viittaavien kohtien muuttamista ja sisällön muokkaamista sopivaksi.
Varoitus: Kokemukseni riippumattomana arvioijana on, että tämä on erittäin yleistä ja usein todellinen ongelma.
Ensinnäkin on yleensä räikeän ilmeistä, että tekstiä on kopioitu tai muokattu. Tekstissä käytetty kieli vaikuttaa usein irralliselta projektista, ja siinä on kaikkialla aukkoja sekä tarpeetonta tekstiä. Miksi näin on?
Valmiin mallin tai olemassa olevan asiakirjan käyttäminen lähteenä sisältää useita riskejä:
- Se vaikuttaa kattavalta, mutta se saattaa sisältää aiheita, jotka eivät ole tarkoituksenmukaisia, ja jättää pois muita olennaisia aiheita.
- Se tarjoaa asiakirjalle otsikot, mutta ei lainkaan ohjeita siitä, millainen sisältö kuhunkin otsikkoon sopii.
- Se saattaa sisältää uudelleenkäytettävältä vaikuttavaa tekstiä, joka on kopioitu muuttamattomana aiemmasta, asiaan liittymättömästä projektista, mutta teksti saattaa antaa väärän vaikutelman tai olla virheellistä tai puutteellista.
Mallien käyttäminen otsikoiden ja perusmuotoilun rakenteen saamiseksi voi olla hyödyllistä, mutta mallien suurin ongelma on tämä:
Malleihin liittyvä houkutus on luottaa niihin liikaa ja kirjoittaa sitten eri osioihin ympäripyöreää tekstiä. Saatat nimittäin ajatella, että asiakirja vain täyttää yhden ”valintaruudun” eikä kukaan kuitenkaan lue sitä. Mallien riskinä on, että lopetat ajattelemisen ja kirjoitat asiakirjan, jolla on vain vähän arvoa.
Testidokumentaation tyypit
Tässä osiossa tarkastelemme testidokumentaation eri muotoja ja pohdimme joitakin näkökohtia jäsennellyissä tai ketterissä/jatkuvissa projekteissa verrattuna perinteiseen vesiputousmalliin.
Testauksen keskeiset asiakirjat kuuluvat yleensä seuraaviin luokkiin:
- Testauspolitiikka ja -strategia (joskus nimeltään päätason testaussuunnitelma)
- Testauksen määrittely (hämmentävästi myös nimillä spesifikaatio tai testaussuunnitelmat)
- Testauksen suunnittelu
- Testitapaukset
- Testimenettelyt tai komentosarjat
- Testauksen suoritus
- Aikataulu
- Loki
- Testausraportti
Edellä esitetty asiakirjatyyppien valikoima kattaa testausprosessin määrittelyn, määrittelyn ja suorituksen keskeiset toiminnot sekä raportoinnin.
On olemassa useita muita testaukseen liittyviä asiakirjoja, joihin byrokraattisemmissa ympäristöissä kuuluisivat testausympäristöjen määrittelyt ja hallintaprosessit, hyväksymismenettelyt, häiriönhallintaprosessit ja niin edelleen (käsittelemme häiriönhallintaa tulevassa artikkelissa).
Edellä mainituista puuttuu ilmeisesti myös testausaktiviteettien yleinen suunnitelma tai aikataulu. Aikataulu ei oikeastaan ole testausasiakirja, vaan se on osa jäsennellyn projektin yleistä projektisuunnitelmaa (käsittelemme myös aikataulusuunnittelua tulevassa artikkelissa, joten pysy kuulolla!).
Käytäntö, strategia ja päätason testaussuunnitelma
| Tarkoitus |
|
| Sisältö |
|
| Lähteet |
|
| Ylläpito |
|
Ketteryys/jatkuvuus huomioon ottaen
Esimerkiksi Scrumia käyttävien ketterien projektien testausstrategiat ovat todennäköisesti melko lyhyitä ja koostuvat vain muutamasta sivusta (jos niitä dokumentoidaan lainkaan). Testausprosessissa ei välttämättä ole vaiheita, mutta siinä määritellään todennäköisesti testaus eri tasoilla. Esimerkiksi:
| |
Testauksen määrittely (suunnittelu, testitapaukset ja menettelyt)
| Tarkoitus |
|
| Sisältö |
|
| Lähteet |
|
| Ylläpito |
|
Ketteryys/jatkuvuus huomioon ottaen
Testauksen määrittelyn alueella ketterä lähestymistapa eroaa rakenteisista projekteista kaikkein selkeimmin.
Mahdollisesti ominaisuuksiin niiden toimituksen aikana keskittyvät testaajat eivät luo lainkaan dokumentaatiota. Tämä on asianmukaista esimerkiksi silloin, jos ominaisuuksien testausta varten on olemassa koko järjestelmän kattava ohje tai peruskirja.
Todennäköisemmin kunkin ominaisuuden testaamista varten laaditaan lyhyt peruskirja tutkivaan testausistuntoon. Peruskirja on lyhyen tutkimusjakson suunnitelman kaltainen. Peruskirjassa yksilöidään tyypillisesti:
| |
Testien suoritus (aikataulu, loki)
| Tarkoitus |
|
| Sisältö |
|
| Lähteet |
|
| Ylläpito |
|
Ketteryys- ja jatkuvuusnäkökohdat
Jos ketterissä/jatkuvissa projekteissa ei sitouduta testimäärittelyasiakirjoihin, puutetta korvataan jossain määrin kannustamalla testaajia pitämään parempia testien suoritusten lokeja.
Kun testausta tehdään istunnoissa testausohjeiden perusteella, testaajan odotetaan tekevän hyvät muistiinpanot suorittamistaan testeistä. Erityisiä testilokityökaluja, jotka ovat enemmän kuin muistikirjoja, on vähän, joten monet testaajat käyttävät yksinkertaisia tekstieditoreja, muistiinpanosovelluksia tai paperisia muistikirjoja.
Lokeja käytetään yleensä kaiken merkittävän toiminnan ja havaintojen kirjaamiseen istuntojen aikana. Tyypillinen tutkivan testauksen loki sisältäisi esimerkiksi seuraavia asioita:
| |
Testiraportti
| Tarkoitus |
|
| Sisältö |
|
| Lähteet |
|
| Ylläpito |
|
| Ketteryyttä ja jatkuvuutta koskevat näkökohdat Testiraportin tarkoitus ketterässä projektissa voi olla yhden iteraation tai sprintin kattaminen, julkaisua varten tehtävä testaus tai ylemmän tason testivaihe, kuten integraatio- tai koko järjestelmän hyväksyntätestaus. Tarkoitus on sama kaikissa tapauksissa. Suuri osa testiraportin sisällöstä tulee testaajien käyttämistä työkaluista tai heidän muistiinpanoistaan. Tulosten sanallisen yhteenvedon kirjoittaa testausvastaava tai pienemmän testivaiheen tapauksessa testaaja. Kuten tavallista, raportti on todennäköisesti vähemmän muodollinen, ja käytettävissä voi olla vähemmän raakadataa, joka muodostaisi perustan kehittyneille analyyseille. Iteraation tai iteraatioiden aikana työkalussa tai julkisella Kanban-taululla saatetaan kirjata esimerkiksi ominaisuuksien tai tarinoiden toimittaminen, testaaminen ja käyttäjien hyväksyntä. Näin sidosryhmät pysyvät ajan tasalla etenemisestä koko iteraation ajan, eikä muodollista raporttia tarvita yhtä paljon testausjakson lopussa. Etenemisen näkyvyys on keskeinen huolenaihe ketterille tiimeille. Esimerkiksi Scrum-taulun ympärillä pidettävissä säännöllisissä, mahdollisesti päivittäisissä tilannepalavereissa tiimin jäsenet jakavat käsityksensä etenemisestä, esittävät toisilleen kysymyksiä ja sopivat jatkuvasti yhteisestä tilanteesta ja seuraavista vaiheista. Näin muodollista testiraporttia ei ehkä koskaan tarvita, koska tiimi on aina tietoinen tilanteesta ja ajan tasalla. Jos testaajat pitävät kirjallisia muistiinpanoja sessioidensa toiminnasta, automatisoitujen raporttien laatimiseen ei ole analysoitavaa dataa, joten sessio- ja etenemisraportointi voidaan esittää julkisella ja visuaalisella tavalla. Tämä edellyttää testaajilta suurta kurinalaisuutta ja hyviä viestintätaitoja. Testausvastaavan tai -päällikön on laadittava sidosryhmille vastaavasti informatiivinen raportti suullisten raporttien perusteella. | |
More Articles
Muutamia neuvoja
Projektien dokumentointi on arkaluonteinen aihe testaajille ja muille projektiryhmän jäsenille.
Seuraavat asiat kannattaa ottaa huomioon dokumentointia suunniteltaessa.
- Dokumentilla on oltava selkeästi määritelty tarkoitus ja kohdeyleisö. Jos kohdeyleisösi ei tarvitse dokumenttia, se ei lue sitä. Jos dokumentti ei vastaa heidän omia tavoitteitaan, he eivät sitoudu siihen.
- Toiminnan dokumentointi on yleensä parempi tehdä ennen sen suorittamista tai sen aikana. TDD:ssä testit esimerkiksi kirjoitetaan ennen koodia. Testisessioiden lokit tulisi tallentaa session aikana, ei kirjoittaa jälkikäteen.
- Testauksen jonkin osa-alueen tallentamiseen tarvittava olennainen data voi olla vähäistä. Esimerkiksi muistikirjaan kirjattu testi saattaa riittää testaajalle, mutta sitä ei ole helppo analysoida. Ehkä yksinkertainen tekstitiedosto, jossa on merkintöjä, olisi yhtä nopea laatia, mutta sitä voisi myös analysoida mukautetulla työkalulla.
- Testimenettelyt eivät välttämättä ole lainkaan tarpeen, jos testaajat tuntevat testattavan järjestelmän hyvin. Ehkä vain testitavoite tai testausperuskirja riittää. Valmistellut testitapaukset voidaan dokumentoida laskentataulukossa vain vähäisin tiedoin.
Lopuksi
Jos laadit sidosryhmillesi kattavan dokumentaation eivätkä he lue sitä, syynä on se, etteivät he näe siinä arvoa.
On parempi antaa sidosryhmän edustajalle tyhjä paperiarkki, lisätä yhdessä dokumenttiin aiheet, jotka hänen tarvitsee nähdä, ja edetä siitä. Hän saattaa pyytää valtavan määrän sisältöä, vaikka todellinen tarve olisi melko yksinkertainen. Kysy jatkuvasti: ”miksi he haluavat tämän?”
Kiitos lukemisesta. Liity seuraamme ensi kerralla, kun kääritään hihat ja aloitetaan testauksen suunnittelu.
Tilaa The QA Lead -uutiskirje saadaksesi ilmoituksen, kun sarjan uudet osat julkaistaan. Nämä julkaisut ovat otteita Paulin Johtaminen testauksessa -kurssista, jota suosittelemme lämpimästi, jos haluat perehtyä tähän ja muihin aiheisiin syvällisemmin. Jos teet niin, käytä ainutlaatuista kuponkikoodiamme QALEADOFFER saadaksesi $60:n alennuksen koko kurssin hinnasta!
