A VUI-k, azaz hangalapú kezelőfelületek esetében pontosan olyan lényeges a felhasználói tesztelés, mint bármely más rendszernél. Habár a tesztek nagyban fognak hasonlítani azokhoz, amiket a mobil alkalmazásoknál megszokhattunk, amennyiben kizárólag hangalapú kezelést tesz lehetővé az adott eszköz (mint mondjuk az Amazon Echo-ja), akkor azért jelentős különbségeket is találunk.

A tesztelések esetében a költségvonzatra éppen úgy érdemes figyelmet fordítani, mint a fejlesztés során – például kevés cég engedheti meg, hogy egy drága prototípusból több tucatot „szétszórjon” a célpiacon éles tesztelésre, viszont a hatékony tesztelésre igenis érdemes pénzt fordítani, mert sokkal többe kerül az, ha az ügyfelek sokasága kezd panaszkodni alaphibákra, amiket egy átfogó tesztelés akár már a fejlesztés során kiszűrhetett volna.

A cikkünkben ezért gyakorlati útmutató keretében osztunk meg olcsóbb és drágább VUI tesztelési módokat és lehetőségeket, hogy a hangalapú kezelőfelületek készítői minél hatékonyabb felhasználói teszteket valósíthassanak meg.

VUI tesztelési alapvetések

Kezdjük a legalapvetőbb kérdéssel: honnan fogja tudni a felhasználó, hogy beszéddel irányíthatja a rendszert? Sose vegyük készpénznek, hogy majd a marketing részleg gondoskodik erről, vagy valaki úgyis elmondja neki.

Inkább gondoljunk azokra a nagyszülőkre, akik életükben először találkoznak okostelefonnal. Egészen másfajta telefonokhoz szoktak hozzá és joggal keresik rajta a nyomógombokat. Megfigyelhető, hogy új eszközök esetében az emberek azért nem használnak hangparancsot, mert nem tudják, hogy beszélhetnek az eszközhöz!

Érdemes tehát akár azzal kezdeni a felhasználói tesztet, hogy kiderüljön, maguktól rájönnek-e, hogy hangparanccsal (is) tudják irányítani a rendszert. Szintén megfigyelésre érdemes még akár a beszédfelismerő rész implementálása előtt is, hogy mit és hogyan mondanak a tesztelők, mennyire artikulálnak.

Ennek későbbi változata a VUI stressz-tesztelése különféle artikulációs helyzetekkel – mennyire érti a rendszer a motyogást, a háttérzaj melletti beszédet, a több ember beszélgetése közben kiadott parancsokat, vagy akár a beszédhibás, esetleg sérült (pl. stroke-on átesett, féloldalasan bénult) emberek beszédét.

Alapvetően fontos végig figyelemmel követni, hogy miért és hol akadnak el a felhasználók, mi okoz frusztrációt számukra, és egyáltalán: a várthoz képest mekkora időkülönbséggel (gyorsabban vagy lassabban) tudják elvégezni a teszt feladatokat.

Kritikus figyelemmel kell lennünk arra is, hogy a klasszikus UX tesztelési módszertan, a think aloud protocol nem jól működik hangvezérlési rendszerek tesztelésekor. Ilyenkor a felhasználó hangosan gondolkozik, mi pedig kérdéseket teszünk fel neki, ugyanakkor ezt a párbeszédet a hangvezérlő rendszer értelmezni próbálja, hisz nem tudhatja, hogy a felhasználók egymást közt csevegnek.

Követekezzenek most azok a szempontok, amelyekre érdemes hangsúlyt helyezni a VUI-k tesztelése során!

A spanyolviasz újrafelfedezése helyett inkább építsünk az ismeretekre

Habár tényleg büszkeség tölthet el bárkit, ha korszakalkotó felfedezést tesz, és az eszközét az új iPhone-ként vagy az új PC-ként kezdik emlegetni, érdemes azért előbb alaposan körbenézni a piacon. Szinte bizonyosan kitalálta valaki ugyanazt már korábban – legfeljebb másként valósította meg.

