Category: Ohjelmistotestaus

Olen vieraantunut henkilöbrändi -käsitteestä. Ammattimaine iskee enemmän. Mutta mistä ammattimaineessa sitten on kysymys? Sitä kuvaa parhaiten sana kolmiyhteys ja mielikuvituksen Moleskinevihkoon piirtyvä kolmio.

Ensimmäiselle sivulle kirjoitetaan taito. Taito on onnistumisen ensimmäinen edellytys. Esimerkiksi toistaitoisen testaustunarin on vaikea rakentaa mainetta. Ensin pitää pyydystää paljon bugeja. Joskus sosiaalisessa mediassa törmää “instajulkkiksiin”, jotka yrittävät ponnistaa omalla tontillaan ammattimaineeseen ilman näyttöjä työtaidoista.

Muutama vuosikymmen sitten taito saattoi riittää. Ainoa tapa saada potkut oli, jos paikkakunnan tehdas sattui palamaan ja konttori oli kärventynyt. Tänään on ihan sama kuinka priimaa jälkeä työstä syntyy, potkut tulee, jos asiakas ei enää palaa. Pelkkä taito ei enää riitä.

Kolmion toinen sivu on tyyli. Miten asiantuntijana hommat hoidamme. Tyyli tarkoittaa tapaa ajatella, viestiä ja työskennellä. Kukaan ei halua työskennellä mulkeron kanssa. Sen sijaan ammattimaineen kolmiyhteydessä tyyli tarkoittaa sitä, että jos katoat, jengillä tulee ikävä.

Kolmas ja viimeinen sivu viittaa statukseen. Liian moni uskoo, että ammattimaine tehdään hamuamalla statusta. Googleta vaikka kokeeksi Facebookin algoritmiuudistus. Isossa osassa hakutuloksista digitalistin statuksella esiintyvä noviisi toistelee sokeasti ”Kyllä, Facebookin algoritmit muuttuvat”. Tyyli saattaa olla kunnossa, mutta sanat kumisevat tyhjyyttään, jos työnäytteillä todistettu taito puuttuu.

Status on taidon ja tyylin oheistuote.

Miksi sitten olen vieraantunut henkilöbrändin käsitteestä? Erään viisaan miehen sanoja lainatakseni, brändi on vain yritys kaupallistaa kentällä kasvanut maine.

Tähtää siis ensin timanttisesta taidosta ja tyylista taottuun ammattimaineeseen.

Tarina on peräisin Marko Rytkösen kynästä. Marko on Vuoden Testaaja -äänestyksessä ehdokkaana. Äänestämään omaa suosikkiasi pääset TÄSTÄ

Joitain vuosia sitten johdin testausta yhdessä kansainvälisessä projektissa. Palvelu mitä me tehtiin oli täysin uusi, kuuminta hottia siihen aikaan. Tai niin me ainakin uskottiin. Odotin innolla, että sain uuden version testattavaksi. Pääsin vaikuttamaan tuotteeseen, toiseksi eniten tuotepäällikön jälkeen. Olinhan minä ja mun testitiimi ensimmäisiä oikeita käyttäjiä ja mulla siten aitiopaikka tuotteeseen. Ensimmäisenä maailmassa.

Testaus oli ulkoistettu ja minä johdin sitä. Minulla oli 10 hengen tiimi innokkaita testaajia Kiinassa. He olivat päässeet mukaan kansainväliseen projektiin tekemään tätä uutta coolia palvelua. Heidät oli valittu muiden ehdokkaiden joukosta. Vieläpä länsimaiselle asiakkaalle. Siihen aikaan se oli heille uutta ja ihmeellistä, ja tämä lisäsi intoa entisestään.

Valitettavasti testaajissa asui innokkuuden lisäksi myös pelko. Pelko epäonnistumisesta. Pelko rangaistuksesta. Tämä kävi ilmi kick-off palaverissa, kun yksi heistä kysyi kainosti:

Montako ignorattavaa bugia meistä jokainen voi raportoida, ennen kuin meitä rangaistaan?

