Testauksen joustavuus ketterään kehitykseen

Ajatusten jäsentely ajan kanssa johtaa minulla aina siihen että "testaan" omia tuotoksiani eli kurssimateriaaleja ja laitan niitä uusiksi isommalla kädellä. Nyt ajattelun kohteena on ollut ketterän testauksen kurssi, josta on taas versio IIR:n kanssa ensi viikolla. Menossa versio 10 materiaaleistani - aika vähän jäljellä perusideaa lukuunottamatta vaikka alkuperäinenkin oli vähintään kohtuullinen paketti.

Eräs asia jota olen erityisesti tässä pohtinut on testauksen jostavuus, jota tarvitaan ketterän kehityksen mukana elämiseksi. Tähän pohdintaan minua inspiroi erityisesti eräs keskustelu (perinteiseen) hyväksymistestaukseen liittyen kun projektit tehdään "ketterin menetelmin".

Perinteisesti testauksen joustavuus tehdään jotakuinkin näin:

• suunnitelmia kokonaisuudelle ja yksityiskohdille laatiessa kaikki priorisoidaan
• suunnitelmiin rakennetaan mahdollisimman iso puskuri yllätyksille korostamalla testauskierroksia, korjaustarvetta ja regressiotestausta - käytännössä kuitenkin leikataan yleensä osa kokonaistoiveesta pois kun "ei niin paljon voi kuitenkaan testaukseen aikaa / työtä laittaa"
  
• joustotarpeen kohdalle sattuessa tiputetaan alemman prioriteetin asiat pois - jos kyetään. Monesti on käynyt niinkin että ne on saatu tehtyä esteiden vallitessa ja ne tärkeät jutut vielä odottaa tekemistään
  
• kun tiputtelu ei riitä, heitetään suunnitelma nurkkaan ja tehdään uusi, jotta saadaan aikaan parasta työtä käytettävissä olevien rajoitteiden puitteissa. Uusi suunnitelma voi olla "tehdään nyt vaan testausta kunnes on pakko lopettaa".
  
• keskitytään neuvottelemaan minimikorjauksista eli lasketaan laatua alimman mahdollisen hyväksyttävän laadun rajalle ja keskitytään siihen että kompromissi on edes jossain määrin tiedostettu

Ketterissä menetelmissä on varsin toisenlainen tapa ajatella testauksen joustotarvetta. Osittain ajattelumallissa tuntuu että ei vaan jousteta, kun lukee erilaisia keskusteluja valmiin määritelmästä (definition of done) - ihan kuin testaus olisi aina sama juttu jokaisen tuotteen tehtävälistan alkion osalta. Käytännössä kuitenkin joustavuutta testauksessa tarvitaan aina.

Tein oman alustavan listani esimerkeistä joissa huomaan että jouduttiin opettelemaan joustamaan monipuolisemmin testauskäytännöin jo ennen kuin ketterät menetelmät tulivat käyttöön.

1. Testauksen ajurina lisäarvo, ei testitapauslista
2. Suhtautuminen muutoksiin - saako virheitä korjata?
3. Tiivis yhteistyö toteuttajien ja testaajien kesken
4. Testauksen kuuleminen arvokkaana tiedonlähteenä
5. Erikoistumisen keventäminen - komponenttitestaajasta sovellustestaajaksi
6. Jatkuva ohjelmistotoiimitus asiakkaille koekäyttöön palautteen saamiseksi testauksen laadusta
7. Säännöllinen, usein tapahtuva integrointi
   
8. Vaatimuksista haetaan tukea, ei "oikeita vastauksia"
9. Dokumentoinnista ennen tekemistä dokumentointiin tekemisen yhteydessä
10. Laadusta puhuminen ryhmäkokemuksena

Testauksen ajurina lisäarvo, ei testitapauslista
Etsimme kokeilujen kautta keinoja tehostaa testausta ja yhdessä projektissa sovittiin yhdessä sidosryhmien kanssa että vaivalla suunnitellut testitapaukset laitettaisiin projektin ajaksi sivuun.

