Kukaan ei halua käyttää softaasi

Kipeä totuus, jota joidenkin ohjelmistotaloissa työskentelevien tuntuu olevan vaikea ymmärtää, on että kukaan ei oikeasti halua käyttää sitä softaa jota teemme.

Jos mielesi tekee nyt väittää vastaan, mietipä hetki, miksi some- ja pelimaailmassa käytetään niin paljon keinoja, jotka luovat käyttäjille addiktioita. Ne tarjoavat käyttäjilleen mukavaa ajanvietettä, mutta joutuvat silti itse luomaan käyttäjille tarpeen palata.

Käyttäjän tarpeet ovatkin keskeinen syy siihen, miksi ohjelmistoja käytetään. Jos ohjelmiston avulla pystyy tekemään työnsä nopeammin, helpommin ja laadukkaammin kuin ilman, todennäköisesti ihmiset käyttävät tuota ohjelmistoa työssään, jos siihen vain on mahdollisuus.

Se ei kuitenkaan tarkoita, että he haluaisivat käyttää sitä ohjelmistoa. Ei, he haluavat saada työnsä vaivattomasti tehtyä.

Miksikö tämä on oleellista ymmärtää?

Siinä missä rakentamamme softa on meille itsellemme koko elämä, asiakkaillemme se on vain pieni osa heidän työtään, yksi työkalu muiden joukossa. Meidän täytyy ymmärtää sitä ympäristöä, jossa tuotetta käytetään, jotta voisimme ymmärtää, millainen tuote palvelisi asiakkaitamme parhaiten. Testaaja, joka ei ymmärrä todellisten käyttäjien toimintaympäristön haasteita, saattaa hyvinkin priorisoida aivan vääriä asioita tehdessään valintoja, mitä osa-alueita tarkastella kriittisesti ja mitä havaintoja raportoida.

Testattavuudesta ja omien rajojen tunnustamisesta

Testaajan rooli nähdään helposti puutteiden etsimisenä muiden tekemisistä. Kun koodi on kehittäjän mielestä riittävän hyvä ollakseen valmis, testaajan tehtävä on tavallaan löytää kaikki merkitykselliset kysymykset, joita ei ole vielä esitetty tai joihin ei ainakaan ole vielä löydetty vastauksia. Tyypillisesti ajatellaan kysymyksen olevan siitä, toimiiko ominaisuus ja vastaako se speksejä. Näkökulmia on kuitenkin monia muitakin. Löytääkö käyttäjä toiminnallisuuden? Ymmärtääkö hän, mitä se tekee? Eteneekö prosessi riittävän sujuvasti? Selviääkö järjestelmä riittävän hyvin raskaista operaatioista? Mitä muutokset tarkoittavat testattavuuden, ylläpidettävyyden tai tietoturvallisuuden näkökulmasta?

Yhden ihmisen voi olla vaikea löytää kaikkia kulmia, joista kysymyksiä voi esittää. Oma osaaminenkaan ei välttämättä riitä kaikkeen. Siksi on tärkeää tunnistaa omat rajansa ja puutteensa ja miettiä, miten niiden yli on mahdollista päästä. Joskus vastaus voi olla tiedon etsiminen, jotta oma näkemys ja osaaminen laajenisi. Joskus vastaus voi olla avun pyytäminen.

Minä kokeilin pari viikkoa sitten esittää tiimille testaukseen liittyvän ongelman, jota en itse pystynyt ratkaisemaan. Saimme aikaan mainion keskustelun testattavuudesta, sekä tavoista mahdollistaa nykyistä paremmin testiautomaation rakentaminen. Suunnittelupöydällä on nyt jo aikaisemminkin pohdittu mutta keskustelumme jälkeen prioriteetiltään noussut muutos, joka toivottavasti parantaisi yhden keskeisen toiminnon käytettävyyttä, sekä vähentäisi testausta vaativien prosessikulkujen määrää. Automaation rakentamiseen liittyviä ongelmia on ratkottu yhdessä, työ on vielä kesken, mutta se kaikkein perustavanlaatuisin este on jo saatu purettua.

