Ohjelmistotestaus ja laatu

Yksikkötestauksen opettaminen

2011-08-16T03:48:00.000-07:00

Yksikkötestaus on hankala aihe kouluttaa. Ei siksi, että testien tekeminen olisi oikeasti hankalaa, mutta siksi, että kyseessä on käytäntö, jota ilmankin pärjää ainakin teoriassa. Samanlaatuisen koodin voi kuvitella saavansa aikaan myös ilman testaukseen hurahtamista ja testikoodin ylläpitoa.

Siis voi ainakin kuvitella pääsevänsä samaan.

Tämä voi olla yksi syy siihen, että useimmat yksikkötestauksesta kirjoittavat ja esitelmöivät joutuvat lähtemään aina samoista perusteista liikkeelle. Ainakin jos yleisönä ovat Microsoftin kehitysympäristöissä työskentelevät. Tämä yleisö ei ehkä ole vielä täysin ottanut asiaa omakseen ja enkä ole varma siitä, onko niin tehnyt edes Microsoft.

Itselläni on sama tuntuma, jonka tämän blogikirjoituksen kommenttiosion kirjoittajat jakavat. Se ei välttämättä ole kovin mairitteleva.

Ilokseni olen huomannut realististen yksikkötestausta käsittelevien artikkelien lisääntyvän netissä. Monet ovat tajunneet, että tiukat yksikkötestauskäytännöt ovat liian fundamentalistisia lähtökohtia ja voivat johtaa turhautumiseen. Yksikkötestauksesta pitää saada jotain hyötyä irti ilman että pitää muuttaa kaikkia koodauskäytäntöjä.

Itse suosittelen loppukesäksi kaikkien luettavaksi Gojko Adzicin kirjaa "Specification by example". Kirja liittyy enemmän hyväksyntätestaukseen kuin yksikkötestaukseen, mutta siitä viis. Itse olen saanut kirjasta enemmän ideoita yksikkötestaukseen kuin monesta virallisesta yksikkötestausoppaasta.

Lisäys 20.8.2011:

Tämän blogijulkaisun tekijän tuntuma tukee omaa näkemystäni :
Is it too much to ask if you can write a unit test?

Kuinka paljon panostaa työvälineisiin?

2011-06-09T01:06:00.000-07:00

Idea tähän kirjoitukseen heräsi ohjelmistotestaus.fi blogin kirjoituksesta. Kirjoitus oli hyvä ja ajatuksia herättävä. Päätin pohtia myös täällä hiukan sitä kuinka paljon aikaa kannataa käyttää työvälineiden kuntoon saattamiseen.

Yksinkertainen sääntö pätee useimmiten: Jos työn alla olevaa pikkuviritystä (yhtä toimintoa esimerkiksi) käyttää yli 500 henkilöä, sen kuntoon hieronta voi kestää reilusti aikaa ja silti homma maksaa itsensä takaisin säästettynä aikana.

Jos taas työn alla olevaa viritystä käyttää vain 10 henkilöä, niin useimmiten pitäisi päästä nopeasti eteenpäin. Tälläisiä virityksiä ovat useimmat testitapaukset. Niiden käyttäjiä (testaajia) on yleensä vähän.

Tämä yksinkertainen sääntö on kuitenkin vaarallinen, koska se unohtaa tyystin motivaation, käytön intensiteetin/frekvenssin ja sen, että tottuminen saa aikaan isoja harhoja.

Puolinaisilla virityksillä työskentely syö pitemmän päälle motivaatiota. Käytön intensiteetti ja taajuus (frekvenssi) voi taas yksittäisellä käyttäjällä olla joillekin toiminnoille yli 50 kertainen verrattuna muihin. 10 tälläistä käyttäjää vastaa 500 tavallista käyttäjää.

Systeemityötä tekevien joukossa on paljon henkilöitä, jotka nauttivat oman ja muiden systeemityöprosessin hiomisesta. He pitävät sujuvasta harkitusta prosessista, joka alkaa suunnittelusta ja päättyy paketointiin. Heille se, että tehdään vain jotakin äkkiä ja käytetään niitä välineitä, joita on nyt käsillä, voi olla lannistavaa moraalin kannalta.

Ihmiset myös tottuvat uskomattomiin tapoihin tehdä työtä ja tulevat niissä myöskin nopeiksi. Alunperin hätäisesti suunniteltu ja noepasti korvattavaksi ajateltu tapa tehdä työtä vakioituu äkkiä. Tällöin juututaan helposti niin sanottuun "lokaaliin maksimiin", jossa surkea tapa tehdä töitä optimoidaan huippuunsa ja tuon huipun kaikilla puolilla alkaa näkyä vain valtavia pudotuksia, jotka pitäisi ensin ylittää jos parempaa tapaa halutaan etsiä.

Kommentteja Michael Boltonin esityksestä

2011-06-07T06:59:00.000-07:00

Lueskelin kommentteja Michael Boltonin RST testauskurssista (esimerkiksi täältä) ja kuulin kollegalta sen mitä tapahtui Boltonin Otaniemen esityksessä.

Olen pikkuisen yllättynyt Boltonin sanojen vaikutuksesta. Herrojen Michael Bolton ja James Bach blogit ovat täynnä samanlaista provosoivaa materiaalia, enkä tiedä miksi tämä suora syyttely tuli kenellekkään yllätyksenä.

Boltonin ISTQB:tä kohtaan esittämä kritiikki, joka monen mielestä oli perusteetonta haukkumista, ei silti saa tässä mitään puolustusta. En kuullut alkuperäistä esitystä, jotenka en voi oikeasti ottaa siihen sen enempää kantaa.

Kuitenkin voisin väittää seuraavaa:
1. ISTQB on koonnut myös suomalaisia testaajia yhteen touhuamaan. ISTQB ei kuitenkaan ole pyhä, jos jotkut ovat sen eteen tehneet kovasti töitä.
2. ISTQB:n käsitys testauksesta ja sen opettamisesta on helposti tulkittavissa tunnepitoisen testauksen vastakohdaksi. ISTQB:n syllabusten tyyli provosoi vastareaktioita ihmisiltä, jotka suhtautuvat testaukseen intohimoja herättävänä ongelmien ratkaisutieteenä, missä kyseenalaistetaan ja käännetään asiat ylösalaisin.
3. ISTQB opettaa faktoja, tekniikoita ja periaatteita, jotka jollain lailla liittyvät testaukseen ja jotka on valinnut joukko testauksen ammattilaisia omien näkemystensä perusteella. Enempää ISTQB:n tuottamasta oppisisällöstä ei voi sanoa perustellusti.
4. ISTQB tenteillä tehdään rahaa. Siinä yksi syy siihen miksi niitä ei joissain piireissä arvostella ollenkaan. Itse olen pitänyt ISTQB kursseja ja arvostellut niitä samalla. Minusta se oli tärkeää, jotta kurssilaisille tulisi selvä kuva siitä mitä he voivat kurssilla oppia.

Kommentit Boltonin esityksestä ovat tervetulleita. Lähettäkää myös linkkejä, jos olette jo pohtineet asiaa omissa blogeissanne.

Uusi blogi englanniksi

2011-04-14T06:22:00.000-07:00

Tein rinnakkaisen blogin englanniksi. Ensimmäinen aihe käsittelee Virossa pidettävää RST kurssia. Linkki blogiin.

Impostor syndrome

2011-01-31T01:02:00.001-08:00

Tähän kirjoitukseen minut innoitti hyvä ja paljon kommentoitu blogikirjoitus . Kirjoittaja (Jean Hsu) puhuu monesta, ja osittain myös ilmiöstä nimeltä Impostor syndrome, jolla on varmasti myös suomenkielinen nimi.

Impostor syndroomassa potilas ei usko niin millään omiin kykyihinsä. Kaikki on esimerkiksi aina jollain lailla tuurin tai olosuhteiden tuotosta. Mikään ei myöskään tunnu vahvistavan potilaalle positiivisempaa mielikuvaa. Tämä syndrooma ei ole mitenkään virallisesti tunnustettu psykologinen ilmiö, mutta osittain varmasti kaikille tuttu.

Blogikirjoitus puhui naisten kokemuksista, mutta mainittu taudin kuvaus on tietysti yleisempi ongelma. Uskon itse, että esimerkiksi ammattialoista tietojenkäsittely ruokkii tätä ongelmaa ihan työkseen. Systeemityön parissa on erittäin helppoa sairastua itsensä aliarvioijaksi ja jäädä tilanteeseen vangiksi loppu-uran ajaksi. Useiden ohjelmistokehitys organisaatioiden sisäiset ja tosiasialliset rakenteet perustuvat tähän syndroomaan.

Tietojenkäsittelyn ammattilainen voi tuntea itsensä herkästi täysin tietämättömäksi alastaan, vaikka takana olisi vuosikymmenten ura ja kouluttautuminen. Jos et omaa vahvaa ammatillista itsetuntoa, olosi voidaan saada hetkessä epävarmaksi. Se mitä nippelitietoa sinun oletetaan tietävän tai mistä sinun oletetaan olevan perillä voi olla jatkuvasti edestäsi karkaava tavoite. Myöskin se minkä verran sinulle kerrotaan tietoa, ennen kuin sinulta odotetaan jo soveltamista tai arviota, voi olla aina tarkoituksellisen niukkaa.

Testaajat eivät ole immuuneja tälle ammatillisen epäpätevyyden jatkuvan tuntemisen syndroomalle. Testaajalla pitäisi olla oikeus kysyä niitä tyhmiä kysymyksiä, mutta ympäristön oletus saattaa olla, että tiettyjä asioita ei silti selitetä auki. Saatat esimerkiksi tehdä töitä vuosikausia koodaajan kanssa, joka ei vaivaudu selittämään koodinsa yksityiskohdista mitään, mutta pitää etäisyyttä sinuun puhumalla vain täysin aukipurkamattomilla ammattitermeillä omasta työstään.

Alalta löytyy tietysti myös oikeaa epäpätevyyttä. On paljon sitä, että oletetaan, että koko systeemityöala on jo opittu muutamassa vuodessa ja loput onkin sitten vain kiinni siitä kuinka verbaalisen akrobaattisesti osaa oman niukkatietoisuutesi kätkeä, eli kuinka hyvin selviää puhumalla. Useat asiakasrajapinnassa kiinni olevat konsultit ja kenttäinsinöörit ovat hyvin nuoria, innokkaita ja valitettavasti alttiilta tälle toiselle ansalle.