Tämä pysäytti minut täysin. Se nostatti läjän muita kysymyksiä. Miten he voi testata, jos eivät uskalla raportoida löydöksiä? Kumpi voittaa, innostus vai pelko? Ja ennen kaikkea: mitä minä voin tehdä omalta osaltani, jotta pelko häviää? Sillä jos testaajalla on pelko raportoida löydöksiä, se olisi yhtä paha asia, jos kokki pelkäisi laittaa ruokaan mausteita. Tai postinkantaja pelkäisi laittaa lehden postilaatikkoon. He eivät pystyisi tekemään työtänsä niin hyvin ja tehokkaasti, kuin ilman pelkoa. Sama pätee testaamiseen. Löydösten raportointi testauksen stakeholdereille on kaiken aa sekä oo.

Onneksi sain käännettyä pelon pois ja kaikki meni lopulta hyvin. Aikaa se vei, koska he olivat edellisellä asiakkaalla saaneet rangaistuksia tästä samaisesta asiasta. Siksi olivat kysyneet tätä myös minulta. Testaustiimi osoitti hyvyytensä. Raportoivat paljon uusia ideoita ja bugeja. Myös bugeja, joita ignorattiin myöhemmin. Samalla managerit olivat tyytyväisiä, olivathan he tarjonneet minulle alun perin 20 testaajaa, mutta suostuin ottamaan “vain” 10 (reilun kahden viikon neuvotteluiden jälkeen). Managereiden näkökulmasta saimme siis testattua puoleen hintaan. Ottivat tästä casesta oppeja muihin sen alueen projekteihin meidän työpaikalla.

Olen törmännyt urallani myös toisenlaiseen pelkoon. Pelkoon siitä mitä testaajalle käy, jos hän ei löydä kaikkia bugeja. Sinänsä hassu pelko, koska kuten kaikki tietää, testaajan on mahdotonta löytää kaikki mahdolliset bugit. Tässä tapauksessa testi päällikkö oli kysynyt alihankkijalta, miksi he eivät olleet löytäneet yhtä tiettyä bugia tuotteesta. Tämä kysyttiin tuotekehityksen aikana, eli tuote ei ollut vielä edes julki. Bugi ei siis ollut osunut ns. tuulettimeen vielä. Alihankkijan johtaja oli ratkaissut asian itsenäisesti ja vastasi seuraavasti.

Ongelma selvitetty. Kyseinen ihminen ei työskentele enää meillä.

Toisin sanoen, meidän hyvää tarkoittava kysymys, josta oli tarkoitus oppia testaamaan paremmin, seurasi irtisanominen. Tämä tapahtui maassa, jossa ei maksettu messeviä 18 kuukauden irtisanomispaketteja, mitä Suomessa oli silloin tapana jakaa.

Luottaisitko itse lääkäriisi, jolla on pelko tutkia potilasta ja tehdä diagnooseja? Lääkäriin, joka ei uskaltaisi katsoa kurkkuun, kun kerrot että kurkku on kipeä. Antaisitko hammaslääkärin, joka pelkäisi porata hampaita, hoitaa sinun hampaitasi?

Yllämainitut pelot ovat onneksi ääritapauksia, mutta olen kohdannut myös pienempiä pelkoja, jotka yhtälailla vaikuttavat testaajien työhön. Pidä siis huoli siitä, että myös testaajilla on työympäristö, jossa he voivat työskennellä ilman pelkoa. Ymmärrä samalla, että se mikä ei pelota sinua, voi pelottaa muita. Näin saat parempaa testausta ja tuotteestasi tulee todennäköisesti entistä parempi. Voit jopa säästää rahaakin samalla.

P.S. Marko on työskenellyt testauksen parissa yli 20 vuotta. Hän on ollut testaamassa sekä rakentamassa ja johtamassa testausta useissa erilaisissa projekteissa ja organisaatioissa. Viimeiset vuodet hän on toiminut sisäisten IT-osastojen test managerina, vastuualueenaan testauksen kehittäminen monitoimittaja ympäristössä, jossa applikaatioita on satoja ja tiimejä sekä alihankkijoita kymmeniä. Hän on ketterien lean-toimintatapojen innokas puolestapuhuja ja pyrkii rakentamaan testausta sisään tuotekehitysprosessiin ja kehittämään tätä kokonaisuutta yhdessä tiimin kanssa. Lisäksi hän on kiinnostonut ihmisten valmentamisesta ja johtamisesta.