On mahtavaa saada työskennellä ympäristössä, jossa ongelmista ollaan valmiita tekemään yhteisiä, ja jossa niihin myös halutaan löytää ratkaisut.

Minä näen testaajan työn keskeisenä tarkoituksena auttaa kehittäjiä työssään. Tärkeää on myös muistaa, miten monin tavoin kehittäjät voivat auttaa testaajaa tekemään työnsä paremmin.

Löydä se mitä on vaikea nähdä

Tiimillämme on pyrkimyksenä pitää kahden viikon välein retroja. Jokainen valitsee vuorollaan aihepiirin, jonka puitteissa laittaa muut täyttämään post-it-lappuja, joita ryhmitellään etsien työskentelyn kipukohtia.

Tällä viikolla pääsimme isojen kysymyksien äärelle etsimällä asioita, jotka eri vaiheissa prosessia tuottavat arvoa, hämmennystä tai ajanhukkaa. Iso tussitaulu peittyi post-it-lapuilla minulle ennennäkemättömällä tavalla.

Suurimmaksi ongelmaksi keskustelussa nousivat isot muutostyöt, joissa usein speksauskin on hieman epämääräinen. Niitä on vaikea edistää, ne vievät paljon aikaa, ja niissä on tavanomaista suurempi riski päätyä tekemään vääriä asioita.

Se, minkä itse koin erityisen mielenkiintoiseksi, oli että puhuimme tavallaan ihan samoista asioista, joilla vain pari viikkoa aikaisemmin olin perustellut testausstrategian luomista: hyödyllistä puuhasteltavaa riittää aina, joten ikäviin tai hankaliin hommiin ei välttämättä koskaan tule tartuttua ainakaan riittävällä tarmolla, jos ei ole tiettyä kurinalaisuutta omassa tekemisessä. 

Siinä missä minä testaajana tarvitsen strategista ajattelua edes nähdäkseni ne kokonaisuudet, jotka eivät mukavuusalueella pysytellen tule testatuksi, kehittäjä tarvitsee kurinalaisuutta ja strategista ajattelua jotta nuo isot ja vaikeat kokonaisuudet saataisiin pilkottua ja tehtyä pois alta. Vaihtoehto on, että niitä joko vältellään, tai edistetään vastahakoisesti mitenkuten milloin ehditään. Ja kun ympärillä tapahtuu koko ajan, rakennettava tuote saa jatkuvasti uusia ominisuuksia, pieniä parannuksia tai vähintään bugifiksejä, vältellen ja nitkutellen edistettävät kokonaisuudet helposti kasvavat, muuttuen yhä vaikeammiksi toteuttaa loppuun asti. 

Ja lopulta aika usein ne hankalimmin edistettävät asiat ovat kuitenkin tärkeitä.

Keskustelimme tavoista, joilla näiden isojen asioiden edistymistä voisi nopeuttaa, ja pohdimme syitä jotka ovat estäneet tässä onnistumista. (Ja vain pari päivää myöhemmin kävimmekin yhteistuumin pilkkomaan yhtä elefanttia.)

Jälkikäteen aloin muistella asioita, joita olen pitänyt testaajan urani suurimpina saavutuksina. Niistä lopulta aika harvat liittyvät tilanteisiin, joissa olen löytänyt bugin toteutetusta järjestelmästä. Parhaita ovat olleet hetket, kun olen keksinyt esittää kysymyksen, joka on paljastanut vältellyn aiheen. Usein ne ovat olleet asioita, jotka ovat selvästi vaivanneet kehittäjiä itseäänkin, mutta kissaa ei ole tullut nostettua pöydälle koska ei ole ollut pakko, ja muita, akuutimpia asioita on riittänyt enemmän kuin omiksi tarpeiksi. Joskus kyse on ollut asioista, jotka vain on ymmärretty eri tavoin, eikä kukaan ole pysähtynyt ajattelemaan asiaa huomatakseen ongelman laajuutta.