Mikä siis neuvoksi? Millä nostaa omaa ammatillista itsetuntoa terveesti ja taistella varsinkin suurten ohjelmistoyritysten tasapäistämistaipumuksia vastaan? Suurille yrityksille kun sopii se, että sinä et koe itseäsi kyvykkääksi yksin, vain vain osana heitä. Et ole mitään verrattuna talon suuriin guruihin, eikä osaamisesi ole mitään sinänsä tuotteistettavaa. Kun lähdet ulos talosta sinusta saattaa tuntua, että jäljelle ei jäänyt mitään omaa, koska yhtiön viitekehys alkoi ajan saatossa ulottua myös henkiselle puolelle. Sairastuit ehkä impostoriksi.

Lääke Impostor syndroomasta ulos voisi olla se, että tietojenkäsittelyn koulutuksessa kiinnitettäisiin entistä enemmän huomiota omasta osaamisesta puhumiseen. Tästä kirjoitan myöhemmin lisää.

Ps. Viimeinen vuosi on kulunut ahkerasti kehittäjän testauksen ja kehityksen parissa. Kouluttajan on hyvä välillä lähteä pitempikestoisiin kehitysprojekteihin mukaan

Suomalainen testaustutkimus on harhapolulla?

2010-01-08T00:09:00.000-08:00

Ohjelmistotestauksen suomalainen tutkimus on yleensä pitkälle teknillisten oppilaitosten tuottamaa. Tämä näkyy tutkimusten näkökulmassa ja loppupäätelmissä.

Michael Bolton blogissa oli mielenkiintoisen kirjoitus, jonka pohjana oli TKK:lla tuotettu tutkivaa testausta käsittelevä tutkimus vuodelta 2007.

Boltonin yhteenvetokommentti tutkimuksesta oli "Testing is a qualitative evaluation of a product; this study is a quantitative evaluation of testing.". Olen pitkälti samaa mieltä.

Teknillisten tutkimusten tarkoituksena on löytää teknillisiä, määrällisiä (kvantitatiivisia) mittareita tutkimustensa kohteista. Testauksessa on kuitenkin paljon tarpeellisempaa huomioida tilannekohtaiset, sosiaaliset ja oppimiseen liittyvät mittarit, joita ei voida niputtaa teknisen käsitteistön avulla.

Tekninen korkeakoulu on huono paikka lähteä tutkimaan testausta laajemmin. Suomalaisessa teknisessä tutkimuskentässä on perinteisesti totuttu hyvin tekniseen maailmankuvaan ja tekniikan valtaan. Tilannekohtaisen oppimisen roolin myöntäminen siirtäisi vallan pois tekniikan guruilta toisille tiedealueille ja vaatisi aivan toisenlaista näkökulmaa.

Pitäisi myöntää seuraava: Ruohonjuuritason testaajat saavat testauksen aikana tietoonsa asioita ja muodostavat kohteestaan malleja, joista tekniset gurut eivät tiedä etukäteen mitään, eivätkä osaa niitä millään lailla etukäteen mallintaa.

Jos tämä myönnettäisiin se tarkoittaisi testaajien arvostuksen nousua ja myös sitä, että testaajien täytyisi itsekin herätä huomaamaan olevansa tässä ainutlaatuisessa asemassa.

Vuoden testaaja 2010

2009-12-08T09:11:00.000-08:00

Vuoden testaajan nimittäminen ja valinta on tullut taas ajankohtaiseksi. Ohjeet ja lomakkeet löytyvät täältä.

Miksi valita vuoden testaaja?
Syy 1: Mainosarvo. Sitä tarvitaan, jotta testaustyö edes jotenkin näkyisi mediassa.
Syy 2: Valintaperusteiden mietintä. Mistä syistä arvostamme muita testaajia ja millä perusteella nostamme joitakuita esille?

Ketkä yleensä puhuvat testauksesta, jos on tarve nostaa testaajia esille? Kuinka usein kyseessä on oikeasti testausta ruohonjuuritasolla tehneet ammattilaiset?

Kokeneiden testaajien kuunteleminen

2009-11-17T23:02:00.001-08:00

Kokeneiden testaajien kuunteleminen koulutustilanteessa on puuhaa, jota olen onnekseni saanut silloin tällöin tehdä. Olen oppinut paljon, enkä missään nimessä haluaisi luopua näistä tilaisuuksista.

Yllättävän usein joutuu kuitenkin edelleen huomaamaan, ettei ulkomaailmalla ole käsitystäkään siitä työstä ja työn muodosta, jota testaajat todellisuudessa tekevät. Yhtä usein huomaa myös, että testaajat ovat jotenkin alistuneet tähän tilanteeseen, antavat tämän eron olla olemassa ja esimerkiksi hyväksyvät sen, että heille saarnataan asioista, jotka ovat lopullisen työn kannalta täysin yhdentekeviä.

Yksi syy tähän voi olla se, että jos työ oikeasti on kaoottista, voi olla mukavaa paeta hetkeksi toivemaailmaan jossa kaikki on järjestyksessä, kun se on tehty "oikealla tavalla". Kursseilla ja opetuksessa ei ole mukavaa kohdata sitä samaa hahmotonta painajaista, joka työpaikalla taas odottaa. Opettajan pitää luoda haavekuva, jota kohden ponnistella.

Ei auta ideaalit kuitenkaan paljon käytännössä. Niiden olemassaolo voi johtaa kyynistymiseen, jos lähellekään ei voi päästä tai jos ongelmat eivät tunnut hellittävän. Mikä neuvoksi?

Haluaisin itse testaajana oppia enemmän reagoimaan siihen mitä havaitsen, enkä vain ottamaan valmiita havaintoja vastaan. Ulkomaailmallekin haluaisin kertoa, että havaintoni ovat uniikkeja ja havaitsemiskykyni on tärkein työvälineeni testaajana. Hyväksymäni koulutus ei saa viestiä, että joku jossain tietäisi, mitä minun tulee havaita ja arvostelisi havaintojani kuin tarkistuslistaa.

Yritysten johdolle tämä toiveeni ei näy. Heille testaus on esitetty ja esitetään yhä edelleen ylhäältä päin kontrolloitavana vaiheena, jossa tavoitteet ovat selvät ennen testaukseen lähtemistä. Havaintoni testaajana eivät vaikuta tämän päätöstason asioihin, eivätkä ne siksi vaikuta lopulta mihinkään ketjussa alaspäin.

Testaajien äänenkannattaja

2009-11-04T12:24:00.000-08:00

Kerron seuraavassa oman mielipiteeni siitä mikä saa testaajat innostumaan James Bachin testausfilosofiasta.

1. James on pienen ihmisen asialla. Hän on taistelemassa yksittäisen testaajan puolesta suurta koneistoa vastaan. Se tuntuu hyvältä ja nostaa meidän kaikkien testaus itsetuntoa.

2. James on jättänyt koulut kesken, on ylpeä siitä ja mollaa "akateemisia" testaajia jatkuvasti. Hän haluaa kunnioittaa käytännössä opittuja taitoja ja voitte uskoa, että se juuri lämmittää itseoppineiden testauskonkareiden mieltä.

3. James ei ole niellyt teknisten edelläkävijöiden ja muiden auktoriteettien kunnioittavaa pelkoa. Hänen ei tarvitse vedota auktoriteettiin kyseenalaistaakseen jotakin. Hän voi sanoa ja heittää jotain, jota me muut emme kehtaa sanoa, koska me epäilemme että sehän voisi näyttää jotenkin teknisesti tai tieteellisesti triviaalilta. Me muut paketoimme siksi sanottavamme ympäripyöreiksi ja poliittisesti korrekteiksi väittämiksi, joissa ei siksi ole mitään särmää, eikä siksi lopulta mitään mieleen jäävää.

4. Testaajien odotetaan olevan nöyriä ja kilttejä. James ei täytä odotuksia.

5. James on löytänyt selkeän vihollisen ja osaa myydä tästä tilanteesta syntyvää jännitettä.

6. James tietää monen muun testauskonsultin tapaan, että testausteorian ja käytännön ero on suurempi kuin valovuosi. Ero on itse asiassa niin käsittämättömän suuri, että sen voi muotoilla, selittää tai täyttää hyvin monella erilaisella tavalla ja valitseepa sitten minkä tahansa "täyttötavan" voi vailla huolta ja aivan täydellä pokalla väittää, että on valinnut ainoan oikean tavan. Valtavasta teoria-käytäntö erosta nimittäin seuraa se, ettei kukaan pysty myöskään todistamaan väitteitäsi vääräksi, jos vain olet tarpeeksi aggressiivinen omien väitteittesi kanssa.

Jos joku vie voiton teoria-käytäntö kiistassa, niin ehkä lähinnä se, joka saa eniten tunnepuolen kannatusta testaajien keskuudessa ja silloin kyllä James on vahvoilla.

James Bachin filosofiaan ja blogiin pääsee tutustumaan täällä.

Testausvinkki 5

2009-10-28T01:01:00.000-07:00

Kuinka paljon taikauskoisuutta liittyy meidän omaan päivittäiseen ohjelmistojen käsittelyyn? Ohjelmistoja on kaikkialla ja useimpiin niistä emme ehdi aktiivisesti tutustua ja siksi kuvittelemme loput. Kuvittelu johtaa taas outoon käytökseen.

Luultavasti emme ole kuvittelumme kanssa yksin.

Listaapa huviksesi miten ajattelet esimerkiksi tankkauspisteiden korttiautomaatin ja bensapumpun toimivan yhteen. Miten tämä "tieto" vaikuttaa käyttäytymiseesi? Yritä myös selvittää miten oikeasti automaatti ohjaa pumppua.

Ovatko ohjelmistokehittäjät käsityöläisiä?

2009-10-23T00:51:00.000-07:00

Tätä kysymystä kysyttiin täällä.

Ennen kuin vastataan, on mietittävä mitä sana "käsityöläinen" tarkoittaa.
Useimmille tuosta sanasta tulee mieleen jonkinlainen räätäli, kuvanveistäjä tai taidemaalari. Monet meistä sekoittavat termin jollain lailla taiteen tekemiseen, jossa on sallittua tai jopa hyödyllistä rikkoa sääntöjä.

Haluammeko me sekoittaa ohjelmistokehittäjien työn entistä enemmän taiteen tekemiseen?

Emme taatusti halua. Emmekä siksi ota käyttöön mitään termejä, jotka ovat suuren yleisön silmissä näin läheisesti kytköksissä taiteeseen tai taiteilijaelämään.

Suurin osa ohjelmistokehittäjien työstä on tunnettujen ja kurinalaisten sääntöjen noudattamista ja heidän tulisi siksi käyttää taiteellisia vapauksia paljon vähemmän kuin tähän mennessä on tehty.

Monessa muussakin it-alan työssä tehdään käsitöitä ja niitä ei erityisemmin pidetä käsityöläisammatteina. Itse asiassa näillä muilla alueilla tarvittaisiin luovuutta paljon enemmän korvaamaan konkreettisten käytäntöjen puutetta.