Hän tekee yhä vapaaehtoistyötä FiSTB:ssä, jonka hallituksessa hän oli vuosina 2012-2017. Marko oli FiSTB Testing Assemblyn pääjärjestäjä vuosina 2015-2017 ja hän on yhä mukana järjestämässä tätä yhtä Suomen suurinta ja suosituinta testausseminaaria. Voit seurata Markon ajatuksia Twitterissä @_mry.

Iso ja raskas puuovi aukeaa. Sisään saapuu alansa asiantuntija, nainen jakkupuvussaan. Valoisassa kokoustilassa tuoksuu kahvi, kuuluu iloinen puheensorina, näkyy tuttuja kasvoja ja uusia hymyjä. Jakkupukuinen nainen vetäytyy tilan seiniä pitkin noutamaan kahvia. Hän hymyilee tutuille ja laskee nopeasti kasvonsa alaspäin. Sydän hakkaa, kädet hieman hikoilevat. Nainen etsii väkijoukosta sen ihmisen kasvot, kenen kanssa on eniten aiemminkin viettänyt aikaansa ja käy istumaan hänen viereen.

Edelleen sydän hakkaa. Ajatukset sumenevat ja on vaikea kuulla mitä esityksessä kerrotaan. Nainen ajattelee vain: mitä jos minulta kysytään jotain. Mitä jos joudun puhumaan.

Kuluu kymmenen vuotta. Sydän hakkaa edelleen. Sama raskas, iso puuovi aukeaa jälleen valoisaan kokoustilaan. Sisään astuu sama nainen. Katse ylöspäin, suuri hymy kasvoilla. Tila tuoksuu kahville ja pullalle. Ihmisten puheensorina täyttää tilan. Nainen hengittää hetkeä. Hän katsoo avoimin mielin ihmisiä. Noutaa kahvinsa ja käy istumaan sen ihmisen viereen, jota ei ole koskaan ennen tavannut ja pohtii samalla, kenellä tilassa olevalla on eniten vaikutusvaltaa ja pyrkii keskustelemaan hänen kanssaan. Nainen pyytää oma-aloitteisesti puheenvuoroa. Edelleen sydän hakkaa melkein rintakehästä ulos. Mutta kun viimein saa puheenvuoronsa, hän nopeasti syrjäyttää pelkonsa ja haluaa esittää kaikille oman tärkeän asiansa.

Naisen asiantuntijuus ei sinällään ollut muuttunut kymmenen vuoden aikana. Sama tieto on kaikkien saatavilla ja asiantuntijoina emme lopulta juuri toisistamme poikkea. Kyky käyttää taitojaan rakentaa ammattimaineen seuraavalle tasolle.

S.E.P.P.O. -framework #5/5, O = Objective

Ihmisen suurimpia kirouksia on, että haluamme olla onnellisia. Kaikki jatkuvasti uudistuvaan mielentilaamme vaikuttavat asiat (S = situation, E = Experience, P = Projection, P = Probability, ja luultavasti miljoona muuta määrittelemätöntä tekijää) määrittävät suuresti sen, olemmeko onnellisia juuri nyt. Mielentilamme tällä hetkellä kantaa mukanaan siemenen huomisen onnellisuudesta. Etsimme onnellisuutta lähes kaikesta mitä teemme, ja uskomme voivamme olla onnellisia vasta, kun odotuksiimme on vastattu asianmukaisesti.

Meitä kaikkia yhdistää palava halu olla onnellisia.

Jos tuote ei tuota käyttäjälle nopeaa onnellisuuden tunnetta, sen käyttö loppuu välittömästi. Käyttäjät valitsevat aina tuotteen jonkin tarkoituksen takia. Verkkokaupoissa on tarkoitus selailla ja tilailla tuotteita. Puhelimilla on tarkoitus soittaa toisille puhelimenomistajille. Sosiaalisella medialla on tarkoitus pönkittää omaa kuvaa itsestään. Käyttäjää harmittaa vietävästi, jos tuote ei vastaa sitä tarkoitusta, minkä käyttäjä odottaa tuotteen omaavan. Lisäharmitusta aiheuttaa, jos pienet asiat matkan varrella eivät vastaa odotuksia. Verkkokauppa toimii hitaasti, puhelimen näppäimet ovat liian pieniä, sosiaalinen media ei näytä omaa profiilikuvaa riittävän isona. Äänestämme nopeasti jaloillamme, koska nykymaailmassa riittää paljon muutakin sellaista tarjottavaa, mikä tuottaa meille kaipaamamme hetkellisen onnellisuuden.

