Tarinoita IT-hankkeiden ihmemaasta
Lukijamme on lähestynyt meitä erittäin kiinnostavalla tarinalla julkisen sektorin IT-hankkeista. Tarina herättää varmasti fiiliksiä sekä puolesta, että vastaan.
Hei,
Olen lukenut blogistanne vuosien varrella pari juttua joissa on ohimennen puhuttu julkisista IT-projekteista. Haluaisin nyt tuoda tähän aiheeseen lisävalaistusta.
Olin hiljattain isohkossa julkisen puolen IT-projektissa pääkaupunkiseudulla. Tavallisesta poikkeavaksi tilanteen teki se, että Tilaaja oli hankkinut itselleen ammattitestauksen turvaamaan tilauksen tason. Minä olin yksi näistä Tilaajan testaajista.
Kyseessä oli SAP-ympäristössä pyörivä järjestelmä. Järjestelmässä oli useita osia ja näille omat Toimittajansa ja kaikkien Toimittajien piti saada omat palikkansa keskustelemaan toisten Toimittajien palikoiden kanssa.
No aloitimme tietenkin heti testaustyön kun työmaalle päästiin. Toimittajat olivat saaneet rakennettua järjestelmän jo sille mallille, että järjestelmän eri osiin pystyi kirjautumaan ja niitä yksittäisinä palikoina testaamaan. Vain parin tunnin päästä testauksen aloittamisesta oli selvää, että nyt saattaa hyvin tulla bugien kirjoittamisen uusi Suomen ennätys tai jopa Maailman ennätys. Korostan, että olimme vasta aloittaneet Toimittajien yksittäisten järjestelmän osien testauksen. Bugeja löytyi kaikilta ohjelmistotestauksen osa-alueilta alkaen käytettävyydestä aina turvallisuuteen asti.
Raportoimme välittömästi bugit ja kun raportti saavutti Toimittajat, niin alkoi show jota en ole urallani kertaakaan aikaisemmin nähnyt. Toimittajat ottivat välittömän puolustusaseman ja alkoivat asemasodan testausta vastaan.
Emme osanneet testata, testasimme prosessin vastaisesti ja testasimme täysin vääriä asioita.
Yksi SAP-Toimittajan edustaja huusi ihan suoraa huutoa, sillä bugeja oli liikaa. He eivät olisi millään niitä halunneet korjata niitä, ainakaan samalla rahalla.
Tästä “prosessin vastaisesta” testauksesta nousi oma suosikkini. Toimittajat olivat sitä mieltä, että kun on prosessiksi sovittu nappien painamisjärjestys 1 ja 2 niin se on sitten se eikä muita hyväksytä. Me tottakai testasimme myös mitä tapahtuu kun painaa 2 ja 1, ja niinhän sieltä paljastui että luvattoman monessa kohtaa järjestelmä rakoili ja lopulta kaatui.
On älytöntä olettaa, että loppukäyttäjä ei koskaan painaisi nappeja väärässä järjestyksessä.
Minulle alkoi selviämään pala kerrallansa, että mistä on kyse. Toimittajat olivat vuosikausien aikana tottuneet siihen, että bugien korjaus laskutetaan erikseen ja siitä oli muodostunut heille merkittävä osa projektin laskutusta. Toimittajille on hyvää businesta IT-projektin venyminen, sillä heille se tarkoittaa isompaa laskutusta ja voit uskoa minua kun sanon, että laskutus juokseen.
Toisinaan vitsailin kollegani kanssa, että taitaa olla laskutus Toimittajan ainoa asia mikä toimii hyvin. Minulle jäi käsitys, että oli varsinkin SAP-Toimittajille ensimmäinen kerta kun he kokivat, että Tilaaja testautti tilauksen ulkopuolisilla ammattilaisilla ennen tilauksen hyväksymistä ja tämä nyt sitten tavallaan vaaransi Toimittajien normaalit laskutusrutiinit. Itse henkilökohtaisesti selitin Tilaajalle, että näin bugisesta toimituksesta ei kannata maksaa mitään ja että ennen kuin edes harkitaan laskun maksua, niin bugit on korjattava ja testaamalla todettava korjatuiksi.
Ehdimme toimia Tilaajan palomuurina puoli vuotta kunnes sitten eräänä päivänä tuli ilmoitus:
Johtokunta oli päättänyt antaa potkut Tilaajan testaustiimille.
No eipäs siinä mitään ihmeellistä, ajattelin. Olimme saaneet kuitenkin jo paljon asioita etenemään ja opetettua Tilaajalle tärkeitä asioita IT-järjestelmien tilausprosessista ja softatestauksesta. Olin siis kohtuullisen tyytyväinen kaikesta huolimatta, mutta toki samalla ymmärsin sen, että valmista ei tule tästäkään hankkeesta vuosikausiin, mutta hyvin lähellä he olivat.
Tässä ei kuitenkaan ollut vielä kaikki. Vielä projektissa olessani, sain kuulla että tässä johtokunnassa istuu näppärästi Tilaajan ja Toimittajan edustajat yhdessä. Toki on hyvä asia, että Tilaajalla ja Toimittajalla on yhteinen foorumi, mutta tämä johtokunta pystyy päättämään esimerkiksi että poistetaanko Tilaajalta testaus.
Päätöksen tämän kirjoituksen laatimisesta tein kuitenkin vasta sen jälkeen kun kuulin toiselta testaajakollegaltani, että hänen julkisen puolen IT-projektissa oli johtokunnassa sama järjestys. Heillä vain oli testaustulokset heitetty lähes sellaisenaan roskiin. Kyseinen IT-hanke meni pahasti pieleen ja saimme kaikki lukea siitä valtakunnan ykkösmedioissa.
Tarinahan jatkuisi vaikka kuinka pitkään ja herkullisista yksityiskohdista ei ole puutetta. Lopuksi mainittakoon vielä yksi sellainen. Koimme nimittäin tilanteen, missä Toimittajat olisivat halunneet myydä Tilaajalle omat testaajansa tai “konsulttinsa” kuten SAP-piireissä on tapana sanoa. Tämä on ajatuksena aivan käsittämätön.
Tilannehan olisi täsmälleen sama, jos huoltaisit itse oman autosi ja suorittaisit vielä katsastuksen päälle omakätisesti.
Kaikesta huolimatta kyseinen projekti oli minulle ehkä urani paras. En nimittäin ole armeija-aikani jälkeen nähnyt kun aikuinen mies huutaa ja ulisee täyttä kurkkua työaikana. Sain kokea hurjan konkreettisesti testauksen tehon ja minä tarvitsin tämän kokemuksen. Tästä on hienoa jatkaa.
Kun Toimittaja huutaa kurkku suorana, on testaaja saattanut tehdä jotakin oikein.
Osuvaa tekstiä !
Erkki Laitilalle. Ei kai tarinan ongelman ydin suinkaan ole testaajien tai koodaajien ammattitaidossa? Millä tavalla teorian hyvä hallinta olisi estänyt tarinan lopputuleman?
Erittäin antoisaa luettavaa kaikkien kommentit! Kiitos niistä!
Pysähdyin miettimään Maaretin kommenttia siitä kuinka korjaaminen on usein mutkatonta ja nopeaa. Eniten haaskaantuu kuitenkin aikaa vääntämiseen siitä onko kyseessä muutospyyntö vai bugikorjaus.
Keskustelu siitä aiheesa on eritätin subjektiivista. Sehän on tietysti mielipideasia, jonka puitteissa raha merkitsee paljon. Hyväksytyistä muutospyynnöistä saa laskuttaa, bugikorjauksista ei. Mielenkiintoista olisi tietää saako siitä vääntämisestä laskuttaa, vaikka lopulta todettaisiinkin löydös bugiksi, joka kuuluu takuun piiriin?
Valtion projekteissa tyypillistä on, että toimittajapuolen päätöksen tekijät ovat entisiä tilaajapuolen virkamiehiä, jotka sopivat asioista entisten kollegoiden kanssa. Sellaisia henkilöitä yritykset mielellään palkkaavat hyvien etujen kera. Toimittajat valikoituvat henkilökohtaisten suhteiden perusteella, ei suinkaan tarjouspyyntöjä analysoimalla. Mutta koska Suomi on olevinaan maa, jossa ei ole korruptiota, niin näitä asioita ei voi kukaan tuoda omalla nimellään julkisuuteen pilaamatta työuraansa. Virkamisten ja ex-virkamiesten symboosi siis sen kun jatkuu ja kansa maksaa.
Mitä tulee projektityön ja ohjelmistotyön laatuun, niin surullinen tosiasiahan on, että alalla on edelleen täsmälleen samat ongelmat kuin oli jo 60-luvulla. Mitään todellista kehitystä ei ole tapahtunut ihmisten tavassa toimia. Uudet menetelmät ovat olleet vanhojen periaatteiden verhoilua uusiin sanoihin.
Keski-käisten ulosajo IT-firmoista taas perustuu siihen, että nuoret eivät halua työpaikalleen kokeneita ihmisiä muistuttamaan siitä, kuinka huonosti asiat oikeasti ovat. Softaprojektien halutaan olla mukavaa puuhastelua ja epäkohtiin huomionsa kiinnittävät ihmiset pilaavat tunnelman.
Liiketoimintasovellusten suunnittelu ja testaus on tavallisesti asiakkaan projektihenkilöiden vastuulla. Toisin sanoen ihmisten, joilla on toimialaosaamista, mutta harvemmin minkäänlaista ohjelmistoteknistä osaamista. Tällaisten määrittelyjen ja testausraporttien lukeminen on pääsääntöisesti masentavaa puuhaa. Ongelmat lähtevät jo siitä, että testaajien sanavarasto ei riitä ohjelmiston kuvaamiseen. Kryptisten kuvausten ja kuvakaappausten selvittely on toki tärkeää, jotta ohjelmiston määrittely selkiytyy, mutta mistään ammattimaisesta testauksesta ei voi puhua.
Koska bisneskulttuuriin kuuluu, ettei asiakkaille aiheuteta mielipahaa ainakaan sanomisilla, niin toimittajapuolella testausvaiheeseen yleensä suhteudutaan samaan tapaan kuin lasten kiukutteluun. Priorisoidaan, jotta saadaan tärkeimmät bugit korjattua, yritetään pitää sovituista asioista kiinni (ei uusia ominaisuuksia), ja toisinaan korjataan helppoja ei-tärkeitä virheitä, jotta hyvä henki säilyy.
Kriittistä ei ole havaittujen puutteiden korjaaminen, vaan se koska laskun kuittaava asiakkaan maksumies päättää, että ohjelma on valmis otettavaksi käyttöön. Maksumies harvemmin osallistuu suunnittelun ja testauksen yksityiskohtiin, mutta kantaa ainakin periaatteessa vastuun epäonnistumisesta, yhdessä toimittajan kanssa. Toimittajan vastuu on siinä, että rahat maksetaan tavallisesti osissa, usein vieläpä niin, että suurin osa tulee vasta käyttöönoton jälkeen. Jos siis homma ei toimi, rahaa ei tule, tai se on aina tiukassa, jatkuvien epämiellyttävien neuvottelujen takana.
On selvää, että liiketoimitasovellusten toimittajat eivät ole tottuneet ammattimaiseen testaukseen, jonka tuloksena on pitkä lista enemmän tai vähemmän tärkeitä, mutta aina kiusallisia puutteita. Sellaisia, jotka asiakas voi nostaa esiin lypsääkseen lisätyötä ilmaiseksi. Alustaan liittyviä ongelmia ei usein voi realistisesti edes korjata. Lähde siinä sitten soittamaan SAP:lle ja vaatimaan korjauksia.
Olen ollut alalla kymmenisen vuotta, enkä koskaan ole nähnyt ammattimaista ohjelmistotestausta, jos tietoturva-auditointeja ei sellaiseksi lasketa. Hienoa, että viette tätä eteenpäin!
Antti: Eiköhän se vääntökin kaikkiaan laskuteta, vaikkei suoraan niin välillisesti. Olen tykästynyt ”relational contracts” -konseptiin, jossa sekä muutos, virhe että palkkioraha laitetaan sopimusteknisesti samaan laariin. Niinpä toivottavasti ainakin saadaan toimittajapuolellekin tarve ja tavoite tehdä mahdollisimman vähillä muutospyynnöillä järjestelmä joka tekee sitä mihin se on tarkoitettu.
Luulen ettei elinikä auta minua ymmärtämään miten voi olla eläkkeen laskentajärjestelmä, joka toimii määrittelyjensä mukaan mutta ei laske eläkettä oikein. Mutta joitain osia siitä mysteeristä luulen jo matkan varrella tarttuneen.
Tietoviikko otti tekstistä ja keskusteluista oikein tyylikkäästi kopin. Julkinen keskustelu polttavista aiheista on aina hyvästä: http://bit.ly/T2La5C
Kirjoitin oman näkökulmani hieman pidemmin omaan blogiini: http://testauskirja.blogspot.fi/2012/08/onko-buginen-jarjestelma-it.html
Aikamoista lapsenuskoa ”suurten toimittajien” tunnettuihin (~sitähän ne muutkin käyttää) on havaittu myös business-puolella.
Järjestelmien puutteita ja bugeja raportoitaessa ei Tilaajakaan aina meinaa uskoa, että moisen kertaluokan reikiä näistä markkinajohtajista sitten löytyy.
Niittyviita on rohkea mies – todistaa sen , minkä moni jo tietää: suurissa julkishallinnon it-projekteissa on niin paljon hyöytyjiä (pimeitä välistävetäjiä myös?), että se takaa esim. terveyshuollon atk-puolen jälkeenjääneisyyden vuosiksi eteenpäin.
>Toimittajan ammattitaitoa on määritellä homma hyväkatteiseksi
>ja tietää miten se tehdään.
Eikohan projektit mene halvimman hinnan perusteella. Isoimmat palvelutalot tekevat niin matalan tarjouksen kuin pystyvat, sopimuksen jolla toimitetaan jotain paivaan x mennessa ja yritetaan CR:lla vedattaa kunnollinen kate takaisin. En edes muista koska oma jattamani tyomaara-arvio olisi mennyt omalta bid managerilta lapi ilman etta jokainen VBS-elementti vedetaan juustohoylalla pienemmaksi kun se T:lla alkava firma tekee kuulemma niin ja niin halvalla. Siina on sitten kiva selitella asiakkalle sutta toimitettaessa etta talla mennaan – rahaa ei ole enempaan eika aikataulu anna myoden.
Enpä ihmettilisi yhtään, vaikka puolustusvoimien SAP hankkeesta olisi kyse… Lievästi sanottuna tympäisee veronmaksajien rahojen tuhlaaminen. Itellä hyvä, että riittää rahat ruokaan ja samalla hyvät veljet romuttaa hyvinvointivaltiota minkä ehtivät.
Kiitos hyvät lukijat rohkeista kommenteista ja antoisista keskusteluista!
On ollut hyvin mielenkiintoista seurata keskustelua tämän aiheen tiimoilta ja olla myös mukana paljon kahdenkeskisissä kahvipöytäkeskusteluissa.
Mielenkiintoista tämä on siksi, että suurin osa tapaamistani henkilöistä uskoo tietävänsä mistä projektista tässä oli kysymys. Henkilöiden kertomuksissa samankaltaisia projekteja eri tahoille/loppuasiakkaille on tullut vastaan nyt yli 10. Tässä kuvauksessa piilee siis myös joiltakin osin varsin yleinen käytäntö.
Minulle tämä asia tiivistyy yhteen tai kahteen kysymykseen: tämä on siis tilanne nyt, mutta mitä me testaus ja ohjelmistokehittäjien yhteisönä voimme asialle tehdä? Ja mitä me aiomme asialle tehdä?
Syyllisten etsiminen johtaa vain entistä kireämpään umpisolmuun eikä tuo ratkaisua. Jokaisessa osapuolessa on omat hyveensä ja paheensa.
Tarvitaanko lainsäätäjän apua? Pystytäänkö me ammattilaiset yhdessä tämä ratkaisemaan keskenämme? Kuka näyttäisi esimerkkiä? Jos ehdotan, että valitaan yksi julkinen projekti ja tehdään siitä positiivinen esimerkki, niin saako tämmöinen ajatus kannatusta?
Ammattitestaaja,
Erittäin hyvä pointti. Asioista valittaminen onnistuu keneltä tahansa. Ratkaisujen ehdottaminen ja toteuttaminen onkin sitten niiden todellisten gurujen hommaa 🙂
Kaikki lähtee ongelmien tunnistamisesta. Sen jälkeen voidaankin edetä seuraaviin vaiheisiin, jotta joku kaunis päivä meillä onkin toimiva IT-järjestelmien ostamisen ja toimittamisen järjestelmä. Matkaa lienee kuitenkin vielä pitkästi jäljellä.
Kuulostaa liiankin tutulta. Suurten ohjelmisto-, palvelu-, ulkoistushankkeiden kohdalla mennään usein ainakin julkisella sektorilla metsään, kun tarjouspyynnön kriteerejä ja eri asioiden painotuksia ei tehdä oikein ja huolella. Tätä tosin tapahtuu ihan samalla tavalla myös yksityisellä puolella. Tarjouspyyntöjen jopa kymmeniin, mitä eksoottisimipiin (esim. vaikkapa 2 tunnin taattu korjausaika kaikkialla Suomessa) vaatimuksiin on vastattava kyllä ja hintakin on vielä saatava ”kohdalleen”, jotta päästään kynnyksen yli tekemään se sopimus. Jokaisella vähänkin suuremmalla IT-alan yrityksellä on ns. Margin recovery plan, joka tehdään tarjousvaiheessa hyvin huolellisesti. Muuten ei ”nahkoineen” tai miinus-katteella tarjouksen tekemiseen tule lupaa esikunnasta. Erilaisia laskutettavia toimenpiteitä on siis saatava tehtyä, jotta katemarginaali saadaan sopimuksen aikana hilattua esikunnan vaatimalle tasolle.
Se yritys, joka tarjoaa oikeiden kustannusten ja arvioiden mukaan, ei tee yhtään isompaa sopimusta yksityisellä tai julkisella sektorilla. Julkisen puolen hankintalakiin pitäisi ilmeisesti tehdä parannuksia. Yksityisellä puolella kysymys on johdon, IT:n ja ”sourcingin” ammattimaisesta yhteistyöstä ja kustannusten tekemisestä mahdollisimman läpinäkyviksi toimittajien kanssa.
Ehkäpä tämä on lapsellista toiveajattelua. Saahan sitä unelmoida.
Luulenpa, että samassa laivassa on sekä julkinen että yksityinen sektori. Ainakin oma kokemukseni jälkimmäisestä on, että ei ole hallussa sen enempää tarve- kuin vaatimusmäärittelykään. Onneksi on iso joukko konseptin kehittäjiä, jotka osaavat kyllä sanoa minkalaista räätälöintiä järjestelmä vaatii, että se sopii meidän käyttöön.
Ja kohta huomataan, että muuataman miljoonan järjestelmään on jo kulutettu 30 miljoonaa, mutta ei siinä vielä mitään. Tätä käytetään sitten perusteena: ”Olemme käyttäneet jo nin paljon tähän, ettei voi muuta kuin jatkaa:” Firman kannalta olisi paljon kannattavampaa heittää pilattu järjestelmä roskiin, mutta ymmärrettävästi yksilön kannalta tilanne on toinen. Kukapa sitä virheensä haluaa myöntää.
Olen täysin samaa mieltä Antin kommentista: ”Kaikki lähtee ongelmien tunnistamisesta”. Kun tavoitteena olevan toiminnallisuuden logiikka riippuvuuksineen on ymmärretty ja dokumentoitu, tekninen toteutus on se yksinkertaisempi osa projektia.
Kiitos arvokkaasta ”testausraportista”. Olen jokusen vuoden jo tehnyt tietotekniikkahommia. Näin tökeröä esimerkkiä asiakkaan osaamattomuudesta en ole kuitenkaan ennen nähnyt, enkä kuullut.
Kysymys kyseisen SAP-järjestelmän tilaajalle: suostuisitko matkustamaan lentokoneella, jota ei ole testattu sekuntiakaan? Tai ostaisitko 200 000 eurolla auton, jota kukaan ei ole – missään vaiheessa – tarkastanut? Minulta jäisi kaupat tekemättä.
Suurin syy IT-projektien epäonnistumiseen on osaamattomuus. Tuo ilmenee monessa tilanteessa:
1. Asiakas ei osaa itse arvioida työmääriä -> on siis luotettava toimittajan työmääräarvioon -> luotetaan toimittajan tarjoukseen. Toimittajien tarjousten luotettavuus on samaa tasoa kuin teenlehdistä ennustaminen. Nimittäin aina löytyy kilpailutuksessa pari järjestelmätoimittajaa, jotka ovat höylänneet työmääräarvionsa niin alas, että kaupat syntyvät vuorenvarmasti, jos toimittajan valitsemisen tärkein kriteeri on hinta. Asiakas herää todellisuuteen siinä vaiheessa, kun käyttöönottopäivänä on puolet järjestelmästä koodaamatta ja kustannukset kasvaneet moninkertaisesti tarjoukseen verrattuna.
2. Megaprojektit. Tuollaisen 200+ htp:n projektin toteuttaminen – ilman osittamista – natisee liitoksistaan erilaisia megaluokan riskejä:
a) Valtavasti speksaamista & suunnittelua (onko asiakkaalla kokonaiskäsitystä järjestelmän ominaisuuksista, ymmärtääkö asiakas yksityiskohtaisesti, mitä järjestelmällä pitää pystyä tekemään ja ymmärretäänkö esim. järjestelmänosien väliset riippuvuudet?).
b) Valtavasti koodaamista & testaamista (ja uudelleenkoodaamista/testaamista/määrittelemistä, koska speksihän tarkentuu ohjelmoijien ja testaajien palautteen perusteella).
c) Kuka haluaa osallistua projektiin, joka myytiin asiakkaalle epärealistisella – siis höylätyllä – aikataululla & kustannuksilla?
3. Immateriaalioikeudet. Kun noihin edellä listattuihin sudenkuoppiin lisätään vielä se, että asiakas ei tajunnut vaatia järjestelmän immateriaalioikeuksia itselleen, saadaan luotua erinomainen rahasampo toimittajalle. Siis toimittaja lähettää erittäin tunnollisesti laskuja, mutta softan laatu kehittyy mikroskooppisen pienin askelin, jos sitäkään.
Summa summarum: IT-projektien ja tietojärjestelmien laatu paranee roimasti sinä päivänä, kun tilaajien osaaminen paranee.
Meillä IT-alan ihmisillä on peiliin katsomisen paikka. Mielestäni tällä alalla on paljon valehtelua ja liian vähän kiinnostusta & kunnioitusta työn laatua kohtaan.
Ehdotuksiani nykytilanteen korjaamiseksi olen kirjannut esimerkiksi tänne:
http://www.linkedin.com/groups/Julkishallinnon-kaikkiin-ITprojekteihin-saatava-ennakkoarviointi-4138461.S.100774260?qid=b77acfdb-84de-4d5b-ab25-f22972703412&trk=group_items_see_more-0-b-ttl
Erittäin hyvä listaus Pekka. Täytyi aivan käydä liittymässä mukaan JulkICT -grouppiin Linkedinnissäkin 🙂
Hieno homma, Antti:) Toivon softakehityksen ihmisten osallistuvan aktiivisesti julkishallinnon ICT:n strategiatyön kommentointiin (http://www.linkedin.com/groups/JulkICTstrategia-4138461). Nyt on mahdollisuus vaikuttaa julkishallinnon linjanvetoihin.
Ohjelmistotestauksen osalta olen samaa mieltä kuin muutama yllä kirjoittanut alan kollega: testauksen yksi peruskivi on riippumattomuus. Testaajilla ei saa olla kytkostä järjestelmän toteuttajiin. Muutoin tulee mieleen tarina ketusta, joka palkattiin kanatarhaa vartioimaan..
Vaikka kuvaus SAP-katastrofiprojektista oli karua luettavaa, se oli samalla hyvä kuvaus testaajan arjesta. Joskus voi tosiaan syntyä toimittajan kanssa kiistaa, kun testaajat ovat tehneet nk. työnsä liian hyvin. Noissa tilanteissa kannattaa muistaa yksinkertainen asia: testaaja ei ole toteuttajatahon kumartelija. Testaajan tehtävä on työskennellä laadun vartijana – puolueettomasti. Samalla testaaja kantaa vastuunsa asiakkaan ja projektin tavoitteiden saavuttamisessa. Laatu on odotusten täyttämistä:
http://www.mmmtike.fi/www/fi/ajankohtaista/blog.php?we_objectID=267
Ohjelmistotestaus on vielä suhteellisen uusi osaamisalue tietotekniikassa. Laadunvalvonnan merkityksen ymmärtämisessä on sekä tilaajilla että toimittajilla melkoisesti tekemistä. Sitä ennen tulemme näkemään vielä – valitettavasti – monia katastrofiprojekteja.
Toisaalla on paljon tekemistä testauksen edellytysten hahmottamisessa, kuten testausosaamisen vahvistamisessa, järkevien testausaikataulujen suunnittelussa ja tiedonsaannin varmistamisessa (toteutuksen etenemisen status, määrittelyjen muutokset ym.).