Projekteissa yleensä käytettiin merkittävä osa ajasta olemassaolevien ominaisuuksien mukanaolemisen varmistamiseen, regressiotestauksella. Sitä oli optimoitu ja priorisoitu, ja tuloksena oli varsin järkevästi dokumentoidut testitapausmäärittelyt. Suhteessa testitapauksiin ja niiden prioriteetteihin, oli sovittu että tietyn prioriteetin testit pitää suorittaa ennen julkaisua kokonaisuudessaan ja toisen luokan osittain. Varsin perinteinen ja normaali tapa.

Sovimme kuitenkin käytännöksi projektissa sen että aikaa varattiin testaukselle saman verran suhteessa kehitykseen kuin tyypillisessä projektissa. Sen sijaan että testaajaa kannustettaisiin käymään läpi perustarkistukset, kannustus olikin virhekattavuuden maksimoimiseen. Tehtävänantona: löytäkää niin monta merkittävää virhettä kuin annetussa työmäärässä kykenette!

Tulokset löydöksille olivat merkittäviä. Virheet löytyivät sopivammassa aikataulussa suhteessa kehitykseen (jokainen päivä oli oman suunnitelmansa kohde) ja niitä löytyi enemmän.

Pieni muistutus siitä että kerta hyviä tuloksia ei tarkoita pysyviä tuloksia saatiin myös: yhden kerran puhtaan speksin tiputtamisen taktiikka toimi, kun perusidea kattavuudesta oli selkärangassa aiemman speksin käytön perusteella. Aika hoitaa muistin pyyhkimisen, joten tukirakenteita tarvitaan. Edelleen kuitenkin testejä joustavuusmielessä voi ohjata niiden tuottaman tiedon arvokkuuden perusteella.

Suhtautuminen muutoksiin - saako virheitä korjata?
Testauksessa on usein opittu varomaan ja välttelemään muutoksia. Jokainen muutos ohjelmistoon saattaa nollata siihen mennessä tehdyn testauksen perusteella saavutetun tietotason, erityisesti jos muutoksia tehdään ajattelematta kokonaisuutta.

Yleinen joustotapa, jossa muutosraadit päättävät mitkä muutokset ovat riittävän arvokkaita päästäkseen mukaan ja mitä vältetään, on joustoa riittävän laadun osalta. Se toimii mainiosti projektin loppuvaiheissa, mutta muutoksen välttäminen alusta saakka ei tunnu kovin joustavalta.

Kokeilimme ennen ketteriä menetelmiä projektissa vanhojen tunnettujen ongelmien priorisoimista mahdolliseen korjaukseen periaatteena "mihinkäs se olisi hävinnyt kun ei sitä olla ainakaan tarkoituksella korjattu". Toteuttajien ohjaus oli että korjata saa, siinä on hyvää listaa asioista joita voi toteuttaa jos on odotusaikaa. Kuitenkin toteuttajia muistutettiin myös siitä, että uusien vaatimuksien / ominaisuuksien edistäminen on tärkeintä.

Lopputuloksena saatiin korjattua satoja ongelmia ja asiakaslausunto laadusta: "betalaatu on parempaa kuin aikaisempi julkaisulaatu". Testauksen kannalta erityinen oivallus oli että varhaiset korjaukset itse asiassa helpottivat työtä, mutta meillähän olikin aivan erinomaisia toteuttajia vaikka joskus jotain yllätyksiä regressiomielessä tuleekin.

Tiivis yhteistyö toteuttajien ja testaajien kesken
Keskustelut testaajien sijoittelusta organisaatiossa vellovat yleensä suuntaan jos toiseenkin, mutta koin organisoinnista tehdyt valinnat yhtenä joustavuuden aikaansaamisen onnistumistekijänä. Kun testaajat ja toteuttajat olivat samojen henkilöesimiesten alaisia, nämä eivät voineet vahingossakaan rakentaa raja-aitoja alaistensa välille, vaan onnistumisen kriteerit olivat yhteisiä.

