Ohjelmistotestaus.fi

Jos rohkeus riittää, niin markkinoinnin ammattilaiset  voivat saada ihmeitä aikaan nykyaikaisen internetin avustuksella. Menestystarinoita voi syntyä isolla budjetilla ja harkitusti. Tai joskus käy vain hyvä tuuri. Menestystarinasta on poikkeuksetta etua liiketoiminnalle, mutta vain silloin kun homma onnistuu.

Viimeviikolla NASA:lla sattui tuuri kohdalle kun Mars-mönkijä oli heittäytynyt taiteelliseksi.

Aivan vahingossa NASA:lla päästiin kokeilemaan julkisuuden valokeilaa, mutta kävijäryntäykseen ei oltu varauduttu. Kaikki vierailijoiden tuottama potentiaali valui hukkaan, kuten niin monessa harkitussakin markkinointikampanjassa.

Wappukysymys sinulle hyvä lukija: Mitä tapahtuu, kun jättipenis iskee sinun verkkopalveluusi ja pääset parrasvaloihin Reddititssä, Pinterestissä, Twitterissä, Pheedissä ja Chan4:ssä?

Kun web-sivustoa tai -palvelua optimoidaan joudutaan usein miettimään mikä on riittävä tavoitetaso latausajoille. Jos palvelusi kohdekäyttäjäryhmä on ihmiset, pitää tavoitelatausajat suhteuttaa siihen miten me, eli sinä ja minä koemme ne osana palvelun käytettävyyttä.

Käytettävyys-guru Jakob Nielsen on käsitellyt artikkeleissaan vasteaikojen ja viiveiden vaikutusta käyttökokemukseen ja määritellyt kolme aikarajaa.

0.1 s kuluessa tapahtuvat toiminnot koetaan välittömiksi ja luonnollisiksi. Sekunnin kuluessa huomataan latausviive, mutta ei vielä häiriinnytä siitä. Tapahtuman kestäessä 1 – 10 s pitäisi viiveen olla jo ominaisuuden luonteesta riippuen jollain tavoin perusteltua ja käyttäjän saada joku palautte, että hänen toimensa on huomioita.

Yli 10 s johtaa täydelliseen herpaantumiseen ja toiminnon hylkäämiseen, joten jos jonkin asian, vaikkapa tietokantaraportin koostaminen kestää näin kauan, pitää se taikoa jotenkin viiveettömämmäksi operaatioksi. Vaikkapa kertomalla käyttäjälle, että hän saa sähköpostia ja latauslinkin, kun operaatio on valmistunut.

Jotta tästä tietoiskusta saadaan riittävän häikäilemätön myyntipuhe, niin tilaa Proven Knockout heti! Sen avulla voit taikoa vauhtia ja kestävyyttä kaikkiin toiminnallisuuksiin.

Tieturin Testaus 2013 -tapahtuma oli menestys. Lukijamme Laura Selonen teki Antin puheenvuorosta tärkeitä huomioita ja halusi vierailla blogin kirjoittajana. Laura kirjoittaa myös omaa blogiaan osoitteessa qaljs.blogspot.fi.

Antti Niittyviita toi Testaus 2013 seminaarin puheenvuorossaan esille näkemyksen, että testaajalta tulee löytyä stand-up koomikon taipumusta ja puhua liiketoimintaihmisten kanssa sujuvalla ja charmikkaalla tavalla. No, kaikki meistä eivät siihen tietenkään kykene, syystä tai toisesta. Varsinkin, jos kyseessä on tarpeeksi iso pomo, jolla ei välttämättä ole aikaa kuunnella, jos ei pointti tule esille tarpeeksi nopeasti ja ytimekkäästi.

Mikä siis avuksi, jos ei omaa sujuvaa supliikkia liiketoimintaihmisten kielellä ja samaistuu niihin onnettomiin, jotka ovat hakeutuneet tekniikan pariin siksi, että heistä on luontevampaa jutella koneille kuin ihmisille?

Yksi vaihtoehto on puhua testiraporteilla. Samassa tilaisuudessa ensimmäisenä puhunut Mark Fewster puhui riskipohjaisesta raportoinnista ja hänen puheenvuoronsa herättämät ajatukset inspiroivat minut vastaamaan Antille ja väittämään, että testaajan ei ole pakko olla koomikko, jos se ei tunnu luontevalta. Raportit voivat puhua sen heikommalla supliikilla varustetun kovan luokan ammattilaisen puolesta. Kysyn mielelläni pomolta, mitä hän odottaa testauksen raportoinnilta.

Monet tuotepäälliköt eivät itsekään tiedä mitä odottaa, ja silloin joutuu kertomaan mitä testaus voi raportoida. Sen normaalin ”näin monta testiä on ajettu ja näin monta bugia on löydetty” -tyyppisen raportoinnin sijaan voi puhua ominaisuuksista jotka on testattu ja toimiviksi todettu vastaan ne ominaisuudet, joita ei ole syystä tai toisesta testattu. Vaihtoehtoisesti voi puhua riskeistä jotka on pystytty testauksella minimoimaan vastaan ne riskit jotka on todettu toteutuviksi (löytyneiden, korjaamattomien bugien muodossa), tai joista ei tiedetä (koska ei ole testattu).

Haastankin nyt testipäälliköt kirjoittamaan testiraportteihinsa ”executive summaryn” jossa kerrotaan liiketoimintapäällikölle lyhyesti ja ytimekkäästi missä nyt ollaan menossa tuotteen laadun arvioinnissa.