Arkisto: helmikuu 2010



Tee testispeksit uudella tavalla!

26. helmikuuta, 2010 | Kirjoittaja: Antti Niittyviita

Jarkon uusin projekti oli alkanut painaa hommia jatkuvan integroinnin periaatteella. Projekti oli ensimmäinen tyyppiään organisaatiossa, jossa Jarkko teki testimanagerin hommia. Projektin alussa testauksen haluttiin toimivan varsin perinteisellä mallilla. Testauksessa nimittäin suunniteltiin releaselle savustustestit ja iso kasa toiminnallisuustestejä. Ne paketoitiin ennalta suunniteltuihin testisetteihin.

Jarkon testaustiimi käytti noin 4000 testitapauksen speksattua joukkoa. Testitapaukset oli jaoteltu erillisiin testisetteihin ohjelmiston osa-alueen mukaan. Yhden testisetin ajaminen vei aikaa tiimiltä kolme päivää. Ongelma tässä oli se että buildiautomatiikka teki aina uuden releasen joka yö. Kun yksi testikierros valmistui, sen tulokset tulivat kaksi päivää myöhässä. Kaksi uutta rellua oli jo ehtinyt tuutista ulos. Testitulosten parasta ennen päiväys siis meni jo!

”Tämähän ei varsinaisesti kuulosta ongelmalta!” totesi projektipäällikkö. Jarkko kuitenkin laski että  testikierroksen loppusuoralla löytynyt vakava integraatiobugi voi pahimmassa tapauksessa aiheuttaa kolmen päivän töiden reverttauksen versionhallinnasta. Pahimmassa tapauksessa töitä saattoi mennä hukkaan jopa 8 developperin ja 3 testaajan, eli 33 miestyöpäivän verran! ”Kalliiksi tulee” -perusteli Jarkko.

Jarkko ja testaustiimi olivat onneksi tiedostaneet riskin hyvissä ajoin ja etsivät aktiivisesti ratkaisua ongelmaan jo ennen kuin projektijohto asian ymmärsi. Tiimille oli projektin alussa valittu kätevä testauksenhallintajärjestelmä, jossa testisettejä ei ollut pakko rakentaa ennalta. Niitä pystyi muodostamaan dynaamisesti tarpeiden mukaan. Kun pullonkaulat projektissa lopulta ymmärrettiin ja ratkaisun löytämiseen allokoitiin vielä lisäresursseja, tiimi ryhtyi ripeästi toimeen:

Testauksenhallintajärjestelmä integroitiin buildiautomatiikkaan siten että aina uuden buildin valmistuessa, testausjärjestelmään luotiin automaattisesti uusi testauksen kohde (release). Jokainen testitapaus piti sisällään jo ennalta tiedon siitä millä releasella kyseinen testi oli viimeksi tehty. Yksittäiselle testitapaukselle voitiin siis näin muodostaa myös ”parasta ennen” -päiväys. Tämän jälkeen joka aamu tiimi rakensi päiväkohtaisen testaussuunnitelman ja testisetit dynaamisesti. Testisettien rakennuksen kriteereinä olivat:

  1. top-10 testitapaukset, eli järjestelmän ylläpitämän kirjapidon mukaan kymmenen eniten virheitä löytänyttä testitapausta
  2. aikaisemmin epäonnistuneet testitapaukset, jotta nähdään onko tullut parannuksia aikaisempiin releaseihin
  3. releasen muutoskohteet, eli testauksen riskipohjainen suunnittelu
  4. ”parasta ennen” -päiväyksen eniten ohittaneet testitapaukset ja lopuksi
  5. tutkiva testaus

Näin toimiessa testaustiimillä oli jatkuvasti ajantasaisempi kuva lopputuotteen kypsyydestä ja siitä millä osa-alueilla kaivattiin eniten korjauksia. Kriittisimmät virheetkin saatiin kiinni keskimäärin työpäivää aikaisemmin, kun ei väkisin väännetty ennalta suunniteltuja testisettejä samassa järjestyksessä kuin aina ennenkin. Muutosten toteutus oli lopulta niin onnistunut että firma päätti muuttaa testauksen toimintatapoja muissakin projekteissa samaan suuntaan.

Kuinka usein teillä on paukutettu aina saman regressiotestisetin alkupäätä päivän verran ja löydetty sitten testauksen keskeyttävä virhe viimeisestä kolmanneksesta testitapauksia? Aika ärsyttävää sanon minä. Usein vanhassa mallissa pysytään siksi että joku haluaa menneisyyden testimetriikat vertailukelpoisiksi tulevien testikierrosten kanssa. Tästä syystä testsetin muuttaminen on joskus niin pirullisen työläs prosessi. Unohda perinteinen:

