Kuinka rakennetaan muutosvastarinta

Sujuvatko IT-projektisi turhan helposti? Ovatko asiakkaat liiankin tyytyväisiä? Ei hätää, tässä muutama vinkki, joilla saat työhösi uutta haastetta.

Älä ole kiinnostunut asiakkaan prosesseista, vaan minimoi tuotettavan tiedon määrää

Jo määritysvaiheessa kannattaa unohtaa asiakkaan käyttäjäroolit sekä niihin liittyvät tehtävät ja tavoitteet. Älä osoita kiinnostusta sen selvittämiseen, mitä asiakkaan todelliset käyttäjäryhmät ovat, mitä he tarvitsevat tai saavatko he äänensä kuuluviin. Määritystyöpajojen ensisijainen tehtävä on juoda kahvia ja jutella mukavia samalla kun selataan läpi irrallisia vaatimuksia ja tuotetaan sisällötöntä dokumentaatiota erilaisten johtajien luettavaksi.

Parasta on, jos saat määritystyöhön nakitettua henkilön, joka ei ymmärrä mitään asiakkaan toimialasta eikä myymästään teknologiasta, mutta osaa poliittisen jargonin jolla voidaan antaa kaikille käsitys että tässä nyt määritetään jotain vaikkei oikeasti määritetäkään. Jos myyt valmissoftaa, älä ainakaan esittele tuotteen demoympäristöä asiakkaalle - hehän saattaisivat vaikka ymmärtää, mistä määritystä tehtäessä puhutaan.

Suunnittelu- ja toteutusvaiheessa panosta vain siihen, että koodaaja pääsee mahdollisimman helpolla. Pyydetty toiminnallisuus on olemassa, jos sen yksinkertaisin käyttötapaus on mahdollista viedä läpi. Ei väliä, onko normaalin ihmisen mahdollista muistaa prosessin läpiviemisen vaatima akrobatia, tai löytyykö käyttöliittymästä kaikki tarvittava sen tekemiseen. Tärkeintä on, että ratkaisu on olemassa.

Panosta käyttöliittymän sekavuuteen

Pidä huolta, että käyttöliittymässä näkyy käyttäjälle moninkertainen määrä toiminnallisuuksia siihen nähden mitä hän tarvitsee. Parasta on, jos joukossa on viattoman näköisiä toiminnallisuuksia, joiden käyttäminen aiheuttaa katastrofin. Ja lupaavan ja tarpeellisen näköisiä toiminnallisuuksia, jotka eivät tee mitään. Ja toiminnallisuuksia, joista kukaan ei tiedä, mitä ne ovat ja miksi ne ovat siellä, saati seuraisiko niiden piilottamisesta katastrofi.

Jos käyttöliittymässä on personointeja kuten asiakkaan nimi, kirjoita se väärin. Tai kopioi toiminnallisuus toiselta asiakkaalta ja jätä vaihtamatta nimi, jotta käyttäjät varmasti ymmärtäisivät, ettei tätä järjestelmää heitä varten rakenneta.

Pyydä asiakkaalta vastauksia samoihin kysymyksiin useampaan kertaan

Älä lue projektissa tuotettua määritysdokumentaatiota. Älä pidä sitä ajantasalla. Pyydä asiakkaalta tietoa listoina, joiden merkityksiä he eivät ymmärrä, ja pyydä tätä tietoa kuukauden päästä uudelleen hukattuasi ensimmäisen version tai todettuasi ettei sen sisältö kuitenkaan vastaa asiakkaan tarpeita.

Älä näytä asiakasta ja teknisiä asiantuntijoita toisilleen, vaan pidä välissä suodattimena henkilöä joka ei ymmärrä heistä kumpaakaan, ja jolla ei riitä aika tehtäviensä hoitamiseen.

Kouluta keskeneräisellä järjestelmällä