Miksi suomessa ei ole avointa testauskeskustelua?

2009-10-15T04:11:00.000-07:00

Seuraavassa on syitä, joiden vuoksi moni jättää testauksen rauhaan ja kannustaisi mielellään myös minua tekemään niin.

1. Suurin osa ohjelmistokehityksen ammattilaisista ohittaa tämän blogin äkkiä, koska tässä ei puhuta tarpeeksi teknisen näköisesti testauksesta, joka heidän mielestään on it-puolen pakollisia reuna-alueita, jonka oikeat ammattilaiset voivat tunnetuilla teknisillä tavoilla hoitaa alta pois.
Ajattelutapa menee jotensakin seuraavanlaisesti: "Ne jotka testausta tekevät, voivat ehkä saada iloa siitä, että joku höpöttää psykologiasta ja muista tieteistä tässä yhteydessä, mutta jos kylmät faktat vaan lasketaan, niin testauksessa on pääsääntöisesti kyseessä vain tylsästä, toistuvasta, rutiininomaisesta nappulatekniikasta tai automatisoinnista."
Kun näin ajatellaan, on selvää, ettei blogeja synny.

2. En omaa, enkä kaupittele mitään mumbo-jumbo testituotetta, jolla triviaali asia (testaus) saataisiin entistä helpommin pois päiväjärjestyksestä. Siksi en oikein omaa kredibiliteettiä puhua aiheesta ja siksi on tietysti turha blogittaa. Eikö vain?

3. Yliopistot kouluttavat ohjelmistokehityksen tarpeita varten kapean näkökulman omaavia tietojenkäsittelytieteen ammattilaisia. He eivät osaa nähdä testausta muuna kuin yhtenä tietojenkäsittelytieteen reuna-alueena. Vaikka heille puhuttaisiin asiakkaan näkökulmasta ja he väittäisivät ymmärtävänsä sen olevan jotain mitä heillä ei ole, tämä ei oikeasti näy käytännössä. Asia on kuulemma vain järjestettävissä teknisesti kunhan otetaan vaikkapa käytettävyys kunnolla huomioon tutkimuksessa. Uskokaa siis vain, että Aalto-yliopisto hoitaa asian, kun kaikki alan asiantuntijat saadaan kerrankin yhteen asian taakse.

4. Testaajia on vähän ja he eivät näe suomenkieliselle blogille kysyntää. Tietotekniikan liitto julkaisi hiljattain testaussanaston, mutta epäilenpä että sen kehittyminen jää vähiin, jos vapaa-ehtoista keskustelua aiheesta tapahtuu vain säännönmukaisilla foorumeilla työssä, yliopistoilla ja konferensseissa. Siis jos kuvittelemme, että kyllä noilla foorumeilla tiedetään testauksesta paljonkin ja miten minä nyt siitä sitten kirjoittamaan.

5. Jos olisin ison, monikansallisen it-yrityksen työntekijä, kokisin valtavaa painetta mukautua paikalliseen "testausilmastoon". Jos perustaisin blogin ja puhuisin siinä testauksesta jonain muuna kuin teknisesti hallittavissa olevana kokonaisuutena, menettäisin kasvojani varsin ukkovaltaisissa teknis-orientoituneissa yhteisöissä. Teknisistä asioista puhuminen testauksen yhteydessä taas menettää kiinnostavuutensa parin kolmen blogikirjoituksen jälkeen ja siksi en lopulta blogittaisi.

Ps.
Kirjoitin edellä olevan tekstin viime viikolla ja löysin sen jälkeen yhden uuden suomenkielisen blogin aiheesta. Palataan sen suhteen asiaan, kunhan olen ehtinyt tutustua blogin tarjontaan.

Testaajien palkoista

2009-10-09T05:18:00.000-07:00

Avustajien rahallinen palkitseminen on yleensä minimaalista.
Esimerkiksi lääkäri saa yleensä "vähän" enemmän kuin hoitajat. Perusteena pidetään vastuun ottamista, työn vaativuutta ja laajuutta.

Olen verrannut ohjelmistotestaajan työtä hoitajan työhön. Osaksi se onkin sitä. Testaajan työn tarkoitus on tukea ohjelmistokehitysprosessia eri tavoin.

Hoitotyö on kuitenkin vain yksi näkökulma ohjelmistotestaajan työhön. Lähinnä se kuvaa testaajalle sopivaa asennetta työtovereihin, mutta ei kaikkea.

Toinen tärkeä analogia testaajan tehtävästä on rikoskomisarion työ. Se on vaativaa ja vastuunottavaa puuhaa. Komisario tarvitsee kohtuu vapaita edellytyksiä ja kukaan tuskin kiistää häneltä niitä. Komisario asettuu vastehankaan asiakkaittensa kanssa ja se kuuluu asiaan.

Testaajan työssä tarvitaan molempia (hoitaja+komisario) näkökulmia. Joskus on pakko olla pelkkä jääräpäinen tutkija jos haluaa saada tuloksia aikaan ja joskus taas on tuettava, jotta muiden itsetunto säilyisi.

Miten tämä näkyy testaajien palkoissa?
Vastaus: Ei mitenkään!

Ohjelmistokehityksen palkkamalleja tekevät tahot, jotka näkevät vain pelkän lääkäri-hoitaja suhteen. Otetaan esimerkki tästä. Yhdysvaltalainen Joel Spolsky esittelee Fog Creek yhtiön kehitysorganisaation palkkamallia seuraavissa osoitteissa: Ladder ja Raise

Malli on hienolta näyttävä. Mukana on muun muassa "scope" tekijä, jolla kuvataan jälkimmäisen lähteen mukaan seuraavaa: "Are you primarily helping someone else do his or her job?" Eli siis autatko pääasiassa toisia tekemään työnsä. Jos autat, on palkkasi vähäisempi ja taas jos auttamisen sijaan omaat jonkin oman kohdealueen vastuun, "scope"-tekijä on korkeampi ja siksi palkkasi on parempi. Yksinkertaista.

Tukityötä tekevä hoitaja-komisario testaaja ei sovi tähän malliin. Hän pyrkii yhteistyössä muiden kanssa rikkomaan ne näkökulmat jotka ovat vallinneet tähän asti ja tuo asiakkaan näkökulmaa tilalle. Edellä viitattu malli taas antaa testaajalle kunniaa kun hän on sisäistänyt kehitysorganisaation "kaanonin" eli sen näkökulman "miten meidän (kehitysorganisaation) mielestä asiat tulisi tehdä". Siihen asti kunnes testaaja omaksuu tämän näkökulman, palkka on huono.

Mielestäni kyseisen mallin mukaisten testaajien palkat voisivat olla myös jatkossa huonoja. Miksi? Koska asetetun näkökulman rikkomiseen ei ole juuri eväitä jäljellä, kun yksi ainoa tapa tehdä on ensin vakiinnutettu omaan mieleen.

Spolskyn esittelemä malli ei millään lailla kannusta "pois-oppimiseen".

Testien ohjaama hyväksyntätestaus

2009-10-07T00:28:00.000-07:00

Testien ohjaama hyväksyntätestaus (englanniksi Acceptance Test-Driven Development) perustuu yleensä testeihin, jotka testaavat abstraktoitua käyttöliittymää. Abstraktointi tarkoittaa tässä vaihtoehtoisen ohjelmoitavan rajapinnan testaamista normaalin käyttöliittymän sijasta. Tämä rajapinta on abstrakti, koska sen käyttötapa voi erota suuresti todellisen käyttöliittymän käyttötavasta. Esimerkiksi käyttäjä saattaa käyttää diaesitys ohjelmassa hiiren liikettä tai vaihtoehtoisesti valikosta haettua toimintoa ilmaisemaan sen mihin kohtaan diaa hän haluaa suurennoksen, mutta abstraktissa liittymässä tämä voi tapahtua aina kutsumalla funktiota, jolle annetaan suurennoksen koordinaatit parametreinä.

Huolimatta erilaisesta käyttötavasta tarjotun toiminnallisuuden pitäisi silti olla sama molemmissa liittymissä.

Testien ohjaama hyväksymistestaus tarkoittaa lyhyesti seuraavaa:

1. Joitain testejä (yleensä ohjaavia testejä) pyritään esittämään järjestelmällisesti ja selkeästi kaikille.
2. Näiden testien sisällöstä sovitaan yhdessä käyttäjien, tilaajien, testaajien, kehittäjien ynnä muiden viiteryhmien kanssa.
3. Tärkeää on, että kaikki ymmärtävät sovittujen testien kohdalla käytetyn liittymän abstraktoinnin samalla tavalla, jotta hommasta tulisi jotain.
4. Hyväksymistestaus perinteisessä muodossa ei häviä minnekään.

Kommentteja listan kohtiin:

Kohta 1: Käyttäjän virallinen käyttöliittymä täytyy myös testata, yhtä lailla kuin ohjelman sopivuus käyttäjän kykyihin, olosuhteisiin, tapoihin ja ympäristöihin. Testien ohjaama hyväksyntätestaus ei ole siksi oikopolku onneen. Se on ratkaisu vain yhteen pieneen tasoon koko testauskentässä. Sen tavoite on siirtää tämä pieni taso toivottavasti entistä enemmän kehittäjien tietoisuuteen ja vastuulle.

Kyseessä on se osa testaustyöstä, jonka ehdimme yhdessä tiiminä huolella pureksia, käydä läpi, suunnitella ja hahmottaa.

Kohta 2: Se miten käyttäjä, testaaja tai kehittäjä kuvittelee abstraktion todellisen toteutuksen tapahtuvan on tärkeä tieto. Sen ymmärtäminen ja hallinta vaatii pitkää ja aikaa vievää yhteistyötä. Se osataanko yhdessä abstraktoida liittymästä toiseen ei ole ollenkaan itsestään selvä asia.

Kysymyksiä ihmeteltäväksi:

Millaisen tunnelman pitkälle automatisoidut, jatkuvasti ajettavat, abstraktia liittymäpintaa testaavat ja ehkä lukumäärältään lukuisat testit antavat eri viiteryhmille, joiden eteen tuloksia jatkuvasti tuodaan? (Esimerkki esitystavasta, jolla kaikki voivat seurata testejä ja niiden suoritusta on FIT ) Tuleeko mieleen ajatus, että nyt on kehitystyötä tehty kurinalaisesti niin kuin pitääkin vai ajatellaanko, että testausta on nyt tehty huolellisesti?

Hyviä työvälineitä testaajille?

2009-10-06T09:33:00.000-07:00

