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.
Ei kommentteja :
Lähetä kommentti