A VUI-k esetében jellemzően találni fogunk olyan IVR-t, esetleg mobil alkalmazást, ami nagyjából ugyanazt tudja, legalább körvonalaiban, mint az általunk megálmodott rendszer. Ezeket használjuk fel már a fejlesztés során, kiváltképpen a teszteredményeket, mert már ez önmagában rengeteg időt és felesleges kört takarít meg.

Még a fejlesztés legelején érdemes előzetes felmérést végezni a célközönség körében, illetve a későbbiekben a tesztek derékhadát erre építeni.

Az Ergomaniánál sokat tanultunk a Microsoft esetéből. A redmondiak a Cortana fejlesztése során tapasztalt személyi asszisztenseket kértek meg, hogy mondják el, milyen eszközöket és módszereket használnak – és amikor kiderült, hogy kérdéseket tesznek fel, ha egy utasítás nem volt érthető számukra, a Microsoft fejlesztői ezt a funkciót beépítették a Cortana rendszerébe.

Vonjuk be a célközönséget a fejlesztésbe már az elején
A Microsoft példáját megfogadva, sokat lendít a fejlesztésen, ha minél előbb és minél többször be tudjuk vonni a célközönséget a tesztelésbe. Elvégre az ő számukra készül az adott rendszer, így a napi gyakorlatuk alapján az interjú készítői meg tudják érteni, mire van leginkább szükségük. Ebből kifolyólag a legtöbb tervezett funkcióról a mélyinterjúkat követően meg lehet állapítani, hogy valóban hasznos volna-e a célközönség számára.

Egy VUI esetében, kiváltképpen, ha nincs grafikus felület, rengeteg olyan gyakorlati eset, use case adódhat, amelyre a fejlesztők nem is gondoltak, de a leendő felhasználóknak már régóta hiányzik vagy okoz gondot.

Határozzuk meg pontosan a tesztfeladatokat

Mindegy, hogy egy korai fázisú tesztről, prototípus kipróbálásáról, vagy egy késztermék teljeskörű tesztjéről beszélünk, sose számítsunk arra, hogy a felhasználók azt csinálják, amit mi szeretnénk.

A legjobb, ha mindig egyértelműen és szabatosan fogalmazzuk meg a tesztfeladatokat, lépésről lépésre, szájbarágósan. Inkább nézzenek minket akadékoskodónak, mintsem használhatatlanok legyenek az eredmények.

Használati teszteknél a kevesebb többet számít
Viszont mindez nem jelenti azt, hogy ki kéne maradjanak a „szabad problémamegoldás” esetek, azaz amikor csak egy kiinduló állapot és egy cél adott, és a felhasználókra bízzuk, hogyan jutnak el a célig.

Az Ergomaniánál azt az elvet követjük, hogy a felhasználási teszteknél a lehető legminimálisabb befolyásolásra törekszünk, amikor azt akarjuk megtudni, a VUI mennyire közérthető és használható gyakorlatilag bárki által (és itt a „bárki” alatt a célközönség tagjait értjük).

Variáljunk a feladatok sorrendjén
Már az félreviheti a tesztelést, ha a felhasználók az egymást követő feladatok sorában korábban megtanulnak egy „trükköt”, egy könnyítést – és később hajlamosak azzal élni. Ez viszont befolyásolja az eredményeket, mert „előzetes tudással” állnak neki olyan feladatoknak, ahol elvileg nem rendelkezhetnek vele.

Erre a megoldás a feladatok randomizált sorrendben történő megadása az egyes tesztelőknek, hogy „előzetes tudásra” minél kevesebben tehessenek szert.

Jól válasszuk meg a tesztelőket és a kérdéseket

Habár elsőre evidenciának tűnhet, tapasztalataink szerint mégis gyakorta előfordul, hogy a készítők nem a megfelelő felhasználókat választják ki tesztelésre. Például egy egészségügyi alkalmazásnál aligha az életerős, egészséges egyetemisták az ideális alanyok – sokkal inkább azok a betegek, akiknek készül a fejlesztés és az ő hozzátartozóik, gondviselőik!

