Kävin keskustelua kursseista, opetustavoista ja opetussisällöistä osana työpajamme jälkipyykkiä. Keskustelu oli varsin lyhyttä ja lähtökohdiltaan varsin erimielistä. Toisaalta tavoitteena tuskin onkaan saavuttaa yhtenäistä näkökulmaa.
Olen kritisoinut taustalla erään kurssitoimittajan ketterän testauksen kurssimateriaalia. Julkaisen lähiaikoina kritiikkini tarkasteltavaksi, ja vastaavasti minulla on käynnissä oma analyysi omien materiaalieni parantamiseksi että saisin pois osan omista vähintään yhtä räikeistä virheistäni.
Voisin varmaan hoitaa palautteen antamisen helpommin omaksuttavassa muodossa, mutta uskon että ihmiset huomaavat johdattelun. Jos on sanottavaa, sen voisi sanoa, ja jos toinen osapuoli on tuttu, asian voisi ottaa asiana eikä henkilökohtaisena.
Olen kiitollinen saamastani lyhyestä palautteesta oman opetustyylini osalta: minulle on jonkin kuulijajoukon osalta muodostunut maine että minulle on olemassa vain yksi tapa tehdä asioita, esim. ketterässä testauksessa.
Jäin miettimään tätä, ja totesin parannettavaa. Minun on entisestään tarpeen korostaa materiaalieni case-pohjaisuutta. En usko prosesseihin ja ohjeisiin, vaan esimerkkeihin ja ristiriitaisuuksiin niissä. Kuvittelen puhuessani sanovani että minun kokemissani tilanteissa näin, ja olen jopa toistuvasti muuttanut materiaaliani ketterän testauksen suhteen erottaakseni "näin sanotaan yleisissä ohjeissa" ja "tälläisessa maailmassa minä olen kokenut tälläista".
Esitystilanteessa sanominen ei ole sama kuin kuuleminen. Tarkoitukset ja merkitykset värittyvät puolin ja toisin aina viestintätilanteessa. Erityisen keskeisten ja vaikeiden asioiden kanssa dialogiin on varattava aikaa ja tukea. Sama pätee lukemisen suhteen: saatan tulkita liikaa esim. siihen että kalvolla otsikolla Scrum kerrotaan olevan kolme backlogia: product, sprint ja test. Ehkä siinä tosiaan tarkoitetaan että jos testaus on erillinen tiimi, heillä voi olla oma sprint backloginsa. Teksti ei kerro.
Kaikenlainen viestintä on kaksisuuntaista, paitsi jos tyydytään siihen että todetaan erimielisyys ilmaistun muodon kanssa. Itse tavoittelen muutosta parempaan, joka viime kädessä vaatii dialogia.
Kun luette kirjoittamaani tai olette eri mieltä sanomani kanssa, antakaa minulle tilaisuus muuttaa mieltäni tai selittää mitä itse asiassa tarkoitan.
Niin tai näin, taustalla tässä pohdinnassa on perusolettama omista kokemuksistani: ketterässä kehityksessä testauksella voidaan saada aikaan jotain hyvää, mutta toisaalta sen perinteisillä muodoilla voidaan syödä merkittävästi hyötyjä kokonaisuudelta.
maanantaina 9. marraskuuta 2009
Ketterän testauksen työpaja, tuoreita ajatuksia
Tänään oli ketterän testauksen työpaja, jossa edustettuna varsin monenlaista ketterän kehityksen, testauksen ja perinteisen testauksen osaamista. Porukassa ei kukaan ollut täydellinen juniori kaikkien suhteen, mutta matkaa yhteiseen ymmärrykseen on aika paljon.
Minulle korostui keskusteluissa että joukosta löytyi kolmenlaista "ketterää kehitystä ja testausta":
- "ketteryys koska niin päätettiin"
- "ketteryys koettuna, mutta puolimatkassa"
- "ketteryys koettuna, aika pitkällä"
Joukostamme löytyi jokunen joka katseli organisaationsa ketterän kehityksen pyrkimyksiä vielä isona kokoelmana haasteita, joka tuntui pitkälti estävältä. Oltiin huolissaan laadusta joka pitää selvittää vasta lopussa (ei kovin ketterää), dokumentoinnin puutteesta tässä tilanteessa, testauksen mukanaolosta ja mahdollisuuksista yleensäkin. Kokonaisuus yksittäisen tiimin ulkopuolelta kuulosti lähinnä vesiputoukselta, jossa jokainen vaihe oli muotoiltu scrum-pakettiin. Yleisesti nämä olivat erilaisia Scrummerfall ja ScrumBut -toteutuksia.
Toinen korostunut joukko oli niitä joilla ei ole laajamittaista automatisoitua testausta eikä varsinkaan hyväksymistestiohjattua kehitystapaa, mutta joiden osalta kuitenkin kokemus oli merkittävän, ja hyödyllisen eron omaaminen perinteiseen kehitykseen ja testaukseen. Laatuvastuu on tiimeillä, ja tiimit ovat ehkä jossain komponenttitiimin ja ominaisuustiimin puolessa välissä.
Kolmas korostunut joukko olivat nk. aidot agilistit. Korostuneesti minulle jäi vaikutelma että tässä porukassa oli varsin vähän pitkään testausta - manuaalista sellaista - tehneitä ihmisiä, joskin kohtuullisen pitkään mukana olleita oli. Tämän porukan testausedustusto oli järjestäin ohjelmointitaitoisia.
Jään hauduttelemaan ajatuksiani, mutta pidin erityisen yllättävänä omaa reaktiotani siihen että testaaja ei olisi sovellusalueen osaaja. Toki, asiakas-toimittaja-tilanteissa tulee vastaan minullekin paljon tilanteita, joissa en tunne sovellusaluetta. Testaajana minulla, ainakin omasta mielestäni, keskeisenä taitona on oppia nopeasti vähän kerrallaan ja sitä kautta vaikka en koskaan varmasti muotoudu esim. asiakashallintasovellusten supersovellusalueosaajaksi, kohtuullinen osaaja ja tehokas testaaja voin olla.
Pitäisi varmaan työstää ajatuksella niitä testauksellisia osaamisia, mitä Microsoft-kirja jota juuri luin kuvasti tittelillä "tester dna".
Ja käytäntöjen osalta, tuo kolmijaottelu voisi olla varsin hyödyllinen pohja koulutusmateriaaleissani. Siinäkin on vielä paljon vaihtelua, mutta voisi edes vähän saada otteen että missä skaalalla oikein mennään.
Minulle korostui keskusteluissa että joukosta löytyi kolmenlaista "ketterää kehitystä ja testausta":
- "ketteryys koska niin päätettiin"
- "ketteryys koettuna, mutta puolimatkassa"
- "ketteryys koettuna, aika pitkällä"
Joukostamme löytyi jokunen joka katseli organisaationsa ketterän kehityksen pyrkimyksiä vielä isona kokoelmana haasteita, joka tuntui pitkälti estävältä. Oltiin huolissaan laadusta joka pitää selvittää vasta lopussa (ei kovin ketterää), dokumentoinnin puutteesta tässä tilanteessa, testauksen mukanaolosta ja mahdollisuuksista yleensäkin. Kokonaisuus yksittäisen tiimin ulkopuolelta kuulosti lähinnä vesiputoukselta, jossa jokainen vaihe oli muotoiltu scrum-pakettiin. Yleisesti nämä olivat erilaisia Scrummerfall ja ScrumBut -toteutuksia.
Toinen korostunut joukko oli niitä joilla ei ole laajamittaista automatisoitua testausta eikä varsinkaan hyväksymistestiohjattua kehitystapaa, mutta joiden osalta kuitenkin kokemus oli merkittävän, ja hyödyllisen eron omaaminen perinteiseen kehitykseen ja testaukseen. Laatuvastuu on tiimeillä, ja tiimit ovat ehkä jossain komponenttitiimin ja ominaisuustiimin puolessa välissä.
Kolmas korostunut joukko olivat nk. aidot agilistit. Korostuneesti minulle jäi vaikutelma että tässä porukassa oli varsin vähän pitkään testausta - manuaalista sellaista - tehneitä ihmisiä, joskin kohtuullisen pitkään mukana olleita oli. Tämän porukan testausedustusto oli järjestäin ohjelmointitaitoisia.
Jään hauduttelemaan ajatuksiani, mutta pidin erityisen yllättävänä omaa reaktiotani siihen että testaaja ei olisi sovellusalueen osaaja. Toki, asiakas-toimittaja-tilanteissa tulee vastaan minullekin paljon tilanteita, joissa en tunne sovellusaluetta. Testaajana minulla, ainakin omasta mielestäni, keskeisenä taitona on oppia nopeasti vähän kerrallaan ja sitä kautta vaikka en koskaan varmasti muotoudu esim. asiakashallintasovellusten supersovellusalueosaajaksi, kohtuullinen osaaja ja tehokas testaaja voin olla.
Pitäisi varmaan työstää ajatuksella niitä testauksellisia osaamisia, mitä Microsoft-kirja jota juuri luin kuvasti tittelillä "tester dna".
Ja käytäntöjen osalta, tuo kolmijaottelu voisi olla varsin hyödyllinen pohja koulutusmateriaaleissani. Siinäkin on vielä paljon vaihtelua, mutta voisi edes vähän saada otteen että missä skaalalla oikein mennään.
perjantaina 23. lokakuuta 2009
Se pieni ero: testaus ja laatutietoon reagointi
Päivitin ulkoasun ja sisällön osalta websivujani http://www.testauskirja.com/. Laitoin tietoa päivityksistä jonkinlaiselle kohderyhmälle, ja ensimmäisenä päivänä sain postilla viestin:
"Sivuilla eivät ääkköset näy oikein... olisikohan pitänyt testata / testauttaa jossain ennen julkaisemista..."
Testaajana viesti oli minusta äärimmäisen inspiroiva. Olen kuullut vastaavan kommentin lukemattomia kertoja ohjelmistoprojekteissa, ja lähestulkoon aina pitänyt sitä jonkinasteisen testauksen ymmärtämättömyyden osoituksena. Ymmärtämättömyyttä voi kuitenkin aina koittaa korjata.
Itse ajattelen jotakuinkin näin:
Testaus / testaamattomuus on aivan eri asia kuin laatutietoon reagointi
Testauksella löydetään virheitä. Testaamattomuudella voidaan jäädä ilman laatutietoa. Testauksen osalta mikään ei suoraan lupaa, että tietoon virheestä reagoidaan "toivotusti" korjauksella. Tietoon voidaan reagoida myös päättämällä elää virheen kanssa - pidempään tai lyhyemmän aikaa.
Korjauspäätöksissä pitää miettiä kustannusta suhteessa hyötyihin - kokonaisuutena
Testaajana pitäisin kovasti moitteettomasta laadusta, mutta olen oppinut olemaan ylpeä tunnetusta laadusta. Suorien kustannusten lisäksi pitää miettiä vaihtoehtoiskustannukset: mitä muuta, mahdollisesti tärkeämpää, jää saavuttamatta kun aika päätetään kiinnittää tähän. Virheen korjaaminen on aikaa pois joltain muulta. Uuden palvelun lisäarvo alkaa toteutua vasta kun se on käyttäjillä.
Korjauspäätöksien virheet ovat yleisempiä kuin testaamattomuus
Tiesin ennestään että sivujen osalta skandit eivät toimi tietyillä selaimien ja asetusten yhdistelmällä. Voin piiloutua sen taakse että olen itse asiassa laiska ja surkea kehittäjä, jopa websivuille, ja en osannut tehokkaasti arpoa oikeaa merkistökoodia sivuilleni niin että merkit näkyisivät kaikilla oikein. Voin myös piiloutua sen taakse että aivan sama merkistö-ongelma on ollut vuosikausia testausOSY:n sivuilla, koska nekin minä olen laiskana kehittäjänä tehnyt.
Sen sijaan että piiloutuisin, ottaisin mieluummin ajattelutavaksi sen että tein päätöksen korjaamattomuudesta. Päätös voi olla väärä, mutta päätös kuitenkin.
Sen sijaan että pohditaan että olisiko pitänyt testata, voidaan puida teinkö oikean päätöksen asiakkaideni palvelemisen kannalta priorisoidessani korjauksen ulos "julkaisusta".
Laatupalautteeseen reagointi
Laatupalautteen saaminen (virheraportit) on itse asiassa kivaa. Se käynnistää pohdinnan siitä että olisiko jotain opittavaa, ja jos olisi, mitä.
Testausopeista (tai markkinoinnin opeista) voisi kerätä sen että vain joka kymmenes tyytymätön valittaa. Tämäkin tosin taitaa päteä vain sovelluksiin/palveluihin joilla on merkitystä - ja voisin kyseenalaistaa minun websiteni merkityksen käyttäjäkunnalle valituskynnyksen osalta. Voisin myös ajatella, että ongelma ei ole joko yleinen tai niin häiritsevä että olisi muuttanut asioita minun kannaltani, koska mittareita (näen sivuittain osumien määrän) näyttäisi siltä että aika moni on jaksanut ainakin klikkailla useampia sivuja auki. Testaajana kuitenkin ehkä olettaisi, että ihmiset eivät vaan valita...
Aidosti mielenkiintoinen kysymys onkin: vaikuttaako skandien rikkinäisyys / sivujeni rumuus siihen että joku ei enää uskoisi että osaan testata ja opettaa testausta, koska en osaa korjata?
Kuinkas noiden isojen julkisten epäonnistumisten kanssa saisi kirjoittelijat tajuamaan että kysymys ei ole siitä että olisi pitänyt testata / testauttaa, vaan että olisi pitänyt korjata / korjauttaa. Ja sitä ennen, päättää oikein korjaustarpeen tärkeydestä.
"Sivuilla eivät ääkköset näy oikein... olisikohan pitänyt testata / testauttaa jossain ennen julkaisemista..."
Testaajana viesti oli minusta äärimmäisen inspiroiva. Olen kuullut vastaavan kommentin lukemattomia kertoja ohjelmistoprojekteissa, ja lähestulkoon aina pitänyt sitä jonkinasteisen testauksen ymmärtämättömyyden osoituksena. Ymmärtämättömyyttä voi kuitenkin aina koittaa korjata.
Itse ajattelen jotakuinkin näin:
Testaus / testaamattomuus on aivan eri asia kuin laatutietoon reagointi
Testauksella löydetään virheitä. Testaamattomuudella voidaan jäädä ilman laatutietoa. Testauksen osalta mikään ei suoraan lupaa, että tietoon virheestä reagoidaan "toivotusti" korjauksella. Tietoon voidaan reagoida myös päättämällä elää virheen kanssa - pidempään tai lyhyemmän aikaa.
Korjauspäätöksissä pitää miettiä kustannusta suhteessa hyötyihin - kokonaisuutena
Testaajana pitäisin kovasti moitteettomasta laadusta, mutta olen oppinut olemaan ylpeä tunnetusta laadusta. Suorien kustannusten lisäksi pitää miettiä vaihtoehtoiskustannukset: mitä muuta, mahdollisesti tärkeämpää, jää saavuttamatta kun aika päätetään kiinnittää tähän. Virheen korjaaminen on aikaa pois joltain muulta. Uuden palvelun lisäarvo alkaa toteutua vasta kun se on käyttäjillä.
Korjauspäätöksien virheet ovat yleisempiä kuin testaamattomuus
Tiesin ennestään että sivujen osalta skandit eivät toimi tietyillä selaimien ja asetusten yhdistelmällä. Voin piiloutua sen taakse että olen itse asiassa laiska ja surkea kehittäjä, jopa websivuille, ja en osannut tehokkaasti arpoa oikeaa merkistökoodia sivuilleni niin että merkit näkyisivät kaikilla oikein. Voin myös piiloutua sen taakse että aivan sama merkistö-ongelma on ollut vuosikausia testausOSY:n sivuilla, koska nekin minä olen laiskana kehittäjänä tehnyt.
Sen sijaan että piiloutuisin, ottaisin mieluummin ajattelutavaksi sen että tein päätöksen korjaamattomuudesta. Päätös voi olla väärä, mutta päätös kuitenkin.
Sen sijaan että pohditaan että olisiko pitänyt testata, voidaan puida teinkö oikean päätöksen asiakkaideni palvelemisen kannalta priorisoidessani korjauksen ulos "julkaisusta".
Laatupalautteeseen reagointi
Laatupalautteen saaminen (virheraportit) on itse asiassa kivaa. Se käynnistää pohdinnan siitä että olisiko jotain opittavaa, ja jos olisi, mitä.
Testausopeista (tai markkinoinnin opeista) voisi kerätä sen että vain joka kymmenes tyytymätön valittaa. Tämäkin tosin taitaa päteä vain sovelluksiin/palveluihin joilla on merkitystä - ja voisin kyseenalaistaa minun websiteni merkityksen käyttäjäkunnalle valituskynnyksen osalta. Voisin myös ajatella, että ongelma ei ole joko yleinen tai niin häiritsevä että olisi muuttanut asioita minun kannaltani, koska mittareita (näen sivuittain osumien määrän) näyttäisi siltä että aika moni on jaksanut ainakin klikkailla useampia sivuja auki. Testaajana kuitenkin ehkä olettaisi, että ihmiset eivät vaan valita...
Aidosti mielenkiintoinen kysymys onkin: vaikuttaako skandien rikkinäisyys / sivujeni rumuus siihen että joku ei enää uskoisi että osaan testata ja opettaa testausta, koska en osaa korjata?
Kuinkas noiden isojen julkisten epäonnistumisten kanssa saisi kirjoittelijat tajuamaan että kysymys ei ole siitä että olisi pitänyt testata / testauttaa, vaan että olisi pitänyt korjata / korjauttaa. Ja sitä ennen, päättää oikein korjaustarpeen tärkeydestä.
sunnuntaina 11. lokakuuta 2009
Virheetön järjestelmä tuotannossa
Järjestelen parhaillaan ketterän testauksen työpajaa marraskuun alkuun, ja osallistujia läpi käydessäni koin monta vau-tunnetta katsellessani millaista porukkaa Suomesta löytyykään. Sen sijaan yksi erityinen lause jossain ilmoittautumisien perusteissa pisti silmään: jollakulla oli kokemuksia useista peräkkäisistä järjestelmäversioista jotka olivat virheettömiä tuotannossa.
Olen vuosien varrella ollut jokusessa projektissa mukana vaihtelevissa rooleissa, ja joudun tunnustamaan että minun kohdalleni tuollaista tilannetta ei ole osunut. Varsin vähävirheisiä järjestelmiä tuotantoon on viety, mutta virheetön - ei todellakaan. Ketterien menetelmien mukanaan tuoma stop-and-fix -periaate auttaa todella paljon laadun kanssa, mutta ainakin minun kokemuksissani vielä varsin usein tulee kaksi virheraporttia, joista vain toisen voi korjata kun suurten käyttäjämäärien ja vaihtelevien profiilien kanssa ihmiset eivät vain koe laatua ja virheettömyyttä samalla tapaa.
Asiaa hetken hauduteltuani jään odottamaan innolla määritelmää virheettömyydelle. Mieleeni tuli nimittäin montakin projektia, jossa virhe määritellään varsin suppeasti suhteessa tarkoitettuun toiminnallisuuteen, ja yleensä vielä dokumentaatioon. Sitä ei ketterän projektin osalta määritelmäksi nopeasti leimaisi.
Järjestelmiä, joista ei ole löytynyt yhtään tuotantokorjaustarvetta ennen ympäristön muuttumista on kohdalle kyllä tullut. Nekin tapaukset ovat kyllä kaukana virheettömistä.
Olen vuosien varrella ollut jokusessa projektissa mukana vaihtelevissa rooleissa, ja joudun tunnustamaan että minun kohdalleni tuollaista tilannetta ei ole osunut. Varsin vähävirheisiä järjestelmiä tuotantoon on viety, mutta virheetön - ei todellakaan. Ketterien menetelmien mukanaan tuoma stop-and-fix -periaate auttaa todella paljon laadun kanssa, mutta ainakin minun kokemuksissani vielä varsin usein tulee kaksi virheraporttia, joista vain toisen voi korjata kun suurten käyttäjämäärien ja vaihtelevien profiilien kanssa ihmiset eivät vain koe laatua ja virheettömyyttä samalla tapaa.
Asiaa hetken hauduteltuani jään odottamaan innolla määritelmää virheettömyydelle. Mieleeni tuli nimittäin montakin projektia, jossa virhe määritellään varsin suppeasti suhteessa tarkoitettuun toiminnallisuuteen, ja yleensä vielä dokumentaatioon. Sitä ei ketterän projektin osalta määritelmäksi nopeasti leimaisi.
Järjestelmiä, joista ei ole löytynyt yhtään tuotantokorjaustarvetta ennen ympäristön muuttumista on kohdalle kyllä tullut. Nekin tapaukset ovat kyllä kaukana virheettömistä.
lauantaina 10. lokakuuta 2009
Miten testaus kehittyy?
Olen viettänyt iltaa lukien arvostamieni testausgurujen blogeja, pyrkien päivittämään tietojani siitä mitä maailmassa oikeastaan tapahtuukaan. Erityisen inspiraation pohdiskelulle löysin jälleen James Bachin blogista.
Olen viime aikoina kokenut jonkinasteista epämukavuutta lukiessani Jamesin kirjoituksia. James on pitkään ollut yksi ehdottomista testausidoleistani, ehdottoman taitava testaaja, joka myös kuvailee tekemisiään ja antaa sitä kautta muille mahdollisuuden ottaa valitsemiaan oppeja. Kokemani epämukavuus johti siihen että lähes raukkamaisesti päätin kirjoittaa suomeksi, kunnes uskallan asetella sanani niin etten päädy väärään keskusteluun.
James Bachin blogin viimeisin kirjoitus käsitteli James Whittakerin uusinta kirjaa, jota jokunen varsin merkittävä testausihminen, James Bach mukaanlukien, on pitänyt jonkinasteisena huijauksena. Varsinaista otsikon perusteella odotettavaa asiaa koettiin jossain arvostelussa olevan sivumäärällisesti liian vähän, ja viittausten puute tutkivan testauksen keskeisiin hahmoihin ei myöskään saanut suitsutusta. Ilmeisesti lisäksi koettiin että koko termiä käytettiin väärin.
Olen viime aikoina lukenut James Whittakerin kirjaa, ja edes luettuani toisten gurujen kommentteja, ei mielipiteeni kirjasta muuttunut. Minua ei haitannut että varsinainen sisältö oli ehkä lyhyessä osassa kirjaa, koska muukin sisältö oli minulle oleellista. Olen kahlannut läpi puolet, ja pitänyt siitä mitä olen lukenut. Olen lukiessa jäsentänyt omia ajatuksiani ja saanut uusia ideoita - myös rivien välistä lukien.
Palatakseni kirjoitukseni otsikkoon: miten testaus kehittyy? Jäin pohtimaan sitä että jos tutkivan testauksen jäsentämiseen liittyy pelko siitä että päätyy melko kovan kritiikin kohteeksi, uskaltaako sitä oikeasti asioita yrittää viedä eteenpäin? Kirjoittelin yhdellä listalla jokunen viikko takaperin tutkivan testauksen hallinnoinnin ajatuskehikostani, jonka huomasin olevan erilainen kuin sessiopohjainen testauksen hallinta, vaikka paljon samaa onkin. En vielä säikähtänyt, mutta muistissa on tuoreesti että kun keskustelun avaa, siinä saa samalla sitoutua mahdollisesti aikamoiseen pyöritykseen ja selittelyyn. Ehkä kyse on osittain siitä että englanti ei ole äidinkieleni, mutta ennen kaikkea kuitenkin kirjallisen viestinnän haastavuudesta.
Jos keskustelu käy liian kuumana ja ilmaisut vahvoina, aika iso osa ihmisistä vieraantuu keskustelusta. Aikaa ei vain ole riittävästi, ja oma luottamus taitoihin ja tietoihin horjuu, kokemuksista huolimatta. Auttaakohan tämä uudenoloinen ilmapiiri testausta kehittymään? Nakuttava tuntuma jossain vihjailee, että kohta on valittava gurunsa että ei saa aikaan keskusteluissa vahvoja torjumisreaktioita puolin ja toisin.
Olen viime aikoina kokenut jonkinasteista epämukavuutta lukiessani Jamesin kirjoituksia. James on pitkään ollut yksi ehdottomista testausidoleistani, ehdottoman taitava testaaja, joka myös kuvailee tekemisiään ja antaa sitä kautta muille mahdollisuuden ottaa valitsemiaan oppeja. Kokemani epämukavuus johti siihen että lähes raukkamaisesti päätin kirjoittaa suomeksi, kunnes uskallan asetella sanani niin etten päädy väärään keskusteluun.
James Bachin blogin viimeisin kirjoitus käsitteli James Whittakerin uusinta kirjaa, jota jokunen varsin merkittävä testausihminen, James Bach mukaanlukien, on pitänyt jonkinasteisena huijauksena. Varsinaista otsikon perusteella odotettavaa asiaa koettiin jossain arvostelussa olevan sivumäärällisesti liian vähän, ja viittausten puute tutkivan testauksen keskeisiin hahmoihin ei myöskään saanut suitsutusta. Ilmeisesti lisäksi koettiin että koko termiä käytettiin väärin.
Olen viime aikoina lukenut James Whittakerin kirjaa, ja edes luettuani toisten gurujen kommentteja, ei mielipiteeni kirjasta muuttunut. Minua ei haitannut että varsinainen sisältö oli ehkä lyhyessä osassa kirjaa, koska muukin sisältö oli minulle oleellista. Olen kahlannut läpi puolet, ja pitänyt siitä mitä olen lukenut. Olen lukiessa jäsentänyt omia ajatuksiani ja saanut uusia ideoita - myös rivien välistä lukien.
Palatakseni kirjoitukseni otsikkoon: miten testaus kehittyy? Jäin pohtimaan sitä että jos tutkivan testauksen jäsentämiseen liittyy pelko siitä että päätyy melko kovan kritiikin kohteeksi, uskaltaako sitä oikeasti asioita yrittää viedä eteenpäin? Kirjoittelin yhdellä listalla jokunen viikko takaperin tutkivan testauksen hallinnoinnin ajatuskehikostani, jonka huomasin olevan erilainen kuin sessiopohjainen testauksen hallinta, vaikka paljon samaa onkin. En vielä säikähtänyt, mutta muistissa on tuoreesti että kun keskustelun avaa, siinä saa samalla sitoutua mahdollisesti aikamoiseen pyöritykseen ja selittelyyn. Ehkä kyse on osittain siitä että englanti ei ole äidinkieleni, mutta ennen kaikkea kuitenkin kirjallisen viestinnän haastavuudesta.
Jos keskustelu käy liian kuumana ja ilmaisut vahvoina, aika iso osa ihmisistä vieraantuu keskustelusta. Aikaa ei vain ole riittävästi, ja oma luottamus taitoihin ja tietoihin horjuu, kokemuksista huolimatta. Auttaakohan tämä uudenoloinen ilmapiiri testausta kehittymään? Nakuttava tuntuma jossain vihjailee, että kohta on valittava gurunsa että ei saa aikaan keskusteluissa vahvoja torjumisreaktioita puolin ja toisin.
tiistaina 29. syyskuuta 2009
Vaatimusten palvonta ja testauksen ohjaus
Olen viettänyt lähiaikoina aikaa perinteisen kehityksen, joskin inkrementaalisuudella maustetun, parissa. Teemat ovat hieman erilaisia kuin ketterän kehityksen ja testauksen osalta, ja ajattelin nyt lyhyesti tarttua yhteen lempiteemoistani: vaatimusten keskeiseen rooliin.
Perinteisissä projekteissa on varsin suuri kunnioitus vaatimuksia ja vaatimusmäärittelyjä kohtaan. Porukoissa nyökytellään, kun asiakas-toimittajasuhteessa toimittajalta tulee kohtuullisen kokoisia hintalappuja muutoksille, maustettuna kommentein "ymmärtämättömyydestä sakotetaan". Odotukset tilaajan taidoille määritellä asiat oikein ovat melkoiset, ja sitä myös muutoshallinnan perusteena on hyvä käyttää.
Vaatimuksia kunnioitetaan jopa siinä määrin että käytän siitä sanaa palvonta. Vaatimusten kanssa vietetään mahdollisesti vuosia ennen kuin mitään toteutetaan. Vaatimusdokumentit muodostuvat argumentoinnin aseiksi, eivätkä työkaluiksi tekemiselle.
Viimeisin inspiraation lähde tälle kirjoitelmalle oli oletus että "vaatimuksia vastenhan niitä testitapauksia on suunniteltava, ei sinne mitään muuta saa lähteä soveltamaan".
Minusta vaatimustenpalvonta on yksi yleisistä tehottoman ja heikkotuloksisen testauksen piirteistä. Vaatimuksia sopii palvoa toteuttajan testeissä, nehän kertovat asiat jotka on tarpeen vahvistaa. Testaajan näkökulmasta isossa osassa on etsiä asioita jotka jäävät vaatimusten väliin, ovat moniselitteisiä mahdollisesta hyvästä yrityksestä huolimatta.
Jos (kun) projektit lähtevät vaatimusten kirjaamiseen "yksiselitteisesti", saadaan aikaan uskomaton dokumentaatiomäärä, johon helposti haudataan merkittävääkin tietoa. Ei tämä silti tarkoita että mitään ei kirjata, mutta palvontaan viittaavat elementit ovat yleensä ikäviä.
Vaatimuksia vasten testisuunnittelu on eri asia kuin vaatimuksia hyödyntävä testisuunnittelu. Näkisin jälkimmäisen toivottuna tilana, jossa kirjatut vaatimukset asettavat rajoja sille mitä kohtuullisesti voidaan pitää "virheenä". Testaus voi ja toivottavasti löytää myös niitä "muutospyyntöjä" joiden puutteen vuoksi järjestelmät eivät käytännössä toimi. Rajaus näiden kahden välillä on varsinaista taiteilua. Viime kädessä kysymys tuntuu kuitenkin olevan rahasta: kenelle, keneltä ja kuinka paljon?
Perinteisissä projekteissa on varsin suuri kunnioitus vaatimuksia ja vaatimusmäärittelyjä kohtaan. Porukoissa nyökytellään, kun asiakas-toimittajasuhteessa toimittajalta tulee kohtuullisen kokoisia hintalappuja muutoksille, maustettuna kommentein "ymmärtämättömyydestä sakotetaan". Odotukset tilaajan taidoille määritellä asiat oikein ovat melkoiset, ja sitä myös muutoshallinnan perusteena on hyvä käyttää.
Vaatimuksia kunnioitetaan jopa siinä määrin että käytän siitä sanaa palvonta. Vaatimusten kanssa vietetään mahdollisesti vuosia ennen kuin mitään toteutetaan. Vaatimusdokumentit muodostuvat argumentoinnin aseiksi, eivätkä työkaluiksi tekemiselle.
Viimeisin inspiraation lähde tälle kirjoitelmalle oli oletus että "vaatimuksia vastenhan niitä testitapauksia on suunniteltava, ei sinne mitään muuta saa lähteä soveltamaan".
Minusta vaatimustenpalvonta on yksi yleisistä tehottoman ja heikkotuloksisen testauksen piirteistä. Vaatimuksia sopii palvoa toteuttajan testeissä, nehän kertovat asiat jotka on tarpeen vahvistaa. Testaajan näkökulmasta isossa osassa on etsiä asioita jotka jäävät vaatimusten väliin, ovat moniselitteisiä mahdollisesta hyvästä yrityksestä huolimatta.
Jos (kun) projektit lähtevät vaatimusten kirjaamiseen "yksiselitteisesti", saadaan aikaan uskomaton dokumentaatiomäärä, johon helposti haudataan merkittävääkin tietoa. Ei tämä silti tarkoita että mitään ei kirjata, mutta palvontaan viittaavat elementit ovat yleensä ikäviä.
Vaatimuksia vasten testisuunnittelu on eri asia kuin vaatimuksia hyödyntävä testisuunnittelu. Näkisin jälkimmäisen toivottuna tilana, jossa kirjatut vaatimukset asettavat rajoja sille mitä kohtuullisesti voidaan pitää "virheenä". Testaus voi ja toivottavasti löytää myös niitä "muutospyyntöjä" joiden puutteen vuoksi järjestelmät eivät käytännössä toimi. Rajaus näiden kahden välillä on varsinaista taiteilua. Viime kädessä kysymys tuntuu kuitenkin olevan rahasta: kenelle, keneltä ja kuinka paljon?
tiistaina 19. toukokuuta 2009
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:
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.
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.
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
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.
- Testauksen ajurina lisäarvo, ei testitapauslista
- Suhtautuminen muutoksiin - saako virheitä korjata?
- Tiivis yhteistyö toteuttajien ja testaajien kesken
- Testauksen kuuleminen arvokkaana tiedonlähteenä
- Erikoistumisen keventäminen - komponenttitestaajasta sovellustestaajaksi
- Jatkuva ohjelmistotoiimitus asiakkaille koekäyttöön palautteen saamiseksi testauksen laadusta
- Säännöllinen, usein tapahtuva integrointi
- Vaatimuksista haetaan tukea, ei "oikeita vastauksia"
- Dokumentoinnista ennen tekemistä dokumentointiin tekemisen yhteydessä
- Laadusta puhuminen ryhmäkokemuksena
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.
Tilaa:
Blogitekstit (Atom)
Lukijat
Blogiarkisto