Testi-ikkuna 2 - Yhteenveto ja palautteen vastine

Yleistä

• Pakkiprojektin testi-ikkuna 2:ssa kehitysversion testauksen suoritti loppuun saakka 15 henkilöä ja osittain 4 henkilöä.
• Testiraportit kerättiin eLomake-kyselyllä
• Testauksen numeerinen tulosaineisto
• Testauksessa esiin nostetut kehityskohteet: avovastausten tulosaineisto

Palautteen pääkohdat

• Opintojen pakollisuuden asteiden havainnollistamisessa värikoodausta pidettiin hyvänä, kunhan symboleiden päälle lisätään tooltipit. Valittavien opintojen määrässä opintopisteiden valittu / valittava suhdelukua pidettiin hyvänä, kunhan laskenta on luotettavaa
• (Henkilökunta)testaajille oli epäselvää, millä tavoin tiedot tuodaan Pepistä ja miten varmistetaan, että opiskelija saa oikean "pohjahopsin" käyttöönsä. Samoin opetussuunnitelmissa käytetyn tarjontakorin käsitteen sekä opintojaksojen koodien puuttuminen käyttöliittymistä hämmensi henkilökuntakäyttäjiä.
• Valintojen tekeminen koettiin hieman monimutkaiseksi ja hopsin puurakenne ei pysynyt riittävän stabiilina valintojen aikana (tietyissä käyttötilanteissa puurakenne saatiin katoamaan hetkellisesti)
• Käyttäjät kiinnittivät huomiota, että osalla kokonaisuuksista ei ollut kuvausta. Tämä johtuu siitä, että testattavana olleen hopsin Pepissä olevassa opintosuunnitelmassa ei ole ollut kyseisessä kohdassa kuvausta.
• Opintoja täytyy pystyä lisäämään myös oman opsin ulkopuolelta
• Vertailukori toimi pääsääntöisesti hyvin, mutta siihen pystyi lisäämään saman opinnon useita kertoja
  • Tämä olisi hyvä saada jatkossa toteutusten vertailuunkin
  • Vertailukorista opintojen tyhjentäminen täytyy suunnitella tarkemmin
• Käyttöliittymien täytyy olla yhdenmukaisia, esimerkiksi opintojen kuvauksiin tulee päästä aina samalla tavalla riippumatta hierarkiatasosta
• Responsiivisuus ei toiminut kaikissa kohdin

Palautteen vastine

• Pakkiprojekti ja erityisesti järjestelmätoimittaja kiittävät paneutuvasta palautteen antamisesta! Jo toimitusprojektin alkumetreille on sijoitettu asiantuntijatestausta varten testi-ikkunoita, jotta kehitettävä palvelu vastaisi käyttäjien tarpeita mahdollisimman hyvin. Palaute käsitellään projektin projektiryhmässä, ja projektin scopeen kuuluvat korjauspyynnöt aikataulutetaan ja toteutetaan muuhun kehitykseen niveltäen. Projektin scopen ulkopuoliset kehitystarpeet kirjataan ylös ja tilaajakorkeakoulut ottavat niihin sisäisesti kantaa.
• Iteratiivisen kehitysmallin mukaisesti testattavissa osakokonaisuuksissa oli testauksen aikana vielä verrattain paljon puutteita; esimerkiksi pakollisten, vaihtoehtoisten ja vapaasti valittavien opintojen tunnistaminen ei vielä toiminut lähdejärjestelmästä johtuen. Niin ikään vapaasti valittavien opintojen hakutoiminnallisuutta ei ollut vielä aloitettu, sillä projektissa päätettiin muuttaa toiminnallisuuden toteutustapaa.
• Annetun palautteen perusteella hops-työkalulle on runsaasti odotuksia ja jo ensimmäinen testattava versio sai aikaan voittopuolisesti myönteistä palautetta.
• Useissa palautteissa nostettiin esille, että kehitysversion ratkaisu hopsin muokkaamiselle ei ollut optimaalinen; käyttäjälle ei ollut intuitiivisesti selvää, millä tavoin valinnat tulisi eri opintojen osalta tehdä. Palaute otettiin huomioon jo testi-ikkunan puolessa välissä, jolloin toimittaja päätti keskeyttää kehityssprintin ja suunnitteli hopsin lähestymistavan käyttöliittymällisesti uudelleen. Seuraavassa kehitysversiossa käyttäjille on selkeytetty, miten eri toimenpiteitä hopsin muokkaamisessa tehdään.
• Kehitysversiossa oli virheitä opintopisteiden valinnan oikeinlaskemisessa eri kokonaisuuksien alla, mikä esti testaajaa suunnittelemasta hopsia alusta loppuun oikein. Virhe korjataan samalla, kun palvelu toteutetaan uuden käyttöliittymäsuunnitelman mukaisesti. Samalla selkeytetään tarkastelunäkymässä opintojen pakollisuuden osoittamista.
• Hops-työkalu tuo esille Pepin käyttämisen systematisoimisen tarpeen, sillä hops-työkalu näyttää esimerkiksi opintojen sisällön siinä muodossa kuin ne Pepissä on kuvattu.
• Tulevissa kehitysversioissa opintoja voi hakea oman opsin ulkopuolelta
• Käyttäjät antoivat kaikista testattavista osakokonaisuuksista runsaasti palautetta sekä toiminnallisten vaatimusten että käytettävyyden näkökulmasta. Asiakaskorkeakoulut ja tilaaja käyvät muutosehdotukset läpi, ja ne otetaan huomioon joko toimitusprojektin aikana tai - mikäli ehdotukset ovat selkeästi nykyisen projektin scopen ulkopuolella - jatkokehityssuunnitelmissa.

Lauri Stigell
toimittajan projektipäällikkö 

Testauksessa havaittujen muutostarpeiden toteuttaminen - aikataulu

• Uuden konseptin mukainen hopsin käyttöliittymä ja testauksessa olleet toiminnallisuudet - sprintit 10 - 11
• Opintojen pakollisuuden statuksen selkeyttäminen - sprintti 11
• Opintojen valitseminen oman opsin ulkopuolelta - sprintit 10 - 11
• Käytettävyyden parantaminen - sprintit 11 - 12