Category: Ohjelmistotestaus

Olemme vuosien varrella valittaneet ankarasti testaukseen liittyvistä asioista. On valitettu huonoista työkaluista, testitapausten suunnittelusta, jäykkäniskaisesta yrityskulttuurista, väärien asioiden tekemisestä ja tehottomuudesta. Valitusta on riittänyt, mutta nyt päätimme muuttaa testaustyön luonnetta heti kerralla. Päätimme kirjata ylös sen mitä useimmat testaajat huomaamattaan jo työkseen tekevätkin.

Me törmäämme yhä maailmalla liikkuessamme muka superhienoihin testispekseihin. Testien suunnitteluun on käytetty pirusti työaikaa ja se tuntuu maksajasta varmasti hyvältä. Yhteistä näille noin 80%:lle perinneprojekteista on törkeän huonot testitapaukset. Yleensä testitapaukset kertovat yksityiskohtaisesti MITEN testi suoritetaan. Silloin nus.. viilataan pilkkua.

En tietenkään sano, että viilaminen on mitenkään tylsää hommaa. Bisneksen tekemisessä paukkuja vain käytetään silloin ihan vääriin asioihin.

Testitapauksen tulee ensisijaisesti kertoa MITÄ tulee tulla testatuksi! Sen voi ihan oikeasti sanoa muutamalla lauseella. Oikeastaan Twitter on todistanut, että useimmat asiat voi sanoa vain 140:llä merkillä!

Testauksenhallintajärjestelmien käyttöä ja testaustyön dokumentointia puoltavia perusteluja on runsaasti. Mutta kuinka voitaisiin yhdistää nopea ja tavoitekeskeinen testaussuunnittelu, tutkiva testaus ja sopiva dokumentoinnin taso raportointia ajatellen?

Erittäin toimivaksi ratkaisuksi olemme huomanneet tutkivan testauksen jota tuetaan tarkistuslistoilla. Homma toimii siten, että testispeksit tehdään yksinkertaisena tarkistuslistana asioista mitä session lopussa tulee vähintään olla testattuna. Otsikointiin riittää helposti tuo 140 merkkiä ilman että järkeään käyttävälle testaajalle jää epäselväksi testin tavoite. Testitapauksen askelet ja muun oheiskrääsän olemme heittäneet mäkeen. Yleensä niiden kanssa säätäminen syö vain aikaa, eli rahaa.

Tarkistuslistaa voi käyttää testauksenhallintajärjestelmästä ja tuloksetkin voi kirjata sinne. Myös Excel toimii varsin helposti kun muistaa minimalistisen lähestymiskulman.

• Testien suunnittelu ja speksaaminen on supernopeaa
• Testien ajaminen ei aiheuta putkinäköisyyttä vaan on tutkivaa
• Virheitä löytyy merkittävästi enemmän käytettyyn rahamäärään nähden
• Pomokin tykkää kun pystytään lyömään statsit ja rapsat tiskiin
• Tarkistuslistat kelpaavat myös esimerkiksi käyttöönottoinsinöörin työvälineeksi

Asiaa voi pysähtyä pohtimaan myös testausammattilaisen näkökulmasta. Hänen voi huomata tekevät töitä hyvin saman kaltaisilla menetelmillä jo valmiiksi. Ainoa ongelma on, että usein hän tekee sen kaiken jäykkäniskaisen, pysähtyneen ja muutosvastarintaisen prosessin kahlitsemana. Siksi tuloskaan ei aina tyydytä!

Saat enemmän vastinetta rahoillesi, kun uskallat antaa testausosaajasi hoitaa hommat kuten osaajan kuuluukin.

