Arkisto: marraskuu 2009



Softan laatu on liiketoiminnan kannalta toisarvoista

25. marraskuuta, 2009 | Kirjoittaja: Jaakko Sakaranaho
Kommentit: 5

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

Ammattilaisuuden alasajo?

18. marraskuuta, 2009 | Kirjoittaja: Antti Niittyviita
Kommentit: 6

Tuli kannattavammaksi myydä sutta halvalla kuin laatua kalliilla! Lepää rauhassa ammattimies!

…kirjoitti Markku Saksa Taloussanomien kolumnissaan näin ajettiin ammattimies alas. Nykytrendi tosiaankin tuntuu olevan nopea tuoton tavoittelu laadun kustannuksella. Onko testaaminen siis enää kannattavaa? Ylilaadun ja riittävän laadun rajat molemmat liikkuvat huonompaa kohti. Loppuasiakaskin on alkanut tyytymään siihen mitä tarjolla on.

Itse en koskaan osta kodintekniikan tuotteista ensimmäistä versiota. Mieluummin odotan että tuote on kunnolla testattu ja pahimmat viat on ehditty korjaamaan. Kaupassakin tsekkaan aina tarrat useampien pakettien kyljestä kuten parasta ennen päiväyksen maitopurkista. Tsekkaapa ensikerralla huvikseen tietoja usb-kovalevystäsi tai reitittimestäsi kaupan hyllyssä. Vertaile sarjanumerotarrojen tietoja. On jännää huomata kuinka monta eri versiota saman mallin tuotteesta voi hyllystä löytyä. Testausta on ulkoistettu loppukäyttäjälle. En tykkää!

Ammattilaisutta ei minusta silti ole ajettu täysin alas. Nykyammattilaisuutta on keskittyä oikeisiin asioihin.

Apple teki minusta ovelan tempun laadunvarmistuksen näkökulmasta puhelinbisneksellään. Koko tuotekehitys on silmin nähtävästi lähtenyt siitä että loppukäyttäjälle tarjotaan positiivisia käyttäjäkokemuksia. Todellisuudessa iPhonen taustalla oleva toiminnallisuus ei ole niin hyvää. Tyypihyväksyntätestit takkuavat ja operaattoria ahdistaa kun yksi iPhone saattaa kerralla varata kymmenien puhelinten verran verkon resursseja. Mutta ei se haittaa kun laadussa on panostettu juuri oikeaan paikkaan.

Laatukustannusten oikean ajoittamisen lisäksi laatukustannuksia pitää siis keskittää siihen missä se eniten merkitsee. Loppukäyttäjätuotteilla kannattaa keskittyä käyttäjäkokemuksiin. Se on myös bisnesriskien hallintaa.

Jos aiot markkinoille aikaisessa vaiheessa ja olet päättänyt tehdä sen laadun kustannuksella, varmista että olet testannut vähintäänkin ne oikeat asiat. Asiat, jotka vaikuttavat vastaanottoosi kohderyhmässä.

Lisää testauksen tarkoituksesta

11. marraskuuta, 2009 | Kirjoittaja: Jaakko Sakaranaho
Kommentit: 2

Jatketaan hivenen viime viikon asiasta. Väitin kirjoituksessa, että testauksen tarkoituksen selvittäminen testaustiimille vähentää turhaa työtä. Mennään vielä pykälää korkeammalle.

Testauksen tarkoituksen määrittelee loppuviimein se optimitaso, millä ulkoisten laatukustannusten ja sisäisten laatukustannusten summa on mahdollisimman pieni. Raa’asti yksinkertaistaen ulkoisilla laatukustannuksilla tarkoitetaan tuotepalautuksista, takaisinvedoista, imagotappioista jne. koituvia kustannuksia. Sisäisillä kustannuksilla tarkoitetaan tuotteen kehityksen aikaisia testaus- ja virheenkorjauskustannuksia.

Aukipiirrettynä edellinen näyttää seuraavalta:

Optimitason määrittäminen on periaatteen tasolla varsin suoraviivaista toimintaa. Omat testauskustannuksetkin voidaan kohtuullisen hyvällä tarkkuudella saada selville ja niihin voidaan vaikuttaa mm. käyttötarkoitukseen sopivilla työkaluilla ja prosessien kehitämisellä. Eli kustannusten kertymisen kulmakerrointa saadaan loivennettua. On helppo ymmärtää, että virheiden etsiminen ja korjaaminen ikuisuuksiin ei palvele taloudellista tulosta.

