Johtajuutta testauksessa: testauksen suunnittelu

Mikä suunnitelma oikeastaan on?

Projektisuunnitelma yhdistää projektin tehtävät, arvioidut kestot, riippuvuudet ja tuotokset todellisuuden aikataulutetuksi malliksi.

Jos pidät suunnitelmaa tulevaisuuden ennusteena, suhtautuisit hyvin varauksellisesti siihen tukeutumiseen, mutta juuri niin yleensä toimimme.

Olet ehkä törmännyt projektipäälliköihin, jotka pitävät suunnitelmaansa henkilökohtaisena todellisuutenaan – omana harhaisena maailmanaan. Meidän ei kuitenkaan pitäisi suhtautua projektipäälliköihin näin ankarasti – heitä motivoi usein luomaan suunnitelma ja toteuttamaan se hinnalla millä hyvänsä.

Suunnitelma ei ole todellisuus, vaan todellisuuden malli, joka vaatii jatkuvaa muuttamista.

Tässä artikkelissa käsittelen testauksen suunnittelun jokaista vaihetta, mukaan lukien:

• Tuotokset
• Miten
• Resurssit
• Tukiverkostosi
• Arviot
• Riippuvuudet, riskit ja oletukset
• Viestintä, sitoutuminen ja edistymisen raportointi

Mutta ensin muodostetaan selkeä käsitys suunnitelman hyödyllisyydestä. 

Miksi suunnitella?

Suunnittelun tarkoituksena on yleensä luoda projektin toteuttamista varten yhteisesti sovittu toimintatapa, sitoumukset, riippuvuudet, kustannukset ja aikataulu. Suunnitelma on projektin sidosryhmien, toimittajien ja osallistujien välinen yhteisymmärrys, jossa määritellään tyypillisesti seuraavat asiat:

• Mitä resursseja tarvitaan ja milloin
• Milloin tehtävät on aloitettava ja saatettava päätökseen sekä kuka ne suorittaa
• Mitä taitoja tehtävien suorittamiseen tarvitaan
• Mitkä työkalut ja teknologiat tukevat suunnitelmaa
• Mitä tuotoksia toimitetaan ja milloin ne toimitetaan
• Tarvittavan työn ja resurssien kustannukset
• Prosessi, jolla projektia tai prosessia viedään eteenpäin vaiheesta toiseen
• Toimitusta uhkaavat riskit.

Jotkin näistä näkökohdista on voitu määritellä strategiassa tai ne voivat olla jo valmiiksi käytössä. Saattaa esimerkiksi olla tiedossa, mitkä toimittajat osallistuvat projektiin ja mitä he tekevät sen hyväksi. Käytettävät työkalut ja teknologia voivat olla jo tiedossa ja käytössä. Henkilöt, testiympäristöt ja data voivat olla valmiina. Lisäksi käytössä voi olla strategia, jossa määritellään käytettävä prosessi, lähestymistapa tai tekniikat.

Strategian määritellessä periaatteet tai teorian suunnitelma kuvaa käytännön järjestelyt ja logistiikan sille, miten projekti toteutetaan todellisuudessa.

Strategia määrittelee, miten projekti periaatteessa toteutetaan, kun taas suunnitelma määrittelee ja vahvistaa, miten projekti toteutetaan käytännössä.

Monilla projektipäälliköillä suunnitelma on Microsoft Projectin kaltaisessa ohjelmistossa, mutta toimiva suunnitelma edellyttää, että kaikki projektin osallistujat tietävät, mitä he tekevät ja miten. Tämän saavuttamiseksi suunnitelmasta ja siitä, miten asiat tehdään, on viestittävä kaikille osallisille, ja kaikkien on sitouduttava niihin.

Suunnittelu on matka, ei tehtävä

Lainatakseni Yhdysvaltain entistä presidenttiä Dwight D. Eisenhoweria: ”suunnittelu on kaikki kaikessa. Suunnitelma ei ole mitään.” Tämä ajatus on niin tärkeä, että se ansaitsee toistamisen lähes kaikissa järjestelmäprojektien työskentely-ympäristöissä. Mutta mitä tarkoittaa sanoa, ettei suunnitelma ole mitään? Mikä suunnittelun tarkoitus on, jos lopputuloksena on hyödytön suunnitelma? 