Kun puhutaan laadunvarmistuksesta, softan testaaminen on vain pieni osa kokonaisuutta. Vaikutuksiltaan merkittävintä on löytää niitä asioita, joita vältellään tai ei edes nähdä. Vaikeaa tästä tekee se, että testaajan näkökulmasta ne kaikki saattavat olla näkymättömiä. Kehittäjän taas voi olla vaikea nähdä juuri näiden asioiden esiin nostamista oleellisena, ne voivat tuntua joko vähäpätöisiltä tai kaikkien tuntemilta kollektiivisesti vaietuilta asioilta, mikäli niiden olemassaoloon edes kiinnitetään huomiota.

Tässä mielessä retrot ovat loistavia. Loistavia ovat myös hetket, kun löytää paljastavia kysymyksiä. Hyvä alku ovat "miten tämän voi testata", "kuka tätä käyttää", "mihin tämä vaikuttaa" ja "miksi tämä asia ei ole edennyt".

Testaajien ja kehittäjien välillä on joskus melko voimakastakin vastakkainasettelua. Itse pidän enemmän yhteistyömeiningistä. Toivon, että kehittäjät voivat nähdä minun ongelmani yhteisinä ongelminamme. Tämän viikkoinen retro konkretisoi itselleni myös sitä sinänsä aika itsestäänselvää asiaa, että myös kehittäjien ongelmat ovat minun ongelmiani. Lopultahan ne testaajan turhauttavimmat pulmat liittyvät usein juuri asioihin, joista myös kehittäjä on ollut epävarma. Meistä jokainen tekee osansa löytääkseen ja selkiyttääkseen epämääräisiä asioita. Myös minun tehtäväni on tarttua tähän työhön mahdollisimman varhaisessa vaiheessa.

Toistettavuus vs. varioitavuus

Keskusteltaessa siitä, mitkä ovat suunnitelmallisen, ammattimaisen testauksen keskeisimpiä etuja, joskus nousee ajatus testien toistettavuudesta. Kun testitapaukset suunnitellaan riittävän yksityiskohtaisesti, tiedetään täsmälleen, mitä testaaja on testannut, ja samat testit ovat suoritettavissa täsmälleen samanlaisina kierroksesta toiseen, jolloin saadaan eksaktia dataa siitä, milloin jokin toiminto hajonnut. Testit voidaan myös automatisoida.

Toistettavuus on kyllä tärkeää siinä mielessä, että bugiraportoinnissa keskeisimmässä roolissa on tarjota riittävät tiedot virhetilanteeseen johtaneesta toimenpideketjusta, jotta korjauksen tekevä kehittäjä voisi löytää virheen koodista ja korjata sen. Sen sijaan on kyseenalaista, kuinka tarkkaan on tarpeen dokumentoida ne polut, joiden varrelta virheitä ei jollakin testikierroksella löytynyt.

Huomionarvoista on kuitenkin myös se, että yksikään testikierros ei voi testata kaikkia mahdollisia polkuja, joita pitkin todellinen käyttäjä voi järjestelmää käyttää. Myös testauksessa käytetty testidata on vajavaista verrattuna todellisten tilanteiden aikana mahdollisesti tarvittavaan dataan. 

Suunnitelmalliseen testaukseen toki kuuluu miettiä, mitkä ovat sellaisia rajatapauksia, joissa virheet todennäköisimmin ilmenevät jos niitä on, mutta ovelimmat virheet ovat sellaisia, joita ei voi ennakoida. Siksi testauksen kokonaiskattavuuden parantamiseksi testaajan on hyvä varioida toimintaansa kierrokselta toiseen siirryttäessä.

Sattuma on testaajan paras ystävä.

