Softan laatu on liiketoiminnan kannalta toisarvoista
Ydinvoimalan suunnittelu- ja rakennusvaiheessa turvallisuustekijät ovat aivan oleellisessa asemassa. Työmailla on erikseen nimetyt henkilöt, jotka tarkastavat muiden tekemän työn. Kavereiden tulee olla kokeneita ja asiansa osaavia.
Auton voi katsastaa ainoastaan pätevä henkilö. Autoinsinöörin koulutus, työkokemusta, katsastuksen erikoiskurssit jne pätevöittävät tehtävään. Nollakoulutuksella ei pääse töihin.
Sähkötyömailla on nimetty vastuuhenkilö, joka tarkastaa kytkentöjen turvallisuuden. Ja kuittaa pöytäkirjat omalla nimellään.
Lääketieteellisiin toimenpiteisiin vaaditaan tietty pätevyys.
Kaikki edellämainitut asiat ovat yleisen turvallisuuden kannalta oleellisia, joten laadunvarmistuksen tulee olla huippuluokkaa. Mahdolliset virheet voivat johtaa kuolemiin, joten laaduntarkkailu on erityisen ymmärrettävää.
Entäs nämä:
Viskin- ja viinintuottajat ovat erityisen tarkkoja tuotoksiensa laadusta. Laaduntarkkailusta vastaavat henkilöt ovat omaan asiaansa vihkityneitä ja pitkän kokemuksen omaavia. Mieleen tulee valkopartainen ukkeli. Huono laatu voidaan myydä bulkkituotantoon, mutta oman brandin alla nitä ei markkinoille päästetä. Vaikka juoma päähän menisikin.
Musiikkiteollisuudessa levy-yhtiön edustajana toimii tuottaja. Tuottaja on se henkilö, joka vahtii levyn laatua aina biisien tekemisestä nauhoitukseen ja miksaukseen. Sisäinen laaduntarkkailija siis. Harvoin ihan kokemattomia kavereita.
Kummassakaan ei ole kysymys ihmishengistä, vaikka huono musiikki tai hapokas viini voivat joskus tympäistäkin.
Miten laadunvarmistuksen tärkeys näkyy ohjelmistojen kehityksessä?
- Meillä ei ole alalle valmistavaa yliopisto-/AMK-koulutusta
- Testaustehtäviä pidetään porttina oikeisiin kehitystehtäviin (“Noo, testaile nyt tämä kesä, katsotaan ensi kesänä sitten koodaushommia.”)
- Testaajien urapolku tyssää käytännössä testimanagerin tehtäviin. Seuraava askel on projektipäällikkö. Testausalan osaaminen ei pääse kehittymään.
- Testaajan palkka on saman työkokemuksen omaavaa koodaajaa reilusti huonompi
Ja edelleen puhutaan henkilöistä, joiden tulisi arvioida toisten työn tuloksia kriittisesti.
Softafirman väittäessä laadun olevan tärkeää, kannattaa kysyä miten se näkyy laadunvarmistajien arvostuksessa. Kohdellaanko testausta naapurin vähäpoikana, jota tuotekehityksen isot pojat pitävät lähinnä riesana? Vai pyydetäänkö testaus tasavertaisena peliin mukaan? Miten teillä?
Suosittelemme myös:
Laatu ei takaa tulosta
Olen istunut testaajan tuolilla samaan aikaan kun kehittäjäkollega käytävän toisella puolella hieroi kahta koodiriviä kuusi tuntia. Ratkaisu ei...
Mikä on kun ei taidot riitä?
Ilma oli sakea, tunnelma tiivis ja noin 100 kilttiä koululaista nojautui kuuntelemaan väkeviä tarinoita myynnin ihmeellisestä maailmasta. Istuin...
Herrat, juuri näin.
Otsikkonne on toki raflaava, mutta valitettavasti myös totta.
Liiketoiminta on rahantekoa. Yrityksen tehtävä on tuottaa voittoa omistajilleen. Tärkeintä siis on se, että viivan alla on euroja ja se jaetaan osinkona. Tätähän sijoittajat ja omistajat yhtiöltä hakevat.
Laatu taas on vaikea käsite. Ihmisillä kun on niin erilainen ymmärrys koko sanasta. Toiset ostavat oikeasti laadukkaita (ja usein kalliita) laitteita ja ovat tyytyväisiä. Toiset taas ostavat pilipali-radion Tokmannista. Jotkut ovat jopa sitä mieltä, että Joopajoo -merkkinen stereosoitin on laadukas, koska se on ostettu kalliilla rahalla Stockmannilta. Kyse on mielikuvasta ja Stockmann tekee tyytyväisenä rahaa! Ostajat jopa sietävät sen, että laitteen toiminnassa on kummallisuuksia, koska se on ostettu laadukkaasta liikkeestä, joka “ei myy huonolaatuisia tuotteita”. Pelkkää mielikuvaa, parahin Watson.
Laatu ei ole pelkkiä testaajia. Se on kokonaisuus, jolla softa valmistetaan. Työntekijämarkkinoilla on aina pulaa uusimman asian kokeneista osaajista (esim. gurukoodareista). Hyviä testaajia sen sijaan markkinoilla kuitenkin on. Ja kuten tiedätte, kun markkinoilla on “tuotetta” vain vähän sen hinta nousee ja päin vastoin.
Takaisin kuitenkin rahaan: kuten herra Sakaranaho on itse aiemmassa kirjoituksessaan todennut (11.11.2009), etsivät yritykset kulujen optimointia myös laadussa. Jos siis softan laatu on tavaran kaupaksimenon kannalta toisarvoista, niin silloin otsikkonne pitää paikkansa. Tällöin myös Talouspäällikkö on tyytyväinen, kun voi entisestään pienentää laadunvarmistuksen budjettia, irtisanoa pari henkilöä ja viivan alle jää taas enemmän. Mutta vikahan ei ole Talouspäällikössä, vaan niissä, jotka hyväksyvät huonon laadun ja ostavat silti. Softa-alalla voi kaiken lisäksi ensin myydä puolivalmiin softan ja sitten käydä sitä rahalla korjaamassa. Tuplakate. Ei huono.
Kysymys on siis siitä, mihin keskitytään. Jos tuotetaan laatuviiniä, huolehditaan laadusta rahalla ja liimataan etikaksi muuttuneisiin pulloihin eri etiketti. Tärkeintä on, että viivan alla on plussaa ja omistajat ovat tyytyväisiä. Niin kauan kuin löytyy huonon softan ostajia, niin myös huonompilaatuinen bisnes kukoistaa. Miksi siis turhaan parantaa laatua, kun tavara menee kaupaksi näinkin.
Mistä siis lähtee muutos? Pitäisikö mielestänne yritysten vain ruveta panostamaan laatuun, kuluista huolimatta, vaikka markkinat eivät tätä vaadikaan?
Tässäpä pohdittavaa.
Talouspäällikköltä hyviä pointteja. Ihan ensimmäisenä on myönnettävä, että yhdistin laadun ja testauksen turhan suorasukaisesti samaksi asiaksi. Näinhän ei tietenkään ole. Testauksen tehtävänä on varmistaa, että kokonaisuus (prosessit, tekninen osaaminen jne) toimii.
Muuten aletaan olla asian ytimessä. Asiakkaan tarve on avainasemassa. Talouspäällikkö vertaa Stockmannia ja Tokmannia. Satuin tänään käymään Tokmannilla siivoustarvikeostoksilla. Siellä ei missään mainostettu “laatua”. Jopa mainos muovipussissa kertoi, että “Ostin kun halvalla sain!”. Stockmannin brandi on puolestaan lupaus laadusta. Ja se lupaus pääsääntöisesti myös lunastetaan, usein Tokmannia kovemmalla hintatasolla tosin. Eittämättä Stockmann panostaa laatuun aivan eri tavalla, kuin Tokmanni. Toisaalta Tokmanni ei missään väitä olevansa erityisen laadukas kauppa. Molemmilla on omat kohderyhmänsä, hyvä niin.
Hyvä kysymys onkin, että miksi softan ostajat suostuvat ostamaan “Tokmannin laatua” “Stockmannin hinnalla”. Tähän liittyy myös Talouspäällikön toteamus puolivalmiin softan myynnistä ja sitten korjauksista rahastamisesta. Onko softan ostajien osaaminen niin puutteellista, että näin voidaan toimia? Ilmeisesti.
Talouspäällikkö kyselee, että mistä muutos lähtee. Väitän, että muutos lähtee pakosta. On laskeskeltu, että virheen korjaaminen “valmiiseen” tuotteeseen jälkikäteen maksaa monta kertaa enemmän, kuin testauksen aikana löydetyn virheen korjaus. (Googleen “cost of fixing defects” ja löytyy paljon matskua) Kun softan ammattimaiset ostajat oikeasti sisäistävät asian, tullaan laadunvarmistustyön arviointiin käyttämään ostajan puolelta varmasti paukkuja. Sehän säästää rahaa! Tätä kautta myös myös softan toimittajien pitää keskittyä asiaan.
Riittävä laatu on aina loppukäyttäjän tai ostajan kokema laatu. Mutta. Oikein tehdyllä testauksella ja laatutoimilla saavutetaan laatu vähemmällä työmäärällä. Rahaa säästyy. Myös Talouspäällikkö on tyytyväinen.
Huono laatu voi mennä kaupaksi. Mutta sen markkinoiminen hyvälaatuisena aiheuttaa varmasti hankaluuksia.
Ottaisin kantaa tuohon testaajien arvostukseen. Nyt 2000-luvulla ollaan tultu softatestauksessa jo iso harppaus eteenpäin ja monikin iso ja pienempikin yritys on alkanut panostamaan testaukseen ja testaustekniikoiden kehittämiseen. Arvostuksessa on kuitenkin vielä matkaa jäljellä koodaajiin verrattuna.
On hyvä, että asiasta puhutaan, mutta myös me testaajat voimme tehdä asialle paljonkin. Otetaan rohkeasti vastuuta projekteissa! Kun projektijohto ja koodaajatkin huomaavat, että he voivat todellakin luottaa testaukseen ja testauksen toimittamiin raportteihin, niin vastuu lähtee nousuun ja sanon tämä oman kokemuksen tuomalla varmuudella.
Osa projektien johtajista ei ole koskaan nähnyt toimivaa testausta ja osa taas saattaa kokea testauksen jopa aikaa vievänä ylimääräisenä rasitteena. Tämmöisessä tilanteessa testaukselle ei anneta riittävästi vastuuta ja silloin se ei motivoi testaajia ja kukaan ei oikein viitsi tehdä muuta kuin sen minimisuorituksen.
Yllätetään siis todellisen testauksen voimasta tietämätön managementti ja toimitetaan niille sellaiset tulokset että ei jää testattavan tuotteen status epäselväksi ja koodaajille kunnolla kirjoitetut bugiraportit, niin voin kertoa, että homma alkaa toimimaan ja eipä aikaakaan kun huomaa, että koko projekti alkaa pyörimään testauksen ympärillä ja niinhän sen pitääkin olla… ainakin jos ammattitestaajalta kysytään 😉
Herra Sakaranaholle on syytä kommentoida, että aina kun rahaa säästyy lisää viivan alle, Talouspäällikkö on tyytyväinen!
Summauksena siis voinemme varmaan yksissä tuumin todeta, että laatua on syytä parantaa – ei vain lisätä testaamista. Ja parannetaan myös testauksen laatua! Otetaan käyttöön uusia tekniikoita, työkaluja ja tehokkaampia testausmenetelmiä. Näinhän alalla nykypäivänä tehdään tavoitteena kulujen karsiminen, laadusta tinkimättä.
Uudet menetelmät kuitenkin herättävät mielenkiintoisen kysymyksen: Milloin testaaja muuttuu koodariksi? Nykyiset ketterät menetelmät suosivat jatkuvaa integrointia ja automaattista testausta. “Perustestausta” pyritään tekemään minimoimaan. Asiakkaat haluavat mielummin töihin testaajia, joilla on edes vähän koodauskokemusta. Mutta muuttuuko testaaja siis koodariksi, kun hän alkaa kirjoittamaan scriptejä ja ohjelmia, jotka testaavat ohjelmistoa? Vai onko kyseessä kokonaan uusi osaamisen taso, “testauskoodarit”?
Tässäpä aiheenjuurta tuleviin blogeihinne. 😉
Anonyymi omassa kommentissaan kertoi, että projektien pitäisi pyöriä testauksen ympärillä. Anonyymille täytyy vinkata, että Extreme Programmingin voidaan kärjistetysti ajatella olevan juuri sellainen kehitysmalli, joka näin jo tekee! Siinä yksikkötestaus, integraatiotestaus ja hyväksyntätestaus ovat koko kehityksen avaimet. Nyt siis vain kauppaan ja hyvä XP kirja sille teidän managerille nenän eteen.
Talouspäällikön kommentista sain oikein hyvän idean (omasta mielestäni hyvän). Itsehän olen XP:n suuri ystävä ja aiheesta kertovan kirjan antaminen luettavaksi managementille tuntuu järkevältä. Mutta miten voisin kirjan antaa managementille luettavaksi ilman, että samalla tulen viestittäneeksi, että “prosesseissa on parantamisen varaa” tai että “nykyinen prosessi haisee”.
Saamani idea on siis se, että käytän tulevaa pikkujouluaikaa hyväkseni! Pikkujouluissahan perinteisesti jaetaan yllätyslahjoja ja niimpä solmin lahjoja jakavan pukin kanssa pienen liiton(sala) ja näin varmistan, että XP-kirja menee oikealla managerille. Näin manageri on iloisesti siinä uskossa, että XP-kirjan tuleminen hänelle joululahjana oli yksi monista joulun ihmeistä 🙂
Ideaani saa vapaasti käyttää tulevissa pikkujouluissa ja modifikaatiot ovat myös luvallisia, mutta silloin pitää oma modifikaatio jakaa muiden kanssa! Eli kyseessä niin sanottu open source -pikkujouluidealisenssi 😉