Pelkäsin jossain vaiheessa että tästä seuraisi testaajien siiloutuminen toisilta testaajilta, mutta itse asiassa testaajien yhteistyön saavuttaminen virtuaalitiimiajatuksin oli kertaluokkaa helpompaa kuin vastaava organisaatiossa toisin päin eli toteuttajien kanssa.

Joustavuudessa ei toki vielä ennen ketteriä menetelmiä menty niin pitkälle kuin että ehdotettaisiin että toimitaan päivittäin samoissa tiimeissä ja nähdään jakamaan tekemisiä päivittäin (aivan ihana käytäntö) tai että istuttaisiin vielä samoissa yhteisissä tiimihuoneissa niin että asioita voi tehdä koko ajan yhteistyössä niin tarvittaessa.

Testauksen kuuleminen arvokkaana tiedonlähteenä
Testauksen aseman ja arvostuksen olemassaolo auttoi paljon suuntamaan energioita parempaan ja tuloksia tuottavampaan suuntaan. Kun omaa eloaan ei tarvitse perustella joka välissä, ehtii yllättäviä asioita.

Asemaa arvokkaana tietolähteenä ei kuitenkaan saa jos ei sellainen ole. Testaus ei ole arvokas tietolähde lähtökohtaisesti. Muistin tämän erityisen selkeästi viimeaikojen kokemusten perusteella, jossa tuotettiin paljon dokumentaatiota heikolla uudelleenkäyttöasteella (vaikka uskottiinkin että voisi niitä ehkä hyödyntää myöhemminkin) ja vähän ongelmia korjattavaksi / käsiteltäväksi.

Arvokasta tietoa voi tuottaa varsin monella foorumilla. Erityisen tärkeäksi koin asiallisen toiminnan projektin ohjauksesta päättävässä ohjausryhmässä ja oikean julkaisulaadun - korkealla tietotasolla - tarjoamisen päätöksentekijöille.

Eikä fiksu testausta ymmärtävä "sponsori" korkealla organisaatiossa tee lainkaan pahaa toimintaympäristölle. Sellaisen olemassaoloa ei välttämättä edes tiedosta ennen kuin sen menettää...

Jatkuva ohjelmistotoimitus asiakkaille koekäyttöön palautteen saamiseksi testauksen laadusta
Jo ennen ketterien menetelmien käyttöönottoa vastineena huoleen siitä että tiedämmekö testauksemme perusteella oikeasti laadusta vai luulemmeko vaan kehiteltiin vastineita. Loimme eräässä projektissa jatkuvan betatoimituksen konseptin, jossa ominaisuuksia ja korjauksia toimitettiin säännöllisesti ihan oikeille käyttäjillekin. Tämä kokemus oli varsin arvokas miettiessä rakenteita miten ketterien menetelmien yhteydessä voitaisiin julkaista joka inkrementin päätteeksi.

Olimme aika huolissaan laadusta suhteessa inkrementtien aikana tiukaksi toisinaan priorisoitavaan testaukseen. Jonkin kerran tuli opittua painotuksista myös kantapään kautta löytämällä sisäisesti mahdollisia asioita ulkoisesti, mutta enimmäkseen tuli opittua että aivan niin monet asiat eivät todellakaan hajoa muutosten seurauksena. Ja muutoksista puhuminen tiimissä aidolla tahdolla asioiden hyvin tekemiseen on erittäin voimallinen käytäntö vähentämään varmuuden vuoksi -testauksen määrää.

Säännöllinen, usein tapahtuva integrointi
Muistaen joitain projekteja menneisyydessä muistan hyvin kuinka muutosta välteltiin. Erityisesti osana hyväksymistestauksia uusien versioiden saaminen testaukseen oli lähestulkoon mörkö. Muistan alistumistunteen kun hyväksyttiin kerran kahdessa viikossa suunnitellun version toimittamisen sijaan kaksi kertaa viikossa uusi versio ekalla viikolla, ja aina aloitettiin alusta.

Jatkuva integrointi ketterissä menetelmissä oli minulle varsinainen mörkö. Olin juuri jotensakin onneksi oppinut toimimaan vanhojen kokemusten jälkeen projektissa jossa harrastettiin säännöllistä, useita kertoja viikossa tapahtuvaa integrointia. Näihin versioihin sai melkein tietoa mikä muuttui versioiden välillä, ja yllätyksiäkin tuli.

