QA:sta käytävissä keskusteluissa käsitellään usein suuria käsitteitä ja aiheita. Paljon ammattisanastoa, valkoisia papereita ja TED-puheita. Keskustelu muuttuu nopeasti melko abstraktiksi. Ja myönnetään se: usein se ei ole kovin merkityksellistä niiden käytännön esteiden kannalta, joita työskentelevät QA-tiimit kohtaavat päivittäin.
Siksi on joskus hyödyllistä hidastaa hieman ja keskittyä alan vaatimattomampiin osa-alueisiin. Tässä tapauksessa testidokumentaatioon. Aihe vaikuttaa yksinkertaiselta, mutta kuten kaikissa ohjelmistokehitykseen liittyvissä asioissa, lattialautojen alla vaanii hirviöitä.
Kysymys siitä, miten ja kuinka paljon testidokumentaatiota pitäisi kirjoittaa, johtaa QA:n lähes välittömästi Catch-22-tilanteeseen. Jos dokumentaatiota on liian vähän, on vaikea tietää, missä kokonaisuuden suhteen ollaan. Vielä vaikeampaa on siirtää testaustehtäviä eri resursseille tarpeen mukaan ja säilyttää testauksen johdonmukaisuus. Mutta jos dokumentaatiota on liikaa, niin — hetkinen. Eihän testidokumentaatiota voi koskaan olla liikaa?
Vai voiko?
Olen usein nähnyt QA-tiimien tunnollisesti ja ahkerasti tarttuvan sankarilliseen tehtävään dokumentoida testinsä täydellisesti. Yhtä julkaisua varten. Sen jälkeen dokumentaatio tuppaa jäämään sivuun. Se kerää digitaalista pölyä jossain verkossa. Eikä syynä ole se, että QA-tiimi olisi lakannut pitämästä sitä tärkeänä. He ovat vain täysin uupuneita siitä työmäärästä, joka vaaditaan sen päivittämiseen seuraavaa suurta julkaisua varten.
Tämä johtuu siitä, että innostuksissaan QA-tiimi kirjoitti uskomattoman yksityiskohtaisia testikuvauksia ja pilkkoi asiat maanisen mikroskooppisen tarkkuuden tasolle. He loivat erillisen testidokumentaation jokaiselle yksittäisen ominaisuuden tai käyttäjän toiminnon näkökohdalle tai määritteelle. He tuottivat kymmeniä yksittäisiä testikuvauksia ja tehtäviä sitä varten, mikä on pohjimmiltaan yksi testaustehtävä. Se on kuin kaupassa jonossa eteesi osuva henkilö, joka vaatii maksamaan $80:n ruokaostokset pikkurahalla.
Tämän atomisoivan kiihkoilun tuloksena kyseistä julkaisua varten syntyy satoja, joskus tuhansia testikuvauksia. QA on tahtomattaan päätynyt kirjoittamaan Dickensin romaanin. Kymmenentuhannen kaupungin tarinan. Oletko koskaan oikeasti lukenut sellaista? En minäkään.
Lopputulos on, ettei kenelläkään ole aikaa tai kärsivällisyyttä päivittää näitä tuhansia yksittäisiä testikuvauksia. Seuraavan ohjelmistoversion testaaminen tulee aina olemaan etusijalla, koska se tuottaa lopulta tuloja, kun taas testidokumentaation päivittäminen ei tuota.
Lisäksi testidokumentaatiosovellukset eivät tee testidokumentaatiotietueiden massapäivityksistä lainkaan helppoja. Testiluokkien maailmanlaajuisten muutosten tekeminen voi useimmissa sovelluksissa olla työlästä ja epäintuitiivista (tämä pätee vielä nykyäänkin moniin vikojen seurantaan tarkoitettuihin sovelluksiin). Tämä lisää päivitysten vaatimaa ajankäyttöä ja henkistä kuormitusta.
Tämän seurauksena kaikki tuo huolellinen testidokumentaatio päätyy hylätyksi. Ja kaikki sen luomiseen käytetty aika menee lopulta hukkaan. Se ei ole uudelleenkäytettävää. Se on yhden hitin ihme. Se on ohjelmistotestauksen ”I Melt With You”. Silti testidokumentaatio on ehdoton edellytys toistettavalle ja järjestelmälliselle testaustyölle. Siinäpä Catch-22-tilanne.
Tästä ongelmasta on olemassa ulospääsy. Ja vaikka minun on tuskallista myöntää se, meidän pitäisi hakea ratkaisua insinöörityöstä. Tai ainakin sen tarjoamasta innoituksesta. Insinöörit kohtasivat samankaltaisen ongelman kaupallisen ohjelmistokehityksen alkuvuosina. Tuon ajan ohjelmointikielten rajoitusten vuoksi heidän oli kirjoitettava jokaisen toiminnon kohdalla uudelleen samaa perusrakennetta koskeva koodi attribuutteja, toimintoja ja suojauksia varten. Yhä uudelleen. Muistinhallinta ja roskienkeruu olivat hyvä (ja vaarallinen) esimerkki tästä ongelmasta.
Tämän seurauksena insinöörit tuottivat valtavia määriä turhaa koodia ja tuhlasivat valtavasti aikaa (eivätkä insinöörit välttämättä pane pahakseen jälkimmäistä. Ebay on yhä olemassa syystä.). Sitten joku älykkö keksi olio-ohjelmoinnin, jossa voitiin luoda ohjelmointiobjekteja, jotka perivät oletusattribuutit jo luonteensa perusteella. Samaa koodia ei tarvinnut kirjoittaa (tai leikata ja liittää) joka kerta. Tämä tarkoitti, ettei laatu enää riippunut yksittäisen insinöörin muistista tai kirjoitustaidoista. Mistä QA on ikuisesti kiitollinen.
Tämä on erittäin hyödyllinen näkökulma QA:lle, kun se kamppailee testidokumentaation umpikujaa vastaan. Insinöörityössä käytettävää olioajattelun käsitettä ei voi soveltaa suoraan tähän ongelmaan, mutta vertauskuvana sillä on paljon tarjottavaa. Oivaltavuus mukautuu määritelmänsä mukaisesti helposti uusiin tilanteisiin.
Olen urani aikana joutunut monta kertaa pohtimaan, miten luoda testidokumentaatiota, joka on kattavaa mutta tiivistä, heti toimintaan ohjaavaa mutta myös helposti uudelleenkäytettävää tulevissa julkaisuissa. Lopulta päädyin ratkaisuun, jossa ”olion” idea sovelletaan itse testidokumentaatioon.
Tässä puhun paljon muustakin kuin testidokumentaatiomallista. Mallit ovat tietenkin erittäin hyödyllinen standardointityökalu, mutta tämän ongelman kannalta ne ovat epäolennaisia. Kehitin ajatuksen, että testit voitaisiin dokumentoida tavalla, joka sisältää yhdessä dokumentissa kaikki niiden eri toimintatilat, käännekohdat, työnkulut ja erityisehdot. Kun tämä lamppu syttyi hämärässä päässäni, vastaus vaikutti yhtäkkiä hyvin yksinkertaiselta. Ja hyvin toteuttamiskelpoiselta.
Paneudutaanpa siihen.
Punaisen pillerin ottaminen
Ratkaisu on nähdä yksittäinen testi ja siten myös sen dokumentaatioartefakti muuna kuin testauksen väitteenä tai kuvauksena, joka koskee yhtä datapistettä tai eristettyä ehtoa. Se on nähtävä kuvauksena koko matriisista (huomaatko, mitä tein?), jossa ominaisuus tai kyvykkyys on validoitava.
Tämä edellyttää kokonaisvaltaista lähestymistapaa yksittäisen testin määrittelyyn. Yhtenäistä, yksittäistä testaustehtävää ei voida mielekkäästi pilkkoa kymmeniksi toisistaan riippumattomiksi ”testeiksi” ilman, että samalla paradoksaalisesti häivytetään erityispiirteet koko ominaisuuden testaamiseen. Kyse on tilanteesta, jossa metsää ei nähdä puilta.
Tässä on hyödyllistä tarkastella testikontekstin käsitettä. Jotta testikohteen idea voidaan toteuttaa tehokkaasti, sinun on ensin pystyttävä erottamaan toiminnallisuuden muuttumaton ydin sen soveltamisen ja toiminnan toissijaisista konteksteista. Atomistinen testidokumentoinnin tyyli sivuuttaa tämän kysymyksen, joten testaajat eivät koskaan opi suorittamaan tätä analyysia järjestelmällisesti ja tietoisesti. Tämä on jälleen yksi atomistisen lähestymistavan haittapuoli.
Yksinkertaisesti sanottuna ominaisuuden tai järjestelmän testikontekstit ovat joukko ehtoja, ympäristöjä, työnkulkuja tai tiloja, jotka voivat vaihdella toisistaan riippumatta itse ominaisuuden rajojen sisällä. Käyttöjärjestelmät ja käyttöjärjestelmäversiot ovat tästä selkeä esimerkki. Vieraat kielet ovat toinen. Järjestelmän tilat ovat vielä yksi esimerkki (esimerkiksi verkkopalvelimen tapauksessa muistivälimuistin käyttö käytössä tai poissa käytöstä). Kun ymmärrät tämän eron, pystyt helposti ajattelemaan monia muita testaamiesi tuotteiden tyyppeihin liittyviä esimerkkejä.
Kun olet saanut tämän analyysin päätökseen (ja sen tulisi joka tapauksessa olla kaiken ammattimaisen testisuunnittelun perusta), pystyt luomaan tiiviitä testidokumentaation muotoja, joissa tämä ero on sisäistetty. Kuvaamassani järjestelmässä yksi testidokumentaation artefakti koostuu seuraavista:
- Testattavan ydintoiminnon tai -ominaisuuden kuvaus.
- Luettelo kaikista konteksteista, joissa ydintoiminnallisuus on validoitava.
- Kaikki muu, minkä olisit normaalisti sisällyttänyt joka tapauksessa (testin kelvollisuuden edellytykset, testin suorittamiseen tarvittavat järjestelmäresurssit ja käyttöoikeudet, linkki asiaankuuluviin tuotevaatimuksiin ja niin edelleen). Mikään näistä ei korvaudu ehdottamallani tavalla.
Tässä vaiheessa saatat ajatella: ”Hei, konteksteja voi olla paljon!” No, totta kai. Mutta ajattele asiaa näin. Tämän tekeminen ei lisää työmäärääsi. Itse asiassa se vähentää sitä. Kattavien testisuunnitelmien laatiminen helpottuu, kun käytössäsi on kuratoitu luettelo dokumentointiin tarkoitetuista ohjelmistotestauksen työkaluista. Tämä menetelmä nimittäin *vähentää huomattavasti* niiden yksittäisten testien määrää, joiden luomiseen sinun on käytettävä aikaa ja joita sinun on ylläpidettävä (tai jätettävä ylläpitämättä) tulevaisuudessa. Atomistisessa järjestelmässä sinun olisi sen sijaan luotava jokaiselle niistä erillinen testidokumentaation artefakti. Tämä johtaa artikkelin alussa kuvattuun Catch-22-tilanteeseen.
Tällä testidokumentoinnin menetelmällä on tiettyjä prosessiin liittyviä seurauksia, jotka saattavat aluksi vaikuttaa hankalilta. Tai jopa huolestuttavilta. Eivätkä ainoastaan laadunvarmistuksen kannalta, vaan myös muiden projektin sidosryhmien näkökulmasta. Jos kaikki osapuolet kuitenkin käyttävät aikaa niiden ymmärtämiseen, he huomaavat niiden olevan todellisuudessa parannuksia. Kaikille.
Keskeisin näistä on se, että kun ominaisuuden kontekstimatriisi yhdistetään varsinaiseen testiin, tästä seuraa loogisesti, että jos kyseinen yksittäinen testi epäonnistuu yhdessäkin näistä konteksteista, koko testi on epäonnistunut. Vaikka kyse olisi vain yhdestä. Voin kuvitella tämän aiheuttavan paniikkia kehitystiimissä. Saattaa nimittäin vaikuttaa siltä, että asetat heidät epäreiluun asemaan ja nostat riman mahdottoman korkealle, jotta testi voitaisiin laskea ”hyväksytysti suoritetuksi”. Tämä pelko on kuitenkin helppo hälventää. Kerro heille kaksi asiaa ja itsellesi kolmas:
- Tämä menetelmä itse asiassa vähentää testauksen seurauksena heidän työtään vastaan kirjattavien virheiden määrää. Atomistisessa menetelmässä minkä tahansa yksittäisen kontekstin epäonnistuminen olisi nimittäin tuottanut oman erillisen virheensä. Näin yhtä ominaisuutta koskevien virheiden kokonaismäärä olisi kasvanut. Tämän pitäisi saada insinöörit hymyilemään. Samoin projektipäälliköt.
- Toiseksi tällä menetelmällä testaaminen antaa automaattisesti asiayhteyden toiminnallisen virheen todelliselle laajuudelle. Mikä nimittäin on ensimmäinen kysymys, jonka virheen korjaamiseen määrätty insinööri sinulta aina kysyy? ”Öh, no, tapahtuuko tämä kaikkialla? Vai ainoastaan kontekstissa X?” Sen sijaan, että joutuisit kiirehtimään takaisin työpöytäsi ääreen ja suorittamaan testin uudelleen kontekstissa X (koska ehkä unohdit tehdä sen alkuperäisen testauksen yhteydessä), sinulla on jo vastaus, eikä insinöörillä ole tekosyytä vältellä asian käsittelyä (sen minkä laadunvarmistus antaa vähempinä virheinä, se ottaa myöhemmin takaisin).
- Kolmanneksi testidokumentaation kontekstianalyysi varmistaa, että todella pohdit kaikkia asiaankuuluvia konteksteja jo testin alkuperäisen dokumentoinnin yhteydessä. Tämä tarkoittaa, että joudut harvemmin paniikkiin kolme päivää ennen julkaisua tai, mikä vielä pahempaa, sen jälkeen, kun huomaat unohtaneesi testata joissakin erittäin tärkeissä konteksteissa. Paniikkiin perustuva laadunvarmistus ei ole kovin tehokasta. Eikä se myöskään ole psykologisesti erityisen miellyttävä kokemus.
Koneistossa
Tämä olioihin perustuva testidokumentoinnin menetelmä vähentää huomattavasti tuotettavien dokumentaatioartefaktien määrää ja tekee siten todennäköisemmäksi sen, että pystyt ja haluat päivittää niitä jatkuvasti tulevia julkaisuja varten.
Ainoa ongelmakohta on se, että vain harvat testidokumentointisovellukset on suunniteltu dokumentoimaan testejä tällä tavalla suoraan. Niissä oletetaan yleensä atomistinen dokumentointimalli, koska se on valitettavasti vallitseva käytäntö, joten niissä ei ole sisäänrakennettua toiminnallisuutta kuvaamani oliomallin helppoa tukemista varten.
Siksi olen usein päätynyt paljon vähemmän monimutkaisiin sovellusratkaisuihin — kuten Exceliin — jotka ovat itse asiassa tähän tarkoitukseen paljon joustavampia ja helpommin mukautettavissa, koska ne ovat yleiskäyttöisiä. Tämän strategian haittapuolena on, että niiden yhdistäminen Jiraan ja muihin vastaaviin järjestelmiin käy hankalaksi. Mutta ehkä integraation merkitystä yliarvioidaan.
Joka tapauksessa se, että monet testien ja virheiden dokumentointiin tarkoitetut sovellukset tekevät yksittäisten tietueiden eräpäivityksistä erittäin vaikeita, on edelleen ongelma. Riippumatta siitä, mitä käytäntöjä niiden luomisessa päätätte käyttää. Mutta tämä pätee riippumatta siitä, miten päätätte kirjoittaa testidokumentaationne. Yksi ongelma kerrallaan, ihmiset.
Pahoittelen jo etukäteen (tai teidän tapauksessanne jälkikäteen), etten anna teille testikohdemallia. Kokemukseni mukaan mallien tarjoaminen on yleensä huono idea, koska ihmiset alkavat yksinkertaisesti käyttää malliasi. Valmiiden, yleiskäyttöisten mallien saatavuus pyrkii estämään ja lyhentämään tiimin omaa luovaa työtä sellaisen mallin suunnittelussa, joka vastaa heidän todellisia tarpeitaan, prosessejaan ja käytännön työkalujaan. Ei siis pahalla.
Otan aina mielelläni vastaan kysymyksiä ja ehdotuksia. Julkaiskaa ne tai lähettäkää ne minulle LinkedInissä.
Ja kuten aina, onnea matkaan.