Esimerkiksi, jos prosessin B läpivienti ennen prosessia A aiheuttaa virhetilanteen prosessissa A, asia ei koskaan selviä testaajalle joka testaa prosessin A aina ennen prosessia B. Samoin jos hakutoiminnossa jokin tietty hakutermien yhdistelmä aiheuttaa virhetilanteen, sitä tuskin löydetään miettimällä etukäteen, millaisia yhdistelmiä testaajan tulisi testata.

On myös vaikea nähdä, mitä haittaa testien varioimisesta olisi. Koska yksittäistä testikierrosta ei voida suunnitella niin, että se olisi varmasti se kaikkein tehokkain löytämään virheitä, vaihtaminen toiseen yhtä hyvään seuraavalla kierroksella ei heikennä testauksen laatua lainkaan. 

Lisäksi testauksessa puhutaan hyönteismyrkkyparadoksista, jonka mukaan toistettaessa täsmälleen samaa testijoukkoa, sen kyky löytää virheitä vähitellen heikkenee. Kehittäjät ikään kuin oppivat välttämään niitä virheitä, joita joutuvat toistuvasti korjaamaan.

Toki variaatiot testauksessa asettavat korkeammat vaatimukset bugiraportoinnille, koska tällöin muuta informaatiota virhetilanteeseen johtaneista syistä ei ole käytettävissä. Yksityiskohtainen bugiraportointi on kuitenkin niitä perustaitoja, jotka erottavat hyvän testaajan huonosta testaajasta.

Olenko hyvä testaaja

Minulle esitettiin hiljattain suora kysymys: oletko hyvä testaaja?

Kysymys on hyvä, mutta siihen on vaikea vastata. Mistä tunnistaa hyvän testaajan? Miten voi arvioida omaa hyvyyttään testaajana, jos ei pääse juurikaan tekemään töitä hyvien testaajien kanssa, joiden tekemisiin voisi omaa puuhasteluaan verrata? Ja toisaalta, hyvätkin testaajat ovat erilaisia. Jos saisin työskennellä gurun kanssa, joka saisi minut tuntemaan itseni jollain testauksen osa-alueella kädettömäksi, silti saattaisi olla jokin toinen osa-alue, jolla hänellä olisi opittavaa minulta.

Kehittäjiltä saatu palaute on tietenkin yksi mittari. Esim. "keksii luovia tapoja rikkoa asioita" on luonnehdinta, jonka otan kehuna. Myös kysymykset kuten "miten tämän sinun mielestäsi pitäisi toimia" ja "tiedätkö, onko tämä android-puhelinten yleinen virhe" luovat vaikutelmaa, että ammattitaitooni luotetaan. Samoin tuoteomistajilta, projektipäälliköiltä ja asiakkailta tuleva palaute kertoo paljon siitä, miten hyvin työssään onnistuu.

Pohjimmiltaan he ovat kuitenkin kaikki ihmisiä, joiden oma osaaminen kohdistuu johonkin muuhun kuin testaamiseen - ehkä he eivät vain tiedä paremmasta?

Ehkä hyvän testaajan on hyväkin olla hieman epävarma omasta ammattitaidostaan. Olemme kaikki vain ihmisiä. Kuka tahansa saattaa tehdä virhearvioita, olla keksimättä jotain oleellista tapaa väärinkäyttää järjestelmää tai jopa olla tunnistamatta jotakin testauksen osa-aluetta, joka olisi juuri käsillä olevan projektin kannalta äärimmäisen tärkeä. Tästä syystä testaaja ei voi eristäytyä yksin omaan kammioonsa, vaan hänen tulee jatkuvasti löytää uusia näkökulmia työhönsä. Tähän tärkeä väline on keskusteleminen muiden projektin osapuolten kanssa. Joskus yksinkertainen kysymys voi olla vaikuttavampi kuin päivän testausrupeama.