Egy VUI-n át irányított egészségügyi eszköznél az a fontos, hogy a rekedtesen, halkan beszélő, olykor motyogó idős páciensek vagy az ápoló személyzet tudja-e irányítani hangparancsokkal a rendszert.

Mennyi tesztelő az ideális?

A tesztelők számának kérdése más megközelítést igényel. Aligha szükséges több száz embert bevonni, akik a teljes népességet képviselik demográfiai eloszlás alapján! Sokkal többre megyünk, ha inkább minőségi tesztelőket választunk ki.

Az már a tesztelni kívánt alkalmazástól vagy VUI-tól függ, hogy mi az a felhasználói mennyiség, aminél nincs szükség többre az eredményes teszteléshez – sőt akkor már csak a pénzt és időt viszik a fölösleges tesztek. Az elmúlt évtizedek tapasztalatai alapján legalább négy, legfeljebb nyolc tesztelő szinte minden rendszer vagy eszköz teszteléséhez tökéletesen elegendő.

Milyen kérdéseket tegyünk fel?

Habár a használati mód megfigyelése számos értékes információt árul el a tesztelés során, a jól feltett kérdések olyan, rejtve maradó részekre is rávilágíthatnak, amelyek létfontosságúak a rendszer fejlesztése vagy véglegesítése szempontjából.

Általánosan megfigyelhető ugyanis, hogy az emberek többsége kerüli a feleslegesnek ítélt (sőt sokszor a lényeges) konfliktusokat, és emiatt inkább elhallgatják a negatívumokat, vagy mellékesnek tekintik egy közvetlen, személyes beszámoló során.

Szintén ellenjavallott rávezető kérdéseket feltenni – az emberek a konfliktus kerülése mellett hajlamosak megfelelésre játszani, így azt fogják inkább mondani, amit hallani szeretnénk. Például az a kérdés kevésbé jó, hogy „azért tetszett ez a megoldás. mert megkönnyíti a dolgát?” – helyette inkább azt kérdezzük, hogy „mit gondol erről a megoldásról, mennyire hatékony?”.

Néha hasznos, ha a tesztelők maguk mondják el, hogy mit tapasztaltak
Az Ergomaniánál a tesztelések során alkalmanként hagyjuk a tesztelőket beszámolni a saját szavaikkal. Ilyenkor mindig nyitott kérdéseket teszünk fel, hogy elkerüljük a sugalmazást. Például, ha egy funkció nem tetszik a felhasználónak, nem találgatunk helyette, hogy miért nincs tetszésére, inkább arra bátorítjuk, mondja el ő maga a saját szavaival.

Ez már csak amiatt is előnyös, mert ha negatív visszajelzést kapunk majd a termék bevezetését követően, ott pontosan ugyanez fog történni: keresetlen szavakkal mondják el, mi okozott gondot a felhasználóknak. Érdemes elébe menni mindennek és még idejekorán orvosolni a felmerült gondokat!

Máskülönben sokkal hatékonyabb, ha végig mi vezetjük a tesztelők figyelmét, és célzott kérdéseket teszünk fel, időnként beiktatva egy-egy szabadabb megfogalmazást lehetővé tévő panelt. Minél inkább vezetett a tesztelés, annál hatékonyabbak leszünk.

Mire figyeljünk a tesztelők figyelése során?
A tesztelők megfigyelése a tesztelés során legalább annyira fontos, mint a tudatos visszajelzéseik, illetve a rendszer generálta logok. Az közhelyszámba megy, hogy a testbeszéd, a metakommunikáció teszi ki a közlések és interakciók 80%-át.

A legtöbb ember ennek nincs igazán tudatában, és emiatt sokkal hitelesebb a testbeszédük a tesztelés idején, mint a tudatos beszámolójuk. Az Ergomaniánál a VUI-k és más felületek tesztelésekor ezért külön figyelmet fordítunk arra, hogy megnézzük, az emberek mit közölnek metakommunikáció útján.