Saat väistämättä testauksestasi enemmän irti kun avaat toimintaympäristön ja testispeksit muutoksille. Huolehdi siis aivan aluksi että testaus saa tehokkaammin ja aikaisemmin bugit kiinni ja vaivaa päätäsi vasta lopuksi metriikoilla. Näin myös lopputuotteesi kiittää!

Testaus 2010 -seminaari oli ketterä

17. helmikuuta, 2010 | Kirjoittaja: Antti Niittyviita
Kommentit: 5

Minä pidän seminaareista. Niissä tapaa uusia ihmisiä ja puheenvuorotkin onnnistuvat yleensä herättämään paljon hyviä ajatuksia. Tästä kirjoitan siksi että pistäydyin viime viikolla Helsingissä Tieturin Testaus 2010 -seminaarissa. Tapahtuma oli ehdottomasti antoisa ja puhujat alan huippuja. Tapahtumassa palkittiin myös vuoden testaaja Tero Jyrinki Enderolta. Onnittelut hyvästä työstä Terolle!

Seminaariohjelman puheenvuoroista eniten ajatuksia herättivät Logican Bob Verhoeffin puheenvuoro riskipohjaisesta testauksesta sekä Qentinelin Katja Kuusikummun esitys testauksen mittaristojen valitsemisesta. Näistä aiheista keskustellaan blogin tulevissa numeroissa enemmän. Tilaa siis feedi nyt!

Mutta sitten itse asiaan. Tämänkin seminaarin teemoissa toistui aihe ketterä testaus: ”Löytyykö oikopolkuja ketterään testaukseen?”, ”Ketterän testaustoimintatavan käyttöönotto ja sen vaiheet”, ”Agile testing in real life”. Ketterä on selkesäti trendikästä, ketterästä kuulee jokaisessa seminaarissa, ketterää puskee jokaisesta tuutista, ketterää, ketterää ja ketterää.

Ketterää.

No huhhuh. Ketterästä huolimatta testaukselta halutaan useimmiten vankkaa ja uskottavaa dataa projektista. Kuten Katja seminaarissa kertoi, testauksen tulee pystyä esittämään tarkkoja metriikoita projektissa edistymisestä, lopputulosten laadusta ja jopa rahasta. Miten ihmeessä näitä asioita voidaan mitata kattavasti, jos palautetaan mieleen:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Eikö asioiden mittaaminen nimenomaan vaadi vähintäänkin hyviä prosesseja ja toimivia työkaluja? Eikö asioiden mittaaminen vaadi hyvää dokumentointia ja päälle ripauksen suunnitelmallisuutta? Melkoinen dilemma selvitettäväksi sanon minä. Asiasta on helppoa puhua ja sitä on helppoa vaatia. Ja kyllähän se myös joskus toimiikin.

Ennen seuraavaa projektia kannattaa kuitenkin todeta että SEIS, hengähtää hetki ja miettiä:

Kaikki ei sovi samaan yhtälöön. Jos vaadit tiimiltäsi todellista ketteryyttä, se tapahtuu vähintäänkin metriikoiden kustannuksella.

Testaaja on myös myyntimies

11. helmikuuta, 2010 | Kirjoittaja: Antti Niittyviita
Kommentit: 1

Työntekijämme Heimo (nimi muutettu) työskentelee edistyksellisessä softaprojektissa, jossa on kymmentä developperia kohti kokonaista kolme testaajaa. Projektin laadunvarmistus toimii tutkivan testauksen periaatteilla eikä Heimo ole koko projektin aikana joutunut testispeksien kanssa tekemisiin kertaakaan. Se on mielenkiintoista vaihtelua kokeneelle testausgurulle. Projektin tuoreinta softareleasea on hierottu nyt pari viikkoa ja ensi viikolla rellu pitäisi saada ulos.

Heimo tietää kuitenkin että softassa on muutama vakava vika, jotka hän on raportoinut jo aivan tämän releasekierroksen alussa. Vikoja ei vain jostain syystä ole otettu vielä korjattavaksi. Heimo on kuitenkin fiksuna miehenä tutustunut viallisesta osa-alueesta vastaavaan developeriin kahvihuoneessa ja työpisteessä ihan vieressä istumallakin. ”Kas tässä se vika nyt sitten olisi”.