Tulevien ulkoisten kustannusten arvioinnissa ensisijaisena lähteenä on aikaisempien hankkeiden ja projektien ”jälkikustannusten” läpikäyminen. Toimintansa vakiinnuttaneissa yrityksissä on toivottavasti aikaisempi data tallella, mutta tuoreiden yrityksen kohdalla tämä voi olla hankalaa. Projektihistoriaa ei välttämättä ole riittävästi tarjolla. Silloin täytyy tehdä optimitason määrittely parhaan arvauksen mukaan.

Mitäpä luulette, tekisikö Sampo Pankki jotakin testauksen suhteen toisin, jos nyt aloittaisi verkkopankin muutosprojektin? Taikka sähköisen äänestyksen toteuttanut porukka?

Testaus ei ole kuluerä vaan investointi. Testaukseen investointi panostaa virheiden löytämiseen halvimmassa mahdollisessa vaiheessa. Kohtele testausta kuten mitä tahansa muuta investointia, kunnioittaen ja systemaattisesti.

Miksi testataan?

6. marraskuuta, 2009 | Kirjoittaja: Jaakko Sakaranaho
Kommentit: 2

Antti kertoi kirjoituksessaan ”Feature managerin heiniä”, että projektissa oli käytetty varsin luovaa ja ketterää testitapausten päivittämistä. Kun projektin kannalta ikävään kohtaan testitapaus oli merkattu failiksi, muutettiin testiä siten, että tulokseksi tulikin pass.

Mikä onkaan testauksen tarkoitus? Voihan olla, että testitapaus oli vain niin spesifinen ja epätodennäköinen, että sen tuloksesta ei tarvitse välittää. Mutta silloin moista testitapausta ei olisi pitänyt edes alunperin laatia.

Kuinka monessa projektissa ylipäätään mietitään, että miksi jotakin testataan?

Cem Kaner toteaa mm. artikkelissaan What Is a Good Test Case, että testauksen tarkoitus tulee pitää mielessä testauksen suunnitteluvaiheessa. Miten muuten voisimme määritellä testauksen resurssit, työkalut, laatia testitapaukset jne?

Avataan Kanerin ajatuksia hieman. Testauksen tarkoituksen määrittelee testattavasta kohteesta, testauksen vaiheesta, kohteen ja käyttötarkoituksen kriittisyydestä jne. Näiden määrittelyjen jälkeen testauksen tarkoitus voi olla yksi tai useampia seuraavista:

  • Teknisen tuen ja asiakaspalvelun kustannusten minimointi. Pyritään löytämään ne virheet, jotka aiheuttaisivat tekniseen tukeen paljon yhteydenottoja. Tällaisia voisivat olla esimerkiksi pankkien verkkopalvelut.
  • Minimoida turvallisuudesta johtuvat syytteet. Onnettomuuteen tai loukkaantumiseen johtavien virheiden löytäminen on etusijalla. Lennonjohtosoftan kaatuminen voi aiheuttaa toimittajalle kylmää hikoilua.
  • Tarkastus ohjelman spesifikaatiota vastaan. Ainoastaan spesifikaation vaatimukset testataan, muita mahdollisia kombinaatioita ei testata. Ei soveltune loppukäyttäjätuotteisiin 🙂
  • Löytää tavat tuotteen käyttämiseen virheistä huolimatta. Vaikka jokin tapa ei toimisikaan spesifikaation mukaan, ei virhe ole kriittinen jos sen voi kiertää. Tähän ohjelmien käyttäjät ovatkin varmasti tottuneet.

Lista ei todellakaan ole täydellinen, mutta toimii esimerkinomaisesti. Jos Feature manager olisi ennen testausvaiheen alkua määritellyt testauksen tarkoituksen, ei a) epäkelpoja testitapauksia olisi suunniteltu tai b) olisi ”vääriä” testituloksia.

Pysähdy hetkeksi, ennen kuin aloitat testauksen. Selvitä itsellesi ja tiimillesi, että miksi tässä oikein ollaan testaamassa. Turha riuhtominen jää paljon vähemmälle. Säästyy hermoja, aikaa ja rahaa. Lisäksi mahdollisuudet projektin läpimenoon kasvavat oleellisesti.

Onko teillä, blogin lukijat, täysin selvillä, että miksi asioita tehdään? Kertokaa hyviä tai huonoja kokemuksia.