Például egyes funkciók kiváltanak-e várt vagy váratlan érzelmi reakciókat? Zavarja-e őket, ha beszélniük kell a rendszerhez? Mikor haboznak vagy kezdenek hadarni? Miként reagálnak a rendszer válaszaira?

A korai fázisú tesztek előnyei

Amennyiben biztos piacismerettel rendelkezünk, tűpontos pszichológiai profillal és számos, a való életből vett use case-zel, akkor az egyes funkciók és modulok korai fázisú tesztelésére talán nem lesz szükség.

Minden más esetben viszont nagyon is ajánlott minden koncepciót „megfuttatni”, mielőtt a programozók vagy a mérnökök nekilátnak megvalósítani. Az Ergomania szakemberei a VUI-k fejlesztése során többek között az élő párbeszéd módszerét is alkalmazzák.

Ez lényegét tekintve úgy zajlik, hogy valaki megír egy, a felhasználó és a rendszer közötti valósághű párbeszédet, majd két ember eljátssza azt. Nagyon hamar kiderül, mennyire élethű a párbeszéd, vagy éppen akadnak-e benne ismétlések, a célközönség számára nehezen érthető részek, stb.

Mivel VUI-król beszélünk, ezért fontos megjelölni a problémás kiejtésű szavakat, amelyek megnehezítik a rendszer dolgát a felhasználó megértésében.

Oz a nagy varázsló-tesztelés
Az Oz a nagy varázsló (angol rövidítéssel WOz)-tesztre akkor lesz szükségünk, amikor a VUI mögötti rendszer igazából még nincs kész és élő ember helyettesíti. WOz-t tipikusan a korai fázisban szoktunk alkalmazni, és inkább minősül kreatív segédeszköznek, mint rendszerkalibrációs megoldásnak.

A tesztelés még inkább hasonlít egy bűvészmutatványhoz, abból a szempontból, hogy egy „varázslóra” és a segédjére lesz hozzá szükség: a „varázsló” végig láthatatlan marad, sőt a legjobb, ha a tesztelők nem is tudnak a létezéséről. Már emiatt sem lehet azonos a segéddel, aki mindvégig jelen van, jegyzetel, segédkezik a tesztelésben, stb.

Régebben például a telefonos ügyfélszolgálati rendszerek, IVR-ok korai tesztelésénél használták a WOz-t, de a VUI-k esetében ugyanolyan jól beválik. A WOz-tesztelés egyik nagy előnye például, hogy egyetlen sor programkód leírása nélkül lehet letesztelni végig a párbeszéd-folyamokat, például:

• Előző lépés: irányítószám megadása.
• Mostani lépés: telefonszám megadása.
• Következő lépés: telefonszám megerősítése.
• Nyitó szöveg: „kérem, mondja el vagy gépelje be adja meg a telefonszáma utolsó kilenc számjegyét.
• Hibaüzenet 1: „sajnálom, de nem értettem. Kérem, adja meg a telefonszáma utolsó kilenc számjegyét.”
• Hibaüzenet 2: „sajnálom, még mindig nem értettem. Kérem, adja meg a telefonszáma utolsó kilenc számjegyét.”
• Zárás hibánál: „sajnálom az okozott kellemetlenséget. Kérem várjon, amíg ügyintézőhöz kapcsolom”.

Természetesen a tesztben résztvevő felhasználó nem tudja, hogy a fenti szövegeket egy ember olvassa be neki – számára olyan lesz, mintha valódi VUI-t használna.

További szempontok VUI tesztelésekor

Mi, az Ergomaniánál a VUI fejlesztések későbbi szakaszában jellemzően a hibákat szűrjük ki először. A hibaszűrés- és javítás közvetlen hasznán túl a felhasználói élmény, a UX fejlesztése miatt is életbevágóan fontos.