Niin kauan kuin on pienikin epäilys oman osaamisen riittämisestä, mieli etsii aukkoja omasta päättelystä. Ilman tätä uusia oivalluksia ei tule. Olisi vaarallista kuvitella osaavansa ja ymmärtävänsä jo kaiken.

Testausta on monenlaista. Kurinalaisuuden ja järjestelmällisyyden yhdistäminen luovuuteen ja jatkuvaan oppimisprosessiin on haasteellinen kokonaisuus, jossa minkä tahansa kulman laiminlyöminen voi johtaa kalliisiin epäonnistumisiin.

Siksi ei ole yhdentekevää, kuka tuotettasi testaa.

Regressiojumppaa

Silloin tällöin peruslaiskalle iskee tarve kuntokuurille. Eihän kroppa pysy kunnossa, jollei siitä pidä vähän huolta. Silloin saattaa löytää itsensä surffaamasta kuntokeskusten tarjontaa tai ohjeita treeniohjelman rakentamiseen itse. Yksi vaihtoehto on miettiä, mitkä osat kehosta kipeimmin kaipaavat kohennusta, ja rakentaa sitten joogaohjelma, joka parhaiten tukee juuri näiden alueiden ylläpitoa.

Hathajooga tarjoaa runsaan valikoiman erilaisia liikkeitä, joilla jokaisella on omat positiiviset vaikutuksensa. Ohjelma koostetaan keräämällä joukko liikkeitä ja laittamalla ne sopivaan järjestykseen. Suunnittelussa huomioon otettavia asioita ovat ainakin:

• Mikä on treenauksen tavoite, eli millaisia asioita on tarpeen sisällyttää treeniin.
• Mitkä liikkeet sopivat lämmittelyyn, mitkä taas vaativat lämmittelyä ennen kuin niitä voi tehdä.
• Vastaliikkeet. Monien voimakkaiden venytysten jälkeen on hyvä tehdä vastaliike, jotta keho saa optimaalisella tavalla kuormitusta.
• Flow, missä järjestyksessä liikkeiden suorittaminen tuntuu mahdollisimman luontevalta.
• Harjoitukseen kerralla käytettävissä oleva aika, sekä kuinka usein se on tarkoitus suorittaa.
• Harjoitukseen käytettävissä oleva tila.
• Henkilökohtaiset mieltymykset, eli mikä on kivaa.

Kun ohjelma sitten on rakennettu, sitä suoritetaan suunnitelman mukaisella tahdilla. Jos käy niin hyvin, että kunto pääsee kohenemaan, tai tavoitteita on jostain muusta syystä tarpeen tarkastella uudelleen, ohjelmaa kehitetään lisäämällä, poistamalla tai muokkaamalla siihen kuuluvia liikkeitä.

Prosessi on yllättävän lähellä regressiotestauksen suunnittelua. Myös siinä mietitään tavoitteet, eli mitkä ovat ne asiat, joiden toimivuus on tarpeen varmistaa. Lisäksi on tarpeen pohtia, missä vaiheissa regressiotestit suoritetaan. Ylläpitovaiheessa pitäisi olla selvää, että regressiotestikierros tehdään ennen jokaista julkaisua. Testattavan järjestelmän muuttuessa myös regressiotestien sisältöä voi joutua tarkastelemaan kriittisesti. Regressiotestaukseen sisällytettävien testien laajuuteen vaikuttaa testaukseen käytettävissä oleva aika sekä budjetti. Nämä asiat vaikuttavat myös silloin, kun regressiotestausta automatisoidaan, sillä myös automatisointi vie aikaa, ja automaattitestauksenkin tulokset on analysoitava. Jos taas testit suoritetaan käsityönä, tehtävän mielekkyyden ylläpitämisen kannalta on hyvä sisällyttää suunnitteluun myös ajatus siitä, miten siitä saisi jollain tapaa kiinnostavaa testaajalle. Tehokkuutta ja mielekkyyttä lisää myös testien järjestäminen tavalla, jolla edeltävät testitapaukset mahdollisimman luontevasti valmistelevat seuraavien testitapausten alkuehdot. Joskus voi olla tarkoituksenmukaista sisällyttää suunnitelmaan myös luodun testimateriaalin poistaminen.

