KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ

Transkriptio

1 KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Eeva Kangas Oy

2 FIXUI "Autamme yrityksiä suunnittelemaan sellaisia tuotteita, joita ihmiset osaavat ja haluavat käyttää" Käyttäjätutkimukset Käyttöliittymäsuunnittelu Graafinen suunnittelu Käytettävyyden arviointi Käytettävyystestaus Koulutukset

3 KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ - Mikä on käytettävyystestaus? - Testaus osana ketterää kehitystä - Milloin voi testata? - Miksi testata? Mikä on lopputulos? - Case esimerkkejä

4 MIKÄ ON KÄYTETTÄVYYSTESTAUS? paras tapa saada monipuolista tietoa tuotteen käytettävyydestä ja löytää sen käytettävyysongelmat. oikeiden kohderyhmien käyttö testihenkilöinä lopputuloksena lista käytettävyysongelmista ongelmien vakavuusaste määritellään ja ongelmille ehdotetaan myös korjauksia käyttäjien mielipiteitä ja kommentteja tuotteesta

5 KÄYTETTÄVYYSTESTAUS - Tehdään yhdessä asiakkaan kanssa testaussuunnitelma (tehtävät ja haastattelukysymykset) - Rekrytoidaan testikäyttäjät, tyypillisesti 6-8 käyttäjää eri asiakassegmenteistä - Toteutetaan esim. neuvotteluhuoneessa käytettävyystestaukset, n. 2h / käyttäjä. Mukana testin vetäjä, muistiinpanojen kirjoittaja ja testikäyttäjä - Analysoidaan tulokset. Kirjoitetaan raportti, jossa lista löydetyistä käytettävyysongelmista, positiivisista löydöksistä ja kehittämisideoista. Ongelmiin annetaan ratkaisu joko tekstin tai esim. rautalangan muodossa. - Tulokset esitellään asiakkaalle, jotta asiakkaalla on mahdollisuus esittää tarkentavia kysymyksiä. - Tarvittava työmäärä: Asiakkaan kommentointien nopeudesta ja testikäyttäjien saatavuudesta riippuen 2-3 kalenteriviikkoa

6 ASIANTUNTIJA-ARVIOINTI - Asiantuntija-arviossa käyttöliittymäsuunnittelija selvittää mikä sivustossa tai sovelluksessa on hänen mielestään ongelmana - Asiantuntija käy läpi sivuston ja etsii sieltä käytettävyysongelmat käyttäen hyväksi heuristiikkalistoja ja omaa kokemustaan. - Asiantuntija listaa käytettävyysongelmat ja antaa niihin parannusehdotukset (selityksin tai rautalankojen muodossa). Tuloksista kirjoitetaan raportti. - Asiakkaalle esitetään tulokset, jotta asiakkaalla on mahdollisuus esittää tarkentavia kysymyksiä. - Tarvittava työmäärä: Palvelun laajuudesta riippuen 1-2 htp

7 TESTAUS OSANA KETTERÄÄ KEHITYSTÄ Suunnittele -> Toteuta -> Testaa -> Suunnittele Älä suunnittele varastoon, vaan tarpeeseen Toteuta sellaista, jota voi testata (prototyyppi, valmis tuote) Tärkeintä on saada palautetta ja saada siten parempi tuote

8 KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Ongelmana on ollut tuoteomistajan roolin hektisyydestä johtuva käytettävyysnäkökulman unohtaminen, tuoteomistajan puutteellinen käytettävyysosaaminen ja motivaatio, sekä ketterien menetelmien puutteellinen tai jopa rajoittava näkemys käytettävyyden huomiointiin. Käytettävyystestausta tarvitaan varsinkin silloin, kun Järjestelmän käyttäjät ovat laaja, ei-teknisesti suuntautunut ryhmä Käyttäjät tulevat asiakkaan organisaation ulkopuolelta Käyttäjien tekemien virheiden kustannus on korkea Erilaisia vaihtoehtoja käyttöliittymätoteutuksille on paljon eivätkä alustan parhaat käytännöt ole vielä vakiintuneet.

9 KÄYTETÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Ohjelmiston testaamisessa keskitytään enimmäkseen ohjelman logiikan testaamiseen, ei niinkään käytettävyyden testaamiseen. Koetaan, että käytettävyystestaus ei sovi ketterään kehitykseen, se unohdetaan kokonaan tai kuvitellaan, että se on sama asia kuin, että homma heitetään kokonaan asiakkaan harteille. Ketterä kehitys on tuonut asiakasta lähemmäksi ohjelmistokehitystä, mutta se ei ole kuitenkaan tarpeeksi. Käytettävyystestauksessa pyritään arvioimaan sitä, kuinka hyvin käyttäjät saavuttavat haluamansa tavoitteet kehitettävää ohjelmaa käyttäessään. Käytettävyystestaus tuottaa suunnittelua ohjaavaa tietoa ja on siten myös luonteeltaan iteratiivista. Käyttöliittymäsuunnittelun iteraatioiden kesto on usein totuttua sprinttisykliä lyhempi: viikkojen sijasta päiviä. Suunnitelma muuttuu tai kehittyy siis nopeasti kokemusten ja palautteen pohjalta.

