Materiaalit: Ketteriä menetelmiä ja riskipohjainen testaus

2002-01-14 TKK, Espoo. Illan emäntänä oli Maaret Pyhäjärvi.

Kaikki puhuvat tänä talvena Extreme Programming:sta ja ketteristä menetelmistä. Testaajia luonnollisesti kiinnostaa eniten testauksen asema näissä muodikkaissa menetelmissä. Maailmalta kantautuu puhetta riskipohjaisesta testauksesta, joka kuulostaa järkevältä. Molemmille asioille on yhteistä että harva on kumpaakaan nähnyt tehtävän oikeasti.

Testing in Agile Methodologies and Extreme Programming (191 k) 2002-01-14_agile

Maaret Pyhäjärvi on tutkijana Teknillisen Korkeakoulun SoberIT tutkimusyksikössä ja on nyt erityisesti selvittänyt pienille ohjelmistofirmoille sopivia ohjelmistotuotannon menetelmiä. Maaret on sikäli erikoinen tutkija, että hänellä on myös perusteellinen testaajatausta.

Harva asia on viimeisen parin vuoden aikana pitänyt koko softa-alan kiinnostusta yllä, kuten ns. ketterät menetelmät, etenkin Extreme Programming, eli XP. testaajan kannalta XP:n kiinnostavimpia puolia ovat

  • Varsinaisten suunnitteludokumenttien puuttuminen – ne korvataan automatisoiduilla testeillä.
  • Yksikkötestit kirjoitetaan ennen koodin kirjoittamista ja ne automatisoidaan 100%:sti.
  • Hyväksymistestit valitsee mieluiten asiakas tai asiakkaan edustaja
  • XP:ssä kaikki projektissa ovat ohjelmoijia

XP siis ilmiselvästi muuttaa testaajien roolia. Maaret esitteli XP:n periaatteita ja myös hahmotteli testaajien roolin muuttumista. Totesimme yhdessä, että asiaa pitäisi selvittää lisää.

Risk-Based Testing (167 k) 2002-01-14Risk-based_testing

Erkki Pöyhöseltä on kysynyt useampikin sisäinen asiakas viime aikoina, miten organisaatio voisi kohdistaa testausresurssinsa paremmin. Erityisesti projektin kalenteriaika pitäisi jakaa järkevästi erilaisten testaustyyppien välillä.

Riskipohjaisesta testauksesta on muutaman viime vuoden aikana puhuneet useammatkin testauskonsultit ja -tutkijat. Toisaalta James Bach ja Cem Kaner ovat puhuneet ja kirjoittaneet paljon siitä, miten riskianalyysi voi auttaa paremmin löytämään asiakkaan tarpeiden kannalta vakavampia vikoja (Risk-based Test Specification). Toisaalta Ståhle Amland ja Paul Gerrard ovat korostaneet riskianalyysin mahdollisuuksia testauksen kohdistamisessa (Risk-Based Test Management / Test Planning).

Materiaalit: Testauskerhon käynnistys ja ensitapaaminen

Testauskerho (myöhemmin vaihtoi nimensä testausOSYksi) piti ensitapaamisensa huhtikuussa 2001 Nokia Research Centerin tiloissa Ruoholahdessa. Puhujina oli englannin vastaavan yhteisön konkareita, Grove Consultants -yrityksestä sekä testauskerhon käynnistäjä Erkki Pöyhönen.

Etukäteen jännitti aika lailla, tuleeko ketään kerhon ensimmäiseen kokoukseen. Huoli oli aivan turha, paikalle saapui upeat 45 testausammattilaista. Ehkä asiaan vaikutti sattumalta pääpuhujiksi lupautuneet, Suomessa samaan aikaan koulutusmatkalla olevat Lloyd Roden ja Mark Fewster, maailmanluokan testauspuhujia molemmat.

Esitykset ja materiaalit:

Lloyd Roden: The Bugs Life

2001-04-10_bugs_life

Lloyd Roden on käsittämättömän hyvä puhuja, joka onnistuu pitämään joka vuosi EuroSTAR-konferenssissa esityksensä täydelle salille. Lloyd valittiin muuten 2001 EuroSTAR:n parhaaksi puhujaksi – ainakin toisen kerran peräkkäin.

Eipä Lloyd pettänyt tälläkään kertaa. Puheessa esiteltiin huumorin kautta erilaisia vikatyyppejä, niiden luonnehdintaa ja miten ne voisi löytää. Lisäksi käytiin läpi hyviä ja huonoja ajattelumalleja testauksen avuksi.

Mark Fewster: Understanding the value of testing

2001-04-10_understanding_value

Mark Fewster on tullut kuuluisaksi etenkin testausautomatisoinnin kouluttajana ja konsulttina. Useampikin suomalaisyritys on hyödyntänyt Markin asiantuntemusta automatisointihankkeissaan. Tätä nykyä Mark on tutumpi testaustekniikoiden ja testaajien peruskoulutuksen puolestapuhujana (mm. ISEB-sertifikaattikoulutusten kautta). Tälläkin kertaa Mark tuli paikalle Aulangolta, jossa oli päivällä pitämässä Soft-ED:n järjestämää ISEB SW Testing Foundation -kurssia.

Mark esitteli ensin organisaatioiden yleisiä tavoitteita testaukselle ja perusteli miksi monet niistä ovat hyviä, kunhan balanssi säilytetään. Lopuksi Mark vielä esitteli varsin hyvän idean testauksen suunnittelun ja raportoinnin toteuttamiseksi tunnistettuihin riskeihin perustuen. Asia jäi vielä hieman teoriaksi ajanpuutteen takia. Ehkä voisimme selvittää tätä kerhon myöhemmissä tilaisuuksissa?