Käyttöliittymäprototyypin testaussuunnitelma Koordinaattieditori
Sisällysluettelo 1. Esittely...3 1.1. Testattavan prototyypin käyttötarkoitus ja pääkäyttäjäryhmä...error! Bookmark not defined. 1.2. Testin tavoite...3 2. Käytettävyyskriteerit ja testausmenetelmä...3 2.1. Testausmenetelmä: Heuristinen testaus...3 2.2. Testeissä käytettävä heuristiikka...4 Järjestelmän tilan näkyvyys...4 Järjestelmän ja tosimaailman yhteys...4 Käyttäjän kontrolli ja vapaus...4 Johdon- ja standardinmukaisuus...4 Virheiden estäminen...4 Tunnistaminen ei muistaminen...4 Joustavuus ja käytön tehokkuus...4 Estetiikka ja minimalistinen suunnittelu...4 Auttaa käyttäjää tunnistamaan, diagnosoimaan ja korjaamaan virheet...5 Käyttäjän auttaminen ja dokumentaatio...5 3. Testijärjestelyt...5 3.1. Testikäyttäjien valinta...5 3.2. Käytettävät menetelmät...5 3.3. Tiedon tallentaminen testin aikana...5 3.4. Testin suorituspaikka ja tarvittavat välineet...6 3.5. Skenaariot...6 Skenaario 1: Lisäinformaatiota visailuohjelmaan...6 Skenaario 2:...6 Skenaario 3:...7 4. Lähteet...7 Versio Päiväys Tekijä Kuvaus 0.1 16.11.01 Mika Ståhlberg Ensimmäinen luonnos 0.2 22.11.01 Mika Ståhlberg Lisätty kaksi skenaariota 0.3 10.12.01 Mika Ståhlberg Lisätty yksi skenaario Editori Käyttöliittymän testaussuunnitelma 2
1. Esittely Koordinaattieditori on sovellus, jolla digitaalitelevisiolähetyksiin voidaan liittää ohjelmiin liittyvää koordinaatti-informaatiota mukaan. Tätä informaatiota voivat hyödyntää katsojan digiboksissa käynnissä olevat MHP-sovellukset. Käyttöliittymän vaatimusmäärittelyssä pääkäyttäjäryhmiksi identifioitiin (1) editoijat ja (2) sisällöntuottajat. Testaamisessa keskitytään näiden käyttäjäryhmien toiveiden täyttämiseen. Koska projektilla ei ole käytettävissään aikaa tai resursseja tehdä täydellistä käytettävyystestausta, on projektin testausmenetelmäksi valittu kustannustehokas mentelmä, heuristinen testaus. 1.1. Testin tavoite Käytettävyystestissä halutaan selvittää 1. Löytääkö käyttäjä toiminnot 2. Onko käyttöliittymän termistö yhdenmukainen käyttäjän termistön kanssa 3. Millaiseksi käyttäjät kokevat testijärjestelmän Tässä testissä ei pyritä selvittämään mitä toiminteita käyttäjä kaipaa nykyisten lisäksi, sillä projektin asiakas on esittänyt toteutettavat toiminteet vaatimuksissaan. Jos tarpeita uusiksi toiminteiksi testeissä ilmenee, kirjataan ne ylös jatkokehitystä varten. 2. Käytettävyyskriteerit ja testausmenetelmä 2.1. Testausmenetelmä: Heuristinen testaus Tässä projektissa käytettävyyden testausmenetelmäksi on valittu hieman perinteisistä käytettävyystesteistä poikkeava heuristinen arviointi 1. Heuristisessa arvioinnissa joukko arvioijia tutkii käyttöliittymää ja vertaa sitä yleisesti hyväksyttyihin käytettävyysperiaatteisiin (eli heuristiikkaan ks. 2.2). Arvioijia täytyy olla useita, sillä eri henkilöt löytävät aina eri ongelmia ja tutkimukset ovat osoittaneet löydettyjen ongelmien olevan eri ongelmia eri arvioijien kohdalla. Editori Käyttöliittymän testaussuunnitelma 3
Arvioija kertoo ääneen arvionsa käytettävyydestä ja testaaja kirjaa ne ylös. Perinteisessä menetelmässä testaaja antaa testikäyttäjälle tehtävän eikä voi auttaa käyttäjää käyttöliittymän käytössä sen enempää. Tämän jälkeen testaaja kirjaa ylös käyttäjän suoritteet. Heuristisessa menetelmässä käyttöliittymän analysoinnin tekee testikäyttäjä (tässä: arvioija), jolloin testaaja kirjaa ylös jalostetut arviot, ei pelkkiä suoritteita. Lisäksi heuristisessa arvioinnissa testaaja voi vastata arvioijan kysymyksiin ja auttaa häntä ongelmatilanteissa. Heuristisen menetelmän etuna on selkeästi perinteisiä menetelmiä parempi kyky arvioida suunnitteluvaiheessa olevan käyttöliittymän käytettävyyttä eli testata paperiprototyyppejä. 2.2. Testeissä käytettävä heuristiikka Testeissä arvioijat perehdytetään seuraavaan Jakob Nielsenin 2 laatimaan käytettävyyskriteerilistaan: Järjestelmän tilan näkyvyys Järjestelmän tulee aina kertoa käyttäjälle, missä mennään. Käyttäjän tulee saada palautetta järkevän odotusajan puitteissa. Järjestelmän ja tosimaailman yhteys Järjestelmä käyttää käyttäjälle tuttuja termejä ja mielikuvia. Järjestelmän informaatio näyttää loogiselta ja luonnollisesti järjestetyltä. Käyttäjän kontrolli ja vapaus Järjestelmän tiloista on löydyttävä hätäpoistumistie, jos käyttäjä on valinnut jonkun toiminteen vahingossa. Vaihtoehtona tai lisänä voivat olla undo-redo toiminteet. Johdon- ja standardinmukaisuus Eri tilanteissa ja vaiheissa samojen sanojen ja kuvien tulee merkitä samaan asiaa. Käyttöliittymän tulee käyttää yleisesti käytössä olevia komponentteja ja tapoja esittää asioita. Virheiden estäminen Virheitä ei päästetä tapahtumaan. Tunnistaminen ei muistaminen Informaation tulee olla näkyvissä. Käyttäjän ei pitäisi tarvita muistaa mitään edellisten dialogien informaatiota. Joustavuus ja käytön tehokkuus Tottuneet käyttäjät voivat suorittaa toiminteet aloittelevia käyttäjiä tehokkaammin, joilloin he eivät saa yhtä paljoa opastusta kuin aloitteleva. Käyttöliittymän räätälöinti. Estetiikka ja minimalistinen suunnittelu Informaatiota ei saa olla liikaa. Käyttöliittymän tulee miellyttää käyttäjän silmää. Editori Käyttöliittymän testaussuunnitelma 4
Auttaa käyttäjää tunnistamaan, diagnosoimaan ja korjaamaan virheet Virheilmoitusten tulee olla selvää suomea ja auttaa käyttäjää selviytymään virheestä. Käyttäjän auttaminen ja dokumentaatio Käyttöohjeiden tulee olla helposti löydettävissä ja etsittävissä (search). Osaa kriteereistä ei voida käyttää kuin vasta lähes valmiin tuotteen arviointiin. 3. Testijärjestelyt 3.1. Testikäyttäjien valinta Arvioijina toimivat asiakkaan (Digita) asiantuntijat, projektiryhmän jäsenet ja käyttäjäryhmiin (ks. käyttöliittymän vaatimusmäärittely) kuuluvat henkilöt. Testihenkilöitä tulee olla vähintään viisi. Tutkimukset 3 osoittavat, että viisi arvioijaa on määrä, jolla saavutetaan optimaalinen tulos. Useammalla arvioijalla ei lisäongelmia järjestelmästä enää löydy. 3.2. Käytettävät menetelmät Testin aluksi arvioija perehdytetään testattavaan tuotteeseen. Testaaja kertoo arvioijalle skenaarioita, eli suoritteita, joita suunniteltu käyttäjä käyttöliittymällä suorittaisi. Arvioinnin aikana arvioija käy käyttöliittymän läpi useita kertoja ja vertaa liittymän eri elementtejä heuristiikkaan (ks. 2.2). Heuristikkalistan lisäksi arvioija saa käyttää myös muita hyvinä pitämiään kriteereitä käyttöliittymälle. Periaatteessa arvioija saa itse päättää, miten arviointi suoritetaan. Perusperiaate on kuitenkin, että ensimmäisellä kerralla kun käyttöliittymän eri osat käydään läpi, arvioija vasta tutustuu pikaisesti liittymään ikäänkuin tuntumaa hakien. Toisella kerralla arvioija keskittyy tarkkaan jokaiseen käyttöliittymän elementtiin ja tällöin hän tietää, miten ko. elementit liittyvät kokonaisuuteen. 3.3. Tiedon tallentaminen testin aikana Testaaja kirjaa ylös arvioijan havainnot. Testin tuloksena on lista käytettävyysongelmista, jotka arvioija on mielestään havainnut. Arvioijien on myös selitettävä ongelmat, eli kerrottava, miksi heidän mielestään jokin tietty ominaisuus on vika käyttöliittymässä. Editori Käyttöliittymän testaussuunnitelma 5
3.4. Testin suorituspaikka ja tarvittavat välineet Testin suorituspaikan on oltava rauhallinen tila, jossa arvioijalla on aikaa ajatella ja kyky keskittyä. Välineinä tarvitaan prototyyppi, skenaariot, heuristiikka ja muistiinpanovälineet. 3.5. Skenaariot Skenaarion avulla on tarkoitus havainnollisesti ja konkreettisesti esittää tapoja ja tilanteita joissa ohjelmaa käytetään. Skenaario 1: Lisäinformaatiota visailuohjelmaan Olet työhuoneessasi. Sinulla ei ole kiire eikä muita ole huoneessa häiritsemässä työskentelyäsi. Pomosi on jättänyt sinulle pöydälle cd-levyn, jolla on ensi viikolla lähetettävän visailuohjelman editoitu versio. Visailuohjelmaan on ollut tapana liittää mahdollisuus saada pop-up -tietoa kaikista kilpailijoista. Hän on jättänyt sinulle lapun, jossa lukee seuraavaa: Terve <Nimesi>, Ohessa se ensi viikon visailu. Voisitko liittää ohjelmaan jokaisen kilpailijan koordinaattitiedon. Kilpailijoiden objekteille tulee laittaa seuraavat infot: Jaska 23v. Työtön rekkakuski, Vammala Jaana 36v. Yh-äiti ja sairaanhoitaja, Ikaalinen Hjördis 68v. Eläkeläinen, Närpiö Pekka 32v. Autonasentaja, Loimaa Että semmosta. Tsemppiä! Pera Skenaario 2: Olet suunnittelemassa tiimisi kanssa varhaisnuorisolle suunnattua makasiiniohjelmaa nimeltä Naakka. Ohjelman maskotiksi ja logoksi on valittu sarjakuvamaisesti piirretty Uka Naakka. Teille tuli villi idea kokeilla uutta koordinaattieditorianne, ja luoda Java :lla toteutettu animoitu Uka, joka Editori Käyttöliittymän testaussuunnitelma 6
lentelee satunnaisesti ruudulla, ja jonka tv-katsoja saa myös halutessaan piipahtamaan ohjelmaa piristämässä. Skenaario 3: Sait tehtäväksesi kehittää eräälle kotimaiselle musiikkakanavalle ohjelmaformaatin, jossa musikkivideoiden ohessa on mahdollista nähdä pop-up tietoja videon esittäjästä, kappaleesta, videossa esiintyvistä asioista tai ihan mistä vaan. Tällaisia ohjelmiahan on jo olemassa, mutta nyt olisi ideana tehdä tästä lisäinformaatiosta valinnaista. Katsoja voi itse valita, haluaako hän katsoa videot au naturel, vai haluaako hän lukea valaisevaa triviaa musiikkivideoon liittyen. Koordinaattieditorilla luodaan pop-up ikkunoiden koordinaatit, ikkunoiden sisältämä teksti ja muita objekteja. Näitä muita objekteja voisi olla vaikkapa sykkivä nuoli, joka osoittaa henkilö, josta pop-up informaatiossa kerrotaan. Skenaario 4: Tehtävänäsi on liittää nauhoitettuun Formula 1 osakilpailuun koordinaattitieto, jonka avulla käyttäjä voi halutessaan nähdä kuljettajan nimen jatkuvasti tekstinä leijumassa auton yläpuolella. Joillakin autourheilua seuraavista katsojista (ja selostajista ) on ollut vaikeuksia erottaa kuljettajien kypäriä toisistaan. 4. Lähteet 1 Nielsen, Jakob: Heuristic Evaluation. http://www.useit.com/papers/heuristic/ 2 sama 3 sama Editori Käyttöliittymän testaussuunnitelma 7