Juuri pöllimäni tarina kertoo ukrainalaisesta luutnantista, joka lähetti pienen tiedustelujoukon Alpeille. Raju lumimyrsky yllätti ryhmän ja pyryä jatkui taukoamatta kaksi päivää. Luutnantti oli varma karvaasta miestappiosta, kun ryhmästä ei toisenkaan päivän iltana kuulunut uutisia. Kaikkien suureksi yllätykseksi ryhmä kuitenkin palasi vuorilta kolmantena päivänä ja vieläpä ehjin nahoin. Mitä oli tapahtunut? Kuinka ryhmä selviytyi tukalasta tilanteestaan?

Helmikuun kuumottavin puheenaihe on ollu palava lautta. Erityisesti Nokian sellainen. Stephen Elopin kirje työntekijöille kertoi karua kieltä. Erityisesti siitä että Nokialla tehtään yhä paljon vääriä asioita.

Chinese OEMs are cranking out a device much faster than, as one Nokia employee said only partially in jest, “the time that it takes us to polish a PowerPoint presentation.”

Karkeasti ottaen kysymys on siitä, että kiinalainen laitevalmistaja pukkaa tuotteen markkinoille nopeammin kuin Nokialla saadaan PowerPoint kalvot kasaan. Sama ongelma vaivaa isoa siivua suomalaisia yrityksiä tuotekehityksestä testaukseen. Työpanoksesta suuri osa valuu monesti suunnitteluun, säätämiseen ja excelien pyörittelyyn. Tuloksen syntymisen kannalta siis joutavaan puuhasteluun.

Ukrainalainen tiedustelijaryhmä selvisi tukalasta tilanteestaan nopealla toiminnalla. Tilanne oli näyttänyt epätoivoiselta myös tiimin näkökulmasta kunnes joku oli löytänyt taskustaan kartan. Sen jälkeen tiimi ryhtyi toimeen. He pystyttivät leirin, odottivat myrskyn loppumista ja selvisivät lopulta takaisin tukikohtaan. Mielenkiintoista tarinassa on se, että tämä kartta oli Pyreneiltä, ei Alpeilta.

Jos ryhmä olisi alkanut viilaamaan suunnitelmaa, selviytymisstrategiaa ja vielä dokumentoimaan sitä, kaikki olisivat auttamatta paleltuneet kuoliaaksi. Sen sijaan he päättivät rauhoittua, ottaa härkää sarvista ja panna toimeksi. Tarinan opetus tietysti on se, että usein huonokin suunnitelma riittää.

Testaustyössä kuvitellaan usein, että hyvä testiplani ja tarkka testispeksi ovat olleet menestyksen salaisuus. Esimiehet ovat tykänneet kivoista exceliraporteista ja softakin on saatu yleensä aikataulussa valmiiksi, kiitos devausgurujen. Siksi liian moni testausasiantuntija urautuu. Hän kuvittelee, että menestys on saavutettu nimenomaan suunnitelmien ja speksien kautta ja alkaa panostaa aina enemmän näihin asioihin.

Kun urautunut asiantuntija panostaa jatkuvasti enemmän suunnitteluun ja excel-harjoituksiin, amatööriltä näyttävä kilpailija painaa ohi oikealta ja vasemmalta.

Kun yksi laittaa töpinäksi, hän tutkii hetkessä monta reittiä loppuun saakka. Samassa ajassa ns. fiksut hädin tuskin ehtivät valmistautua edes ensimmäiselle etapilleen.

Todelliset onnistujat menestyvät, koska he riisuvat kravaatin, käärivät hihat ja ryhtyvät heti toimeen! Siksi hyvin suunniteltu ei ole puoliksi tehty.

Jos softakehitystä ja laatua ei voi mitata rahalla, niin millä sitten?

Oletetaan että sinulla on softatuote ja yksi 10 hengen softankehitystiimi. Tuote pitää päivittää uuteen versioon neljä kertaa vuodessa ja päivitysten asentaminen asiakkaille on hoiduttava mutkattomasti.

