Průběh uživatelského testování : Použitelnost dot kom

Průběh uživatelského testování

Srpen 18, 2009 by Berka
Rubriky: Uživatelské testování, Z praxe, Začátečníci 

Úvod

Uživatelské testování softwaru je možné dělat všemožnými způsoby, ale vždy půjde o jeden princip. Uživateli připravíme co nejvěrněji prostředí, na které je zvyklý a necháme ho dělat práci, kterou běžně dělá nebo by měl dělat. Při tom ho pozorujeme a snažíme se ho co nejmíň vyrušovat. Získané podněty vyhodnocujeme až poté. Cílem je, získat podněty, ne jejich řešení.

Nejlepší by bylo testovat na pracovišti uživatele, to je ale zřídka možné. Minimálně je to nákladnější.

Role

Na uživatelském testování se (u nás) podílí několik důležitých rolí, bývají spojeny.

  • Zadavatel vymyslí, co, jak a s kým by se mělo testovat.
  • Koordinátorka zajistí testované osoby, vytvoří rozvrh a pozve všechny účastníky.
  • Mediátor vede testování a zajišťuje, aby proběhlo optimálně podle zásad vedení testování.
  • Hlavní pozorovatel rozumí do detailu zkoumané problematice a komunikuje s testovanou osobou.
  • Pozorovatelé test pozorují, většinou vzdáleně, a stejně jako ostatní si dělají poznámky. Po skončení testu se podílejí na jeho vyhodnocení.
  • Tester je vždy jen jeden. Plní zadané úkoly a nechá se pozorovat.
  • Psychology u nás nemáme.

Poučení pozorovatelů

Účastníci by se měli sejít před samotným testem. Pokud je to pro někoho poprvé, mediátor (povede test, zná techniky a bude hlídat, aby se dodržovaly) jim dá poučení o tom, že cílem testování je získat podněty a ne řešení, že je třeba uživateli vytvořit co nejreálnější prostředí, jako by byl sám (neradit, nenavádět, nepomáhat a to ani souhlasným nebo nesouhlasným pomrukáváním). Pokud pozorovatele něco zaujme, může se zeptat, pokud ho nebude moc rušit. Lépe je se zeptat až na konci, kdy proběhne krátké intrview.

Je třeba předem pozorovatelům zakázat bavit se vzájemně během testu. Je to totiž lákavé nejen najít problém, ale rovnou se podělit o řešení. Proto se to často při testování stává, ovšem moderátor má takové diskuze tlumit už v zárodku. Důvod je ten, že pokud někdo diskutuje, nepozoruje test a navíc ruší ostatní.

Dále je dobré zmínit, že test by měl trvat hodinu a že pokud přesáhne 90 minut, bude ukončen třeba v polovině. Uživatel je po té době unavený a to, co se nestihne otestovat, by se mohlo zahrnout později do samostatného  testu. Je dobré, myslet na dojem, který si testovaná osoba odnese. Jednak o tom bude mluvit s kolegy, ale také se dá očekávat, že ji ještě někdy o účast na testování požádáme. Všem přítomným také vysvětlíme, co mají dělat. Co nejméně rušit svou přítomností a psát si poznámky, kdykoliv je napadne nějaké vylepšení, které by uživateli usnadnilo práci. Někdo si papír a tužku nevezme (to jsou ti optimisté, co si myslí, že si ty dva nápady zapamatují), buďme připraveni. Dále je třeba říct, že s testerem budou mluvit dva lidé: mediátor a hlavní pozorovatel (to je člověk, který většinou připravoval zadání a problematice rozumí).

Před testem je tak třeba připravit počítač, tedy nainstalovat potřebný software, někam umístit soubory, které bude uživatel při práci potřebovat a podobně. Je dobré myslet na to, že před druhým a dalšími testy, bude třeba odstranit to, co tam tester vytvořil nebo modifikoval.

Poučení testera

