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.
tiistaina 17. marraskuuta 2009
keskiviikkona 4. marraskuuta 2009
Testaajien äänenkannattaja
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ä.
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ä.
keskiviikkona 28. lokakuuta 2009
Testausvinkki 5
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.
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.
perjantaina 23. lokakuuta 2009
Ovatko ohjelmistokehittäjät käsityöläisiä?
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.
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.
torstaina 15. lokakuuta 2009
Miksi suomessa ei ole avointa testauskeskustelua?
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.
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.
perjantaina 9. lokakuuta 2009
Testaajien palkoista
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".
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".
keskiviikkona 7. lokakuuta 2009
Testien ohjaama hyväksyntätestaus
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?
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?
Tilaa:
Blogitekstit (Atom)
Tekstit