Lopputuloksena syntyvä suunnitelma ei ole koskaan hyödytön, mutta Eisenhowerin ajatus liittyy suunnittelun toteuttamiseen ja sen arvoon verrattuna suunnitelmaan. Verrataan lyhyesti, miten suunnittelu toimii erikseen pitkissä, jäsennellyissä projekteissa ja ketterissä/jatkuvissa projekteissa.

Jäsennelty suunnittelu vs. ketterä suunnittelu

Pitkäkestoisessa projektissa liiketoimintasi, toimittajasi ja sisäinen IT-henkilöstösi tarvitsevat tiedon siitä, mitä sitoutumista heiltä edellytetään, jotta he voivat aikatauluttaa ihmisten ja fyysisten resurssien saatavuuden.

Suunnitelman laatimiseen tarvittavien tietojen kerääminen vie arvokasta aikaa. Resursseihin ja ihmisiin liittyvien riippuvuuksien sekä toimittajien ja sisäisten henkilöiden sitoutumisen ja suoriutumisen vuoksi monet asiat voivat mennä pieleen. Jotkin asiat menevät pieleen. Tämän vuoksi suunnitelma tulevaisuuden ennusteena on täynnä haasteita.

Suunnitelman julkaisemista seuraavana päivänä ja jokaisena sitä seuraavana päivänä tulee esiin uutta tietoa, ja joitakin muutoksia tarvitaan. Vaatimuksia hylätään; toimittajat toimittavat myöhässä; ympäristöt, testidata tai työkalut eivät ole ajoissa valmiina. Lista jatkuu. Suunnittelu ei ole koskaan kertaluonteinen tehtävä, vaan jatkuvaa — lähes päivittäistä — toimintaa.

Suunnittelemattomia tapahtumia pidetään usein häiriöinä, eikä niihin kiinnitetä paljon huomiota. Myöhemmin jotkin näistä pienistä häiriöistä kuitenkin muuttuvat suuriksi ongelmiksi. Yksi vesiputousprojektien haasteista on, että jatkuva mukauttaminen voi olla raskasta, koska kaikki muutokset nähdään tarpeettomana näpertelynä. Projektit etenevät usein kaikesta huolimatta siinä toivossa, että asiat ”järjestyvät illan koittaessa”. Näin tapahtuu kuitenkin harvoin, ja on sanottu monta kertaa:

Miten projektista tulee vuoden myöhässä oleva? Yksi päivä kerrallaan.

Ketterä lähestymistapa on osittain reaktio kiinteiden tai joustamattomien suunnitelmien aiheuttamaan turhautumiseen. Ketteryys on todistettu vaihtoehto raskaiden, vaiheittaisten lähestymistapojen hitaudelle. Tarkoittaako tämä, etteivät ketterät projektit suunnittele? Ei. 

Ketterässäkin työssä tarvitaan jonkin verran ennakkosuunnittelua työn jäsentämiseksi, resurssien kokoamiseksi ja tulevien kuukausien julkaisuprosessin aikatauluttamiseksi — ainakin ylätasolla. Kuitenkin iteraatio iteraatiolta ja usein päivä päivältä kokonaissuunnitelmaa mukautetaan jatkuvasti, jotta tapahtumat ja esiin tuleva uusi tieto voidaan ottaa huomioon.

Suunnittelu on jatkuva oppimismatka, ei tehtävä, jolla on toimitettava lopputulos.

Testauksen suunnittelu

Tähän asti olemme tarkastelleet projektin suunnittelua yleisesti ja todenneet, että se on hyvin pitkälti jatkuvaa toimintaa. Seuraavaksi keskitymme erityisesti testauksen suunnitteluun projekteissa. 

Testauksen suunnittelu muistuttaa hyvin paljon projektin suunnittelua – kyseessä on vain pienemmän mittakaavan suunnitelma. Testaussuunnitelma on tietenkin myös sovitettava yhteen laajemman projektisuunnitelman kanssa, koska se riippuu muista projektin toiminnoista ja toimitettavista tuotoksista (ja muut tehtävät riippuvat testauksesta). Testaussuunnitelmat häiriintyvät usein, koska näitä riippuvuuksia ei täytetä.