Konečně přijde tester. Pokud nemá s uživatelským testováním zkušenosti, bude mírně vystresovaný, i když to asi nepřizná. Je třeba mu poděkovat za to, že přišel pomoci zlepšit použitelnost softwaru, který používá nebo možná bude. Pak je nutné ho ujistit, že netestujeme jeho, ale software – že pokud mu něco nepůjde, je to problém softwaru a ne jeho. Za každé jeho selhání budou peskováni vývojáři a problémy odstraní. Dále je dobré zmínit, že se snažíme simulovat jeho pracovní prostředí a ať pracuje, jak je zvyklý. (Hodně lidí tady poznamenává, že nejsou typičtí uživatelé. Nechme je při tom.) My se budeme tvářit, že tady nejsme a nebudeme mu pomáhat. Úkoly má splnit samostatně a po svém. Může používat vše, co má běžně k dospozici, tedy internet, dokumentaci, poznámky, jiný software… A pokud se někde zasekne, může zavolat na podporu. Dále je nutné testera vybídnout, aby komentoval, co dělá, na čím přemýšlí, co ho napadlo a podobně.

Test

Po poučení dáme testerovi vytištěné zadání jeho úkolů. Poznamenáme, že je jednoduché (mělo by být) a že by ho měl zvládnout. Necháme ho zadání si v klidu přečíst, případně mu řekneme další informace. Když začne pracovat na počítači, ujistíme se, že zadání rozumí. Většinou ho řekne vlastními slovy. A většinou začne něco beze slova klikat. I když vidíme, co dělá, je třeba ho rozmluvit, pokud nic neříká, ptát se, co dělá, nad čím přemýšlí… Měl by téměř bez ustání mluvit. Po chvíli si na to zvykne a svou práci komentuje.

Když jde špatnou cestou, necháme ho a pozorujeme, jak a kdy se opraví (nezkušené pozorovatele často svrbí jazyk a když to nevydrží, má je mediátor taktně nebo jakkoliv upozornit). Právě slepé uličky a to, jak se z nich uživatel dostane, je na celém testování to nejpřínosnější (uživatelé si je v reálu také projdou). Když mají pozorovatelé dotaz, měli by si ho nechat na závěrečnou diskuzi. Pokud je krátký nebo by nerušil, je možné se zeptat rovnou. Ale od toho uživatelské testování není. Tester by se měl hlavně soustředit na plnění úkolu.

Tester se občas zasekne a neví, jak dál. Většinou se zeptá na radu. Je třeba mu říct, že my tu běžně nejsme a naopak chceme zjistit, jak to samostatně vyřeší. Většinou na to přijde. Pokud skutečně ne, připomeňne mu možnosti, které má, tedy dokumentaci, internet… a zeptáme se ho, jak by to řešil sám – to pozorovatele samozřejmě zajímá. Když si přesto neví rady, připomeneme mu možnost si zavolat na podporu.

Osvědčilo se naaranžovat k tomuto účelu vedle počítače dětský plastový telefonek (z cukrárny, za sedm korun). Bez něj často není jasné, jestli je podpora stále na telefonu nebo už ne. Také to trochu odlehčí situaci – fakt se tím dovolá. Někdo z pozorovatelů zahraje podporu na druhé straně telefonu.

Tester většinou má po simulovaném zavolání na podporu tendenci jen čekat na radu, když už všichni vidí, co dělal. Je přínosné nechat ho, ať řádně zatelefonuje, zformuluje problém a dostane odpověď, jakou by asi dostal od podpory. Odpovědi z podpory by měly být takové, jako by se od podpory čekaly, stručné a nepřímé. Podpora často neví, kde je problém, jen nabídne, co by se mohlo zkusit.

Zde je důležité zdůraznit, že pokud software nefunguje podle očekávání (padá, funkcionalita se chová jinak, než jsme čekali), testera v tom nenecháme (pokud to nechceme testovat) a problém vyřešíme nebo popíšeme, jak by to mělo být správně. Software by měl být bez chyb, ale uživatelské testování se často dělá na posledních verzích, tedy na alfách a tak se stabilitou to může být na hraně. Nemělo by to ale být pravidlo – ostatně před testem bychom si měli úkol sami splnit, abychom se ujistili, že je vše v pořádku.