Testaustyövälineitä syntyy kuin sieniä sateella. Suurin osa niistä on ohjelmistokehittäjille suunnattuja. Niistä työvälineistä, joiden ideoista voisivat testaajatkin hyötyä laitan infoa Twitteriin:

http://twitter.com/Avustaja

Ehdotelkaa lisää testaustyön apuvälineitä ja kertokaa mitä mieltä olette ehdotetuista.

Esitys Elkom 2009 tapahtumassa

2009-09-29T04:06:00.000-07:00

Pidin 24.9 lyhyen esityksen standardoidun ohjelmistotestauksen hyvistä ja huonoista puolista Elkom 2009 elektroniikkamessuilla. Ohessa on linkki kalvoihin.

Standardoitu ohjelmistotestaus

Esitys lyhyesti:
- Testauksen standardoinnin edut ja haitat
- Standardoinnin kohdeyleisö
- Näkökulmia ohjelmistotestaukseen

Kysymyksiä ennen sertifiointikurssia

2009-09-28T19:52:00.000-07:00

Otteita eräällä testauksen sertifiointikurssilla opetettaviksi määrätyistä asioista (suomennos on omani):

"Kontrollointi on jatkuvaa työtä. Se tarkoittaa sitä, että suunnitelmaa verrataan toteutuneeseen. Kontrollointi ohjaa testausta saavuttamaan tavoitteensa ja strategiansa."

"Testien lähdemateriaalin, testitilanteiden ja testitapausten välillä saattaa olla hyvinkin monimutkaisia suhteita, niin että yksi voi vaikuttaa moneen muuhun. Nämä suhteet täytyy ymmärtää, jotta testauksen suunnittelu ja kontrollointi voidaan toteuttaa tehokkaasti."

Ehdotus:

Kun menette testauksen sertifiointikurssille kysykää jatkuvasti opettajalta: mitä oli tarkoitus oppia ja mitä hyötyä sertifikaatista saan sertifikaatin itsensä lisäksi. Kysykää myöskin mitä näkökulmia kurssi jättää tietoisesti väliin.

Ottakaa tarkkaan selvää mitä kurssilla opetetaan. Vaatikaa 5-päivän kurssia 2-päiväisenä ja kysykää tarkkaan mitä ei opita, jos kurssisisältö tiivistyy rankasti. Kouluttaja osaa varmasti kertoa, mitä uuttaa jää oppimatta.

Sertifiointikursseilla ei saa yhdenmukaisuuden nimissä opettaa olemattomia tai itsestään selviä asioita. Tästä opettajalla on suuri vastuu. Hyvä opettaja ei piilota oman asiantuntemuksensa tai teknisen jargonian alle sitä tosi-asiaa, että opetettava asia sinänsä on jo kaikkien tiedossa ja sen muoto vain hämää ensikertalaista.

Testaajan tulisi olla epäilevä ja mielikuvitusrikas sielu. Kaikkien testauskurssien tulisi tukea tätä tavoitetta. Pyrkimys yhdenmukaiseen sertifikaattiin ei saa tulla esteeksi tälle päämäärälle.

Testauksen synkkä tulevaisuus

2009-09-14T06:04:00.001-07:00

Seuraavassa on lyhyt ote ja suomennos Michael Boltonin esityksestä kesäkuulta BCS SIGIST konferenssista Lontoosta.

Olkoon vain yksi oikea tapa testata
Olkoon vain yksi universaali kieli testaukselle (ja koska amerikkalaiset ja brittikonsultit promotoivat sitä, se tulee olemaan englanti.)
Ne jotka eivät mukaudu, olkoot "kypsymättömiä".

Muutamia heränneitä ajatuksia:

Missä on suomenkielinen testauksesta keskustelu? Missä näkyy kritiikki nykyistä testaussuuntausta vastaan? Missä on suomenkieliset blogit testauksesta? (Yritelmiä on, aktiivisia ei missään.)

Ei riitä, että muutama puhumisesta leipänsä ansaitseva konsultti höpöttää testauksesta joka testausseminaarissa. Tarvitaan innostuneita ohjelmistotestauksen työmyyriä pitämään blogeja ja kasvattamaan omaa näkökulmaa testauksesta. Vain näin suomeen saadaan aitoa testauksen arvostusta, sanastoja ja testausosaamisen reilua jakoa.

Myös suomen kielellä pitää puhua ohjelmistotestauksesta julkisesti. Testaus ei ole niin kuin ohjelmointi, että se opitaan teknisesti kerran ja sitten siitä puhutaan vain uusien tekniikoiden muodossa gurujen kesken. Ohjelmistotestauksesta ei ole olemassa toimivaa yhtenevää kuvausta, jonka päälle voisi kovasti lähteä guruilemaan.

Miksi kuvitellaan, että kaikki osaa testata?

2009-09-13T22:48:00.000-07:00

Pelkkä hyvä päämäärä ei riitä onnistumiseen, jos ei alunperin edes tiedetä mistä lähdetään. Saatetaan rakentaa jotain sellaisen varaan, mikä ei kestä.

Ajateltiin, että kaikki osaa testata, jotenka päämääräksi otettiin jotain muuta. Päämääräksi tulikin sen tarkka mittaaminen kuinka hyvin testauksen tukitöitä osataan tehdä. Itse testaus otettiin annettuna edellytyksenä.

Mitä ovat testauksen tukityöt? Esimerkkejä: testauksen dokumentointi, juurisyiden analysointi, debuggaus, testien kirjoitus, testien skriptaus, testikielien hallinta, testi tekniikoiden hallinta ja sujuva puhuminen testauksen puolesta.

Jokainen näistä tukitöistä voi auttaa, mutta itse testausosaamista testaustilanteessa ne eivät suoraan mittaa.

Alkuperäinen tilanne onkin ehkä seuraava: Jonkin verran testausta osaa tehdä jokainen, mutta kukaan ei ole syntyjään hyvä siinä ja todellisen testausosaamisen mittaamiseen tai kouluttamiseen ei välttämättä löydy osaavia tahoja mistään.

Syy-yhteydet

2009-09-07T09:31:00.000-07:00

Ihmisillä on taipumus liittää mielessään yhteen rinnakkain tapahtuneita asioita. Jos nettiyhteys hidastuu, koska joku käveli juuri wlan-modeemin ohi, epäillään heti syy yhteyttä. Suora ratkaisu: Eristetään polku modeemin ja koneen välillä, niin että kulkeminen vaikeutuu. :)

Olemme helposti taikauskoisia ja uskomme hyvin erikoisiin syy-yhteyksiin. Esimerkistä käy vaikka seuraava sarjakuva.

Lähde: http://blogs.msdn.com/officeoffline/

Koska ihmisten kokemus laadusta on aina osaksi sidoksissa näihin outoihin uskomuksiin, on laadun testaus erittäin vaikeaa. Melkeinpä mahdotonta.

Yksi tapa helpottaa testaustyötä on kokeilla "vierihoitoa". Ole siellä missä käyttäjätkin. Ohjelmistotestaajan, joka ei koskaan vietä arkipäiväänsä ohjelmiston käyttäjien kanssa, on erittäin hankala päästä sisällä asiakkaan arjen kummallisuuksiin.

Testausvinkki 4

2009-09-01T22:13:00.000-07:00

Kriteeri hyvän testauskirjallisuuden etsijälle:
Jos kirjan sisältö näyttää olevan kombinaatio projektikaavioita, dokumenttien mallipohjia ja tietojenkäsittelytiedettä, jätä se hyllyyn.
Kirjan tekijät ovat käytännössä unohtaneet mikä sanan testaus perusmerkitys on. Testaus on tuossa kirjassa luultavasti vain olemassaoleviin tuotantoprosesseihin ja asenteisiin sopivaa rajoitettua laadunvalvontaa.

Testausvinkki 3

2009-08-30T22:51:00.000-07:00

Kun haet testaustyötä, kerro tarkkaan millaista ajattelet testauksen olevan työmuotona. Kerro kuinka laajaa testaus on mielestäsi ja mitä tarvitset pystyäksesi tekemään työsi.
Katso tarkkaan haastattelijan reaktiota. Jos haastattelija vetoaa heti reaaliteetteihin ja "olosuhteiden pakosta" täsmentää työnkuvaasi, voit olla varma, että rajoitukset eivät uudessa työpaikassasi jää tähän.

Testausvinkki 2

2009-06-23T06:50:00.000-07:00

Kun kesällä seilaatte ympäri maita ja mantuja, niin ostakaapa kaikissa mahdollisissa tilanteissa matkalippunne asemilta löytyvillä automaateilla. Tutkikaa niiden käytettävyyttä ja miettikää kuka on mahtanut niitä oikein testata.

Kerään syksyllä tänne omia ja muiden kokemuksia näistä lippukojuista. Lähetä siksi rohkeasti testauskokemuksia.

Kännykuvat oudoista käyttöliittymistä ja bugikuvaukset voi laittaa allekirjoittaneelle osoitteeseen teppo.heikurinen(at)gmail.com
Lupaan julkaista hyvät jutut.

Testausvinkki 1

2009-03-09T07:04:00.000-07:00

Opiskele tietoturvatestausta, vaikka et koskaan tulisi tekemään sitä. Järjestelmän heikkouksia ymmärtäminen parantaa testaustasi, dokumentointiasi ja kykyäsi kommunikoida ongelmat.

Lähtökohtia tietoturvatestauksen opetteluun:
OWASP
CISSP
CISA

Testausammattilaiseksi täsmäkoulutuksella?

2009-02-17T01:03:00.000-08:00

Hiihtolomasta huolimatta testaus pyörii mielessä.

Taantuman tullessa testausammattilaisten täsmäkoulutusohjelmat saavat uutta nostetta siipiensä alle. Niissä yhdistetään yleensä lyhyt koulutus ja käytännön tyoskentely ja siten saadaan testaajia teollisuuden tarpeisiin. Yleensä ohjelman järjestämisen taustalla on jotain yrityksiä, jotka sekä tarjoavat harjoittelun ajaksi työpaikan, että ehkä myös sen jälkeen.

Koulutusohjelmien idea on sinänsä hieno, mutta kiinnostaisi vaan kovasti tietää mitä noilla kursseilla tarkkaan ottaen opetetaan?

Jos haetaan henkilöitä täsmäkoulutuksella tarpeisiin joita alan yrityksillä jo on, niin millaista se koulutus sisällöltään on? Onko niin, että koska tarve on jo olemassa, testaajaa ei enää tarvita sen tarpeen löytämiseen, vaan johonkin muuhun? Miten destruktiivisen ja uusia näkökulmia etsivän työn (testaus) opettaminen onnistuu pysymään oikean mentaliteetin opettamisena, kun testauksen tarpeet on jo tiedossa?