Mikään ei ole parempi tapa pelotella ja hämmentää tulevia käyttäjiä kuin koulutusten järjestäminen heti kun jotain likipitäen pystyssä pysyvää on saatu asennettua. Oppi uppoaa parhaiten, kun koulutuksessa toistuvat fraasit "tämä olisi järkevämpää tehdä vähän toisella tavalla, mutta koska siinä on nyt bugi niin tehdään vähän vaikeammalla ja epäintuitiivisemmalla tavalla" sekä "sitten kun tämä valmistuu, niin tänne tulee näkyviin sellainen toiminto jonka kautta voitte tehdä sitä-ja-tätä". Parasta on, että järjestelmän ollessa koulutuksessa riittävän keskeneräinen, asiakas pääsee käyttämään sitä itse vasta kuukausia myöhemmin, mihin mennessä kaikki opitut tiedonmuruset ovat ehtineet unohtua.

Kikkaile raportoinnin kanssa, jotta asiakas aloittaisi hyväksymistestauksen vaikka toteutus on kesken

Tekee aina hyvää asiakassuhteelle väittää kirkkain silmin että kaikki toimii, kun seuraavana päivänä asiakas kokeilee itse ja saa todeta että mikään ei toimi. Ja kuinka mielenkiintoista onkaan selvittää, miten monta kertaa asiakas suostuu aloittamaan hyväksymistestauksen.

Tee toiminnallisia muutoksia kun järjestelmä on jo asiakastestauksessa tai pilotoinnissa

Jos tuntuu, että joku juttu olisi sitten kuitenkin järkevämpi jollain toisella tavalla, muuta se toimimaan järkevämmin. Ja jää sitten odottamaan, huomaako kukaan eroa, ja jos huomaa, keksiikö millaiseksi toiminnallisuus on muuttunut. Älä ainakaan päivitä käyttöohjetta muutoksen mukaiseksi, älä kerro kouluttajille, testaajille äläkä asiakkaille. Suunnittele valmiiksi ylimielinen vastaus, kun joku onneton kuolevainen uskaltautuu kysymään asiasta tai raportoi muutoksen bugina.

Älä ota asiakkaan ongelmia vakavasti

Kun asiakas on tyytymätön, totea että he eivät vain osaa käyttää järjestelmää, ja siksi heidän pitäisi ostaa lisää koulutusta. Toista tätä viestiä, vaikka asiakas olisi jo maksanut useammasta ekstrakoulutuspäivästä kuin mitä olit sisällyttänyt alkuperäiseen tarjoukseesi riittävänä koulutuspakettina järjestelmän käyttöönottamiseksi.

Älä turhaan suunnittele testausta

Testauksen voi suunnitella monella tavalla. Testitapauksia voi kirjoittaa hyvin yksityiskohtaisesti, tai ne voi rakentaa vain otsikkotasolla, muistilistanomaisesti. Itse testauksen organisointia voi suunnitella enemmän tai vähemmän perusteellisesti. Testaussuunnitelma voi kertoa mm. kuinka paljon työaikaa ja kalenteriaikaa käytetään mihinkin testikierrokseen, miten paljon aikaa varataan niihin liittyviin korjauksiin verifiointeineen, kuinka usein testikierroksia toistetaan, ja mitkä ovat kriteerit testauksen lopettamiseen.

Joskus on hyvä pysähtyä hetkeksi miettimään, millä tarkkuustasolla nämä asiat kannattaa tehdä projektin suunnnitteluvaiheen aikana.