Rozhovor po testu

Když tester splnil všechny úkoly, poděkujeme mu za pomoc a měli bychom se ho zeptat na jeho dojmy a připomínky k tomu, jak dobře se mu úkoly plnily, co by si přál v aplikaci změnit… Zde je také prostor klást dotazy, které jednotlivé pozorovatele napadly během testování. Tady už jde o diskuzi, je možné testerovi poradit nějaké triky, které nezná (je to uživatel, bude rád, že přišel). Většinou i z této debaty vzejdou zajímavé podněty.

My se ještě ptáme, jakou známku by tester dal použitelnosti testovaných funkcionalit. Je to zajímavé slyšet, zvláště horší známky jsou argumentem pro to, aby se „něco změnilo“.

Při celém testování i při diskuzi je důležité mít stále na paměti, že tester tady není k tomu, aby hledal řešení problémů. Můžeme se ho zeptat, jaké řešení by očekával, ale pokud neví, nesmíme na něj naléhat. Hledat řešení je naše práce, ne práce uživatelů ani testerů. Je dobré mu to i říct.

Poděkování

Na závěr bychom měli testerovi poděkovat za přínos použitelnosti aplikace, kterou používá. A přínos to je. Také je dobré mu dát za námahu drobný dárek. Prvním účastníkům jsem třeba dával nanuk, a tak když přišli z testování do své pracovny (byli to kolegové), většinou se jich všichni ptali na dojmy a jejich odpověď byla, že to bylo super, že dostali nanuk.

To asi vyplývá z toho, že na taková nezaběhnutá testování lidé chodí s obavami (budou se na mě dívat, dokonce nahrávat a co když se ukáže, že něco neumím…) a na konci to z nich spadne a vlastně si uvědomí, že to nebylo hrozné, nikdo na ně nekřičel… a dokonce dostali dárek.

Po nanucích jsem dával různé pamlsky a když už testování pro většinu kolegů byla stará vesta, přestal jsem s tím. Ale pěkně poděkovat se musí vždy.

A to je celé. Je to dlouhý článek, ale uživatelské testování je jednoduché.

Komentáře



Článek byl komentován 5x.

  1. Radek on Pá, 5th Zář 2008 10:46 am

    2. Dlouhý ale přínosný, pěkně jsi to popsal. Není co dodat.

    Možná bych jen pro příště doporučoval rozdělit delší článek nějakými nadpisy protože když se k němu někdy vrátím a budu v něm něco hledat, bude to obtížné. Měl bys na něm udělat uživatelské testování. =)

  2. Berka on Pá, 5th Zář 2008 12:16 pm

    3. [Radek] Pravda, doplnil jsem to.

    Na tvém komentáři se dá postavit přednáška o UCD. Ve zkratce: existuje kanál, jak můžeš vývojáři něco sdělit. Ten podněty vyhodnotí a ty zajímavé implmenetuje. Když uživatele neznáme nebo nám nemohou nic říct, některé věci nám uniknou. UCD je sada technik, jak komunikaci zprostředkovat.

  3. meap on St, 19th Srp 2009 7:09 am

    4. Opravdu moc pěkný článek, těším se na další, protože to je jeden z mála zdrojů o použitelnosti u nás, nebo spíše jediný.

  4. Adam on St, 19th Srp 2009 11:33 am

    5. Pěkné. Taky to tak děláme : ) Jen na konci dáváme peníze, protože zveme cizí lidi. Ale je pravda, že drobný dárek pomůže pozitivnímu dojmu, začnu ho k penězům taky dávat.

  5. Berka on St, 19th Srp 2009 7:37 pm

    6. [meap] Díky, pokusím se nezklamat.

    Pokud byste sem někdo chtěl napsat článek nebo dokonce několik, rád vám to umožním.

Pokud chceš mít u svých příspěvků obrázek, zaregistruj se na gravataru!