Category: Ohjelmistotestaus

  • Ulkoistaminen kostautuu kympillä

    Ohjelmistotestaus.fi tarinoi jokin aika sitten miten testausta ei pitäisi kutsua laadunvarmentamiseksi, sillä testauksella ei ole valtaa tehdä muutoksia koodiin, tai oikeastaan mitään muitakaan päätöksiä projektin hallintaan liittyen. Asia on tosi, mutta poikkeus vahvistaa säännön.

    Tiedän projektin, jossa kustannussyistä tilaaja vähensi projektinhallinnastaan väkeä. Lopulta laadunvarmistuksen vastuu valui testaukselle.

    Voisi kuvitella että tässä on totaalisen kaaoksen merkit ilmassa, eikä siinä loppujen lopuksi hyvin käynytkään, mutta täysin eri syistä kun voisi kuvitella.

    Projekti lähti käyntiin ja kaikki valmistelut oli tehty viimeisen päälle hyvin. Testaus ja testipäällikkö oli otettu hyvissä ajoin mukaan ja ne oli ostettu kokonaan ulkopuoliselta taholta. Kaikki työ tapahtui asiakkaan tiloissa.

    Ensimmäinen 6 kuukautta meni hyvin ja homma toimi loistavasti, tilaaja oli tyytyväinen. Kuitenkin sattui niin, että asiakkaan mielestä kyseisen projektin tärkeyttä piti tarkistella. Niin johtoa siirrettiin muihin tehtäviin. Projektin tuote oli kuitenkin pakollinen, joten sitä ei keskeytetty.

    Kului toiset puoli vuotta, ja asiakkaan nimittämä projektivetäjä jäi pois. Testauspäällikkö veti projektipäällikön hatun päähänsä. Käytännössä se tarkoitti sitä, että testauspäällikkö vastasi uusista ominaisuuksista, parannusehdotuksista, sekä niiden hyväksynnästä. Tässä vaiheessa tilaaja myös aloitti suunnittelut kehityksen siirrosta Aasiaan. Kuluja oli vähennettävä.

    Kun projektia oli kulunut noin vuosi, devaus siirrettiin kokonaan alihankkijalle. Aasiasta ryhdyttiin kouluttamaan tiimiä testaamaan ja koodaamaan työn alla ollutta tuotetta. Suomessa testaajia ja devaajia tippui vähän kerrallaan pois. Lopuksi jäljellä oli kolme kaveria: Testaus-/projektipäällikkö, testaaja ja devaaja.

    Tehdessä oppii, näin sanotaan, eikä kyseinen tiimi tehnyt ollenkaan huonoa jälkeä, tilaaja oli edelleen tyytyväinen. Laatu pysyi kasassa suhteellisen pienillä kuluilla.

    Kun projekti oli ollut käynnissä kaksi vuotta ja toimituksiakin tehty ihan kiitettävästi, tilaaja päätti lopettaa projektin kehityksen Suomessa kokonaan. Siitä alkoivat ongelmat: Vikoja tehtiin enemmän kuin ehdittiin korjata, testaus oli samojen testitapausten toistamista viikosta toiseen ja loppuasiakas reklamoi. Projektin johto oli täysin kahvilla. Yksi toimitus saatiin tehtyä, joka sekin toimi huonosti.

    Lopulta tilaaja joutui ottamaan ohjat jälleen omiin käsiinsä. Valitettavasti siinä vaiheessa tuote oli muuttunut jo niin paljon, että työtunteja kului 600 pelkästään tuotteen uudelleenopetteluun. Hukkareissu kesken projektin maksoi puoli vuotta rahaakin arvokkaampaa aikaa! Lisäksi vaiva tiimin uudelleen kasaamisesta oli valtava ja kustannukset tuplaantuivat aivan vahingossa.

    Halpa työvoima ei ole pahasta, mutta kannattaa tarkkaan miettiä miten siirto tehdään, mitä siirretään ja ennenkaikkea milloin? Älä päästää koko projektia lipsumaan käsistä, sillä ongelmien ratkominen käy mahdottomaksi.

    Vieraileva kirjoittaja: Jarkko Tauriainen ottaa testauksen vakavasti. Jopa niin vakavasti, että sana ‘vakava’ kuulostaa vähättelyltä. Testausalalla nopeasti kehittynyt Jarkko, on itse opiskelemalla sisäistänyt testauksen perimmäisen kysymyksen ja omaksuu nopeasti uusien ympäristöjen vaatimukset. Parhaan hyödyn Jarkosta saa irti kun ei höpöttele turhan dokumentoinnin ja prosessien maailmassa, vaan tähtää tuloksiin! Mitä vaativampi projekti, sen parempi.

  • Testaus on epäeroottinen bisnes

    Ohjelmistotestaus on ihan hemmetin epäeroottinen bisnes. Miksi ihmeessä se ketään kiinnostaisi? Testauspalvelu on kallista ja sen takaisinmaksua ei voi mitata mitenkään. Miksi ihmeessä kukaan ostaisi, jos se ei kosketa henkilökohtaisesti?

    Kaikki lähti siitä kun Milla oli ostanut uudenkarhean perheauton. Valkoisen farmarimallisen, sillä hänellä oli koira ja kaksi lastakin. Kaksi viikkoa ajeltuaan Milla sai kirjeen, jossa kutsuttiin tuomaan auto merkkihuoltoon ohjelmiston päivittämisen takia. Kaikkiin vuonna 2011 maahantuotuihin samanlaisiin autoihin oli päässyt vika, joka aiheutti äänimerkin toimintahäiriön jarrutuksessa. Perhana kuinka työlästä, turhauttavaa ja aikaavievää totesi Milla. Millan aikaa koko keikka vei noin tunnin, mutta autovalmistajan aikaa kului vielä vähän enemmän:

    • Vian löytäminen, korjauksen tekeminen ja testaaminen: 10 henkilötyöpäivää
    • Auton huoltokutsun laatiminen ja lähettäminen kaikille asiakkaille massapostina: 2 henkilötyöpäivä
    • Auton huoltoaikataulujen sumplinta koko maassa: yhteensä 20 henkilötyöpäivää
    • 2560 auton huoltaminen yksi auto tunnissa: 341 henkilötyöpäivää

    Siis yhteensä 373 henkilötyöpäivää kustannuksia yhdestä asiakkaille päätynestä ohjelmistoviasta. Se tekee neljänkympin tuntihinnalla yli 110.000€ kuluja! Sillä rahalla maksaisi aivan kohtuulliset palkat testausasiantuntijalle melkein kahden vuoden ajan!

    Huonosti hoidettu testaus kosketti Millaa henkilökohtaisesti. Lisäksi se kosketti autovalmistajan softakehittäjiä, talousjohtajaa, markkinointipäällikköä, PR-vastaavaa, huoltojohtajaa ja maajohtajaakin henkilökohtaisesti. Eikä se johtunut pelkästään oman firman työsuhdeautoista.

    Testauksen hoitaminen ja siitä maksaminen ei kosketa kovin montaa ihmistä. Testauksen laiminlyönti sen sijaan koskettaa varmasti!

  • Elonmerkki 2011 – Viesti tyylillä!

    Ohjelmistotestaus.fi tekee tällä viikolla syrjähypyn! Lähden nimittäin vierailemaan design- ja viestintäalan megatapahtumassa, Elonmerkissä. Siinä samalla alan kirjailijaksi, kiitos Katleena Kortesuon rupelihattuisen idean! Tuskin maltan odottaa.

    Elonmerkki siis on Marina Congress Centerissä 25.8.2011 järjestettävä tapahtuma jämerällä iskulauseellaan: “Viesti tyylillä”

    Elonmerkki 2011 estradilla mm. dekaani Helena Hyvönen Aalto-yliopiston taideteollisesta korkeakoulusta, toimitusjohtaja Laura Lares Kalevala Korusta, yli-innovaatioaktivisti Anssi Tuulenmäki Aalto-yliopiston perustieteiden korkeakoulusta, graafinen muotoilija Pekka Loiri, ulkoasupäällikkö Markus Frey Kauppalehdestä sekä toimitusjohtaja Vertti Kivi Dsignista. Päivän päätteeksi markkinointi- ja brändijohtaja Peter Vesterbacka Roviosta kertoo Angry Birdsin maailmanvalloituksesta.

    Luvassa on siis jämerää settiä, mutta miksi se juuri sinua kiinnostaisi?

    Noh. Kaikkihan johtuu siitä, että pöljyyksissäni menin kirjoittamaan nimen sellaiseen paperiin, jossa sitoudun nakuttelemaan tuon torstaipäivän aikana kokonaista seitsemän (7) blogitekstiä tapahtuman teemoista ja puheenvuoroista. Tekstit julkaistaan testausblogimme kategoriassa Elonmerkki.

    Hyvä testausguru. Nyt jos koskaan on mainio sauma perehtyä viestinnän ja brandayksen saloihin. Nyt jos koskaan kannattaa opetella kertomaan omasta ammattitaidosta myös muille!

  • Yhdentekevä testitapausten määrä

    Minä väitän, että minkä tahansa softan voi testata yhdellä testitapauksella! Testitapauksen ei tarvitse edes olla monimutkainen. Kysymys on vain siitä, että testaaja ymmärtää lukemansa ja tekee työnsä. Paljastan salaisuuden. Esittelen tämän juuri hetki sitten verkkopalvelulle Twitter.com suunnittelemani testitapauksen.

    Step1: Test Twitter.com

    Expected result 1: Twitter.com works

    Ei siis sen suurempaa mystiikkaa. Yhdellä testitapauksella saadaan järjestelmä testattua ja sillä voidaan tietysti mitata myös järjestelmän toimivuutta luotettavasti. Eikö niin?

    Testaukseen edes vähän perehtynyt projektipäällikkö pitää tietysti logiikkaani huterana. Eihän mitään järjestelmää voi arvioida yhden testitapauksen perusteella. Eihän sellaisesta saada edes mitään mittatietoa.

    No niinhän se tietysti on. Nyt kuuluukin vain kysymys, että montako testitapausta sitten tarvitaan, että kunnon mittatietoa saadaan? Kuinka tarkaksi testiseulan resoluutio pitää vääntää, että mittatieto on luotettava? Minä en ainakaan osaa vastata. Eikä takuulla osaa projektipäällikkökään.

    Juttua voit kokeilla itsekin. Kirjoita vapaavalintaisesta kohteesta yksi edelläkuvatun kaltainen testitapaus. Sitten ala vääntämään testiseulasi resoluutiosäätimestä. Jaa siis aina jokainen testitapaus kahdeksi uudeksi ja katso kuinka pitkälle pääset ennen kuin alkaa turhauttamaan.

    Testitapausten määrä on joutava mittari. Heitä se mäkeen kun vielä voit!

  • Virhe on huono sana – osallistu!

    Edellisen blogi-tekstin keskustelussa pyöriteltiin jälleen testaajien ja kehittäjien välisen kommunikaation haasteita. Testaaja testaa ja raportoi Virheet koodareille. Periaatteessa kyse on softamaailmassa neutraalista termistä, mutta missä tahansa muualla Virheellä on negatiivinen sävy. Hoitovirhe, mittausvirhe tai virkavirhe sisältävät kaikki oletuksen siitä, että joku on tehnyt jotakin väärin.

    Vaikka Virheen sävyn softa-alan ammattilaiset ymmärtävätkin, voisiko omasta koodista löydetty Virhe kaivaa alitajunnasta esille ne kouluaikojen laskuoppi- ja kielivirheet, joista opettaja antoi yleensä negatiivista palautetta. Hoitovirheen aiheuttajaksi ei meistä halua kukaan. Virheen tekeminen vitut… harmittaa.

    Koska testaajan löytämä Virhe ei ole millään muotoa negatiivinen tai moittiva, niin miksi sillä pitäisi olla muilla elämänalueilla negatiiviseksi ja moittivaksi koettu termi. Jos Virhettä kutsuttaisiin joksikin muuksi, voisi koodarit tehdä rauhassa töitä ilman alitajunnasta puskevia epämiellyttäviä assosiaatioita.

    LEIKKIMIELINEN TEHTÄVÄ: Keksi neutraali (tai peräti positiivinen) termi testaajan löytämälle vaatimusten vastaiselle toiminnalle, jota tällä hetkellä virheeksi kutsutaan. Kirjoita ehdotuksesi kommenttikenttään!

    Katsotaan mitä saadaan aikaan.

  • Lapsellista kyselyä

    Tulin aamulla bussilla töihin ja todistin n. kolmevuotiaan pojan ja oletettavasti isoäitinsä keskustelun. Tuntui olevan kyselyikä pojalla päällä, sen verran tanakasti kyselyitä tuli koko vartin matkan verran.

    Onko tämä meidän pysäkki? -Ei ole vielä

    Mikä on meidän pysäkki? -Toripakka

    Milloin ollaan perillä? -Noin kymmenen minuutin päästä?

    Miltä se pysäkki näyttää? -No, siinä on semmonen katos ja varmaankin paljon ihmisiä odottamassa

    Miksi me ajetaan tällä bussilla? -Tällä pääsee kätevästi kaupunkiin

    Mitä me sitten tehdään, kun ollaan päästy perille? -Mennään puistoon

    Miksi me mennään puistoon? -Leikkimään ja syömään eväitä. Eikö se olisi sinusta mukavaa?

    No on! Nyt taidetaan olla perillä, tuolla on katos ja ihmisiä! -No niin ollaan, nyt voidaan jäädä pois

    Vierestä kuunnelleen kysymykset vaikuttivat vähän hassuilta. Toisaalta, mitenpä lapsi muuten olisi voinut mitään oppia? Pieni sälli hahmotti maailmansa kysymysten kautta, onhan selvää että bussilla matkustaminen ei ole vielä kovin tuttua. Kysymykset olivat kaikki oleellisia tulevien tapahtumien arvioinnissa.

    Vastaavalla tavalla testaajan olisi hyvä varmistua siitä, että miksi jotakin tehdään ja kauanko siihen on aikaa. Lisäksi on hyvä miettiä määrittelyt sille, että milloin tiedetään releasen olevan julkaisukelpoinen. Lopuksi on hyvä vielä pohtia, että mitä releasen julkaisun jälkeen pitäisi tehdä. Näin suunta pysyy kirkkaana mielessä.

    Jos et tiedä, älä oleta. Päästä sisäinen kyselyikäisesi valloilleen ja katsele maailmaa kolmevuotiaan silmin. Kysy, varmista ja kyseenalaista. Uusia näkökulmia testaukseen löytyy varmasti.

  • 1,7 miljardin euron projekti myöhässä vuosia – tilaaja ei huolissaan

    Vaikka Antti väitti taannoin, että heinäkuussa ollaan kesätauolla, niin tästä on pakko kirjoittaa.

    Tämmönen uutinen osui eilen silmään Tietoviikosta. Uutinen kertoo, että USAn armeijan SAP-projekti on vuosia myöhässä. Projekti on alkanut vuonna 2005, sen piti olla valmis vuonna 2007, jolloin uusi valmistumistavoite asetettiin vuoteen 2010. Tämän hetken arvaus on, että uusi ERP olisi käytössä tämän vuoden joulukuussa.

    Muutama mehukas poiminta jutusta:

    Uusi SAP-järjestelmä korvaa valmistuessaan yli 140 erillistä vanhaa järjestelmää. Uudella erpillä hallinnoidaan 140 miljardin dollarin vuosibudjettia, ja se palvelee 80 000 käyttäjää. Noin 15 500 ihmistä käyttää jo nyt järjestelmää.

    Vau, projekti on neljä vuotta myöhässä alkuperäisestä suunnitelmasta, ja vajaa viidesosa käyttäjistä käyttää järjestelmää!

    Vuodesta 2005 käynnissä olleessa projektissa ei ole vieläkään tunnistettu kaikkia vaatimuksia ja kuluja. Myös tarkastajien vuonna 2008 antamasta 16 suosituksesta seitsemän on edelleen toteuttamatta.

    Yhtäkkiä tuo arvio käyttöönotosta tämän vuoden joulukuussa alkaa kuulostaa kovasti optimistiselta.

    Tilintarkastajien mukaan projekti on tullut jo yli 53 miljoonaa dollaria budjetoitua kalliimmaksi. Vaarana on myös se, ettei järjestelmä valmistuessaan palvele alkuperäisiä tavoitteitaan.

    Yhdysvaltain armeija ei tarkastajien raportin mukaan ole itse yhtä huolissaan projektin tulevaisuudesta vaan toteaa, että esitetyt riskit ovat hallittavissa eivätkä ne vaikuta hankkeen kustannuksiin tai aikatauluun.

    Anteeksi mitä täh häh? “Ei vaikuta kustannuksiin tai aikatauluun”? Kuinkahan paljon projektin pitäisi olla myöhässä, että se vaikuttaisi aikatauluun. Melko varma olen siitä, että armeijan päälliköt eivät tee tuota projektia omilla rahoillaan.

    Älyttömän tarinan lopussa on kuitenkin jotakin järkevääkin.

    Amerikkalaisen konsulttifirma Asuretin toimitusjohtaja Michael Krigsman muistuttaa, että kaikissa suurissa erp-projekteissa vaikuttaa aina kolme tekijää: ohjelmistotoimittaja, järjestelmäintegraattori ja asiakas. Jotta hanke onnistuu, kaikkien täytyy hoitaa oma roolinsa hyvin.

    Eittämättä tässä tilanteessa asiakas, USAn armeija, ei ole vahtinut toimittajien perään riittävästi. Miksi pitäisikään, koska riskit ovat hallittavissa eikä aikatauluongelmia ole.

    Yritykselläsi ei ole rahaa yhtä paljon kuin USAn armeijalla. Ennen toimitussopimuksen allekirjoittamista valitse itsellesi puolueeton kumppani, joka auttaa yritystäsi pitämään toimittaja aikataulussa.

  • Oikea aika reivata

    Juhannus tuli ja meni. Minä aloitin Juhannusvapaat istuskelemalla rantakivillä rakkaassa mökkirannassa. Hetki oli otollinen haaveilulle, sillä kevyt aalto löi rantaan ja miellyttävä merituuli puhalsi myös hyttyset tiehensä. Tuuli taisi olla sopiva, sillä myös lomapurjehtijat olivat lähteneet liikenteeseen.

    Tuulen yltyessä purjehtiminen käy aina haastavammaksi hommaksi. Kyyti kyllä kovenee, mutta myös kapteenin taidot pääsevät koetukselle. Purjeella ajaessa tuulen voimistuminen kallistaa venettä reippaasti. Lisäksi veneen osiin, kuten mastoon ja takilaan kohdistuvat voimat kasvavat. Purje saattaa venyä tai pahimmassa tapauksessa kärsiä jopa vahinkoa, ellei valveutunut kapteeni ymmärrä tilannetta.

    Reivauksen tarkoitus on pienentää purjeen pinta-alaa. Homma hoidetaan esimerkiksi laskemalla isopurjetta alaspäin ja kiinnittämällä se matalammalta puomiin kiinni. Pienentämällä purjeen alaa voidaan edellä mainittuja ongelmia välttää ja matkanteosta saadaa turvallisempaa. Lisäksi nopeus vastatuuleen luoviessa kasvaa.

    Mutta mistä kapteeni tietää milloin on syytä reivata?

    Edellisen tekstin lukeneet saattavatkin jo arvata vastauksen. Kyse on fiiliksestä. Ruorin takana voi toki olla mittarit kallistuskulmalle ja tuulen tosinopeudelle, mutta oikeat päätökset syntyvät kokemuksen ja tuntuman perusteella.

    Suosittelen lämpimästi pientä itsetutkiskelun hetkeä kaikille softa-alalla oleville. Helpointa se on rannassa tai retkinuotiolla.

    Milloin viimeksi dokumentoit lomallesi tai harrastuksillesi vaatimukset? Oletko koskaan tehnyt yksityiskohtaista lomaplaniä? Oletko tehnyt vapaa-ajallesi laatuvaatimuksia tai testitapauksia? Mittaatko onnistumisia jollakin tavalla?

    Ainakin itselläni alkaa ahdistaa pelkkä ajatuskin näistä. Kyllä harrastukset ja lomat yleensä onnistuvat oikein hyvin ilman mitään mainituista. Kesäpohdinnan paikka onkin siinä, voisiko vapaa-ajan toimintatavoista oikeasti olla hyötyä myös ammattikäytössä?

    Hyvää ja rentouttavaa kesälomaa kaikille. Ohjelmistotestaus.fi palaa aalloille jälleen elokuun alussa.

  • Testaaja istuu kartturin paikalla

    Kauhukahvasta ei voi ohjata. Siitä pidetään kiinni rystyset valkoisena kun tie yllättäen käy kuoppaiseksi.

    Istuin alkuviikosta kartturina matkalla lounaalle. Tehtäväni oli kertoa mistä käännytään matkalla kiinalaiseen ravintolaan. Istun autossa harvoin muualla kuin ratin takana ja siksi matka oli opettavainen. Minulle se opetti paljon testaajan elämästä ohjelmistoprojektissa.

    Kartturin saappaissa näin tietysti jatkuvasti kaiken mitä liikenteessä tapahtui ja ketä muita tien päällä liikkui. Saatoin jatkuvasti tuntea jos nopeus olisi ollut liian kova tai ehkä liian hidas. Tunsin tietysti senkin oliko matka kuoppainen ja kuinka jyrkkiä hidasteet olivat. Kuskin jarrutukset ja kiihdytykset olivat minulle päivänselvä juttu. Ne olisin havainnut vaikka silmät kiinni. Näin myös jatkuvasti onko takana tuleva liian lähellä. Osasin myös arvioida näyttääkö tien pinta sateen jälkeen vaaralliselta. Eikä huomioiden tekeminen siihen loppunut. Listaa voisi jatkaa loputtomiin.

    Kaiken tämän informaation pystyin keräämään pelkästään tilanteen seuraamisesta ja tuntemisesta. Niin varmasti kuskikin teki. Ja menestyksellähän ei ollut mitään tekemistä auton mittareiden kanssa. Ajatelkaapa jos olisimme kuskin kanssa molemmat tuijotelleet koko matkan nopeus-, kierros-, kulutus- ja matkamittareita, kuten softaprojekteissa niin usein on tapana. Äkkiä olisimme löytäneet itsemme ojasta.

    Testaaja, kuten kartturikaan eivät pysty suoraan vaikuttamaan matkantekoon. Oikeanlainen kommunikaatio on kaiken a ja o.

    Tämä reissu oli siksi onnellinen, että pystyin todella vaikuttamaan matkantekoon. Kuski oli fiksu ja hän ymmärsi ohjeet mainiosti. Meillä oli myös ennalta sovittu yhteinen tavoite mielessä. Kommunikaatio pelasi erinomaisesti molempiin suuntiin.

    Kartturina yritin tietysti antaa ohjeet rakentavasti ja hyvissä ajoin. Ilmeisesti myös onnistuin siinä, koska kiinalaista saimme lounaaksi ja vielä molemmat samassa paikassa. Mutta mitäpä olisikaan tapahtunut, jos olisin vain viisastellut ja kuittaillut “tuosta olisi pitänyt jo kääntyä”? Veikkaan, että omalta osaltani matkanteko olisi jatkunut jalan.

    Minusta mittarit ovat oivallinen apuväline matkan tekoon. Pääpaino oikeiden ratkaisuiden tekemisessä ei kuitenkaan voi ikinä olla niissä. Kysmys on lähes aina perstuntumasta ja oikeasta keskustelutavasta. Kysymys on fiiliksestä. Jotkut kutsuvat sitä intuitioksi, toiset taas kokemukseksi. Homman nimi on kuitenkin aina sama niin autoilussa, kuin softakehityksessäkin.

    Faktat, mittarit ja numerot ovat oivallinen apuväline, mutta todelliset ratkaisut ja onnistumiset rakennetaan aina lopulta tunnepohjalta. Luottamuspula tunteisiin on päätöksen pahin vihollinen.

    P.S. Tällä matkalla kauhukahvaan ei tarvinnut tarttua. Kyyti oli mukava ja tiimi toimi!

  • Testaus ja laadunvarmistus napit vastakkain

    Quality Assurance, QA tai Laadunvarmistus. Kuulostaa hienolta ja näyttää kovalta käyntikortissa. Harmi vain, että sillä on hyvin vähän tekemistä testauksen kanssa.

    Työskentelin taannoin eräässä isomman mittaluokan projektissa testaajana. Minä metsästin bugeja. Tittelinä meillä testauksen ammattilaisilla oli “QA engineer”. Asiakkaan kanssa keskustelimme aina QA-asioista ja QA:ta puski tuutin täydeltä ja joka suunnalta.

    Kun projektia oli painettu vuoden verran alkoi näyttää selvältä, että eihän tästä saada ikinä valmista tuotetta. Me ymmärsimme sen tehtyämme töitä noin 9 kk ja me uskalsimme jopa sanoa sen ääneen. Tuotteen omistaja ymmärsi sen haaskattuaan rahoitusta vielä 8 kk lisää. Tuo viimeinen 8 kk oli ehkä urani opettavaisinta aikaa. Silloin seulottiin armottomasti ongelmia ja koitettiin löytää ratkaisuja. Harmi vain, että ratkomista yritettiin täysin väärästä päästä. Kaikki nimittäin lähti liikkeelle testauksesta, eli meidän projektissamme laadunvarmistuksesta.

    Teidän tehtävänne on varmistaa laatu. Tehän olette laadunvarmistajia! Miksi tässä projektissa kaikki menee metsään?

    Niinpä. Tästä asetelmasta lähtee hämmästyttävän monen testaajan arkipäiväisimmät ongelmat. Testaajan kuvitellaan olevan vastuussa laadusta, vaikka todellisuus on täysin toinen.

    1. Testaajalla ei ole valtaa tehdä muutoksia koodiin
    2. Testaajalla ei ole valtaa tehdä päätöksiä releaseista
    3. Testaajalla ei ole valtaa tehdä päätöksiä projektijohtamisesta
    4. Testaajalla ei ole valtaa päättää aikatauluista

    Saman kysymyksen ilmaan heitti myös Michael Bolton Rapid Software Testing -kurssillaan.

    Why on earth would you call it quality assurance, when people doing it have no control over the quality?

    Laadunvarmistus on hieno sana, mutta yleensä se on täyttä huuhaata. Ainakin minulla tulee laadunvarmistuksesta mieleen, että nyt testaajan on varmistettava tuotteen laatu. Näin testaajan työn oikeasti hyödylliset tavoitteet voidaan heivata heti romukoppaan. Sana laadunvarmistus asettaa ajatusmaailman väärille raiteille jo ennen kuin työtä on edes aloitettu.

    Testaajan todellinen tehtävä ei ole rakentaa luottamusta tuotteen toimivuudesta. Testaajan todellinen tehtävä on tuhota väärin perusteltu luottamus. Silloin ei ole kyse laadunvarmistuksesta, silloin on kyse testauksesta.

    P.S. Jatkossa tagilla “bolton” merkityt tekstit ovat matkaeväitä, jotka kirjailin ylös Michael Boltonin Rapid Software Testing -kurssilla Helsingissä.