Opetetaanko näissä ohjelmissa eri tavoin luovaa ajattelua, jolla on sitten mahdollista rikkoa työnantajan luutuneita kehitysprosesseja, näkökulmia ja asenteita? Opetetaanko tekemään aloitteita, jotka eivät lyhyellä kantamalla näytä edes säästöiltä?

Opetetaanko ohjelmissa ja jos opetetaan, niin kuinka paljon opetetaan asioita, jotka eivät suoraan liity testaukseen ja jotka eivät siten ole suoraan mitattavia, mutta joista luova testaaja voisi löytää maaperää uusille näkökulmille? Esimerkeistä kävisivät geenitiede, psykologia, hermosto- ja aivotutkimus tai uskontotieteiden tutkimus. Viimeiseksi mainittu voisi hyvinkin valaista niitä uskomuksia ja oletuksia, joita ihmiset omien tarpeidensa takia myös softaan liittävät.

Epäilen, että näiden "muiden" asioiden opettamiselle ei nähdä suoraa tarvetta ja koska aikaa on rajallisesti, ohjelmissa keskitytään niiden asioiden opettamiseen, jotka voidaan opettaa nopeasti. Tässä ei ole mitään uutta: Testaus on aina määritelty asiaksi, jonka oppiminen on nopeaa.

Otetaanko ohjelmiin mielellään mukaan muitakin kuin it-alan perustutkinnon suorittaneita henkilöitä? Jos otetaan, niin vaaditaanko heiltä kuitenkin tiukan tekninen näkökulma: kokemusta it-jargoniasta ja tekniikasta? Epäilen, että vaaditaan.

Epäilen kokonaisuudessaan, että nämä valmennusohjelmat opettavat jotain muuta kuin testausta. Harmi kyllä, uusi oppilas saattaa tietotulvan keskellä aluksi luulla toisin.

Jos osallistut näihin ohjelmiin, kysy osallistumisen jälkeen itseltäsi, opetettiinko sinua käyttämään henkilökohtaisia vahvuuksiasi ja jo omaamiasi kykyjä, tietoja ja taitoja uusilla tavoilla ja uusissa konteksteissa, vai kerrottiinko sinulle, että tätä on testaus, näin siitä puhutaan, näin siitä raportoidaan ja näin sitä valvotaan.

Huippuaiheinen testausblogi

2009-02-11T04:04:00.000-08:00

Mies, joka sai kenkää eräältä kansainväliseltä yhtiöltä sovellettuaan tutkivan testauksen menetelmiä käytännössä. Alansa guruja nykyisellään. Pitää upeaa testausaiheista blogia.
Käykää katsomassa, jos haluatte testauksesta jotain oppia.

Linkki: Tester tested

Mitä testaajien välinen kilpailutus saa aikaan?

2009-02-02T10:04:00.000-08:00

Kilpailutus vie terän pois siltä ainoalta asialta, joka testauksessa todella merkitsee: kommunikaatiolta. Jos muissa systeemityön alueissa kilpailutus voi saada aikaan tervettä kehitystä, niin näin ei ole asia testauksen kohdalla.

Testaustaito perustuu pitkälle luoviin taitoihin: tiedon löytämiseen, tiedon soveltamiseen uusista näkökulmista ja tiedon avoimeen jakamiseen. Miten näiden taitojen yhteydessä kilpailutus voisi olla rakentava voima? Virtaviivaistaminen ja kilpailutus ei todistetusti rakenna luovuutta ja avoimuutta.

Kilpailutusta ei pääse täysin pakoon, mutta testaajien ei kannata olla mukana rakentamassa perusteetonta kilpailutusta testaajien välille. Kaikenlaiset testausstandardit ovat tässä suhteessa vaarallisia, jos ja kun ne pyrkivät määrittelemään ohjelmistotestauksen kokonaisvaltaisesti. Testausta ei vielä tunneta kovinkaan hyvin, mutta standardit antavat ymmärtää jotain ihan muuta. Niille perustetut sertifikaatit ovat vain ikävä tapa luoda huonosti tunnetun asian ympärille keksittyä kilpailua ja keksittyjä hierarkioita.

En silti vastusta testausstandardien (esim. ISTQB) kehittämistä. Niiden varaan ei vain kannata perustaa testaajien arviointia.

Testausstandardit ovat mielenkiintoinen yritys formalisoida testausta. Niiden tutkiminen sopii erinomaisesti testausta käytännössä hyvin tuntevalle, joka osaa nähdä standardoinnin suhteellisen aseman ja osaa kokemuksensa perusteella erottaa niihin ripotellut totuuden siemenet.

Testauskouluttajan tehtävä

2009-01-30T02:31:00.000-08:00

Testauskouluttajan työ on siinä mielessä mukavaa puuhaa, että sen ohessa voi tehdä jatkuvasti myös itse testausta. Voi jatkuvasti kokeilla ja miettiä erilaisia tapoja jumiuttaa arkipäiväisiä sovelluksia mielin määrin. Tiukan kaavamaiseen testaukseen keskittyvässä työssä tämä voi olla harvinainen huvi.

Jos ajattelee, että tämän kaltaisessa testausharjoittelussa jää näkemättä se tärkein, eli testausprosessit ja testauksen kontrollointi käytännössä, niin tämmöinen kouluttajan touhustelu voi näyttää turhalta ja jää äkkiä tekemättä.

Jos taas ajattelee, että testauskouluttajan on tarkoitus ohjata itse testaustyötä, motivoida sitä ja näyttää minkälaisesta käsityöstä lopulta on kyse, niin silloin tästä omatoimisesta testaustouhusta on paljon hyötyä.

Jos kouluttajan kurssin jälkeen opetettava on huomannut, että hänen omasta päivittäisestä testauksesta on löytynyt jotain aivan uutta hänelle, niin hänen ammatillinen vahvuus on kasvanut oikeasti. Jos taas kurssin jälkeen on oppinut vain paketoimaan vanhat testaustermit, prosessit ja metodit uusiin kääreisiin, niin testaustyö näyttää varmasti entistä kaavamaisemmalta ja ammatillisesti heikolta valinnalta.

Ohjelmistotestauksen kansainvälinen kieli

2009-01-28T05:54:00.000-08:00

Systeemityön innovaatioita ohjaavat useimmiten natiivisti englantia puhuvat persoonat. Varsinkin testauksen kohdalla on näin ja yritän nyt perustella väitteeni.

Ensiksikin testaus on se alue ohjelmistokehityksestä, joka on vähiten tunnettu ja siksi se on altis pätemiskohde henkilöille, jotka osaavat perustella ja runnoa läpi "filosofisia" ideatason ajatuksia toisille. Tämä siksi, että testauksen kehittymisessä oleellista on uudet näkökulmat ja vanhojen ajattelumallien haastaminen. Testaaja on se, joka lopulta pysäyttää teknologia-, prosessi- ja metodiuskollisuuden ja kysyy, että "ajattelimmeko myös tätä vaihtoehtoa?"

Ideoiden innostavassa kuvailussa tarvitaan loistavaa kielitaitoa, ja usein sponttaaniutta, jotta kansainvälisissä seminaareissa tulisi kuulluksi. Myös se, että pystyy kouluttamaan jotain muuta kuin tietyn valmiin ajattelumallin ajatuksia, vaatii kielitaitoa, jossa ajatuksen sponttaani juoksu siirtyy suoraan kieliopillisesti ja semanttisesti oikeisiin lauseisiin.

Jos ei pysty tähän englannin kielellä, niin useimmiten täytyy turvautua valmiisiin turvaverkkoihin: standardeihin, prosesseihin, auktoriteetteihin. Näiden kautta välittyy tietoa ja asiat ymmärretään varmemmin, mutta samalla ollaan huomaamatta luovuttu vapaudesta kertoa uusia näkökulmia.

Toiseksi myös vastaanotto ja esitetyn todellinen haastaminen vaatii kielitaitoa. Ajatuksia syntyy ja samoin vastaväitteitä, mutta entä niiden nopea esitys?

Tämä kaikki on valitettavaa siksi, että ohjelmistotestauksen viimeisimmät trendit (esim. ketteryys) painottavat tasavertaista kommunikaatiota ja roolittomuutta, mutta käytännössä näitä ei saavuteta, koska sen todellisen kansainvälisen ohjelmistotestauskielen eli englannin kohdalla toiset ovat aina tasavertaisempia kuin toiset. Roolit syntyvät väkisin.

Ohjelmistotestaus ja standardointi

2009-01-28T04:35:00.000-08:00

Ihan kaikissa asioissa teollinen tuotanto ei suosi standardeja. Varsinkin niiden asioiden yhteydessä, joista halutaan saada todellista kilpailuetua, ei useinkaan edes puhuta standardoinnista. Esimerkiksi autonvalmistajat eivät standardoi tuotteitensa ulkonäköä tai lisäominaisuuksien käyttötapaa. Näissä asioissa standardointi rajoittaisi myyntietua ja siksi moinen puhe on täysin keskustelun ulkopuolella.

Ratkaisevaa sille, mitä standardoidaan ja mitä ei, on kai se minkä luonteiseksi käsiteltävät asiat koetaan. Ne asiat, jotka koetaan tiukkaa kuria, järjestystä, toistettavuutta ja suurinta mahdollista formalismia vaativiksi, joutuvat standardoinnin kohteiksi enemmän tai vähemmän. On sitten tietysti täysin eri asia ovatko nämä asiat todellisuudessa parhaimmillaan näin formaaleja.

Useimmiten esimerkiksi testaus mielletään standardoitavaksi työvaiheeksi, mutta mihin tämä ajatus syvimmiltään perustuu? Onko pohjana empiirinen tieto, tutkittu tieto vai mikä?

Tuntuu vähän siltä, että useimmat argumentoinnit, jotka ovat johtaneet ajatteluun testauksesta mahdollisimman kuria ja järjestystä vaativana työvaiheena, perustuvat vertailuihin testausta arvostamattomien ja sitä kaavamaisesti tekevien välillä. Koska ensimmäisessä joukossa tulokset olivat huonoja, niin tietysti siitä voidaan päätellä että toisen joukon tekemä työ on lähellä optimaalista testausta. Vai voidaanko?

Ketteryys korruptoituu?

2008-12-19T00:43:00.000-08:00

Niin se vaan on, että kaikki hyvä loppuu siinä vaiheessa, kun se puristetaan massamuottiin. Näin on käymässä myös ketterälle ohjelmistokehitykselle ainakin jos post-agile liikkeen maalaamia uhkakuvia uskoo.

Ketterien menetelmien suurin saavutus on ehkä se, että läpi it-alan on alettu uskoa, ettei ohjelmistokehitysprosesseista oikeasti tiedetä juuri mitään sellaista, mitä kannattaisi kovasti formalisoida. Parempi on antaa tuki sosiaalisille työskentelytavoille, jotka ovat lähempänä oikeaa kuin prosessivetoiset likuhihnamallinnukset.