En oman kokemuspohjani perusteella olisi uskonut että voisin muutamaa vuotta myöhemmin uskoa että jatkuva integrointi itse asiassa helpottaa testauksen työtä. Ja että matkalla kohti sitä tahdin tiivistäminen opettaa keskeisiä asioita testauksen joustavuudesta.

Vaatimuksista haetaan tukea, ei "oikeita vastauksia"
Projekteissa oli varsin yleinen testauksen joustavuutta helpottava käytäntö vaatimuksiin suhtautumisen kanssa. Sen sijaan että vaatimuksia olisi kohdeltu "tilausmäärittelynä", tuoteliiketoimintatausta oli auttanut projekteja jo tajuamaan että oikeita vastauksia loppukäyttäjien erilaisten toiveiden ja tarpeiden kanssa ei ole, vaan asioista on hyvä keskustella ja täydentää ymmärtämystä ajoissa.

Vaatimuksista ei siis haettu "oikeita tuloksia" ja testauksen absoluuttista vastausta, vaan lähinnä tukea kattavuuden ajatteluun ja inspiraatioiden lähtökohtaa.

Dokumentoinnista ennen tekemistä dokumentointiin tekemisen yhteydessä
Testitapausten dokumentoinnissa oltiin myös omaksuttu joustavampi käytäntö projekteille. Sen sijaan että olisi oletettu että testitapausmäärittely on valmis testauksen alkaessa, silloin oletettiin olevan valmiina ensimmäinen runko - sen hetken käsitys valmistelutyön perusteella.

Dokumentoinnin osalta ajatusmaailma oli projektin loppuhetkissä sekä tulevissa projekteissa - elinkaariajattelussa.

Erikoistumisen keventäminen - komponenttitestaajasta sovellustestaajaksi
Organisoinnissa vanhastaan palkattiin aina testaaja tiettyyn tarkoitukseen, yleensä tunnistettuun aukkoon. Se tarkoitti sitä että jokaisella testaajalla oli yksilöllinen työnkuva sen komponentin tai testaustason osalta mihin oli tullut rekrytoiduksi. Vaikka ei ollut erityisesti mitään syitä olla laajentamatta suppeaksi muodostuvaa erikoistumista, jotenkin rekrykuponkien tiedot koettiin ohjaavina.

Iso joustavuuteen liittyvä oivallus oli kun usean eri toisiinsa liittyvän komponentin testaajat alettiinkin nähdä sovellustestaajina omien komponenttiensa erikoistuntemuksella, jota oli tarkoitus levittää saman sovellusalueen kolleegoille. Ja kun tätä oivallusta vielä laajennettiin ymmärtämällä sovellustestaus järjestelmätestauksen näkökulmana, saatiin vähennettyä vielä vähän lisää testauksen sisäistä erikoistumista.

Laadusta puhuminen ryhmäkokemuksena
Viimeisenä, mutta ei toki vähäisimpänä jousto-oivalluksena listasin laadusta puhumisen mittareiden lisäksi laadullisesti. Ryhmän kokemusten ja tuntemusten yhteenveto auttoi määrällisen aineiston tulkinnassa ja ohjasi projektista päättävää ohjausryhmään syvällisempiin ja järkevämpiin päätöksiin laadusta. Toki oli tarpeen muistaa, että meistä kaikille aikataulu oli laadun kokemuksen suurimpia kriteerejä, josta ei kevein perustein haluttaisi joustaa... Projektit ovat erilaisia.

Testaustaitojen hiominen automaatiota harkitessa

Toistuvasti monien testaajien kanssa jutellessani huomaan omaavani jossain määrin erilaisen tavan ajatella regressiotestausta ja regressiotestauksen automatisoinnin tarvetta. Minulle ei ole itsestään selvää että pitäisi olla perusregressiotestisetti, jota ajetaan kerta toisensa jälkeen.