Korkean tason tavoitteena joogaajalla on kehon toimintakunnon ylläpito, regressiotestaajalla taas testattavan järjestelmän toimivuuden ylläpito. Testi ei toki itsessään toimivuutta paranna, vaan se vain paljastaa ne paikat, jotka ovat ajan myötä päässeet rupsahtamaan ja kaipaavat nyt tarkempaa huomiota. Vähän niin kuin aloittelevan kuntoilijan lihaskipu paljastaa paikat, jotka ovat päässeet liian vähällä sohvaperunan elämässä.

Testaaja - koodarin vihollinen vai puolustaja?

Testaajien ja kehittäjien yhteistyö ei ole aina ihan kitkatonta.

Kun testaajan eteen tuodaan jotain valmiiksi väitettyä, jonka testaaminen on hidasta koska koko ajan löytyy raportoitavaa, on haasteellista tuoda löydöksiä esiin tavalla, jota hiukankin herkkähipiäinen kehittäjä ei kokisi osin henkilökohtaisuuksiin menevänä nipottamisena. Aikataulu- ja budjettipaineet kiristävät molempien pinnaa, samoin kaikenlaiset "tyhmät" virheet.

Erityisesti kun kyse on valmisohjelmistoon tehtävistä muutoksista, vastaan voi myös tulla vanhaan koodiin liittyviä ongelmia, joiden kiertämisen haasteellisuus siirtää helposti keskustelun korjaustavan etsinnästä bugin merkityksen vähäisyyden perusteluun. Näissä tilanteissa osapuolten voi olla vaikea nähdä tekevänsä yhteistyötä, ennemminkin tuntemukset molemmin puolin risteilevät ärtymyksessä, miksi muutenkin niukkaa aikaa on käytettävä johonkin näin turhauttavaan.

Testaajan tehtävä ei kuitenkaan ole mollata kehittäjää väärin tehdystä työstä, vaan auttaa tätä tekemään työnsä hyvin.

Erityisesti silloin kun testauksesta puhutaan laadunvarmistuksena, testaajan tehtävä on merkittäviä virheitä löytäessään viedä projektin johtoon viestiä, että kehittäjien mahdollisuudet tehdä työnsä hyvin on taattava.

Laatua kun on vaikea saada aikaan, jos sen tekijöillä ei ole tarpeeksi aikaa, tarpeeksi mahdollisuuksia keskittyä, tai tarpeeksi ohjausta.

Harva koodari tekee ihan vaan piittaamattomuuttaan virheitä, ja kokonaisuuden kannalta edullisinta olisi, jos mahdollisimman moni toimintalogiikkaan liittyvä tai muuten merkittävä virhe jäisi kiinni jo silloin kun niitä ollaan kirjoittamassa.

Tässä mielessä olisi myös hienoa, jos testausta ei nähtäisi vain valmiin tuotteen toiminnan verifiointina.

Testaaja voi auttaa ehkäisemään virheitä mm. katselmoimalla määritys- ja suunnitteludokumentteja, esittämällä kysymyksiä sprinttipalavereissa, keskustelemalla rakenteilla olevasta toiminnallisuudesta kehittäjien kanssa, käymällä kehittäjän kanssa demoluonteisesti läpi toteutettua toiminnallisuutta, ja testaamalla hyvinkin keskeneräistä (kunhan hänellä on tieto siitä, mitä voi testata ja minkä ei ole tarkoituskaan vielä toimia). Tärkeää on löytää yhteinen tavoite tekemiselle.

Laatu ei parane testaamalla, vaan tekemällä paremmin.

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.