Ketteryys (agile) on lopulta näin yksinkertainen asia, mutta samalla sen yksinkertaisuus on erittäin vaikeasti tajuttavaa. Vaikeuden todistaa se tapa, jolla suomessakin ketterien menetelmien tulemista on hehkutettu. Etsi vaikka viimeisen kahden vuoden ajalta ketteryydestä kirjoitetut suomalaisten tietotoimistojen artikkelit ja mieti mitä niissä termiin "ketterä ohjelmistokehitys" assosioidaan. Ainakin minulle tulee näistä artikkeleista sellainen tuntuma, että ketteryys on nyt jokin uusi tapa reagoida vikkelästi muutokseen, joka vaatii uudenlaista huippuosaamista, mutta kun sen ketteryyden sitten oppii, niin tuottavuus on selvässä kasvussa. Oppimista auttavat ketterät konsultit, ketterät työvälineet ja ketterä testaus. Näin siis annetaan ymmärtää.

Tämä sumutus voi johtua siitä, etteivät osata nähdä hypen alle ja tajuta, että ketterissä menetelmissä ei ole sinänsä mitään uutta, eikä niihin sisällly mitään takeita onnistumisesta. It-alan ihmiset osaavat kuitenkin ilmeiseti nähdä, millä tavalla hypestä kuin hypestä saadaan aikaa elitistinen, harvain osaama "tuote."

Miten tämä elitisointi onnistuu? Siten, että paketoidaan idea tuotteeksi prosessimaisesti. On löydettävä tai keksittävä seuraavat asiat: 1. Asian osaajat, jotka voidaan yli-inhimillistää, 2. Työvälineet, jotka ovat niin relevantteja, että ilman niitä homma ei luonnistu 3. prosessimalleja, jotka voivat olla kevyitä, mutta ovat silti tärkeitä tuotteen "oikeassa" osaamisessa (sertifioinnneissa), ja 4. tuloksia, jotka näyttävät vakuuttavilta.

Ketteryys korruptoituu, kun sitä käsitellään vanhoilla menetelmillä.
Otetaan tästä esimerkki. Seuraavanlainen kerronta on tätä prosessimaista mystifiointia, jota alan lehdissä valitettavan usein näkee:

"Asiakkaille tarjottujen modernien palveluiden kehitys ja suunnittelu on ketterissä menetelmissä saatu hallintaan, ottamalla jatkuvaan muutokseen reagoiminen ensisijaiseksi lähtökohdaksi. Vanhat tavat, taidot ja oletukset tilaajien tarpeista vanhenevat modernissa tietojärjestelmäprojektissa joka hetki ja sen vuoksi kilpailuetu on mahdollista saavuttaa vain pysymällä askeleen edellä muutosvauhdissa. Kun muutos tulee sen hyväksyntä ei ketterässä projektissa ole kivulias vaihe, vaan koko muutos on täysin ennakkokaavailujen mukainen.
Tähän päästään vaatimalla tekijöiltä enemmän osaamista uusien teknologioiden ja asiakaslähtöisyyden alueella. Tekniikan lisäksi nykypäivän ketterän osaajan on hallittava asiakkaan tarpeet ja erityisesti laadunvalvonta aivan uusissa mittasuhteissa. Käyttäjä otetaan ketterässä suunnittelussa mukaan suunnitteluun ja toteutukseen, eikä vain pelkkään vaatimusmäärittellyyn. Tarkoitus on saada aikaan osaavalla tiimillä aikaan käyttäjälle sopivia palveluita nopeasti."

Eikö tämän olisi voinut selittää myös näin:

"Tarvitut palvelut muuttuvat usein nykymaailmassa ja siksi kehittämiseen ei jää paljoa aikaa. Onneksi toisaalta mitään ei ole koskaan osattukaan kehittää pitkien suunnitelmien ja sopimusten mukaan, jotenka tämä nykyinen muutoksen nopeus sopii meille ihmisille varsin mainiosti. Ketterät menetelmät yrittävät herättää meitä tähän tosiasiaan."

Ohjelmistotestauskirjojen seksikkyys?

2008-12-13T01:28:00.000-08:00

Etsi käteesi jokin ohjelmistotestausta käsittelevä kirja. Jos löydät sen kirjakaupasta, niin älä kuitenkaan osta sitä vielä. Lue vain kirjan sisälllysluettelo läpi, silmäile sisällystä ja ota seuraava testauskirja hyllystä samalla lailla tarkastettavaksi. Jatka tätä prosessia kaikkien tarjolla olevien ohjelmistotestauskirjojen läpi, mutta sivuuta "test driven development" tyyppiset kirjat, joissa testaus sana on mukana vain hämäämässä. (Nuo kirjat kuvaavat kehitysprosessia, eivät testausta.)

Luultavasti huomaat, että kirjoissa jauhetaan paljolti samaa. Samat termit pyörivät, samat tekniikat (esim. ekvivalenssijako, koodikattavuudet) on selostettu juurta jaksaen ja vaikka kirjoittajan varsinainen pointti olisi jossain muualla, hän käy nämä samat pakolliset topiikit läpi ikään kuin velvollisuudesta (tai sitten vain täyttääkseen kirjan sivuja). Vain poikkeustapauksissa tästä poiketaan.

