Blogin kirjoituksen haasteista

Kirjoitteluni aiheet tuntuvat pyörivän erilaisten kriisinpoikasten ympärillä... Tällä kertaa inspiraationa aiempaan kirjoitelmaani tullut kommentti siitä että eikös blogeja enää lueta ja kommentoida.

Keräsin alkuvuodesta listan suomenkielisiä testausblogeja. Olen säännöllisen epäsäännöllisesti surffailut näitä läpi, ja huomannut että enimmäksen trendi tuntuu olevan että alkuun jaksetaan ja sitten kadotaan. Toki löytyy ajatonta tekstiä, josta voisi jatkaa keskustelua vaikka kuinka pitkään alustuksen tai aloituksen jälkeen. Toisaalta taas asioista jotenkin ajattelee keskusteltavan tuoreeltaan.

Huvittavaa sinänsä, mutta minun bloggaamisestani hävisi sekin vähä energia ja aika kun ensin kirjoittelin hetken testausOSYn linkedin-palstalla ja sitten hurahdin kevyesti twitteriin. Tosiasia kuitenkin on että ajan ollessa rajallinen luonnonvara 160 merkkiä testauksesta päivässä on aika paljon helpompaa kuin oikeasti jonkin tarinan kirjoittaminen.

Lisäksi olisi yksinkertaisesti helpompaa, jos useampi kirjoittaisi samaan blogiin, niin ei tarttisi surffailla ihan niin moneen suuntaan.

Pienenä huvittavana yksityiskohtana: minulla on parikymmentä aloitettua blogijuttua, joita en ole suoriutunut kirjoittamaan otsikkoa ja paria riviä pidemmälle... Joskus vielä - ihan kohta. Mutta ensin, vielä muutama hyvä tiivistelmä testisuunnittelun erityispiirteistä uudelle lempitestaussektorilleni.

Testauspäällikkökriisi

Huomaan toistuvasti palaavani pienen turhautumisen tunteen kanssa nykyiseen titteliini: "testauspäällikkö". Kirjoittelin aiemmin siitä kuinka kierolta tuntuu, että testaajasta tulee testauspäällikkö ja toteuttajasta arkkitehti. Edelleen päällikkyys tuntuu tarpeettomalta ja väärään suuntaan ohjaavalta.

Muistan lukeneeni jotain trendilistaa lempiguruiltani, jossa yhtenä trendinä mainittiin että projektinhallinta ja testauksenhallinta yhdistyvät tulevaisuudessa. Testaus jää erikseen, eriytyy, ehkä jopa löytää paikkansa - näin ainakin itse ajattelen.

Testauspäällikkönä minun odotetaan - ulkopuolelta - olevan hallinnollisesti suuntautunut. Minun odotetaan suunnittelevan, ohjaavan, tuottavan mittareita. Ja joku muu onnekas saa tehdä lempityötäni, testausta. Voin mentoroida, opastaa, valmentaa ja kannustaa. Rohkaista ja antaa vinkkejä. Voin vähän tehdä itsekin, mutta odotukset ovat vahvasti muualla.

Sanojen ei pitäisi sitoa, eikä vaivata. Koen silti että jopa aivan samalla työkuvalla, olisin aina mieluummin "testausasiantuntija" kuin päällikkö.

Minun kolleegani, projektipäälliköt tiimissäni, ovat loistavia. Selviäisivät testausasioista siinä kuin mistä tahansa muustakin. Jostain syystä testauspäällikön olemassa olo vaikuttaa enemmän jopa itsetuntoa alentavasti, kun eivät sitten ihan samalla tasolla osaa jokaista detaljia testauksesta.

Odotan innolla ensi viikkoa - saan kolleegan, jolta odotan tukea pohdinnassa tulevasta testauspäällikköroolista.

Kuilu vaatimusten ja toimivan välillä

Vietin taas pari päivää opastaen mukavaa porukkaa testitapausten suunnittelussa. Tästä porukasta ja keskusteluista minulle jäi erityisesti pohdittavaksi, että kuinka yleistä lopulta on, että vaatimukset rajaavat testausta kohtuuttomalla tavalla.

Cem Kanerin materiaaleja muistinvaraisesti lainaten, vaatimukset ovat fiktiota. Parhaimmillaan ne ovat käyttökelpoisia, hyödyllisiä, avuksi.

Jäin pohtimaan, että onko tämä yksi niitä keskeisiä eroja tuoteliiketoiminnan ja projektiliiketoiminnan välillä. Suppealla otoksella kummastakin ei tietysti halua vetää liian pitkälle meneviä johtopäätöksiä, mutta tuntuma on, että projektien tilaamisessa ja toimittamisessa on jotain, joka ohjaa tarpeettomassa määrin siihen, että asiakkaan tarpeita ei koiteta täyttää, vaan vain asioita joita on "vaadittu". Testaajaa jopa kielletään testaamasta mitään muuta kuin vaatimuksissa mainittuja asioita. Muita asioita testataan sitten kun tämän toimituksen osalta ollaan turvassa (aikataulussa / luvatussa laajuudessa), ja asiakas tajuaa että ei saanutkaan täytettyä tarvettaan, mutta vielä uskoo siihen että oma vikahan se toki oli kun ei osannut vaatia.