Jokainen virheestä johtuva myöhästyminen toimituksen valmistumisessa viivästyttää koko projektia 3 päivää. Se vaatii koko tuotekehitystiimin työpanoksen. Maltillisella 50 euron tuntihinnalla viivästys kustantaa 11000,-/laaki. Lisäksi se myöhästyttää seuraavan tuotekehityssyklin aloitusta ja pakottaa asennustiimin pyörittelemään peukaloitaan. Ja taksamittari raksuttaa.

Jokainen vakava asiakasreklamaatio työllistää tuotetukeasi 2 tuntia, tuotekehitystä ja testausta fiksien muodossa 3 päivää. Hinta 1200,-/laaki. Lisäksi se vaikuttaa negatiivisesti yrityksesi imagoon!

Jokainen uusi asiakas, joka takuuaikana valittaa toimituksesta, työllistää asennustiimiäsi 5 päivää lisää. Hinta 1900,-/laaki.

Esimerkiksi 15 tarpeetonta asiakasreklamaatiota vuodessa, 3 virheestä johtuvaa myöhästymistä ja 4 uuden asiakkaan reklamaatiota takuuaikana kustantavat vuodessa yhteensä 58600,-

Järkevästi rakennettu testaus maksaa itsensä aina takaisin.

Työ on hyödytöntä silloin kun kukaan ei tarvitse sen tuloksia. Joutavuuksien tekeminen haaskaa kallisarvoista aikaa ja lisäksi se harmittaa vietävästi. Siksi bugirapsan on parasta olla hyvä!

Tee työtä, jolla on tarkoitus

Tämä lausehan on erään tunnetun suomalaisen firman motto. Se kiteyttää erinomaisesti myös testaajan arkisen aherruksen. Testaustyön keskeisin tarkoitus on nimenomaan löytää virheitä. Erityisesti sellaisia virheitä, jotka läpipäästessään aiheuttavat sietämätöntä tuskastumista missä tahansa softan toimituksen vaiheessa. Kun testaaja raportoi virheitä, silloin työllä on konkreettisimmin tarkoitus. Mutta:

Olet mitä kirjoitat

James Bach kiteytti testaajan työn napakasti. Bugiraportithan ovat useimpien testaajien työn ensisijaisin tulos. Bugirapsat muovaavat lukijoiden asennetta testaajaa kohtaan. Ne voivat toimia myös testaajan maineen rakentajana. Toisaalta niiden kautta tulee myös helposti arvioitua testaajan ammattitaitoa.

Jos testaaja ei jaksa tai ei osaa panostaa riittävästi bugiraportin laatimiseen, silloin työn tarkoituskin heilahtaa harakoille!

Testaajan ensisijainen yleisö tietysti on devaajat. Vaikka esimiesasetelmaa ei ole, niin jokainen tehty bugiraportti on periaatteessa pyyntö devaajalle panostaa työaikaa bugin tutkimiseen ja mahdolliseen korjaamiseen. Huonosti ja huolimattomasti laadittu virheraportti ei kerro devaajalle riittävästi virheen toistamisesta tai sen vaikutuksista lopputuotteeseen. Silloin ihan jokaisen lukijan vuorollaan täytyy tutkia aihetta itse lisää. Se, jos mikä, on omiaan haaskaamaan myös devaajan työaikaa! Jos testaaja haaskaa riittävästi kavereiden työaikaa, alkavat kaverit automaattisesti välttämään yhteistyön tekemistä. Silloin mennään metsään pahasti.

Bugiraportin hyvyys vaikuttaa merkittävästi siihen mitkä virheet korjataan ja mitä ei. Hyvä virheraportti luonnollisesti kuvailee virheen tarkasti ja sisältää myös taustatutkimusta ja vaikutusten analysointia. Hyvä virheraportti antaa lukijalle pelimerkit päätösten tekemiseen niin tuotteen kuin bisneksenkin kannalta. Kannattaa laittaa tämä korvan taakse:

Testaajan rooli on devauksen lisäksi myös bisneksen ja myyntiprosessien tukeminen.

Siksi bugiraportti on testaajan paras käyntikortti. Se edustaa testaajaa silloinkin kun hän ei ole itse paikalla.