Asiaa pohdittuani olen päätynyt siihen, että merkittävä näkemysero on syntynyt sisäsyntyisestä tarpeestani tehdä hyvää testausta olemalla motivoitunut testaustyöhön. Jos suostuisin itselleni myöntämään että on olemassa testaustyyppi, jossa samojen askelten toistaminen ilman itselleen annettavia perusteita muutoksesta on olemassa, kokisin sen työn tekemisen lähinnä häiritsevänä. Sen sijaan ajattelen regressiotestausta älyllisesti vielä monimutkaisempana optimointihaasteena.

Jokainen rikkoutuminen ohjelmistoille tapahtuu syystä. Emme aina ymmärrä ja näe näitä syitä, mutta se ei ole syy olla yrittämättä ymmärtää ja korvata ymmärtämättömyyttä aivottomalla toistolla. Koska syy on jonkinlainen muutos, minä en koe toistavani samaa testiä, vaan etsin uutta tietoa.

Tästä ajattelumallista seuraa ainakin minulle tarve oppia ja kehittää testauksellisia taitojani, etten päädy tekemään asioita liikaa varmuuden vuoksi. Eräs loistava harjoitus minulle ainakin on ollut yrittää tunnistaa asioita joita testaan "kun ne nyt vaan pitää testata" ja alkaa seuraamaan oletuksieni todenperäisyyttä. Kaivan omia muistilokeroitani, kyselen kolleegoilta ja luen virheraporttikannasta todistusaineistoa siitä että on perusteltua tehdä juuri tämä temppu jatkuvasti. Jos en onnistu syitä löytämään, kokeilen varovasti ja tarkoituksella jättää tempun tekemättä kerran - ja seuraan mitä tapahtuu. Palaan ehkä temppuun vielä jossain vaiheessa, ajoituksen itse tarkkaan miettien. Tarkoitukseni on aktiivisesti löytää asioita joita en sitten ehkä kuitenkaan lähtisi testaamaan.

On vaikeaa oppia irti vinoumista, joihin on kasvanut. Olen itse aloittanut testaushommat lokalisointitestauksen parissa, ja vasta vuosia sen jälkeen tajusin että yksi iso oppi oli puolivahingossa syöpynyt lähes selkärankaani. Uskoin vakaasti alkuaikojen kokemusteni perusteella, että eri kieliset windows-käyttöjärjestelmät ovat merkittävässä määrin erilaisia niiden päällä toimivan ohjelmiston kannalta. Tämä usko sai minut vuosia toistamaan testejä suomen- ja englanninkielisissä käyttöjärjestelmissä ilman merkittäviä tuloksia. Oppi piti toki paikkaansa varsin suuressakin määrin alkuaikojeni softalle ja silloisille käyttöjärjestelmille, mutta testauksen onneksi maailma - ja käyttöjärjestelmien toteutustapa - muuttuu. Niilläkin tunneilla olisin voinut löytää jotain tärkeää ja merkittävää - ja löydänkin, tulevaisuudessa.

Tämä pohdinta tulee minulle usein esiin automaation kanssa. Ei ole itsestään selvää että usein käsin toistettava testi kannattaa automatisoida. Jos sillä ei ole koskaan (oletettavasti) saavutettavissa tuloksia käsin, miksi automaatio, joka on askelta ihmistä tyhmempi, tuottaisi erinomaisia tuloksia?

Automaatiolla on paikkansa. Kun se paikalleen laitetaan, sitä tarvitsee ylläpitää ja käyttää, ja sen tuloksia analysoida. Kun tekemistä on muutenkin paljon, voisi kannattaa ensin päättää / miettiä mitä jättää tekemättä. Etenkin kun kaikkea testausta / testauksen automatisointia ei tarvitse tehdä "testaajan näkökulmasta" vaan toteuttajilla on kyvykkyys itsekin löytää monia virheitä ohjelmistoistaan.

Kokeneen testaajan ja kokeneen testaajan eroista

