Viksumman testaamisen hidasteita asiakas-toimittajamaailmassa

Olen viime aikoina miettinyt varsin paljon taas tutkivaa testausta, asiakas-toimittajaprojektien näkökulmasta. Matkalla voi olla muutamia hidasteita:

- suunnittelun ja testaamisen erilainen hinnoittelu. Jos sattuu olemaan tilanne, jossa testaustyötä hinnoitellaan eri lailla riippuen sen vaativuudesta ja on luokiteltu, että suunnittelu on vaativaa ja testaaminen ei, tiessä on kyllä pieni kuoppa. Osittain tämä luokittelu kerjää sitä että tehtävät annetaan eri henkilöille, osittain sitä että valmistaudutaan mahdollisimman paljon, jopa yli sen hyödyllisen ja oikeasti tarpeellisen. Erityisesti haasteelliseksi muodostuu se että haluaisin sen halvemmalla hinnalla tehtävän työn sisältävän merkittävässä määrin nk. kalliimman hinnan töitä. Oikeasti noissa tilanteissa kyllä sanotaan että 100 tuntia testaukseen liittyvää työtä olisi keskimäärin jotain kahden hinnan väliltä.

- vaatimukset. Elisabeth Hendricksonilla oli jossain esityksessään oivaltava kommentti siitä, että lähes jokainen bugi on lopulta - toteuttajansa näkökulmasta - muutos vaatimuksiin. Jos ei ole ajateltu yllättävää vuorovaikutusta käyttöliittymän kanssa, vääränlaista syötettä naapuriohjelmalta tai että joku voisi joskus käydä kahvilla kesken tekemisen ja ohjelma ei tässä tilanteessa toimi, onhan se jollain tapaa perusteltua sanoa, että pyydetään uusia asioita. Mitä tarkempaan vaatimusdetaljiin mennään - jopa pseudokoodaukseen - sitä sidotummaksi suhteessa vaatimuksiin muuttuvat myös testaajan kädet.

- suojautumistarve. Varsin monesti sopimukseen ja projektisuunnitelmiin on osattu kirjata, että testit toimitetaan ennakkoon, ja toimittaja varaa luonnollisesti itsekin aikaa varmistaakseen, että luovutuksen tai hyväksynnän testit läpäistään. Se on paljon helpompaa toimittajan näkökulmassa, jos kerrotaan mahdollisimman täsmällisesti mitä aiotaan kokeilla ja miten. Niinpä asiakkaita tulee helposti ohjattu pois tutkivasta testauksesta, enemmän ennakkoon kirjattuun tyyliin.

- ajoitukset. Kun jostain on sovittu hankinnan alkuun, tuntuu että muuttaminen on tuskallista. Prosesseja pitäisi kehittää projektien ulkopuolella, erillisissä projekteissa, etteivät sotkisi tämän suunnitelmia ja työmääriä. Ja kun testausta tupataan valmistelemaan vasta kun projektin puitteet muuten on sovittu, aika on harvoin suoraan oikea.

Hidasteita, ei esteitä. Taidan alkaa miettiä seuraavaksi hyväksymistestausprosessia, ja siihen rakenteita, jotka sallivat ja tukevat fiksua testaamista.

Hyväksymistestauksen dokumentaation jakaminen toimittajalle

Keväällä IIR:n seminaarissa muutamassakin puheenvuorossa pohdittiin hyväksymistestauspuheenvuorojen osalta periaatetta dokumentaation jakelussa toimittajalle.

Testitapausten osalta silloin taisi vallitseva käsitys olla, että parempi olla antamatta. Syyt olivat kaiketi:
- Huoli siitä että toimittaja testaa vain näillä testeillä ja kokonaisuutena saadaan huonompaa laatua
- Riippuvuudet asiakkaan materiaaleihin aikataulullisesti sovittuina aiheuttavat tarpeettomia paineita asiakaspäässä materiaalin viimeistelyyn
- Asiakkaan materiaalin odottaminen antaa epävirallisen luvan luovuttaa oman testauksen valmistelun yrityksen kanssa ja vähentää vastuunottoa

Testitapausten osalta olen edelleen eri mieltä. Minusta ne kannattaa antaa. Parempi että edes ne toimivat, kuin että viimeisen hyväksymistestin aikana tarvitsee niistäkin huomata etteivät toimi. Kun lähtökohtaisesti lähtee siitä että testi ei ole äärimmäisen toistettava vaan lähinnä muistilistan omainen, näkisin että riskiä siitä että toimittaja kuvittelee vastuun testisuunnittelusta siirtyneen asiakaspäähän olisi hallittavissa. Ja korostetusti kannattaa varata oikeus ja mahdollisuus tutkivaan testaukseen, joka vielä entisestään täydentää suunniteltua kokonaisuutta.

Testaussuunnitelmat ovat minusta paljon haastavampi kysymys. Erityisesti nykymaailmassa missä lähestulkoon järjestelmä kuin järjestelmä koostuu eri tekijöiden osista, en aina ole ihan vakuuttunut että haluaisin avata kaikille osapuolille kaikki näkökulmat riskeihin, mitä osana hyväksymistestausta pitää pohtia. Jotkut asiat kun ovat vaan meidän organisaatiolle. Ja ainakaan minua ei kiinnosta tästä syystä että kirjaan suunnitelmaani nk. arkaluonteisia asioita ja arvioita pohjana riskiarvioilleni, kirjoittaa toista "siistittyä" suunnitelmaa. Sen osalta minusta saa riittää, että testaamme. Jos siinä on jotain minkä kertominen auttaa viestintää, pidän aiheesta mielellään silmäkkäin session. Ja sekin on tietysti lähestulkoon aina.