Perusteellinen testaussuunnittelu liittyy usein siihen, että asiakkaalle on luvattu tiettyjä dokumentteja tietyssä vaiheessa projektia. Jos asiakkaan kanssa sovitaan, että he saavat toimittajan testitapaukset sisältöineen kaikkineen käytettäväksi omassa hyväksymistestauksessaan, ne on rakennettava paljon huolellisemmin ja paljon enemmän aikaa käyttäen kuin jos luodaan vain alustava testitapausluettelo, jota muokataan ja täydennetään tarpeen mukaan testausvaiheessa. Jos asiakas haluaa lukea testaussuunnitelman, siinä ei oikein voi lukea että testataan sitä mukaa kun jotain on likipitäen testattavissa, testaajana se joka sattuu silloin parhaiten ehtimään. Joskus tämä kuitenkin olisi tarkoituksenmukaisempi suunnitteludokumentti kuin sellainen, joka ottaa kantaa kaikkeen mahdolliseen testaamisen aloitus- ja keskeytyskriteereistä testikierrosten organisointiin. Kenties keskeisin hyvän testaussuunnitteludokumentin piirre voisi olla se, että se on riittävän lyhyt jotta projektin kulkua ohjaavat henkilöt lukevat ja sisäistävät sen.

Jos oikeastaan mikään ei todellisuudessa tapahdu suunnitteludokumentaation mukaisesti, eikä sitä tosiasiallisesti edes yritetä noudattaa (olipa syy tähän sitten piittaamattomuus tai projektielämän realiteetit), kuinka paljon aikaa tällaisen dokumentin kirjoittamiseen kannattaa käyttää?

Jos projektia edistetään vähän miten nyt kukakin sattuu ehtimään, on testauksessakaan turha pyrkiä tämän suurempaan kurinalaisuuteen. Klassinen testaus perusteellisine testitapausluetteloineen ja huolella ennalta suunniteltuine testikierroksineen on mielekästä vain, jos myös projektin edeltävät vaiheet viedään läpi vastaavaa kurinalaisuutta noudattaen. Eli määritysvaiheessa todella määritetään ja kiinnitetään määritykset, suunnitteluvaiheessa ihan oikeasti suunnitellaan määrityksen pohjalta, ja toteutusvaiheessa nämä suunnitelmat viedään läpi aikataulussa.

Kaikissa projekteissa tämä ei kuitenkaan ole mahdollista. Eikä kyse ole vain toteuttavan projektihenkilöstön osaamisesta ja viitseliäisyydestä. Tilanteeseen vaikuttaa myös esimerkiksi asiakkaan määritysosaaminen, eli pystyvätkö he kertomaan, mitä haluavat, ja kuinka paljon projektin aikatauluun sisällytettäviä muutoksia he keksivät suunnittelu- ja toteutusvaiheiden aikana, Ja tähän taas vaikuttaa paitsi asiakkaan projektiryhmän IT- ja substanssiosaamisen riittävyys, myös asiakkaan tarpeiden selkeys.

Lisäksi, ihmiset ovat erehtyväisiä. Paraskin projektipäällikkö voi unohtaa jotakin, ja paraskin tekninen vastuuhenkilö ymmärtää jotain väärin. On vain hyvä asia, jos nämä unohdukset ja väärinymmärrykset jäävät kiinni ennen stabilointivaihetta, koska silloin niiden vaikutukset aikatauluihin ja työmääriin ovat vähäisemmät. 

Jokainen projektiin tuleva muutos kuitenkin syö etukäteen tehdyn perusteellisen testaussuunnittelun arvoa. Mitä enemmän asioita on kirjoitettu auki testitapauksiin, sitä enemmän niitä on pakko muokata muutosten mukaisesti, ja sitä suurempi riski on sille että testaus raportoi vääriä asioita bugeina. Mitä enemmän projektin käytännöt ja järjestelyt poikkeavat testaussuunnitelmasta ehdotetuista, sitä vähemmän arvoa on sen kirjoittamiseksi tehdyllä työllä. Kun tämän päälle tulee vielä testaussuunnittelun itsensä epätäydellisyys, on selvää että määritysvaiheen perusteella tehdyt testitapaukset on vähintään katsottava läpi kriittisellä silmällä testauksen alkaessa.