Jos testaajalle ei ole selvää, mikä on tuotteen perimmäinen tarkoitus, eli minkä käyttäjän ongelman tuote ratkaisee, niin testaus kohdistuu väärään asiaan.

Testaamalla vääriä asioita tuotetaan kyllä tuloksia, mutta tulokset eivät välttämättä palvele tuotteen ympärille rakennettua liiketoimintaa. Itsestäänselvät prosessimenetelmät ja testausmetodit tulisi aina rinnastaa tuotteen bisneslupauksen kanssa. Jos mikä tahansa kehitysprosessin tavoite eroaa tuosta lupauksesta, prosessi tuhlaa aikaa ja rahaa.

Testaajan tärkein tehtävä on ymmärtää ja elää tuotteen liiketoimintalupausta. Kaikki muu on täydellisen toissijaista.

S.E.P.P.O. -framework #4/5, P = Probability

Oikea mielentila ja asettuminen käyttäjän saappaisiin (P = Projection) vievät jo pitkälle, mutta elämä ei koskaan etene kuin olemme ajatelleet. Kun tarpeeksi tolskaamme minkä tahansa asian parissa, todennäköisyydet puuttuvat peliin. Soudamme outoa venettä outoon veteen, ja sellaisessa tilanteessa tapahtuu väistämättä jotain odottamatonta. Odottamattomalla tarkoitetaan yleisesti jotain sellaista, mitä kukaan ei ole osannut ottaa huomioon.

Odottamattomat tapahtumat painavat käyttökokemuksen vaa’alla paljon. Testaajan taito törmätä vahingossa odottamattomiin ongelmiin voi pelastaa koko liiketoiminnan.

On mahdollista, että tuote itsessään tai sen käyttäjä tekee jotain täydellisen odottamatonta. Liian tarkasti säädellyssä toimintaympäristössä todellisen maailman todennäköisyydet eivät saa tilaa tulla esiin, ja lopulta ongelmat ilmenevät vasta tuotannossa. Erehdymme helposti uskomaan, että ongelmien ilmeneminen on suunnittelun ja valmistautumisen puutetta, ja päädymme suunnittelemaan ja valmistelemaan entistä enemmän. Palkkaamme konsultteja ja testipäälliköitä parantamaan laadunvarmistusprosessia, mutta saavutamme korkeintaan valheellisen varmuuden tunteen. Aikaisempaan tilanteeseen verrattuna aikaa ja rahaa on vain tuhlattu moninkertainen määrä.

Kun testaajan taustatiedot ovat puutteelliset, todennäköisyydet saavat tilaa tapahtua ennen todellisen vahingon tapahtumista.

Usein kun tuotannossa ilmenee ongelmia, kysymys ei ole puutteellisesta resurssoinnista, vaan vääränlaisesta ajankäytöstä. Vaikka kuinka paljon yrittäisimmekin varautua odottamattomaan, jotain odottamatonta tulee väistämättä tapahtumaan, joko ihmisten toimesta tai tekniikan pettämisen seurauksena. Suunnittelu tuotannollisten kauhuskenaarioiden varalta voi olla järkevää, mutta kauhuskenaarioiden suunnittelu ei välttämättä tuota rahalle vastinetta.

Testaajan on omattava taito irtautua tarvittaessa kaikesta muusta kehitysprosessista ja toimia itsenäisenä yksilönä hetkittäin täydellisen mielivaltaisesti. Tulokset ovat taattuja!

S.E.P.P.O. -framework #3/5, P = Projection

Välittömät kokemukset (E = Experience) eivät ole kaikki kaikessa. Ihmisen mieli on erikoinen mekanismi, joka sisältää paljon opittuja asenteita ja käyttäytymismalleja. Se luo päivittäin massiivisia määriä automaattisia ajatuksia, joiden olemassaolosta emme ole lainkaan tietoisia. Kaikki ne ajatukset, joita pidämme itsestäänselvinä, luovat katseemme eteen linssin, joka vääristää tilanteita ja kokemuksiamme. Asenteemme ja mielipiteemme luovat Platonin vertauskuvallisen luolan, jossa ihmiset erehtyvät luulemaan luolan seinällä liikkuvia varjoja todellisuudeksi.