Testaussuunnitelmat ovat yleiskuvatasolla suhteellisen yksinkertaisia. Niihin voi sisältyä useita toimintoja, jotka riippuvat emoprojektista. Nämä näkyvät usein tehtävinä laajemmassa projektisuunnitelmassa. Nämä toiminnot kuitenkin jakautuvat tiimin kesken, ja suunniteltavana ja suoritettavana voi olla suuri määrä testikohteita. 

Tämä yksityiskohtien taso ei ole projektipäällikön aikataulun kannalta kovin merkityksellinen, vaan se määritellään ja sitä hallitaan yleensä paikallisesti testitiimin sisällä.

Tarkastellaan seuraavaksi testaussuunnitelman keskeisiä elementtejä.

Toimitettavat tuotokset

Mitä testauksen toimitettavat tuotokset ovat?

Mikä kysymys! Tietysti testauserittelyt, testit, tulokset ja raportit? Toimitettavat tuotokset sisältyvät olennaisilta osin dokumentaatioon, joten meidän tarvitsee vain huolehtia paperitöiden saamisesta valmiiksi ja rastittaa muutama kohta. 

Tämä lähestymistapa on yleinen, mutta se on osittain syynä siihen, että testaus (ja testaajat) ovat saaneet maineen kalliina, kankeina byrokraatteina, joista on vain vähän hyötyä. Loppujen lopuksi, kuka lukee nämä laajat dokumentit?

Oletetaan, ettei ketterässä projektissa ole tarkoitus tuottaa testausta koskevaa dokumentaatiota. Tämä on hyvin todennäköistä, joten mitä testaus tällaisissa tilanteissa todella tuottaa? Mitä arvoa testauksella ylipäätään on? Näitä kysymyksiä on hieman myöhäistä esittää, eikö totta?

Kun komponentti, alijärjestelmä tai koko järjestelmä testataan, tuloksena on näyttöä siitä, miten järjestelmä käyttäytyy tietyssä tilanteessa tai asiayhteydessä. Näyttöä järjestelmän käyttäytymisestä kerätään ja kootaan esitettäväksi sidosryhmille (kehittäjille, käyttäjille, johtajille jne.), jotta he voivat tehdä päätöksen: korjata virheitä, integroida komponentin, hyväksyä tai hylätä toiminnallisuuden, julkaista tai ottaa käyttöön alijärjestelmän tai koko järjestelmän.

Testauksen toimitettava tuotos on näyttö järjestelmän käyttäytymisestä, jota sidosryhmät käyttävät päätöksen tekemiseen.

Joissakin projekteissa on nykyään olennaista laatia testidokumentaatio, johon kirjataan, miten testi rajattiin, suunniteltiin, toteutettiin ja suoritettiin. Sidosryhmille arvokkain lopputulos on kuitenkin näyttö järjestelmän toiminnasta.

Testauksen arvo on siinä, kuinka paljon luottamusta sidosryhmillä on tehdä päätöksiä testinäytön perusteella.

Tämä näyttö voidaan kerätä, taulukoida ja analysoida järjestelmällisesti kehittyneissä testinhallintaratkaisuissa ja esittää sidosryhmille tyylikkäinä graafisina esityksinä. Testaaja voi myös käyttää käsin kirjoitettuja muistiinpanoja esitellessään testauksen kulun suullisesti tuoteomistajalle päivittäisessä tilannepalaverissa.

Riippumatta siitä, miten näyttö kerätään ja esitetään, testauksen viimeinen tehtävä on näytön luovuttaminen.

Miten

Projektin laajuudesta tai menetelmästä riippumatta testaus perustuu tiettyyn toimintasarjaan. Tarkastelemme yleistä prosessia testaajan (tai tiimin) näkökulmasta ja perehdymme sen jälkeen joihinkin esiintyviin muunnelmiin. 

On niin kutsuttuja ”testaustoimintoja” sekä ”testausta tukevia” tai ”logistisia” toimintoja. Jotta sisällytät suunnitelmaan kaikki toiminnot, alla olevat taulukot voivat toimia hyödyllisinä tarkistuslistoina.