Yksilön oma etu toimii yhteisön edun hyväksi. Väitteen esitti nykyaikaisen taloustieteen isäksikin tituleerattu Adam Smith jo 1700-luvulla. Samankaltaisilla linjoilla oli myös meidän Chydenius aikanaan.

Mainitun periaatteen Smith esitti vertauskuvalla “näkymätön käsi“. Homman nimi on siinä että järkevät, omaa etuaan ajavat ihmiset hyödyttävät kaikkia pidemmällä aikavälillä. Periaatteen mukaan homma toimii silloin kun ihmiset eivät saa pakottaa toisia vaan voivat hyötyä näistä vain tarjoamalla vastapalveluksia (*). Näkymätön käsi on siis vapaassa taloudessa ihmisten toimintaa ohjaava voima. Päätökset ja tekeminen hyödyttävät kaikkia osapuolia.

Softakehityksessä sama periaate näkyy nyt entistä selvemmin. Parhaisiin tuloksiin pääsevät organisaatiot ovat yleensä rakenteeltaan hyvin matalia. Niissä korostuu työntekemisen malli, jossa tehdyt ratkaisut ovat kaikille hyväksi. Esimerkiksi työkaluvalinnat eivät synny managementtipäätöksillä vaan itse tekijöiden tarpeista. Managementti hyötyy kun tulosta syntyy nopeammin, työntekijä hyötyy kun työkaluksi valitaan hänelle helpoin ratkaisu. Tällaisissa organisaatioissa johtajuutta ei usein anneta vaan se on myös ansaittava.

Online-pelit ovat mielestäni mainio esimerkki tästä. World of Warcraftissa kaikki pelaajat aloittavat yksin, mutta suurimmat tavoitteet voidaan saavuttaa ainoastaan toimivina tiimeinä. WoWissa kykenevimmät yksilöt valitaan johtajiksi tarveperusteisesti. Johtajuus on kestävää ainoastaa siinä tapauksessa että se hyödyttää tiimin kaikkia jäseniä.

Muinoin johtajat valikoivat seuraajiaan. Uhkaajat pudotettiin pelistä teloittamalla tai karkottamalla maasta. Siis pakottamisella ja pelolla. Nykyisin ihmiset valitsevat ketä haluavat seurata. Nämä valinnat palvelevat aina jollakin tavalla omaa etua. Käytännöllisin esimerkki on Twitter, jossa Lady Gagaa seuraa lähes 8 miljoonaa ihmistä. Barack Obamalla seuraajia on yli 6 miljoonaa ja minulla alle 10. Vielä on siis vähän tekemistä 🙂

No. Homman pointti lienee kuitenkin selvä. Twitterissä yksilöt hyötyvät seuraamisesta ainakin sosiaalisesti, Twitter.com hyötyy valtavista käyttäjämääristä taloudellisesti, Lady Gaga ja Barack Obama taas hyötyvät hommasta vähintäänkin PR-mielessä.

Hyvä asiakas. Tavoittele avoimesti omaa etuasi. Niin minäkin teen. Se on lopulta kaikkien etu!

* Vastapalvelukset voivat olla oikeasti palvelua, hyödykkeitä tai vaikkapa rahaa.

Kun vuoden vaihde painoi hetki sitten päälle, niin testaajan työkuorma kasvoi aivan yllättäen. Softakehityksestä hävisi järki totaalisesti. Testaajasta tuli syyllinen, kun tulosta ei syntynyt deadlineen mennessä. Mitä siis tapahtui?

Homman nimi on siinä, että testausta käytetään tuotekehityksen tukena. Tietysti se on hieno ja toimiva ajatus, paitsi jouluna.