Testaussuunnittelu on mahdollista tehdä myös toisin. Määritys- ja suunnitteluvaiheessa testauksen rooli voi keskittyä enemmänkin katselmointiin ja konsultointiin. Testaussuunnitteludokumentaation keskeisin rooli voi olla tiedon kerääminen siitä, mihin dokumentteihin nojaten testaus on tehtävä, sekä millaisia riskejä projektiin liittyy testaamisen näkökulmasta ja miten niihin varaudutaan. Riskitarkastelussa käsitellään niin testaukseen ulkopuolelta vaikuttavat riskit kuin riskit joihin testaaja voi itse vaikuttaa, muistaen erityisesti asiakkaan toiminnan kannalta keskeisimmät toimitettavaan järjestelmään liittyvät riskit, joiden tulisi vaikuttaa testauksen sisällölliseen painotukseen. Varsinaiset testitapaukset voidaan luoda tutkivan testauksen ohessa, tosin tällöin on muistettava että testaukseen tarvittavaan aikaan on lisättävä myös dokumentaation vaatima aika.

Mikä siis on päivän opetus? 

Klassisella, kurinalaisella testauksella on oma arvonsa ja paikkansa, mutta kaikkialle se ei sovi. Jos tiedät, ettet aikuisten oikeasti pysty viemään projektia läpi tiukasti vesiputousmallin mukaisesti, älä tee myöskään testaussuunnittelua niin kuin mentäisiin vesiputousmallilla. Älä silloin myöskään lupaa asiakkaalle testitapauksia (paitsi korkeintaan otsikkotasolla) suunnitteluvaiheessa. Tosiasiat voi tunnustaa jo etukäteen, ja ammattimainen testaaja pystyy kyllä luovimaan tiensä myös vähän epämääräisemmässä projektiympäristössä. Säästytään puolin jos toisin paljolta pahalta mieleltä ja turhalta työltä, jos projektin toimintatavoista sovitaan avoimesti etsien ne tavat, joilla tieto parhaiten löytää tarvitsijansa, ja testaus voidaan suunnitella tavalla jolla se todennäköisesti voidaan myös toteuttaa.

Mikä on testauksesi tavoite?

Testata voi monella tavalla. Harvassa ovat järjestelmät, jotka ovat niin yksinkertaisia, että niiden täydellinen bugittomuus kannattaa varmistaa - ainakaan kaikissa projektin testausta sisältävissä vaiheissa. Riippuu jossain määrin myös testattavan järjestelmän kypsyydestä, mistä näkökulmasta ja millaisin tavoittein testausta kannattaa tehdä. Siksi testauksen tavoitteitakin on syytä arvioida testauskierrosten välillä uudelleen.

Tavoitteiden järkevään asettamiseen vaikuttaa mm. testaukseen käytettävissä oleva aikataulu, testaajien määrä ja osaaminen, sekä se, miten valmis testattava järjestelmä on. Tärkeä näkökulma on myös se, minkälaista tietoa testaamisella halutaan saada. Onko tavoitteena jonkin toiminnallisuuden määrityksenmukaisuuden verifioiminen, yleiskuvan muodostaminen koko järjestelmän tai jonkin tietyn moduulin kunnosta, vai jotain ihan muuta? Kaikkea ei välttämättä kannata tavoitella kerralla.

Yksi lähestymistapa on ad hoc testaus, jonka tarkoituksena on nopeasti ja sen kummemmin suunnittelematta löytää bugeja. Itse tykkään aloittaa uuden toiminnallisuuden testauksen näin, ikään kuin kokemattomana käyttäjänä selvittäen, miten rakennelma toimii. Samaa näkökulmaa tulee usein käytettyä silloin kun on tarve kevyelle regressiotestaukselle. Tämä on suhteellisen tehokas tapa löytää server errorit ja muut isot mokat, joiden vastaantuleminen on myös vähemmän turhauttavaa ad hoc-tyylillä kuin yritettäessä kurinalaisesti kahlata läpi testitapauksia. Kovin pitkälle tällä tyylillä ei kuitenkaan päästä.

