Avainsanat: ‘testaus’

Avoin työpaikka: Kivireen vetäjä

perjantai, 9 joulukuuta, 2011 | Kirjoittaja: Antti Niittyviita

Prove on kotimainen talo täynnä ohjelmistotestauksen guruja. Ammattitaitomme salaisuus löytyy tuskasta ja pitkistä työpäivistä! Ruoskimme itseämme ja toisiamme päivästä toiseen kohti suurempia voittoja. Gurumme metsästävät bugeja ympäri Suomen (mm. Oulussa, Tampereella ja Helsingissä). Pitsinnypläys ja tyhjänpäiväinen papereiden pyörittely ei meitä kiinnosta. Me tähtäämme todellisiin tuloksiin.

Proven guruilla on jo muuten Suomi hyppysissä, mutta viimeinen sokea pisteemme löytyy etelästä. Siksi etsimme testauksessa gurunviittaa jo kantavaa hengellistä johtajaa julistamaan testauksen ilosanomaa pääkaupunkiseudulla. Liikevaihtomme (2011 reilu miljoona) on kasvanut 100%:n tahdilla viime vuosina ja haluamme ylittää itsemme puristamalla kaikista vielä pikkuisen enemmän.

Barona IT hakee Provelle siis jämerää ja kaukonäköistä vetäjää Helsinkiin perustamaan ja johtamaan pääkaupunkiseudun toimintoja. Nykyinen Proven pääkaupunkiseudun henkilöstö siirtyy heti yksikönvetäjän alaisuuteen. Hävytön ote sekä hyvät puheenlahjat ovat avaimia tehtävässä menestymiseen.

Prove tarjoaa:

  • Vaarallista ja kovaa menoa sekä tuskantäyteisiä työtunteja!
  • Juuri ja juuri riittävää palkkaa
  • Jos homma onnistuu, luvassa on mainetta ja mammonaa

Edellytämme, että:

  • Osaat puhua testauksesta aivan kuin tietäisit siitä jotain
  • Et puuhaile joutavia vaan osaat keskittyä olennaiseen
  • Osaat rohkeasti olla eri mieltä etkä pelkää sanoa sitä
  • Pärjäät ainakin yhden erän painissa toimitusjohtajamme Antin kanssa

Tärkeimmät tehtäväsi ovat:

  • Rekrytä hyvän Auran omaavia uusia Guruja(tm) Proven riveihin
  • Viedä testauksen ilosanomaa uusille asiakkaille

Jos meininki tuntuu hyvältä ja muut reunaehdot täyttyvät, olet etsimämme henkilö! Työpaikka täytetään välittömästi oikean henkilön löydyttyä. Lisätietoja tehtävästä antaa HR-konsultti Kristiina Aksberg, 050 413 1441 tai kristiina.aksberg@barona.fi

Hae paikkaa viimeistään 02.01.2012 mennessä klikkaamalla tästä.

Lisätietoja tehtävästä: kristiina.aksberg@barona.fi , +358504131441

Share

Nyt olemme myös Facebookissa

keskiviikko, 7 joulukuuta, 2011 | Kirjoittaja: Antti Niittyviita

Ohjelmistotestaus.fi löytyy nyt myös Facebookista. Käy siis tykkäämässä ja tilaa tuoreimmat päivitykset suoraan seinältämme! Samalla saat juttuvinkit kuumimpiin testausaiheisiin uutisiin maailmalta.

Share

Testaus ja laadunvarmistus napit vastakkain

torstai, 9 kesäkuuta, 2011 | Kirjoittaja: Antti Niittyviita

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ä.

Share

Kuinka hankalaksi takuukorjauksen voi tehdä?

tiistai, 17 toukokuuta, 2011 | Kirjoittaja: Jussi Niittyviita

Hyvin hankalaksi, on oikea vastaus. Sain asiakaspalvelukokemuksen siivittämänä ajatuksen kirjoittaa juuri sattuneesta tapahtumasta. Tapahtuman kulku on seuraavanlainen:

Kävin ostamassa Anttilasta uudenkarhean ja laadultaan peruskäyttöön välttävän Samsungin dvd-soittimen. Soittimessa ilmeni yllättäen selkeästi käyttäjästä riippumaton virhe: soitettaessa dvd-(tai cd-)levyn trackit saattavat välillä hypätä kokonaan seuraavalle kesken trackin toiston.

Tästä pienestä ja satunnaisesti toistuvasta viasta johtuen kiikutin soittimen takaisin Anttilaan vaatien takuukorjausta. Vähäpätöisesti asiakkaaseen suhtautuen tekniikan osaston myyjä yritti vääntää kättä viimeiseen asti, että kyseessä olisikin vain käyttäjän naarmuinen cd-levy. Yllättävän kovan kädenväännön jälkeen vedin viimeisen kortin hihasta ja kerroin myyjälle: “Olen tietotekniikan diplomi-insinööri ja ammatiltani ohjelmistotestaaja. Olen vakuuttunut, että vika on laitteessa.” Ääni muuttui nopeasti kellossa ja laite otettiin korjaukseen. Liekkö ensimmäinen kerta historiassa kun diplomi-insinöörin tutkinnosta on konkreettista hyötyä? ;)

Reilun kuukauden päästä olin jo lähes unohtanut omistavani dvd-soittimen, kun Anttilasta kilahti tekstiviesti Nokialaiseen.  “Tuotteenne on saapunut korjauksesta ja valmis noudettavaksi.” Hain soittimen ja kotona avasin korjaussaatteen sisällön: Firmware päivitetty. Ajattelin OK, saattaahan moinen virhe korjaantuakkin firmwaren päivityksellä. Aloin heti koestamaan soitinta niin eiköhän se taas muutamien Pink floydin rallattelujen jälkeen pompannut seuraavalle trackille kesken hyvän fiilistelyn! Liekköhän Infocaren (Oulun Anttila ulkoistaa tuotekorjauksensa nähtävästi sinne) pojat eteläisessä Suomessa olivat edes testanneet virheen toistuvuutta. Eikun takaisin Anttilaan laite kainalossa. Tällä kertaa soitin otettiin mukisematta korjaukseen.

Parin viikon kuluttua Nokialaiseen kilahti tekstiviesti, jossa pyydettiin asiakasta lähettämään mallilevy Infocarelle, jotta virhe saataisiin toistettua. Viestissä ei ollut minkään valtakunnan tietoja postitusosoitteesta, sähköpostiosoitteesta tai asiaa käsittelevän henkilön nimestä. Viestin loppuun ladattiin vielä ultimaattum: mikäli asiakas ei lähetä mallilevyä 7 päivän kuluessa laite postitetaan takaisin siten, että asiakas maksaa kustannusarviomaksun ja lähetyskulut. Kovin asiakasläheistä toimintaa!

Tapahtuman kulku on tänään viestin saapumispäivänä edelleen auki.

Äkkiä aiheesta herää kysymyksiä. Kuinka perinpohjaisesti Infocaren pojat ovat eteläisessä Suomessa yrittäneet varmistaa virheen oikeellisuutta? Millä logiikalla on halvempaa lähettää laite korjaukseen Oulusta Helsinkiin kuukauden ajaksi, jotta siihen tehtäisiin ainoastaan 5 minuutin firmwaren päivitys? Onko todellakin valmistajan, myyjän tai korjausfirman etu, että asiakasta uhkaillaan postikuluilla, kun kaikki olisivat selvinneet helpommalla vain antamalla toinen laite tilalle?