1. Kysymys testaajalle: Miksi meidän regressiotestissä on vieläkin niin paljon faileja?
2. Ohjeistus testipäällikkölle: Kannustahan vähän sitä testitiimiä, että saadaan vihreä palkki nousemaan!
3. Case katselmoinnin agenda: Miten testitapauksia pitäisi korjata, että pass rateksi saataisiin 98%?
4. Toimittaja testaajalle: Eeeei tuo ole defekti, pistä case vihreeksi vaan!
5. Pitääkö palkata lisää testaajia?

Testausta käytetään häikäilemättömästi hyväksi nimenomaan silloin kun on bonukset pelissä. Silloin tarvitaan hopeareunustettua totuutta että tavoitteet saavutetaan. Helpoimmin se käy, kun testataan softa kuntoon. Näin testaajat painavat täysin turhaa työtä koko loppuvuoden. Devaajat ovat tyytyväisiä, kun kaikki näyttää hyvältä. Managementti vain hymyilee ja rahaa kuluu vielä lisäksi uskomaton määrä perusteettomiin bonuksiin.

Minun on pakko vastata edellisiin kohtiin:

1. Siksi kun softa on vieläkin ihan romuna
2. Just joo! Testaamallahan ne virheet korjaantuu
3. Heitän pallon takaisin: Miten softaa pitäisi korjata, että pass rateksi saadaan 98%?
4. Kyllä se on defekti, jos loppukäyttäjää ***uttaa armottomasti
5. Ei varmaankaan. Näyttää siltä että nyt tehdään vääriä asioita!

Se on oikeasti kallis tikki, jos et uskalla ottaa kantaa näihin jouluhullutuksiin tänäkään vuonna!


Testausalalle vihkiytyneenä ihmisenä automaattinen vastaukseni tähän kysymykseen on “ehdottomasti kyllä!”. Vastaus on hyvä yleisesti ajateltuna, mutta entäs sitten talous- ja mainenäkökulmasta katsottuna. Tältä kannalta virheen vakavuus ja sen toistettavuus näyttelevät pääroolia. Heitän esimerkkinä kaksi skenaariota:

1. Conan Barbaarin uudenkarhea kahden käden miekka osoittautuukin tylsäksi. Valmistusvirhe on selkeä ja toistettavissa jokaisella käden heilautuksella. Conan Barbaarin taistelutaitoihin tämä tuskin vaikuttaa, mutta tavallisen tusinataistelijan käsissä miekka koituu käyttäjänsä kuolemaksi.

2. He-Manin juuri pakasta vedetty yhden käden miekka on terävä ja leikkaa lihaa todella huonosti vain tietyssä osumakulmassa. He-Man on myöskin Conanin veroinen miekkamies, jonka taistelutaktista näkemystä yksittäiset huonot viillot eivät juuri horjuta, mutta se yksikin huono osuma voi muuttaa taistelun suunnan täysin odottamattomaan.

Conanin ja He-Manin yhteisellä miekanvalmistajalla on valinta edessä. Jatkaako tuotantoa samanlaisena vai korjatako virheet? Bisnesmiehenä miekanvalmistaja punnitsee valmistusvirheiden vakavuudet tarkoin ja päätyy korjaamaan Conanin tylsän miekan mutta jatkaa He-Manin terävän miekan tuotantoa normaaliin tapaan. Miekanvalmistajan mielestä korjauskustannukset ovat joskus huomattavasti suuremmat kuin kyseisestä virheestä aiheutuvat kustannukset.

Oikean elämän esimerkki tästä valinnasta on Joulupukin Hiace-reen viimeisin otsikoissa ollut valmistusvirhe SUA (sudden unintended acceleration). Virheen kuvaus lyhyesti: Petteri on käynyt salilla liian usein. Kysymys kuuluu onko rekivalmistajalla ollut kyseinen virhe tiedossa, kun reet ovat päästetty tuotantoon? Virheen esiintymismäärä eli toistettavuus on hyvin pieni verrattuna myytyihin rekiin. Tämän kaltaisten virheiden korjauskustannukset ovat lähes varmasti suuremmat kuin virheestä suoraan aiheutuvat kustannukset. Virheestä epäsuorasti aiheutuvat kustannukset ovat kuitenkin asia erikseen. Henkilövahinkoihin ja kuolemantapauksiin johtavat virheet nostavat sataprosenttisella varmuudella kunnon mediamylläkän, jonka seurauksena ihmiset eivät välttämättä enää luotakaan Joulupukkiin kuten ennen.