10 KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Uusia käyttöliittymäversioita on syytä toimittaa säännöllisesti, jotta on mahdollista saada käyttäjiltä ja asiakkailta jatkuvasti palautetta, jonka perusteella sitä voidaan parantaa entisestään. Liiketoimintaan, kehitykseen ja käytettävyysaktiviteetteihin osallistuvien ihmisten on syytä työskennellä yhdessä päivittäin. Ketterän kehityksen kommunikointitapa pienentää kuilua käytettävyystiedon keräämisen ja sen perusteella muutosten tekemisen välillä. Tehokkain tapa kehitettävän järjestelmän käytettävyyden saamiseksi selville on perinteinen käytettävyystestaus. Testataan käyttöliittymää säännöllisesti ja kaikissa projektin vaiheissa.

11 SCRUM JA KÄYTETTÄVYYSTESTAUS (NORTHROP, 2011)

12 NOPEA KÄYTETTÄVYYSTESTAUS OSANA SPRINTTIÄ Suppea testaus on parempi kuin ei testausta ollenkaan. Kolme testikäyttäjää riittää nopeaan testaukseen. Tarkoituksena on löytää suurimmat ongelmat ja reagoida niihin varhaisessa vaiheessa. Myös aiempia testisuunnitelmia voidaan käyttää hyväksi. Jos testattava palvelu on hyvin geneerinen ja kaikille tarkoitettu, saat testihenkilöitä vähällä vaivalla esim. yrityksen sisältä muista projekteista tai työntekijöiden perheiden jäsenistä. Muista kuitenkin, ettei ainakaan kaikkien testihenkilöiden kannata olla ohjelmistoalalla olevia. Jos palvelun käyttäjäkunta on spesifisempi, voit esim. ulkoistaa rekrytoinnin käytettävyysalan firmalle säästääksesi omaa aikaa.

13 NOPEA KÄYTETTÄVYYSTESTAUS OSANA SPRINTTIÄ Raportoinnin tulee olla myös nopeaa. Lista ongelmista ja muutospyynnöt niihin. Ongelmat nopeasti järkevässä muodossa tuotteen omistajan tietoon, että korjaukset saadaan työlistalle. Kun nopea testaus saadaan rutiininomaiseksi, ja materiaalit ovat siihen jo olemassa, ei testaukseen mene kuin 1 2 päivää. Nopeaa testausta ei tarvitse tehdä välttämättä joka sprintissä, vaan silloin vain kun selkeitä uusia toiminnallisuuksia julkaistaan. Perinteistä muodollisempaa 5-8 testihenkilön testausta ei kuitenkaan tulisi unohtaa. Laajemman testauksen voi suorittaa aina esim. kun tuotantoon on menossa isompi versiopäivitys.

14 MILLOIN VOI TESTATA? Hankkeen alussa Ennen kuin aletaan suunnittelemaan uutta ohjelmistoa Tai ennen kuin aletaan tekemään uutta versiota palvelusta Prototyyppivaiheessa Kun tuote on lähes valmis Käyttö todellista ja aitoa Erittäin runsaasti dataa Kun tuote on markkinoilla Jatkuvaa kehitystä Liiketaloudelliset kriteerit Käyttäjäkeskeiset kriteerit

15 HANKKEEN ALUSSA Kun halutaan vaatimusmäärittely uudelle palvelulle/seuraavalle versiolle. Ketterässä ohjelmistoprojektissa määrittelyt elävät ja kokonaisuus tarkentuu vähitellen. Referenssejä: FixUi toteutti TerveMedialle ryhmäkeskustelun, jossa lääkärit saivat antaa palautetta tämän hetkisestä Lääkäriportaalista. Tuloksia käytetään hyväksi portaalin kehittämisessä. - > toiveita, ideoita, parannusehdotuksia, käyttökokemuksia

16 PROTOTYYPPIVAIHEESSA Tarkoituksena on saada selville isoja kysymyksiä: onko tuote sellainen, mitä käyttäjät toivovat? Puuttuuko ominaisuuksia? Onko ominaisuuksia liikaa? Referenssejä: MaxTrainer kuntoiluohjelmasta teimme paperiprototyyppitestin, jolla nähtiin ollaanko tuotteen suunnittelussa menossa oikeaan suuntaan.

17 KUN TUOTE ON LÄHES VALMIS Saadaan viimeiset korjaukset tehtyä ennen tuotteen julkaisua. Palveluille on yhä luonteen omaisempaa jatkuva palvelukehitys, joka tuo toistuvia muutoksia palveluihin. Huom! Jätä aikaa korjauksille Referenssejä: FixUi teki käytettävyystestin Kainuun maakuntakuntayhtymän Intranetistä juuri ennen käyttöönottoa.

18 KUN TUOTE ON MARKKINOILLA Saadaan tuote entistä paremmaksi seuraavaan versioon. Referenssejä: FixUi teki asiantuntija-arvion Verkkoaseman julkaisujärjestelmästä. FixUi teki käytettävyystestin Oulun kaupungin Intranetistä ennen kuin alettiin suunnittelemaan Intrasta seuraavaa versiota. -> käytettävyysongelmiin parannusehdotuksia

19