Jokseenkin hahmotan, että tokihan jokaisesta tunnista pitää saada laskuttaa. Mitta sitä en hahmota, että voidaanko ihan vakavissaan lähteä siitä, että tehtäisiin projekti, joka täyttää vaatimukset ilman väliä siitä millaista tarvetta vaatimukset olivat kuvaavinaan. Kai se on sinänsä luonnollinen vastareaktio muodissa oleville kiinteähintaisille toimituksille.

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.

Paljonko testauksen pitää tuottaa hyötyä?

Vuodet testaushommissa ovat opettaneet, että testaajan tuottama lisäarvo ei ole lainkaan niin suoraviivaista, että testitapausten suunnittelun, suorituksen tai virhemäärien mittaamisella saataisiin kiinni sen tuottamasta arvosta. Testausnäkökulmalla ja testauksella on arvoa, se on hyödyllistä - usein.

Tämä ei kuitenkaan ole itsestäänselvyys. Olen aistivinani että testaus on tullut muotiin erityisesti asiakas-toimittajasuhteissa jopa siinä määrin, että koen että näissä tilanteissa vastaan on osunut kohtia, joissa testausotsikon alla tehty työ ei ehkä tuotakaan kovasti lisäarvoa.

Jos testauksessa käytetään varsin mittava työmäärä, tuotetaan kertakäyttötestitapauksia ko. projektin näkökulmaan ja katselmoidaan niitä suurella panoksella ja lopulta ei juurikaan löydetä ongelmia, voi minusta jo perustellusti miettiä että olikohan panokset oikein asetetut. Etenkin, jos jälkeen tulevat testausvaiheet osoittavat, että löydettävää kuitenkin olisi ollut.

Jos kohdalle osuu projekti, jonka osalta on perusteltua sanoa ettei se testaamalla juurikaan parane erilaisten reunaehtojen vuoksi, onko enää järkevää suositella että kuitenkin testaukseen panostetaan, ja vielä suuremmassa määrin. Vai voisiko testausihminen suositella jopa testaajien poistamista ja muiden ratkaisijoiden lisäämistä? Voisiko otos olla kattavuutta parempi tavoite hyötyjä ajatellen?

Välillä jää sellainen fiilis kaivertamaan, että erityisesti testauspalveluja tarjoavat osaoptimoivat testauksen, eivätkä ajattele testausta osana arvoketjua. Samoja tavoitteita voisi edistää halvemmilla ja tehokkaammilla keinoilla. Vai onko testausasiantuntijan kädet tosiaan niin sidottu ettei lähimaailmaa saa nytkäytettyä lähemmäs raiteita? En usko.

Me ollaan testaajia kaikki

Jossain verkossa surffaillessani GoogleAds päätti näyttää minulle kohdistetusti mainoksen, jossa Reaktor etsi "koodaavaa pääarkkitehtiä". Paikka ei ole kyllä missään määrin minulle kohdistettu, mutta termiin liittyvä teema sattui olemaan testauspuolelta juuri pohdiskelun alla.

Jos mietitään karkeasti ohjelmistokehityksen rooleja, niitä olisi kaiketi kolme: vaatimuskaveri, toteutuskaveri ja testauskaveri. Näistä kuka vaan voisi nk. edetä urallaan hallintovaihteelle ja ryhtyä vaikka projektipäälliköksi. Toteutuskaverista tulee kuitenkin omalla vaihteellaan edetessään arkkitehti, ja testauskaverista testauspäällikkö.

Erityisesti olen ihmetellyt viime aikoina sitä, että toteuttaja joka pomppaa projektipäälliköksi ei yleensä enää kuvaa itseään koodaajana. Testaaja joka siirtyy testauspäälliköksi on hyvinkin vahvasti edelleen testaaja. Erityisesti tämä jäi minua mietityttämään sen vuoksi, että olen ollut huomaavinani, että varsin monet testausasiantuntijat eivät olekaan henkilökohtaisesti vuosikausiin testanneet. Toiset, kuten minä, testaavat kepoisasti silloin tällöin, nauttien pinnallisista mutta silti korjauskelpoisista virheistä joita rajatussa ajassa voi löytää. Koen tiettyä tuskaa, kun niin suuri osa ajasta kuluu ohjatessa, neuvotellessa, mittareita kehitellessä ja nauttien katsoessa kun toiset tekevät rakastamaani työtä hyvin. Kai se on jonkinasteista kateutta. :)

Olen vakuuttunut, että testaus on sekä taito että ajatusmalli. Taito katoaa jos työtä ei harjoita. Ajatusmalli säilyy. Taitopuolella etääntyminen on liian helppoa, kuvaten työtä edelleen kuitenkin samalla sanalla - me ollaan testaajia kaikki, nekin meistä jotka eivät ehdi muilta testaustöiltään testaamaan.