Asiat, joita pidämme tärkeinä, eivät välttämättä ole todellisuudessa lainkaan tärkeitä. Itsestäänselvyydet ovat tie kadotukseen.

Usein koemme tärkeyden tunteita sellaisten asioiden suhteen, mitä meitä edeltäneet ihmiset ovat havainneet tärkeiksi. Itsestäänselvinä asioina emme uhraa ajatuksia niiden todenperäisyydelle tilanteessa, joka kantaa nimeä nyt. Kannamme mukanamme sokeita uskomuksia, joihin toiset ihmiset ovat uskoneet sen sijaan, että tarkastelisimme tilannetta sellaisena kuin se todella on. ”Testaus täytyy suunnitella etukäteen.” Hyvin harvan tuotteen käyttäjä suunnittelee käyttösessiotaan etukäteen. ”Testaajan on tunnettava tekninen vaatimusmäärittely läpikotaisin.” Hyvin harvalla käyttäjällä on käsissään teknistä vaatimusmäärittelyä, puhumattakaan innosta lukea edes yhden sivun mittaista ohjetekstiä. ”Laadukasta testausta ei voi tehdä pelkän bisneslogiikan ymmärtämisen kautta. Tarvitaan jotain lisää!” Bisneslogiikka ja tuotteen olemassaolon tarkoitus on lähes väistämättä ainoa, mikä käyttäjällä on mielessään.

Hyvä testaaja osaa hyvällä maulla kyseenalaistaa myös itsestäänselviä asioita.

Testaajan ensisijaisesti tärkein tehtävä on asettua käyttäjän saappaisiin, ja mukautua tarkastelemaan tuotetta sieltä käsin. Usein käyttäjän näkökulmasta katsottuna on havaittavissa järisyttävä määrä ongelmia, mitä vaatimusmäärittelyissä ei ole otettu huomioon. Useimmiten nämä ongelmat ovat erittäin liiketoimintakriittisiä, jotka tuotantoon päästessään haaskaisivat paljon aikaa ja rahaa jälkipyykissä.

Useat softaprojektit laahaavat aikatauluistaan jäljessä ja tuottavat laadutonta jälkeä, koska niissä vaikuttavat ihmiset uskovat sokeasti itsestäänselvyyksiin. Testaajan asettuminen oikeaan mielentilaan – vaikkakin projekti olisi raa’asti myöhässä – voi pelastaa vielä häkellyttävän paljon.

S.E.P.P.O. -framework #2/5 (E = Experience)

Tilanteesta (S = Situation) syntyy aina tunne, jota ihminen peilaa kokemuksiinsa. Jokainen tähän maailmaan synnytetty tuote on uhrattava käyttäjien aikaisempien kokemusten alttarilla, ennen kuin käyttäjä pystyy muodostamaan mielikuvan tuotteesta: tykätäkö vai ei? Toisin sanoen, käyttökokemus muodostuu siitä, kuinka käyttäjän odotukset vastaavat todellisuutta.

Kokemukset ovat valikoituja muistoja, joista tislaamme kaikki odotuksemme.

Jos odotusten ja todellisuuden välillä avautuu ammottava kuilu, uutena muodostuva kokemus ei välttämättä ole positiivinen. ”Aikaisemmin käyttämäni aktiivisuusmonitori on antanut nopeammin palautetta päivästäni… Netflix tekee tämän asian aivan toisin… Verkkokaupan hitaus on alennusmyynnin alkaessa tuskallista verrattuna eiliseen… Mainoksessa tämä hampurilainen näytti paljon muhkeammalta…” Kokemus, jonka muodostamme, kumuloituu aikaisempien kokemustemme päälle. Uusi kokemus synnyttää aina uudenlaisen tilanteen, joka synnyttää puolestaan uuden kokemuksen.