Fejlett VUI-nál dialógus alapú, használhatósági tesztelések is szükségesek

A WOz teszteknél már említettük a párbeszéd szerepét és fontosságát – ám ugyanezt úgy is el kell végezni, hogy ezúttal nincs egy „varázsló a paraván mögött”, aki helyettesíti a gépi intelligenciát. A rendszer mindenképpen interpretálni fog, és ebből hamar kiderül, hogy képes-e megfelelően kezelni, terelni a beszélgetést, vagy szétcsúszik, esetleg túl sokszor akad el.

Ezek a használhatósági tesztek többnyire megírt forgatókönyv szerint zajlanak, amik részben a gyakorlati használhatóságot, részben a (még) rejtett hibák feltárást célozzák. Természetesen ahány rendszer, annyiféle funkcionalitás – emiatt a használhatósági teszteknél csak néhány sablon létezik, minden más forgatókönyvet az adott rendszer szerint alkotunk meg.

Ilyen általános tesztelési lehetőség például az aktiválás folyamata, vagy a háttérzaj, akcentus, beszédhiba alkalmazása. Például lehet ilyen módon tesztelni egy időpont beállítási funkciót:

• Felhasználó (F): „Állítsd hatra az időzítőt”
• Ekkor a rendszernek vissza kell kérdeznie, hogy pontosítsa az utasítást.
• Rendszer (R): „Reggel vagy este hatra?”
• (F): „Reggel hatra”
• Ekkor még mindig nem teljes a parancs, tehát ha jól működik a rendszer, újabb pontosítást kér.
• (R): „Egyszeri alkalommal, vagy ismétlődő legyen?”

És így tovább – a tesztelés során a felhasználó például mindig csak egy újabb részinformációt ad meg, a rendszernek pedig dialógus által kell pontosítania. Ez a forgatókönyv például előhozza azt, hogy a rendszer képes-e mind a korábbi információkat értelmezve kezelni, mind hierarchizálni az információt, azaz tudja-e, milyen sorrendben kérdezzen rá a paraméterekre.

Derítsük ki, mi frusztrálja a felhasználókat

Például előfordult, hogy így derült ki, a felhasználókat frusztrálja az egyik rendszernél, hogy a felvételt manuálisan kell leállítsák, ahelyett, hogy a rendszer maga állította volna le. Az emberek nem szeretnek többet foglalkozni az eszközökkel, mint amennyit feltétlenül muszáj és bármennyire is apróság egy gomb megnyomása, vagy hangparancs kiadása, a tapasztalat azt mutatja, hogy frusztrálja őket.

Ha nem találsz húsz hibát, válassz új tesztmódszert

Általában elmondható, hogy egy prototípusnál, ha a tesztelési módszer nem hoz elő legalább húsz hibát, akkor nem a rendszer jó – a módszer volt pocsék. Persze, nem szó szerint értendő a húsz hiba – egyszerűen az a megfelelő módszer, ami a lehető legtöbb hibát feltárja.

A VUI-nál a szövegértés minden
Tekintettel arra, hogy VUI-k teszteléséről beszélünk, életbevágóan fontos a pontos szövegértés. A WOz bármennyire is hasznos a korai fázisban, nem képes kiszűrni azokat a kritikus részeket, ahol a szoftver elhasalhat a szövegértésen.

A használhatósági tesztek is elsősorban arra szolgálnak, hogy kiderüljön, mennyire könnyű kezelni a rendszert, vagy hol szakad meg a folyamat, esetleg következik be végzetes programhiba.

Emiatt aztán az Ergomania szakemberei külön tesztelik a rendszerek szövegértését, amikor kifejezetten azt vizsgáljuk, hogy mennyire képes egyrészt a problémás szavakat megérteni, másrészt mennyire tud kontextuálisan „gondolkodni” a rendszer.

Akár teszteltetni akarja a saját rendszerét, akár saját VUI-t fejleszteni, vegye fel az Ergomaniával itt a kapcsolatot, és a legjobb megoldást szállítjuk Önnek!