Järjestelmän käyttäjien kannalta keskeisintä lienee prosessin mukainen testaus, mikä tarkoittaa käytännössä sitä, että käydään läpi toiminnallisuuden kuvaavat käyttötapaukset. Yhteen käyttötapaukseen voi liittyä useampia testitapauksia, mutta periaate on kuitenkin sen tarkistaminen, että käyttäjän toimiessa oikein myös järjestelmä toimii oikein.

Tätä on kuitenkin syytä laajentaa myös sen tarkistamiseen, että järjestelmä osaa toimia myös tilanteissa, joissa käyttäjä ei toimi oikein - esimerkiksi julkista verkkokauppaa käyttävän asiakkaan ei voida olettaa ymmärtävän selaimensa teknisiä ominaisuuksia tai selaavan manuaalia samalla kun asioi.

Hyvä testaaja yrittää välillä myös rikkoa testattavan järjestelmän. Siis esimerkiksi syöttää kenttiin vääränlaisia arvoja, luoda liian paljon uusia kohteita massaluontitoiminnoilla, kulkea edestakaisin kuin ei ihan tietäisi mihin haluaa mennä, palauttaa muokattuja arvoja oletusasetuksiin, ja tehdä kaikkea mahdollista kiellettyä, mihin käyttöliittymä antaa mahdollisuuden.

Yleensä näitä mahdollisia väärin toimimisen tapoja on niin monia, ettei kaikkia ole mahdollista käydä läpi. Hyvään testaussuunnitteluun kuuluukin miettiä, mitkä ovat niitä oleellisimpia kokeiltavia asioita. Jos vielä suunnitelmat tehdään riittävän väljästi mahdollistamaan se, että negatiivinen testaus tehdään jokaisella testikierroksella vähän eri tavalla (toki tekemiset huolella dokumentoiden, jos bugeja tulee vastaan), testauksen kattavuutta saadaan tavallaan kasvatettua kierros kierrokselta.

Käyttötapauksien ympärille rakennettavaan testaukseen saa lisäväriä saippuaoopperatekniikalla. Testaussuunnittelu voidaan tehdä vähän kuin käsikirjoitettaisiin näytelmää, joka on täynnä värikkäitä henkilöitä ja yllättäviä juonenkäänteitä.

Oma inhokkini testauksessa lienee testaaminen vaatimusluetteloa vastaan. Pahimmillaan eteen lyödään satoja rivejä pitkä excel, jonka sisällöstä ei aina oikein edes selviä, mihin asiaan mikäkin esitetty vaatimus liittyy. Osa riveistä kuvaa hyvin nopeasti tarkistettavia asioita (esim. "järjestelmä sisältää kalenterin"), osan läpikäynti vaatii paljonkin aikaa (esim. kieliversioiden toiminnan vastaavuus toisiinsa nähden, tai pitkän prosessin loppupään toiminnallisuus, johon liittyvä testiaineisto on ensin luotava käsin). Vaatimuksien järjestys ei yleensä ole mitenkään looginen suhteessa järjestelmän normaaliin käyttöön. Ja joukossa on ehkä myös yleisiä ei-toiminnallisia vaatimuksia, joiden testaamista ei oikein ole mahdollista upottaa järjestelmätestaukseen.

Silti vaatimusluetteloa ei voi vain unohtaa, sillä kaikkien vaatimuksien upottaminen käyttötapauksiin ei aina ole mielekästä. Niistä muodostettavat testitapaukset voidaan kuitenkin usein linkittää käyttötapauksiin luoden niiden testaamiselle mielekkäämmän asiakokonaisuuden.

Tärkeää on myös toteutettavan järjestelmän ulkoasun testaaminen visuaalista ilmettä ja rautalankamalleja vasten. Selainkäyttöisissä ohjelmistoissa tähän liittyy myös selainriippumattomuuden testaaminen, eli sen tarkistaminen, että kokonaisuus toimii kaikilla sovituilla selaimilla. Yhä useammin järjestelmiä käytetään myös mobiililaitteilla. Riippuen sovitusta tukitasosta testaaminen eri selaimilla ja laitteilla voi viedä paljonkin aikaa.