Päivän oppimispohdintojeni keskeisenä teemana on "kokeneen testaajan" erot. Testausidolini Cem Kaner sanoi jossakin rekrytointia käsittelevässä tekstissään vapaasti muotoillen että on testaajia joilla on viiden vuoden kokemus ja testaajia joilla on viisi vuoden kokemusta. Jatkoin ajatusta, että on myös ihmisiä joilla ei ole vuodenkaan kokemusta, mutta vähintään viiden vuoden positiivinen asenne, jolla saadaan aikaan saman verran tuloksia kuin sillä viiden vuoden kokemuksella.

Teema päätyi pohdintoihini kun vedin yhteen kurssipalautteet tutkivan testauksen työkurssini koeversiolta tiistailta. Annettujen arvosanojen keskiarvo kokonaisuudessaan oli 4,1/5. Joukosta löytyi yksi jolla oli muihin nähden vahvasti eriävä mielipide: 2,1/5. Kommenteista löytyi viitteitä siihen että kokenut testaaja ei tälläistä sisältöä tarvitse, itsestäänselvyyksiä, sopii lähinnä ammattikorkeakouluihin. Kuitenkin tilassa oli tämän kokeneen testaajan lisäksi 18 muuta, joista minun ymmärtääkseni 17 on kokeneita testaajia. Muut kokivat opit tärkeinä ja arvokkaina. Mistä siis syntyy tälläinen ero?

Ihmisillä on oikeus mielipiteisiinsä ja jokaisen mielipiteet ovat perusteltuja heille itselleen. Minä näen tässä itselleni loistavan tilaisuuden oppia. Vaikka oppimiseni spekuloinnin kautta olisikin täysin epätodellinen suhteessa opin aloittaneen tarkoituksiin, koen että se on minulle arvokasta.

Osa testaajista on tehnyt vuosia testausta ilman että heiltä on vaadittu itseohjautuvuutta tai sisäistä kurinalaisuutta - ulkoiset kyttäysmekanismit tehtävien suorittamiselle ovat aivan oma lukunsa; oppimista siitä mitä ja miten testataan; tai tuloksia löydettyjen virheiden eikä vain kuitatun kattavuuden kautta. Näille ihmisille tehtävät jaetaan yksityiskohtien tasolla "katso nämä testitapaukset" ja töitä seurataan ja tuetaan jatkuvasti muistutellen. Virheistä oleellisia ovat vain ne, jotka ovat poikkeamia odotetusta lopputuloksesta. Jos muut ovat oleellisia, ei se ainakaan ole minusta kiinni, voi toki korjata testiskriptin niin että sama virhe ei seuraavan kerran mene ohi. Valitettavasti vaan virheiden syntyminen on sen verran luovaa että ihan samaan kohtaan tuskin kauhean usein isketään.

Kokeneen testaajan, joka on kokenut koneenosana toimija, voi korvata automaatiolla tai vaikka intialaisella. Kokenutta testaaja joka oppii jatkuvasti ympäristöstään ei voi korvata automaatiolla - ja intialaisistakin tarvitaan sitä olemassaolevaa ajattelukykyistä osaa. Kokematon testaaja joka oppii on joka päivä päivän oppien verran parempi. Siihen meidän pitäisi minun nähdäkseni kaikkiaan testauksessa pyrkiä - koko ajan eteenpäin.

Testaamisen lopettamisen haasteet

Luulin taas oppineeni / oivaltaneeni jotakin, joka on tarpeen laittaa muistiin. Kun puhutaan testauksen kattavuuden saavuttamisesta, joukosta tuntuu löytyvän toimintatavoissaan kahta ääripäätä - ja tietysti erilaisia välimuotoja:

1. Ne jotka luulevat että ihan vähän testausta on tarpeeksi ja lopettaminen tehdään kuvitellen että "kaikki on testattu"
2. Ne jotka tiedostava kuinka laaja ja monipuolinen ongelmakenttä testauksessa on ja eivät ole vielä oppineet priorisoimaan vaan koittavat jokaisen idean osalta sisällyttää vielä senkin ilman riskiperusteista perustelua saati sitten tuloksia - kunnes sovellus julkaistaan lähestulkoon käsistä repien