Kun asiaa ajattelee tuotteen valmistajan Samsungin kannalta tuntuu pahalta. Virheen hinta pääsee moninkertaistumaan näin älyttömän ja tehottoman takuukorjausmenettelyn ansiosta. Kulujen karsimiseksi tulee mieleen kaksi vaihtoehtoa. Ottaa bugit kiinni jo tuotekehityksessä tai alkaa runnomaan korjausputkea paremmaksi.

Koko tarina kiteytyy vinkiksi valmistajalle:

Käyttäjä voi olla tuotteesi parissa 24/7. Et voi olettaa, että yksittäinen korjaaja pystyy havaitsemaan satunnaisesti tapahtuvan virheen parin minuutin (tai tunninkaan aikana). Virhettä ei kannata asettaa lyhyen tarkastelun jälkeen ignored-tilaan mikäli se toistuu vain satunnaisesti. Välinpitämättömyys kostautuu kalliisti.

Share

Askel kerrallaan kohti toimivaa testausta

torstai, 5 toukokuuta, 2011 | Kirjoittaja: Antti Niittyviita

Kun testaus puuttuu tai se ei toimi, ongelman myöntäminen on yhtä tuskaa. Yleensä se paljastuu vasta kun tavara on jo osunut tuulettimeen. Edelleenkin liian usein puhelin soi meidän toimistolla kun huonot on jo housussa.

Meiltä puuttuu toimiva testaus. Miten tässä nyt kannattaa toimia?

Koska epävarmuus niin usein kalvaa toimivan testauksen rakentajaa, ne ensiaskelet jäävät ottamatta. Vasta pakko pistää liikettä niveliin. Silloin asiakas hengittää jo niskaan ja softakehittäjän aika palaakin yllättäen virheiden korjailuun.

Me päätimme tarjota ilmaisen opetuksen siitä, miten toimiva testaus voidaan rakentaa sopivan pienistä rakennuspalikoista.

  1. Kehitä: Rakenna softakehittäjien kanssa säännöllinen elämänrytmi. Jotain testattavaa on tultava tuutista ulos usein. Ilman tätä ei ole mitään järkeä investoida testaukseen.
  2. Resurssoi: Palkkaa riittävän kokenut testausosaaja tai osta palvelu partnerilta. Pääasia on, että tyyppi on oikeasti testaaja, eikä vain huono devaaja!
  3. Testaa: Polkaise hommat käyntiin tutkivan testauksen menetelmällä. Asiakkaasi elämään vaikuttavien vikojen löytyminen mahdollisimman aikaisin on oikeasti se, mihin kannattaa investoida heti!
  4. Rakenna: Tuo mukaan uusia työkaluja. Paranna testauksen- ja virheidenhallintaa. Rakenna systemaattinen tapa toimia esimerkiksi tarkistuslistoilla. Voit pohtia myös automaatiota.
  5. Tiivistä: Tiivistä kuilua kehityksen ja testauksen välillä. Tähtää testauksessa pitkistä vesiputouksista lyhyisiin tai Agileen.
  6. Mittaa: Rakenna enintään kolme helppokäyttöistä mittaria softan laadun arviointiin. Meidän mittarimme perustuvat kaikki virhetietoihin.
  7. Optimoi: Säädä testauksen määrää asteittain kunnes optimaalinen taso on löytynyt.

Hoitamalla yhden asian kerrallaan pääsee softakehityksessä jo pitkälle. Näiden askelmerkkien avulla on mahdollista rakentaa täysin uusi ja laadukas näkökulma ohjelmistojen rakentamiseen alle kuukaudessa.

Voit rakentaa toimivan testauksen pienistä osatavoitteista. Sinun on vain otettava härkää sarvista ja ryhdyttävä toimeen!

P.S. Jos alkuun pääseminen tuntuu vinkeistä huolimatta hankalalta, voit tilata meiltä Kick-offin. Me hoidamme kohdat 1.-4. pois kuleksimasta vain kahdessa viikossa! Sinun ei tarvitse osallistua kuin aloitustapaamiseen ja loppukatselmointiin.

Share