Seurauksena on se, että nuo kirjat ovat hirveitä järkäleitä, joista seksikkyys on kaukana. Niitä ei kukaan it-peruskoulutuksen jälkeen oikeasti lue (vaikka niissä kuinka lukisi sanat "practical ja "advanced") ja niitä käytetään korkeintaan viitehakemistoina, joista haetaan esimerkkejä koulutukseen, mutta ei todelliseen testaustyöhön. Noiden kirjojen tehtävä on siksi todellisuudessa kirjoittajan aseman varmistus. Kun kukaan terve it-osaaja ei lue näitä kirjoja, jotenka niiden tehtäväksi jää esteettisin arvoin (lähinnä sivumäärillä) todistaa, että kirjoittaja tietää testauksesta jotain. Silloin kirjan sisällöksi sopii aivan hyvin perusasioiden kertaus, koska se on turvallista itse kirjoittajalle ja karkoittaa kaikki testauksesta omaehtoisesti kiinnostuneet lukijat.

Poikkeuksia löytyy, mutta niitä ei ole julkaistu viimeisen 30-vuoden aikana kuin muutama. Yksi niistä on "Lessons learned in software testing", jota vieläkin voi suositella, vaikka julkaisupäivästä on aikaa.

Nuo muutamat poikkeuskirjat kirjat on helposti luettu läpi ja sitten lukija jää kysymään, että oliko se nyt siinä? Mistä saisi mahdollisesti lisää tietoa, ilman, että täytyy avata toinen "puhelinluettelo" samoista aiheista ja etsiä siitä jotain piilotettuja aarteita? Löytyykö kirjoja, jotka eivät aliarvio lukijaa? Onko blogit ja sekalaiset web-sivustot ainoa vihjeiden lähde?

Toisenlaisiakin kysymyksiä herää näiden kirjojen pohjalta: Osataanko testaus jo nyt niin hyvin, että kirjoissa voidaan siirtyä kertaamaan ja hiomaan jo tämän hyvin tunnetun monoliittisen testauskokonaisuuden kulmia? Jos koko ohjelmistotestaussysteemi on valmis, niin sitten on ehkä ymmärrettävää, että kertaamisen taakkaa on vain paljon, koska "totuus" on jo tunnettu.

Kaipaisin itse lisää kirjoja, jotka lähtevät soveltamaan ja synnyttämään testauksen riemua. Jos tiedät sellaisia, niin laita kommentteja.

Uutuus: Advanced Software Testing - Vol. 1

2008-12-09T11:02:00.000-08:00

Kasainvälisen testaustandardointi organisaation ISTQB:n presidentti Rex Black on tuottanut uuden kirjan, jonka sain pari viikkoa sitten hyppysiini. Kirjan nimi on "Advanced Software Testing - Vol. 1" ja alaotsikko on "Guide to the ISTQB Advanced Certification as an Advanced Test Analyst".

Kirja on tehty itseopiskelupaketiksi ISTQB:n jatkokursseja ja sertifikaatteja varten. Esipuheessa kirjaa suositellaan myös niille, jotka eivät ISTQB sertifikaattia aio suorittaa, mutta ovat kiinnostuneet kehittyneestä ohjelmistotestauksesta. "if you are .. field where a sophisticated understanding of software testing is needed, then this is a book for you."

Kirja seuraa ISTQB:n määritelemän "Advanced Test Analyst" kurssikuvauksen sisältöä orjallisesti. Jos kurssikuvaus (syllabus) on sanonut, että tietty asia on tarkoitus vain tunnistaa, niin silloin se vain mainitaan kirjassa ja jos jotain pitäisi todella osata käyttää, sille on omistettu kymmenittäin sivuja.

Yksi esimerkkialue johon kirjassa panostetaan on määritelmiin perustuvat testaustekniikat. Esimerkit liukulukujen käytöstä tekniikoiden kanssa ovat kohtuullisen hyviä ja antavat lukijalle ehkä eniten ideoita, mutta muuten yksityiskohtaisuuden määrä ei tunnu olevan suhteessa saatuihin hyötyihin. Otetaan esimerkki: Kirjan käyttötapausluvussa kuvataan pitkästi kuinka luonnosmaisen käyttötapauksen jokainen skenaario kopioidaan omalle lomakkeelleen ja kuinka nämä skenaariot sitten vielä kopioidaan tarkoille testitapauslomakkeille askelsarjoiksi. Kuvauksen tarkkuus lisääntyy kopioinnin aikana, mutta onko se käyttötapaustestauksen pääasia? Puoli sivua on tämän jälkeen käytetty sen selittämiseen mitä muuta käyttötapauksesta voisi testata.

Tilapohjaiseen testaukseen kirjasta käytetään 30 sivua, mikä on ihan hyvä asia.
Ohessa mainitaan muun muassa koosteiset tilat ja tilapohjaisuuden yhdistäminen muihin tekniikoihin, mutta kirjassa ei ole näistä sovellettua esimerkkiä.

Tutkiva testaus ja haavoittuvuuksien testaus on määritelmien lisäksi kirjassa yhdistetty ISTQB:n määrittelemiin tekniikoihin esimerkkitehtävässä, johon Rex antaa oman ratkaisuehdotuksensa. Jos emmitte kirjan ostoa, katsokaa kirjakaupassa sivut 258-262. Siinä löytyy kirjan ehdotelma heuristisen ja tekninen testauksen yhdistämisestä toisiinsa.

Testauksen hallinnasta ja riskipohjaisesta testauksesta annetaan hyviä linkkejä, mutta itse kirja ei lisää juuri mitään siihen, mitä näistä asioista voi oppia lukemalla kurssikuvauksen ISTQB:n sivuilta ja tekemällä lyhyen nettietsinnän.

Jos olet valmentautumasssa ISTQB:n peruskurssille ja omistat jonkin IT-alan perustutkinnon, niin tässä on kirja, joka kannatta ostaa ennemmin kuin yksikään puhdas ISTQB fundamentals kirja. Jos taas et valmentaudu ISTQB tentteihin, niin tarkista edellä mainitut sivut ja katso innostutko, ennen ostopäätöksen tekemistä.

Analogia ohjelmistotestaajan työlle

2008-12-09T04:05:00.000-08:00

Testaaja on palvelun tuottaja, jonka työ useimmissa organisaatioissa on verrattavissa hammashoitajan työhön. Muisteleppa vaikka viimeistä paikkausreissuasi ja sitä mitä muistat hoitajan roolista.

Saattoi olla, että juuri hoitaja kutsui sinut sisään ja haki asiakastietosi sillä välin kun tohtori jutteli sinulle mukavia. Ennen operaation alkua hoitaja oli tehnyt paljon muutakin ja siksi lääkärillä oli aikaa lörpötellä kanssasi. Esimerkiksi suuhusi työnnetyt instrumentit oli steriloitu huolella, leukasi alla oleva työtasot oli putsattu ja operaation kannalta kaikki tarpeellinen oli haettu käden ulottuville sitä hetkeä varten, jolloin lääkäri tarttuisi toimeen. Paikkauksen aikana, hoitaja oli myös luultavasti se, joka sekoittaa paikka-aineet.

Lääkäri ohjaa operaatioita ja hoitaja varmistaa sujuvuuden ja hygieenian. Hyvän hoitajan toimintaa ei kaikin puolin edes huomaa, koska se tukee kaikessa lääkärin toimintaa saumattomasti. Huonon hoitajan huomaa esimerkiksi epäkäytännöllisyydestä ja kiireestä, joka vastaanotolla vallitsee.

Ohjelmistotestaajan työn pitäisi periaatteessa olla vastaavaa tukityötä, joka kannattelee muiden uurastusta, tehden sen helpommaksi. Toisille tulisi saada "siivet selkään", niin että heidän osansa systeemityössä helpottuu huomaamatta ja työ onkin osittain leijuntaa testaajan luomalla alustalla.

Hoitajan työ on positiivista ja niin tulisi testaajankin työn olla. Hoitajan työ rakentaa työlle puitteita myönteisessä hengessä, mikä on välttämätöntä hoidon onnistumiseksi ja työilmapiirin ylläpitämiseksi. Testaajan työn tulisi samoin nostaa myönteisessä hengessä esiin kiinnostavia testauskohteita, eikä vain puhua bugeista, jotka rassaavat kaikkien hermoja. Puhuminen avoimesti siitä mitä aikoo testata ja mitä ei aio ja mikä voisi olla haastellinen kohde testaukselle, on yksi tapa kehittää tätä myönteistä kommunikaatiota. Samalla testaus tulee ikään kuin tarjottimella siihen lähelle ja voi olla että asiaan tartutaan ilman erillistä komennusta.

Testaus SCRUM projektissa

2008-12-02T02:52:00.000-08:00

Otsikkona tämä olisi huippuaihe kirjalle tai kurssille. Varmasti löytyisi ostajia.
Testaus SCRUM projekteissa on päivän polttava aihe.

Miten testaus ja Scrum nitoutuu yhteen?.

Ensiksi on todettava, että scrum ei ole systeemityömenetelmä, joka helpottaisi testauskäytäntöjä. Scrum on manageroinnin viitekehys, joka helpottaa kehitystiimien ja kehityskohteiden hallintaa. Scrum luottaa empiiriseen (kokemusperäiseen) mangerointiin, ketteryyteen ja kehitystiimien itseohjautuvuuteen. Scrum on tapa mangeroida prosessia, jossa manageroitavaa kohdetta, tuotetta tai tiimiä ei tunneta riittävästi, jotta sen toiminnasta voitaisiin tehdä teoreettinen malli. Tämän kaltaisia tuntemattomia prosesseja ovat käytännössä kaikki ihmisten suorittamat kehitystyöt. Siksipä scrum sopii kaikenlaisen ohjelmistokehityksen hallintamalliksi.

Scrumin yhteydessä puhutaan paljon testauksesta, mutta useimmat näistä termeistä tulevat muualta. Taustalla on usein jokin muu ketterä (agile) menetelmä. Esimerkiksi Extreme programming (XP) on ketterä menetelmä, joka Scrumista poiketen tarjoaa suoria testauskäytäntöjä ja joskus nämä sekoitetaan Scrumin piirteiksi.

Jos unohdamme muiden ketterien menetelmien käytännöt ja analysoimme mikä puhtaassa Scrum managerointiprosessissa kohdistuu suorasti tai epäsuorasti testaukseen, tulee mieleen seuraavia asioita:

1. Ei rooleja (Ei puhtaita kehittäjiä, testaajia jne.)
Tämä on mahtavaa osaavan testaajan kannalta ja myös upeaa niille kehittäjille, jotka ovat tuskailleet ja ihmetelleet sopivien testikohteiden valintaa.
Pysyvät roolit tuppaavat jähmettämään mielen tietyille urille, kun taas vaihtelevat roolit saavat aikaan uusia näkökulmia. Osaava testaaja ui näissä roolittomissa tiimeissä kuin kala vedessä, koska nyt hän voi tehdä muutakin osaamaansa, tuottaa tietoa monin eri tavoin ja hänen kysymystensä kanssa on kaikkien elettävä päivä toisensa jälkeen. Ei ole enää helppo muodostaa kehittäjien "hautomoja", joissa "tekniset" kaverit keskustelisivat keskenään "ei-triviaaleista" ongelmista kielellä, joka helpottaa "itsestään selvyyksien" yli pääsemistä. Tämä ei onnistu nyt, sillä Scrum tiimissä keskustelun taso on sovittava yhdessä testaajan kanssa ja - yllätys, yllätys - tekninen taso ei välttämättä laske siitä yhtään. On vain huomattava, että on muitakin näkökulmia.

1. Lyhyet kehityskierrokset
Perusperiaate: Ota vain sen verran kakusta kuin pystyt kerralla syömään. Kokemus on tässä tärkein opettaja.
Uskon, että lyhyet kehityssyklit pakottavat miettimään esimerkiksi testausdokumentaation uudelleen. Lyhyt sykli vaatii äkkiä jotain näkyvää myös testauksesta. Miten perustelet nyt vanhan valtavan testisuunnitelmapohjan käytön, kun muistat ettei kukaan ehtinyt sitä aikaisemminkaan lukea? "Se tuo arvoa pitkällä juoksulla", saattaisit sanoa, mutta kuinka paljon aikaa ottaa tämän todistaminen? Kun kehityskierros on lyhyt, asiat joiden eduista ehditään saadaan empiiristä näyttöä, ovat sellaisia, joiden edut näkee pian. "Tulitikkuaskin kansi" jyrää näin ollen massiviiset suunnitelmat, koska sillä on aina ja heti jotain annettavaa.

Saattaa myös olla, että itse kyhätty muistilista on aina tehokkampi kuin monoliittinen IEEE829 missään vaiheessa.

Siinä pari piirrettä testauksesta SCRUM prosessissa.

Kuinka mitata testaajien saavutuksia?

2008-11-27T13:38:00.000-08:00

Usein todetaan, että ohjelmistotestaajan työtä ei voi arvioida suorilla mittareilla, kuten bugien määrällä, vaan enneminkin sillä kuinka hyvin testaaja on pystynyt tukemaan muiden työtä. James Whittaker ilmaisee tämän hyvin blogissaan sanomalla, että hyvän testaajan työn tuloksena kehittäjät tulevat tietoisemmiksi aukoista, joita heillä on tiedoissaan ja taidoissaan.

Näiden aukkojen paikkaamisesta syntyy todellista parannusta ja ohjelmiston laadun nousua.

Otetaanpa esimerkki: Testatessani metsätyökonetta ja sen softaa, voin laajentaa ohjelmistokehittäjien tietoisuutta tutustumalla tyypillisen metsätyökoneenkäyttäjän arkipäivään, lepo- ja tupakkataukoihin tai koneen ohjaamoon normaalisti kannettavaan oheisvarustukseen. Kertomalla näistä havainnollisesti ja miettimällä ääneen sitä miten nuo asiat voivat vaikuttaa koneen kuljettajan motorisiin mahdollisuuksiin, saatan herättää kehittäjissä uusia ideoita testauksesta, mikä hyödyttää vuorostaan ehkä minuakin. Informaation lisääminen saa siten aikaan parannusta, jota en välttämättä omilla testeilläni olisi saavuttanut.

Testauksen kustannukset

2008-11-26T14:42:00.000-08:00

Kunnat ovat heränneet tajuamaan, että ulkoistaminen ei välttämättä ole pelastus kaikkeen. Kunnallisalan kehittämisäätiön KAKS:in tukimus antaa tästä viitteitä.

Yllättäviä ulkoistamiskulueriä saattaa syntyä esimerkiksi seuraavanlaisesti:

Jos ennen kunnan terveyspalvelujen ulkoistusta paikallinen terveyskeskuslääkäri hoiti "isolla luudalla" ja halvalla lähes kaikki ongelmatapaukset ja kunta käytti erikoislääkäreitä säästeliäästi, niin rahaa säästyi, mutta tästä säästöstä ei välttämättä oltu kunnan sisällä täysin tietoisia. Jos nyt sitten ulkoistuksen jälkeen yksityinen taho käyttääkin erikoislääkäreitä aina kun heitä oikeasti tarvitaan, nin kulut saattavat olla kertaluokkaa suuremmat.

Eihän tämmöistä "onnettomuutta" tietysti osattu laskea etukäteen.

Kuinka on ohjelmistotestauksen ulkoistamisessa?
Uskon, että samanlaisia yllättäviä kulueriä, löytyy varmasti kun testausta siirretään muille. Jos oma testitiimi on lähinnä näytellyt testausta ja tyytynyt suorittamaan sen mitä valmiit vanhat testitapaukset vaativat, niin tilanne voi olla kulujen kannalta hyvinkin yllättävä kun jokin uusi tiimi ottaa työn asiakseen. Myös päinvastoinkin voi käydä. Osaava kokenut testitiimi on saattanut tehdä kulisseissa paljon hyödyllisiä asioita, jotka ovat jääneet yrityksen johdolta täysin huomiotta ja siten siis laskematta.

Uskon, että kokeneet testaajat ovat yrityksen parasta työvoimaa ja heitä ei tulisi ulkoistaa. Jos olet kuitenkin ollut mukana jonkin työn siirtämisessä, niin kuulisin mielelläni kommenttejasi siirtämisen tuomista yllättävistä kulueristä.

Oredev 2008 Osa 2

2008-11-26T13:47:00.000-08:00

Tässä jotain muistiin jääneitä huomioita ja lainauksia Robert C. Martinin eli Bob sedän puheenvuorosta Oredev 2008 seminaarissa.

Yksikkötestit ja TDD (Test driven design) varastivat aimo osan Martinin esityksestä. Hyvä näin, koska aihe on kuuma.

"Suite of tests is 10 times more important than architecture and design" Olen Martini kanssa tästä samaa mieltä, jos vielä puhutaan hyvistä testeistä

Makeat naurut yleisöstä irroitti kommentti "Even if TDD is stupid, it's valuable". Jos oikein rehellisesti ajattelee, niin onhan se näin. TDD eli Test Driven Design on tiukka rutiini, jossa uskotaan massiivisen tuplakoodauksen (testit ja lähdekoodi) voimaan, eikä se missään nimessä kuulosta kaikin puolin järkevältä touhulta. Kuten BDD ja vastaavat muut lähestymistavat osoittavat, ei se tule myöskään mikään lopullinen vaihe olemaan.

"Issue tracking system is a symptom" Martin sanoi ja viittasi oireella kehittäjien löysään testauskulttuuriin, joka antaa moisille työvälineille markkinatilaa. "QA should find no bugs" olisi oikeampi asenne jokaiselle kehittäjälle. Jos jotain vikoja pääsee läpi, se on suuri häpeä.

"Avoid Debugging" Debuggauskyvyt eivät ole toivottavia taitoja, vaan jälleen oireita siitä, että jotain tärkeämpää ei osata tehdä. Tärkeämpää ovat kurinalaiset koodaus ja testaus menetelmät.

BDD (Behaviour Driven Development ) kansantajuisesti

2008-11-26T11:59:00.000-08:00

BDD eli Behaviour Driven Development on kehitysmetodi, joka jatkaa siitä, mihin monella TDD eli Test Driven Development jää.

TDD on suunnittelumetodi, mutta sitä pidetään usein testausmetodina. Tässä on suuri väärinkäsitys. TDD on puhtaasti suunnittelumetodi, koska siinä määritellään koodin rajapintojen toiminta kuvaamalla testeiksi kutsutuissa koodinpätkissä noiden rajapintojen kautta ohjelmaan tai sen osaan menevä liikenne (kutsut, viestit jne.) ja liikenteen järjestys.

Testi on TDD:ssä siis määritys ja sen kutsuminen testiksi on harhaanjohtavaa. Testi on minusta yleensä jotain mikä tarkistaa tai utelee asioita, mutta ei yleensä se joka alunperin määrittää ohjelman käyttäytymisen.

BDD:ssä tämä on tajuttu ja siksi noita koodin pätkiä, joita TDD:ssä kutsutaan testeiksi, kutsutaan BDD:ssä käytöksiksi (Behaviour) tai suoraan spekseiksi.

BDD:ssä on on oivallettu myös se, että noista spekseistä (eli käytöksistä) voisi saada laajempia dokumentaatiohyötyjä, jos niiden kuvauksessa käytettäisiin kieltä, joka esittää asian abstraktimmin kuin puhdas "aseta-harjoita-tarkasta" koodi, jollaisia suurin osa TDD käyttäjien niin sanotuista testeistä on. Abstraktimpi kuvaus saattaisi löyhentää kiinnevoimaa (coupling), joka speksien (käytöksien) ja lähdekoodin välillä usein on ja saattaisi avautua helpommin myös niille, joille ohjelmistoa tuotetaan.

Näihin kaikkiin BDD antaa eväitä. Itselläni on kokeilussa sovelluskehys CppSpec, joka vaikuttaa lupaavalta. Palaan asiaan, kunhan siis speksaus (eikä testaus) edistyy.

Vuoden testaaja 2009 ?

2008-11-25T02:20:00.000-08:00

Vuoden 2009 ohjelmistotestaaja julkistetaan Tieturin testauspäivässä 15.1.2009.
Ehdokaslista on jo valittu, nyt on mahdollista äänestää.

Miksi tämmöinen palkinto on olemassa?
Onko tarkoitus esimerkiksi palkita se testaaja, joka vuoden aikana löytänyt eniten vikoja?

Ei nyt ihan.

Suomalaisella ohjelmistotestauksella on vähän puolestapuhujia. Maaret Pyhäjärvi ja Erkki Pöyhönen ja muutamat muut ovat tehneet hyvää pioneerityötä, mutta yleisesti ala kaipaa kaikkia mahdollisia julkisuustempauksia. Testauksen pioneerit, soveltajat ja oman tiensä kulkijat saavat aivan liian vähän palstatilaa. Yleensä heitä kaivetaan esiin kun ohjelmistoongelmia on julkisuudessa (vrt. Sampo) ja tarvitaan joku sanomaan, että "tarttis tehdä jotain" tai että "tulisi parantaa testauksen koulutusta".

Tätä taustaa vasten olin positiivisesti yllättynyt kolmisen vuotta sitten kun Tieturin seminaariosaston silloinen kehityspäällikkö Sirpa Joensuu ehdotti vuoden testaajan valitsemista. Sirpan ideana oli tuoda testaukselle tunnettavuutta ja sitä hän toikin. Katsokaa huviksenne vaikka, kuinka moni lehti huomioi viime vuoden valinnan ja kuinka monella blogilla asiaa on käsitelty puolesta ja vastaan.

Tietotekniikan liiton sivuilta löytyy testaussanasto

2008-11-25T00:50:00.000-08:00

Tietotekniikan liiton sivuilta löytyy suomennettu ISTQB sanasto. ISTQB sanasto

Pisti silmään seuraava: Smoke test = aloitustesti.

Oredev 2008

2008-11-25T00:37:00.000-08:00

Vietin viime viikon Ruotsissa Oredev seminaarissa ja se totta vie kannatti.
Tulen tässä blogissa kommentoimaan ajatuksia, joita tuo tilaisuus herätti.
Jos et ole käynyt Oredev:ssä ja olet ohjelmistotestaaja tai kehittäjä, suosittelen tähän tilaisuuteen tutustumista. Luennoitsijat olivat alansa huippua, järjestelyt toimivat ja etelä-ruotsalaiseen tapaan tunnelma oli rento. Muiden osallistujien mietteitä ja arvioita esiintyjistä löytyy muun muassa Microsoftin Glenn Blockin ja Ayende Rahien blokeista

Pääasiassa Oredev on ohjelmistokehittäjille suunnattu tapahtuma, mutta mukana oli myös vahva kaksipäiväinen testausosuus, jonka sisältöä mielnkiinnolla seurasin. Tämä ohjelmahaara antoi minusta eniten ohjelmistotestausta päätyökseen tekeville, eikä valitettavasti juuri mitään seminaarin varsinaiselle kohdeyleisölle eli ohjelmistokehittäjille. Se, että näin tapahtui, ei taas ole mitään uutta ohjelmistokehitysseminaareissa. Yleensä jos kehitysseminaarissa paikalle tulee testauksesta jotain tietäviä puhujia kuten James Bach, niin puheesta suurimman hyödyn saa muut kuin varsinaiset laadun tuottajat.

Miksi näin on?

Yksi syy voi olla se että näissä seminaareissa puhujat joutuvat käyttämään vähintään 15-30 minuuttia siihen, että he selittävät mitä he nyt tarkoittavat puhuessaan yksikkötestauksesta, integraatiotestauksesta, testien ohjaamasta kehityksestä (TDD) ja muista termeistä, joita ohjelmistokehittäjän testaukseen liittyy.

En kritisoi tässä näiden termien käyttöä. Kaikki ne ovat tärkeitä, koska ne valaisevat sitä millä tasolla, miten ja kuinka usein testausta tulisi tehdä. TDD esimerkiksi muuttaa testauksen keskittyneeksi kehitystysmetodiksi, joka vaatii itsekuria. Tämä on erinomaisen kunnioitettava kehityssunta!

Epäilen enemmän, että jotain on pielessä tässä asetelmassa, koska puhujat joutuvat aina toistamaan samat kommentit ohjelmistokehittäjän tekemän laadunvarmennuksen muodosta ja termeistä, mutta eivät juuri ehdi puhua sen sisällöstä.

Kun puolet puheesta on kulunut yhteisen terminologian selittämisessä, ei jää paljon aikaa muuhun.

En suosita lääkkeeksi sitä että tehdään tarkempia standardeja siitä mitä esimerkiksi yksikkötestaus on. Sellainen on jo syntyessään kuollut ajatus. Kaavaa oikeasta testaustasosta ei ole, jotenka unohdetaan se nyt näistä esitelmistä vähäksi aikaa ja keskitytään esimerkkeihin.

Uskon, että nyt vuonna 2008 löytyy paljon ohjelmistokehittäjiä, jotka ovat jo omaksuneet jonkin systemaatisen ajattelumallin (esimerkiksi TDD) testausta varten. Nämä kehittäjät yrittävät harjoittaa sitä aktiivisesti ja tajuavat sen hyödyt ja siksi he haluavatkin nyt termien sijasta ideoita testien sisällöksi tai uusia tapoja tarkistaa asioita. He haluavat esimerkkejä, eivät vain termejä.

Ei pidä pelätä sitä, että puhtaasti testausesimerkkejä läpikäyvistä esityksistä saattaa tulla "vain reseptikavalkaadeja", eivätkä ne ehkä sitten vastaakaan yleiseen maailmanparannus teemaan: "miten testaan aina oikein". Paras on olla rehellinen: kehittäjän ohjelmistotestausta ei vielä osata formalisoida kovinkaan kummoisesti ja siksi parasta mitä puhuja voi tehdä on antaa vihjeitä mahdollisista testauskohteista ja testaustavoista, joista joku testausta arvostava saattaa saada iloa.

Ps. Minusta olisi henkilökohtaisesti joskus kiva kuulla perusteltuja kannanottoja esimerkiksi siitä, mikä hyötysuhde on todella saatu jonkun mock-sovelluskehyksen systemaattisesta käytöstä, kun verrataan mockien luomiseen, ylläpitoon, oppimiseen ja dokumentointiin menneitä työtunteja siihen onko työtunnit vähentyneet myöhemmissä testausvaiheissa. Jos tiedätte jotain aiheesta tai muita konkreettisia hyötyjä mock-sovelluskehyksistä, niin kommentoikaa.