Vaikka vikaa ei ole vielä korjattu, Heimo ei ole eskaloinut asiaa ylemmäs projektimanagementille. Hän pystyy perustelemaan virheen seuraukset tuotteelle, maksajalle ja loppukäyttäjälle. Lisäksi hän pystyy eliminoimaan yksi kerrallaan esteet vian korjaamiselle tarjoamalla riittävästi tietoa viasta ja mahdollisesti myös debug-informaatiota.

Koska Heimo on hyvä tyyppi ja pidetty mies projektissa, perustelut otetaan vakavasti ja lopulta vika korjataan. Heimo sai haluamansa, tuotekehitys ei joutunut napit vastakkain testauksen kanssa eikä vastaava developeri joutunut selittelemään managerille miksi vikaa ei korjattu. Kaikki tämä kiitos fiksun lähestymisen. Vaan eikös kuulostakin ihan myyntityöltä?

Softanmurskausta -blogin Teemu Vesala kirjoitti aiheesta ”Laatukonsultti -mikä se on?”. Lista oli pitkä ja täyttä asiaa. Tuohon listaan minä lisäisin että testausguru on myös tuotekehittäjän tukihenkilö ja hyvä myyjä. Kovan luokan testaaja osaa myydä näkemyksensä tuotteen edusta developereille ja managementille ja silti säilyttää ”asiakassuhteensa” devauksen kanssa hyvänä ja lämpinänä.

Testaaja: Perustele hyvin syyt virheenkorjaustarpeelle ja poista yksi kerrallaan korjaamisen esteet. Näin teet myyntityötä joka edistää lopputuotteen etua ja helpottaa myös sinun elämääsi.


Yhteisön älykkyys ajaa aina edelle

3. helmikuuta, 2010 | Kirjoittaja: Antti Niittyviita
Kommentit: 4

Olipa kerran messut. Messujen vetonaulana oli arvontastandi huikeilla palkinnoilla. Koko homman keskiössä oli iso purkki täynnä ranskanpastilleja, josta pastillimäärän tarkimmin arvannut henkilö tietysti voittaisi palkinnon. Useimmat messuvieraat totesivat homman olevan täyttä arpapeliä.

Messupäivän aikana standilla kävi tuhat ihmistä tekemässä omat arvauksensa. Jokainen arvasi tietysti parhaan kokemuksensa mukaan. Ständille saapunut Jaakko oli kuitenkin fiksu kaveri. Hän ei heittänyt omaa arvaustaan kehiin heti vaan seurasi päivän ajan muiden arvioita ja lopulta voitti pääpalkinnon.

Jaakko oli lukenut James Surowieckin kirjan The Wisdon of Crowds. Hän toimi seuraamalla koko arpajaisyhteisön vastaukset ja muodosti sen perusteella oman mielipiteensä. Arpajaisyhteisön kollektiivinen mielipide osui tarkemmin kohdalleen kuin yhdenkään yksittäisen asiantuntijan lausunto pastillien määrästä. Kuinka usein sinä olet törmännyt työelämässä Jaakon lähestymistapaan?

Testaajan näkökulmasta näin ihan kärkeen tulee mieleen projektien error-palaverit, joissa muutama projektin viisas käy viikon virhelistan läpi arvioiden mm. virheiden vakavuutta, vaikutusta loppukäyttäjään tai korjauksen työmäärää. Arviot virheistä toki ovat asiantuntijoiden tekemiä, mutta voisiko kehittäjäyhteisöä hyödyntää arvion muodostuksessa tarpeeksi helpolla tavalla?

Mielipiteen kysyminen tuntuu työläältä ja palavereihinkaan ei kannata kutsua koko kööriä äänestämään. Mielipiteen antamisen voi silti tehdä helpoksi kuten Taloussanomat tekee kommenttiosastollaan. Siellä lukija voi kertoa oliko kommentti hyvä vai huono naksauttamalla jompaa kumpaa peukkua:

Hyvä vai huono juttu?

Hyvä vai huono juttu?

Vastaavanlainen toiminnallisuus olisi omiaan rankkaamaan virheraportteja kun tuoreimmat rapsat listattaisiin esimerkiksi projektinhallinnan etusivulle tai testauksenhallinnan dashboard-näkymään. Järjestelmään, joka on yhteinen ja aktiivisesti käytössä koko projektihenkilöstöllä. Samainen toiminnallisuus on helposti laajennettavissa virheraporttien arvioinnista myös testitulosraportteihin, testisetteihin tai jopa projektin vaatimustenmäärittelyyn.

Sorry, there are no polls available at the moment.