Henkilökohtainen tuntumani on että enemmistö kohtaamistani vielä edustaa vaihtoehtoa 1, ja siksi ehkä kokemus koekurssilla jossa "kaksi puolituntista sessiota riittää" -lausunto muuttui testaamisen ja jäsentämisen kautta "tässähän on hommia kuukaudeksi" -lausunnoksi, tuntui erityisen palkitsevalta.

Olen kuitenkin osunut aika moneen sellaiseenkin joka ei sitten millään haluaisi ohjelmistoa käsistään päästää. Pitää miettiä miten sitä taitoa opettaisi, ja toisaalta, onko olettamani siitä että se on tavallaan jatko-oppien askel ollenkaan todellinen.

Näistä löytyy vielä (ainakin) kolmas muunnelma joka vaatii erilaista lähestymistapaa oppimiseen: kaverit tiedostavat vaatimusten monipuolisuuden ja tietävät miten paljon tehtävää testauksessa olisi ja eivät osaa jättää sitä tekemättä, mutta eivät tuota tuloksia edes varsin bugisella ohjelmistolla koska eivät tunnista virheitä ilman valmista vastausta siitä mitkä asiat pitää raportoida.

Testauksen kohteista oppimismielessä

Olen pohtinut viime aikoina erityisen paljon kurssitarkoituksiin soveltuvan testattavan ohjelmiston valintaa. Tutkivan testauksen työkurssilleni viimeisille kierroksille pääsi kaksi vaihtoehtoa:

• TestLink: testauksen hallinnan Open Source -työkalu
• FreeMind: ideakarttatyökalu

Päädyin valinnassani Freemindiin.

TestLinkin osalta minulle itselleni testatessa kävi siten, että löysin itse asiassa kohtuullisen vähän bugeja, mutta suhteessa sitäkin enemmän puuttuvia ominaisuuksia. Kuten testaushallintatyökalut yleensäkin, tämä sai minut taas lähinnä toivomaan että toimisi jollain tapaa niinkuin minä toivoisin ja tukisi paremmin tutkivaa testausta. En pitänyt tausta-ajatuksesta jonka synnytin puolivahingossa, jossa kehittelin tapoja nyt kuitenkin tehdä ne asiat tällä työkalulla kun se kerran käsillä on.

Freemindin osalta valitsin 0.9.0 RC3 -version. Ajattelin alkuun että avoimen lähdekoodin projektit ovat paremman laadun maineessa kuin perinteiset suljetut ohjelmistot, ehkä tämä olisikin erityisen vaikea kohde sen osalta että virheitä olisi vaikea löytää. Kuitenkin osoittautui että vaikka itsekin valmistellessa tuli aika monta havaintoa tehtyä, 19 testaajaa huoneessa päivän ajan löysi niitä lähestulkoon liikaa. Tässä korostui se että kun laadussa on tarpeeksi toivomisen varaa, yksityiskohdat helposti piilottavat toisia alleen, ja laatukokemuksen perustaminen järkevälle tasolle vaatii aika paljon harkintaa.

Kurssin aikana jäin edelleen pohtimaan eteenpäin hyvää testauksen kohdetta oppimis- ja opetusmielessä:

• Riittävän buginen ohjelmisto saa tuntemaan että sai jotain aikaan. Toisaalta sen kanssa pääsee aivan liian helpolla.
• Liian bugiton ohjelmisto korostaa sitä että testaus voi olla myös varmistumista, eikä aina ongelmien metsästystä.
• Täydellinen olisi sinänsä kompromissi näiden väliltä: jotain helppoa löydettäväksi, jotta saisi itsevarmuutta uusille ja epävarmoille. Enemmistö kuitenkin vaikeaa, silti virheitä sisältävää. Tekniikoille ja ajatusmalleille tarvitsee myös purtavaa, mutta vaikeus lisää opetukseen tarvittavaa aikaa.
  

Olisikohan paras tapa saavuttaa tämä alkamalla kirjoitella niitä FreeMindin bugiraportteja sisään projektin tietokantoihin? Kaikkiaan minusta pohjaksi erittäin lupaava ohjelmisto, näin niinkuin testauskohdemielessä.