Kenenkään kokemuksia ei pysty kopioimaan sanojen rajoittuneeseen muotoon. Mikään speksauksen määrä ei riitä kattamaan tilanteita, mitä tuotteen todellisessa käytössä tulee vastaan, puhumattakaan käyttäjien sisäisestä kokemusmaailmasta. Testauksen tärkeimpiä tuloksia missä tahansa tilanteessa ovat testaajan kokemukselliset havainnot hänen tietoisuudessaan tapahtuvista ilmiöistä.

Suomeksi sanottuna testaajan fiilis on merkitsevä tekijä minkä tahansa tuotteen onnistumisessa!

Testaajan luottamus omaan välittömään kokemukseen tuotteen toimivuudesta on väistämättä linjassa käyttäjän luottamukseen omasta välittömästä kokemuksestaan. Kokemus ei välttämättä ole muodollisesti sama kahden eri ihmisen välillä, mutta kokemuksen muodostumisen prosessi on sama. Ei ole mitään järjellistä syytä, miksi testaajan henkilökohtainen kokemus tulisi ohittaa.

Testaaja on parhaimmillaan, kun hänen työnsä tulokset perustuvat omaan, henkilökohtaiseen kokemukseen. Jos jokin asia tuntuu vialliselta ja harmittaa, mikään määrä teknistä vaatimusmäärittelyä ei pysty tuota harmitusta poistamaan.

S.E.P.P.O. -framework #1/5, S = Situation

Läsnäoleva tilanne on kaikki mikä merkitsee. Hetki, jota myös kutsutaan nimellä nyt. Kun sitä ajattelee, se tuntuu harvoin täydelliseltä. Siihen liittyy paljon odotuksia ja vaatimuksia, jotka osoittavat yleensä seuraavaan hetkeen, jota usein kutsutaan nimellä tulevaisuus. Tilanne, jossa ihminen kulloinkin on, vaikuttaa olennaisesti siihen, mitä ajatuksia hänessä nousee ja mitä tekoja nuo ajatukset saavat aikaiseksi.

Tilanne, missä testaaja työnsä tekee, vaikuttaa olennaisesti testauksen tuloksiin.

Kokeeko testaaja tekevänsä työtä, jolla on tarkoitus, vai onko työ tehtävä koska määritelty kattavuus ei ole vielä riittävä? Aiheuttavatko tilanteeseen liittyvien lopputulemien odotukset ja pelkotilat ylimääräistä stressiä? Onko projekti myöhässä suunnitellusta aikataulusta? Onko aikaa liian vähän? Soittelevatko lapset turhista asioista kesken tärkeän testauskierroksen? Joudutaanko tekemistä priorisoimaan? Ovatko testauksen taustatiedot puuttelliset? Onko oman työn tulevaisuus riippuvainen tuloksista, jotka syntyvät juuri tänään? Onko liian kylmä tai kuuma? Paistaako aurinko liian kirkkaasti? Hengittääkö pomo niskaan? Vituttaako? Ahdistaako? Tässä vaiheessa seuraa monelle yllätys: kuvailin juuri tilanteen, jossa testaaja saa itsestään irti tärkeimmän mahdollisen työpanoksen.

Tilanne, jossa käyttäjä on naamatusten tuotteen kanssa, on yleensä aivan yhtä epätäydellinen.

Ei välttämättä ylläkuvatuilla tavoilla, mutta ihmismielelle ominaisella tavalla paeta läsnäolevaa tilannetta ajattelun maailmaan. Epämääräinen epätäydellisyyden kokemus, ja siitä versoava tunnemaailma värittävät tilanteen aina omalla värillään. Kun testauksen lähtökohtana on epätäydellisyys, tulokset palvelevat väistämättä tuotteen käyttäjän epätäydellistä sielunmaailmaa ja tilannetta.

Laboratorio-olosuhteissa kattavasti suunniteltu, orjallisesti toteutettu ja tarkkaan dokumentoitu testaustyö ei tuota tuloksia, jotka vastaavat todellisen maailman haasteellisia käyttötilanteita. Myöhässä ja puutteellisilla taustatiedoilla tehty testaus on usein softaprojektin kannattavin vaihe.