Olisiko sittenkin kannattanut korjata se mitättömän kokoinen pieni bugi?

Testausgurut toivottavat virheetöntä joulua ja kustannustehokasta uutta vuotta kaikille tasapuolisesti!

David Devaaja paukuttelee koodia projektissa yhdessä Kari Koodarin kanssa. Parin viikon Sprinttiä on nyt painettu viimeiset päivät pitkillä ylitöillä. Kun poikien työ lopulta valmistuu, heivataan softa ja juuri valmistunut featurepaketti Tiina Testaajan käsittelyyn. Aika usein sitä sanotaan Agileksi.

Hirveän usein firmat kertovat tekevänsä softaa ketterästi. Siitä huolimatta tarkempi pureutuminen softakehityksen ytimeen paljastaa edellä kuvatun tilanteen. Yleensä kyseessä onkin inkrementaalinen tai iteratiivinen (IID) tapa tehdä softaa. Siinä devaajat vetäytyvät rakentamaan kierrokselle sovittujen vaatimusten näköistä softaa ja valmis setti testataan. Äkkiä Agileksi väitetty työ vaikuttaakin sarjalta pieniä vesiputouksia.

Speksaus-devaus-testaus,

speksaus-devaus-testaus,

speksaus-devaus-testaus.

Tämä ajatusmaailmaero aiheutti keskustelua myös Oulussa järjestetyssä TestausOSY:n Agile-seminaarissa. Inkrementaalinen softakehitys ei nimittäin ole automaattisesti Agilea. Agile sen sijaan on luonteeltaan inkrementaalista.

Keskeisimmät erot tulevat tiimityön luonteesta ja nopean palautteen merkityksestä. Palaute ei ole nopeaa, jos työ tehdään vaiheissa ensin devaus, sitten testaus. Silloin ei myöskään ole kysymys tiimityöstä vaan kahden tiimin yhteistyöstä. Hämmentävää, eikö totta?

Minusta Agilen ero perinteiseen inkrementaaliseen softakehitykseen tiivistyy seuraaviin kohtiin:

1. Tiimi on itseorganisoitu: ei managereita, ei pakotettuja prosesseja
2. Palaute on aina nopeaa: testaajalta devaajalle, asiakkaalta tiimille
3. Työ mukautuu pintautuviin vaatimuksiin: ei pitkiä inkrementtiplaneja
4. Työkalut auttavat tavoitteen saavuttamisessa: ne eivät määrää miten se saavutetaan

Jotta inkrementaalisesta saadaan oikeasti Agilea, ihmisten täytyy oppia päästämään irti vanhasta ajatusmaailmasta “hyvin suunniteltu on puoliksi tehty”. Täytyy lopettaa yritykset ennakoida onnistumista mittaroinnilla tai spekseillä. Täytyy oppia hyväksymään epävarmuutta ja ennakoimattomuuta. Asiat eivät aina mene kuten etukäteen oli suunniteltu. Ennen kaikkea ihmisten täytyy uskaltaa!

Työkalut ja prosessit tulevat ja menevät. Pääasia on, että tulosta syntyy ja softa toimii!

ISEB, ISTQB, CSQA, CSTE, CQIA, CTM, SSBB ja CSTP. No huh huh sanon minä. Testausalan sertifikaatteja on moneen junaan, mutta mitä ne oikeasti opettavat?

Tietysti sertifioinnista jää kouraan todistus. Todistus kertoo siitä että tietty testausosaamisen ja terminologian perustaso on saavutettu. Se kertoo että tentistä on päästy läpi ja kysymyksiin löytyi oikeat vastaukset.