Yksi yllä olevassa taulukossa mainittu toiminto, jota et ehkä tunnista yhtä hyvin, on palautetoiminto. Olet varmasti jo joutunut työskentelemään puutteellisten vaatimusten kanssa. 

Palautteen, katselmoinnin ja haastamisen yhteydessä testaajat käyvät vaatimuksen läpi ja mallintavat sen, havaitsevat ongelmia ja voivat esimerkkien avulla osoittaa, missä vaatimukset ovat puutteellisia, epäselviä tai ristiriitaisia.

Jos pidät vaatimuksia puutteellisina, tälle toiminnolle kannattaa ehdottomasti varata aikaa.

Testauksen logistiikka

Testauksen logistiikka tukee edellä kuvattuja testaustoimintoja. Esittämäni testaustoimintojen luettelo on melko kattava, mutta testauksen logistiikka vaihtelee jokaisessa projektissa ja organisaatiossa. Alla oleva luettelo ei siksi ole kattava. Käy omassa projektissasi huolellisesti läpi kaikki toiminnot tai riippuvuudet, joita testauksen toimittaminen edellyttää.

Resurssit (henkilöresurssit, fyysiset resurssit)

Käytämme usein sanaa resurssit viitatessamme projekteissamme työskenteleviin ihmisiin, eikä se tunnu kaikista hyvältä. Ihmiset eivät ole esineitä, vaan tietenkin inhimillisiä olentoja. Pienemmissä projekteissa voi olla mahdollista käyttää nimiä, mutta suuremmissa organisaatioissa, joissa projektitiimit ovat mukana eikä niitä ehkä ole vielä koottu, resurssien määrä on yksinkertaisesti lyhyt ilmaus ihmisten määrälle.

Vielä tärkeämpää on, ettei ratkaisevaa välttämättä ole ihmisten määrä – heidän osaamisensa on se, jolla todella on merkitystä. Ihmiset työskentelevät tietenkin eri tavoin ja yleensä eri nopeuksilla, joten tämä on otettava huomioon suunnittelussa.

Henkilöiden lisäksi tarvitset testauksen eri vaiheissa erilaisia fyysisiä resursseja, jotta testaus voi edetä. Ne vaihtelevat tavallisista erittäin erityislaatuisiin, ja minkä tahansa näistä puuttuminen voi vaarantaa testaustehtävän onnistumisen.

Saatat olla jo siinä onnekkaassa tilanteessa, että käytössäsi on täysin varusteltu, hallinnoitu ja testaukseen tarkoitettu laboratorio. Jos näin ei ole, sinun on ehkä määriteltävä kaikki työympäristöön tarvittava aina fyysisestä tilasta ja kalusteista muistilappuihin ja pyyhekumeihin asti.

Alla olevassa taulukossa on esitetty joitakin tyypillisesti tarvittavia resursseja. Oma luettelosi poikkeaa epäilemättä huomattavasti tästä. 

Kun olet tunnistanut kaikki suunnitelmasi toteuttamiseen tarvittavat resurssit, pohdi, tarvitsetko suunnitelmaasi lisätoimintoja niiden hankkimiseksi.

Tukiverkostosi

Jos testaamiseen tarvittavat ihmiset ja taidot olisivat hallinnassasi, projektit voisivat olla paljon yksinkertaisempia! Harvalla tiimillä on kuitenkaan kaikkia tarvitsemiaan taitoja tai valtuutusta ja pääsyä tarvittaviin fyysisiin resursseihin. Monissa projekteissa henkilöstö ja toiminta järjestetään matriisijohtamisen periaatteiden mukaisesti. Tiimin avainjäsenet raportoivat itse asiassa muiden erikoistuneiden osastojen johtajille, ja saat heiltä vain rajallisen työpanoksen.

Saatat joutua määrittämään tietyn tuntimäärän päivässä tai aikatauluttamaan ajankohdat, jolloin yllä mainittuja asiantuntijataitoja voidaan hyödyntää. Joskus sinulta kysytään, millainen palvelutaso on hyväksyttävä, esimerkiksi: ”korkean prioriteetin pyyntöihin vastataan kolmenkymmenen minuutin kuluessa ja niin edelleen.”

Arviot