Istuin muutama vuosi sitten Michael Boltonin ja James Bachin yhteisesti pitämällä testauskurssilla. Koulutus oli kovaa, mutta ihan mielettömän hedelmällistä. Jossain vaiheessa kurssin viimeisenä päivänä mieleeni ilmestyi varoittamatta ja täydellisen tyhjästä käsite nimeltä S.E.P.P.O. -framework. Kirjaimia vastaavat sanat olivat kuin tarjottimella edessäni, vaikka en ollut tietoisesti ajatellut koko asiaa. Raapustin ne välittömästi muistiinpanojeni jatkoksi, koska kaikki hyvät ajatukset katoavat, jos emme erityisesti niitä päätä muistaa.

Emme voi tietää mistä ajatuksemme ja tekomme todella syntyvät. Kehomme ja aivojemme automatiikka toimii merkittäviltä osin ilman meidän osallistumistamme.

Aikaa kului ja SEPPO ei saanut osakseen tekoja, kunnes eräänä päivänä asiakkaan edessä ajauduin tilanteeseen, johon SEPPO oli kuin tarkoitettu. Kyseisen tapaamisen aihealue kosketti vahvasti tutkivan testauksen suhdetta tarkistustyöhön (speksattuun testaukseen, testiautomaatioon, jne…) En ollut koskaan aikaisemmin pukenut teoriaa jäsennellysti sanoiksi, mutta tuossa myyntitapaamisessa, tuntemattoman ihmisen edessä ja täydellisen valmistautumattomana, sen ensimmäinen muoto sai alkunsa. Lopputulemasta päätellen teoria osui ja upposi! Sen olennainen sanoma kuuluu tänä päivänä seuraavasti:

Testaajan tarkoitus on vähentää tuotteen onnistumiseen liittyvää epävarmuutta. Todellinen varmuus ei löydy kattavuuden käsitteen valheellisesta varmuuden tunteesta, vaan ihmismielen kokemuksesta.

Jäsentelin SEPPOA muutamissa tapahtumissa tuon ensimmäisen kirkastuksen jälkeen. Sitten syystä tai toisesta, joka on minulle tuntematon, mielenkiintoa herättänyt mallinnus testaajan mielentilasta jäi taas menneisyyden peräaaltoihin.

Aika virtasi toistamiseen SEPON ohitse, mutta ei kuitenkaan antanut sen unohtua. Sain odottamattoman tekstiviestin eräänä tammikuisen kylmänä iltana, minkä saatuani päätin välittömästi, että kirjoitan 6-osaisen blogitekstisarjan SEPON kunniaksi. Luit juuri ensimmäisen osan. Toisessa osassa mennään jo itse asiaan ?

Softaprojektien taistelukentillä makaa jo riittävästi hengettömiä ruumiita ja juoksuhaudoissa asemasotaa käyvät kalpeat ja bullshit-prosessien uuvuttamat funktio-olmit. SEPPO palauttaa testaajan takaisin todellisen työnsä äärelle.

Pomo heittää pallon Leenalle. ”Muistatko miten tämä ongelma ratkaistiin aiemmin?” Leena muistaa. ”Palastelemalla ongelma näin, ja keskittymällä kokonaisuuteen sekä näihin yksityiskohtiin.”

Vuotta myöhemmin Leena on jo johtaja, ja jakaa muistamaansa ratkaisua eteenpäin uudelle firman ukolle, Jarkolle.

Jarkko saa tietämättään maistiaisen yrityksen kulttuurista. Aamujen karttuessa hän huomaa: iso lafka – iso kääntösäde. Kulttuurin kuuluu pysyä lestissään, luomatta uusia muistijälkiä.

On toki totta, että rutiini ei ole huono asia. Se luo turvallisuutta ja viisaissa käsissä myös laadukkaita tuloksia. Vaarana on kuitenkin pölyn kasautuminen hartioille.

Kokemuksesta voin kertoa, että uusi silmäpari löytää uusia bugeja poikkeuksetta paikoista, missä tottumus on tehnyt jo testaajan työtä. Tuloksellinen testaustyö edellyttää muistista tulvivien ehdollistettujen rutiinien pistämistä päreiksi.

Siksi kysynkin. Olisiko paikallaan sekoittaa toisinaan tiimin dynamiikka? Miten olisi esimerkiksi projektien välinen testaajavaihto tai konferenssi tai koulutus?