Which of the following would you not use when choosing test techniques?

1. Level and type of risk
2. Time and budget
3. Regulatory standards
4. Recommendations from developers

Edellä on esimerkki ISEB serfitioinnin tenttikysymyksestä. Jos omaa edes vähän käytännön kokemusta muuttuu tähän tehtävään vastaaminen vaikeaksi ellei aivan mahdottomaksi(*). Testaustekniikoita valitessa on tietysti tärkeää miettiä riskejä, resursseja, lakeja ja standardeja. Ihan yhtälailla tärkeää on keskustella devaajien kanssa. Yksikään tiimi ei toimi jos joku sooloilee. Vastaavanlaisia, ristiriitaisia tunteita herättäviä kysymyksiä ovat kaikki sertifiointitentit pullollaan.

Ehkä juuri siksi minusta onkin pitkään tuntunut, että sertifikaatit eivät yksinkertaisesti sovellu nykyaikaiseen testaukseen. Niitä ei voi pitää testauksen hyvyyden mittarina, sillä ne yrittävät hieroa testaajat samaan ajatusmaailmaan ja muottiin. Kuitenkin parhaat tulokset testaustyöstä saavutetaan aina kun samaa asiaa katsotaan yhtä aikaa useammasta näkökulmasta. Erilaiset ihmiset eri suunnilta. Katvealueita jää vähemmän.

Sertifikaattikoulutukset ovat kuitenkin yleensä varsin asiallisia. Niissä on liikkumatilaa keskustelulle, kritiikille ja käytännön kokemuksellekin. Juuri siksi uskon, että sertifikaatit kaikesta huolimatta kertovat sen, mitä testaajan voi olettaa vähintäänkin tietävän. Tärkeimmän ne kuitenkin jättävät aina kertomatta.

Sertifikaatti jättää kertomatta sen, mitä testaaja oikeasti osaa.

(*) ISEB:in mukaan ainoa oikea vastaus tehtävään olisi ollut tuo viimeinen kohta 4.

Ecofin antoi kesäkuussa toimeksi EU:n laajuisen stressitestin tekemisen pankkisektorille. Testauksen tarkoituksena oli selvittää, miten eurooppalaiset pankit pystyisivät kohtaamaan odotettua merkittävästi heikomman talouskehityksen. Yhteensä 91 pankkia EU-alueelta valittiin testattavaksi. Kattavuus testeillä oli 65% EU:n pankkisektorin yhteenlasketusta taseesta.

Testit suoritettiin vauhdikkaasti kunnes heinäkuun lopulla testaajat julkistivat tulokset. Pass-rate oli varsin hyvä. Noin 92%. Vain seitsemän pankkia Espanjasta, Saksasta ja Kreikasta reputti testeissä. Lisäksi testaajat olivat vakuuttuneita testien luotettavuudesta ja ankaruudesta. Kunnon stressitestausta siis.

Yksikään irlantilainen pankki ei kuitenkaan saanut hylsyä kesällä järjestetyissä testeissä. Mitä ihmettä?? Näin testaajan näkökulmasta katsottuna pistää kyllä miettimään.

Kaikesta mediahuomiosta huolimatta juuri kukaan ei kysy, että mikä testeissä meni pieleen? Se on olennaisin kysymys arvioidessa testauksen hyvyyttä. Se on olennaisin kysymys jos tosiaan halutaan parantaa testauksen luotettavuutta.

On kuitenkin tärkeää huomata, että tuo kysymys kysytään vain jos uskotaan testien epäonnistuneen. Siksi minusta tuntuu, että pieleen menikin testauksen tavoitteiden asettelu. Testien tulos oli täsmälleen se mitä niiden haluttiinkin olevan!

• Gaining confidence
• Finding defects

Kumman tavoitteen sinä olisit asettanut europankkien stressitesteille?

“Sun tarttee varoo mitä sä haluut, koska sä saatat saada sen” – Andy McCoy