Ohjelmistoprojektien arviointi on hankalaa. On kirjoitettu paljon siitä, kuinka vaikeaa tai jopa mahdotonta arviointi on. Arvioita tarvitaan kuitenkin kaikissa projekteissa, ja mitä suurempi projekti on, sitä enemmän olemme niistä riippuvaisia.

Tarvitsemme arvioita aikataulun laatimiseen, mutta ongelmana on, ettei arviointi takaa tarkkuutta. Parhaimmillaan voimme laskea työmäärän tai kuluneen ajan jollakin varmuus- tai todennäköisyystasolla.

Jotkut pitävät arviointia mustana taiteena, ja olemassa on jopa #NoEstimates-liike, jolla on huomattava kannatus. On kiistelty paljon siitä, voiko arviointi koskaan olla riittävän tarkkaa tai onko se ylipäätään hyvä käytäntö ohjelmistoprojekteissa.

Arvioinnista ei koskaan tule eksaktia tiedettä. Omien kokemusteni perusteella haluan kuitenkin jakaa muutaman periaatteen, joiden esittämiseen tunnen oloni mukavaksi:

• Vaatimukset ovat vajavaisia ja epätäsmällisiä.
• Ihmiset ovat enemmän tai vähemmän päteviä, tunnollisia ja ahkeria.
• Mitä pienempi työtehtävä on, sitä helpompi se on arvioida. Jaa suuret tehtävät pienemmiksi yksiköiksi aina kun mahdollista ja kokoa arviot suuremman tehtävän arvioksi.
• Arviointi perustuu kokemukseen. Jos sinulla ei ole kokemusta, etsi tilanteita, joissa muiden kokemus on merkityksellistä ja mukautettavissa.
• Työtehtäväsi on ainutlaatuinen, joten etsi työskentelymalleja muista tunnetuista tilanteista, joista sinulla on kokemusta.
• Pyydä muita tekemään arvio ja vertaile niitä. Poikkeamien käsittely tuo esiin erot odotuksissa, varmuudessa ja perusteellisuudessa.
• Arvioi paras mahdollinen tilanne ja sen jälkeen huonoin mahdollinen tilanne. Hyvä arvio on jossain niiden välissä.

Tee arvio tänään ja aloita työskentely; huomenna ja jokaisena seuraavana päivänä loppuun saattamista koskeva arvio tarkentuu karttuneen tiedon ansiosta.

Riippuvuudet, riskit ja oletukset

Edellisessä artikkelissa käsittelimme riskejä ja testauksen roolia riskienhallinnassa. Tuoteriskit liittyvät siihen, vastaako tuote käyttäjien tarpeita toiminnallisten tai teknisten vaatimusten osalta. Tässä keskitytään varsinaisen toimitussuunnitelman riskeihin.

Projekteissa asiat menevät pieleen. Suunnittelussa on tehtävä selväksi, mitkä epäonnistumisen riskit on otettu huomioon ja huomioitu suunnitelmassa. Tässä on kolme näkökohtaa: riippuvuudet, riskit ja vastatoimet.

Riippuvuudet

Riippuvuudet muodostavat luettelon tarvittavista henkilö- ja fyysisistä resursseista sekä edeltävistä toiminnoista, joiden on valmistuttava, jotta suunnitellut toiminnot onnistuvat ja tuottavat tuloksia. 

Jokaiseen testaustoimintoon liittyy aina riippuvuuksia, olipa kyseessä laajamittainen järjestelmätason testi tai toiminnon tutkiva testausistunto. Riippuvuudet kattavat kolme pääaluetta.

Riskit

Riski tarkoittaa todennäköisyyttä, että suunnitelmasi epäonnistuu toteutuksen aikana. Riskit liittyvät esimerkiksi seuraaviin asioihin:

• Arviosi: mikä voisi aiheuttaa arvioidesi virheellisyyden? Järjestelmän suurempi monimutkaisuus, virheellisyys, keskeneräisyys tai jatkuva muuttuminen voivat kaikki vaikuttaa arvioihisi.
• Henkilöitä ei ole käytettävissä, heiltä puuttuu kokemusta tai taitoja tai he eivät ole täysin sitoutuneita projektin vaiheeseesi. He voivat olla tiimin jäseniä tai tukiverkostosi henkilöitä.
• Infrastruktuuria, kuten testiympäristöjä, työkaluja (tai työkalujen käyttöön liittyvää koulutusta) tai toimitiloja, ei ole käytettävissä, niitä ei ole valmisteltu asianmukaisesti tai ne ovat viallisia.
• Edeltävät toiminnot eivät valmistu ajoissa (tai ne hylätään, niiden tuloksena toimitetaan osittaisia tai viallisia tuotteita tai niitä ei toimiteta lainkaan).

Vastatoimet

Jokaisen näiden riskien osalta sinun on arvioitava todennäköisyys ja vaikutus sekä merkittävien riskien kohdalla asianmukainen vastatoimi tai odotettu seuraus. Vastatoimet ovat yleensä jotakin seuraavista:

• Oletus: riskin katsotaan olevan riittävän vähäinen ohitettavaksi tai merkityksettömäksi. Se on kuitenkin tiedossa ja kirjataan oletuksena (saatavuudesta, täydellisyydestä jne.).
• Mukauttaminen: riski on merkittävä, mutta jokin toimenpide voi vähentää sen vaikutusta suunnitelmaan. Jos esimerkiksi testattava järjestelmä toimitetaan osittain ja joitakin toimintoja puuttuu, suunnitelmaa voidaan mukauttaa testaamaan vain käytettävissä olevia toimintoja.
• Seuraus: joitakin riskejä ei voida sisällyttää suunnitelmaan. Jos järjestelmä toimitetaan myöhässä, testausta ei voida aloittaa ennen sen toimittamista.

Viestintä, sitoutuminen ja edistymisen raportointi

Lopuksi käsittelemme suunnittelun tärkeää mutta usein sivuutettua näkökulmaa. Saatat laatia projektisuunnitelman, joka sisältää kaikki tehtävät, osallistujat, resurssit, vastuut, riippuvuudet, aikataulut, työmäärän ja kustannukset. Tai kyseessä voi olla ketterän tiimin jäsenten välinen suullinen yhteisymmärrys. 

Joka tapauksessa suunnitelma on viestittävä tehokkaasti kaikille, jotta kaikki tietävät, mitä vaaditaan ja milloin.

Osallistujien hyväksymä suunnitelma on heidän välisensä sopimus. Jos tiiminvetäjä hyväksyy suunnitelman, se tarkoittaa implisiittisesti tai eksplisiittisesti sitoutumista täyttää tiiminsä osuus sopimuksesta.

Suunnitelma on osallistujien välinen sopimus.

Vähemmän muodollisissa projekteissa kirjallista suunnitelmaa tai sitoumuksia ei välttämättä ole lainkaan. Näissä tilanteissa suunnitelma on tiimin jäsenten välistä jatkuvaa keskustelua. Tiimi kokoontuu päivittäin, ja suunnitelman aktiivisista tehtävistä keskustellaan reaaliajassa. Minkä parissa ihmiset työskentelevät? Eteneekö työ odotusten mukaisesti? Millaisia ongelmia ihmiset kohtaavat? Mitkä ongelmat estävät etenemisen?

Kaikissa projekteissa edistymisen raportoinnilla on kaksi tarkoitusta. On selvää, että kaikkien on tarpeen tietää, missä vaiheessa kukin on nykyisen projektitoimintansa osalta. Edistymisraportti on kuitenkin myös jatkuva määräaikainen tarkistus siitä, voidaanko edistymistä ylläpitää, sekä keino varmistaa, että osallistujien sitoumuksiin voidaan luottaa.

Kiitos lukemisesta, liittykää seuraamme ensi kerralla, kun aiheena on… arvasitte oikein, toteutus!

Tilaa The QA Lead -uutiskirje, niin saat ilmoituksen, kun sarjan uudet osat julkaistaan. Nämä kirjoitukset ovat otteita Paulin testauksen johtamisen kurssilta, jota suosittelemme lämpimästi, jos haluat perehtyä syvällisemmin tähän ja muihin aiheisiin. Jos päätät osallistua, käytä ainutlaatuista kuponkikoodiamme QALEADOFFER ja saat 60 dollaria alennusta kurssin täydestä hinnasta!