Usein järjestelmätestaaminen alkaa käytännössä kun testattavat toiminnallisuudet ovat vielä kovin raakileita. Tämä asettaa myös omat haasteensa testaamiselle, vaikka sinällään testauksen aloittaminen mahdollisimman varhaisessa vaiheessa on hyvä asia.

Toteutusvaihetta tukeva erillisen testaajan tekemä testaus voi vähentää turhaa työtä kun virheitä löydetään ennen kuin niiden päälle rakennettavia kokonaisuuksia ehditään viimeistellä. Joskus se myös voi vähentää kehittäjän työtaakkaa, kun testimateriaalin luomiseen ja rakentuvan kokonaisuuden testaamiseen saa reaaliaikaista apua.

Toisaalta kommunikaatiokatkokset voivat johtaa turhaan työhön, jos testaaja päätyy raportoimaan bugeina asioita joita ei ole vielä toteutettu, tai asioita jotka aiheutuvat niistä jännyyksistä, joita kehittäjän yhtäaikainen tekeminen järjestelmässä aiheuttaa.

Ihanteellisimmillaan yhtäaikainen toteutus ja testaus tapahtuukin niin, että testaajat ja kehittäjät työskentelevät vierekkäin, jolloin kysyminen on helppoa ja myös hiljainen tieto välittyy kaikille. Jos tämä ei ole mahdollista, voidaan projektiviestintään käyttää myös sähköisiä välineitä. Tämä kuitenkin vaatii kaikilta osapuolilta tietynlaista aktiivisuutta - ei esimerkiksi voida olettaa, että testaaja pystyy aina arvaamaan, milloin hänelle annettu tieto tavoitetilasta tai testattavuudesta on riittämätöntä.

Mistä laatu tulee?

Testaajan työ on laadunvarmistusta. Joskus vastaan tulee käsitystä, että testaajan mukaan ottaminen takaisi lopputuloksen laadun.

Näin ei kuitenkaan ole. Testaajan tehtävä on laadun mittaaminen ja arviointi, sen parantaminen taas on pohjimmiltaan ihan muiden heiniä.

Laatu ei muutenkaan ole erillinen palikka, jonka voisi lisätä projektiin ihan vain jonkin dokumentin tai yksittäisen henkilön muodossa. Laatu on kaikkien yhteinen asia.

Laadun syntyminen vaatii tarkoituksenmukaista määritystä ja suunnittelua. Nykymaailmassa käytettävyys ja visuaalinen miellyttävyys ovat keskeisessä asemassa laadun kokemisessa, mutta tärkeää on tietenkin myös se että tuote vastaa toiminnallisuuksiltaan käyttäjien tarpeilta.

Laadun tuottamista helpottaa mahdollisuus seurata tarkoituksenmukaista prosessimallia, hyödyntäen sen tarjoamia työvälineitä.

Testausosaamisesta on apua laadun tuottamisessa niin järjestelmän määrittelijöille, suunnittelijoille kuin toteuttajille. Oma etunsa on kuitenkin myös siitä, että testaajalla ei ole vastuuta minkään näiden osa-alueiden tekemisestä. Näin siksi, että ihminen on sokea omille virheilleen, eikä testausosaaminen itsessään suojele ihmistä erehdyksiltä. Sen sijaan testausosaaminen antaa välineitä sen arviointiin, antaako määritys riittävät tiedot ohjelmiston toteuttamiseen tai vastaako toteutus määritystä.

Keskeisimpään kysymykseen, eli vastaako järjestelmä asiakkaan tarpeita, testaus voi vastata vain silloin kun asiakas itse testaa. Toimittajan testaajalla harvoin on mahdollisuutta verrata määritystä asiakkaan tarpeisiin, koska hän ei osallistu määrityksen tekemiseen eikä siksi pääse käsiksi tietoon joka voisi osoittaa määrityksen puutteet tarpeisiin nähden.

Erityisesti isojen asiakasorganisaatioiden kanssa työskennellessä ongelma on myös se, ettei asiakkaankaan projektiryhmällä välttämättä ole riittävää tietoa kaikkien tulevien käyttäjien tarpeista.

Lisäksi järjestelmän määrittäminen on helposti liian abstraktia henkilölle, joka ei ole määritysammattilainen. Todelliset tarpeet saattavat tulla tästä syystä esiin vasta testausvaiheessa.

Tämä nostaa haasteeksi sellaisten työvälineiden ja työskentelytapojen löytämisen, jotka konkretisoivat, mistä projektissa on kysymys.

Erilaiset demoympäristöt tai vaikka paperille hahmoteltu käyttöliittymä jota saa ihan itse "klikata" voivat auttaa konkretian luomisessa. Ketterät menetelmät taas antavat mahdollisuuden tarkentaa määrittelyä sitä mukaa kuin asiat konkretisoituvat.

Joskus voi olla myös tarpeen opettaa asiakasta testaamaan, tai esimerkiksi kysyä, pääsevätkö kaikkien tulevien käyttäjäryhmien edustajat arvioimaan määrityksen onnistumista.

Testaamisen mielekkyydestä

Joskus kuulee ihmettelyä, miten kukaan voi haluta olla ohjelmistotestaaja. Sellaiselle, joka on joutunut muun työn ohessa kliksuttelemaan läpi liudan jonkun muun naputtelemia testitapauksia testaus varmasti näyttäytyykin tylsänä ja aikaavievänä tehtävänä, josta on vaikea sanoa, turhauttaako enemmän jos kaikki menee läpi, vai jos mikään ei toimi kunnolla.

Tämä on kuitenkin hyvin kapea näkökulma testaukseen. Hyvin tehty ohjelmistotestaus saattaa alkaa jo myyntivaiheessa kun mietitään, kuinka työläitä asiakkaan toiveet ovat täyttää. Testausnäkökulma on avuksi myös luotaessa ohjelmistomääritystä, sillä yksi keskeisimpiä hyvän määrityksen ominaisuuksista on että sen perusteella voi testata, täyttääkö ohjelmisto sille asetetut vaatimukset. Testaussuunnittelua on mahdollista käyttää myös toteutuksen tukena, sillä testitapaukset saattavat tarjota paitsi konkreettisen ja selkeästi jäsennellyn tavan lähestyä määritystä, myös eräänlaisen muistilistan poikkeustilanteista, joista ohjelmiston on selviydyttävä vaikka määritys ei niitä käsittelekään.

Toki testaustehtävien suorittaminen on välillä myös suunnattoman tylsää. Mutta harva työnkuva on pelkkää hupia. Siksi kai meille työstä maksetaan, että olemme hetkittäin valmiita tinkimään omasta mukavuudestamme saadaksemme jonkin tärkeän tehtävän tehdyksi. Testauksen tehtävä on suojella liiketoimintaa niiltä katastrofeilta, joita bugit voivat aiheuttaa, eikä sankaritekojenkaan tekeminen ole pelkkää riemua.

Testaamisen mielekkyyteen voi myös vaikuttaa. Testitapauksia voi suunnitella niin, että niiden läpikäynti on ennemminkin uteliaisuutta herättelevä kuin uneliaisuutta aiheuttava kokemus. Automatisointi saattaa joskus pelastaa tekemästä niitä puuduttavimpia tehtäviä. Mielekkyyden luominen ja ylläpitäminen testauksessa lieneekin yksi niistä testauksen tehtävistä, joilla ammattilaiset erotellaan harrastelijoista, ja joissa kovimmallakin asiantuntijalla on aina mahdollisuuksia kehittyä vielä paremmaksi.