Mindenki látott már olyan projekteket, ahol iszonyatos költséggel fejlesztettek le felesleges dolgokat, vagy ha nem is feleslegeseket, de teljesen téves koncepció mentén valósítottak meg egyébként akár hasznosnak is mondható funkciókat. A jó hír, hogy ez nem kötelezően szerves része a fejlesztésnek, mert egy viszonylag olcsó technikával a papír prototípus teszteléssel megelőzhetőek az ilyen költséges (sokszor milliókra rugó) baklövések.
Mi is a papír prototípus teszelés?
A papír prototípus tesztelésben nem valódi működő oldalt vagy alkalmazást tesztelünk, hanem rajzolt vagy nyomtatott képekkel imitáljuk annak működését. A tesztben a tesztelt felhasználón kívül egy tesztvezető és egy másik résztvevő, az ún. számítógép vesz részt. A felhasználó a papír képeinkkel úgy dolgozik valósnak tűnő feladatokat végrehajtva, mintha azok valódi képernyőnézeteket mutatnának (kattint = ujjával vagy ceruzával mutat valahova, görget = ujjával lefelé irányuló mozgást végez, begépel = ceruzával, tollal ráír a felületre), míg a számítógép mutatja neki azokat az új nézeteket, amelyeket gesztusaival előhívna. Pl. a papíron egy webáruház nyitóját látja, és ha ujjával egy termék fotójára nyom, akkor a számítógép elé teszik a termékoldal képernyő tervét. A tesztelés során a képernyőkön valódi tartalmat kell elhelyeznünk, azzaz a lorem ipsum jellegű töltelékszövegek, vagy itt most a termékleírása lesz típusú instrukciókkal teleszórt drótvázak alkalmatlanok a minőségi visszajelzések begyűjtésére.
Néhány videó, ami megmutatja, hogy ez miképp is néz ki a valóságban:
[youtube height=”300″ width=”624″]http://www.youtube.com/watch?v=GrV2SZuRPv0[/youtube]
 
[youtube height=”300″ width=”624″]http://www.youtube.com/watch?v=_g4GGtJ8NCY[/youtube]
 
[youtube height=”300″ width=”624″]http://www.youtube.com/watch?v=6TbyXq3XHSc[/youtube]
 
[youtube height=”300″ width=”624″]http://www.youtube.com/watch?v=AtfWM2jRS2w[/youtube]
 
Fontos megemlíteni azt az előnyét a klasszikus felhasználói teszteléssel kapcsolatban, hogy a váratlan eseményekre is jobban tudunk reagálni. Ha egy alkalmazás kattintható prototípusában olyan helyre jut a felhasználó, ami nincs kitalálva, akkor kínos magyarázkodás fogadja, míg a papír prototípus tesztelésben könnyedén fel tudjuk neki skiccelni 1 perc alatt, hogy nagyjából mi fogadná, ha kitaláltuk volna korábban:)
Mire jó?
Mivel nem kell hozzá programozni, hanem csak rajzolni, ezért számos elképzelést és designt tesztelhetünk, mielőtt nagyon sokat költöttünk volna rájuk. Csak néhányat említve az előnyeiből:

• Időben kiszúrhatunk használhatósági hibákat, amelyek akár kritikusak is lehetnek.
• Észrevehetjük kiemelten fontos funkciók hiányát.
• Könnyebben dönthetünk két egymással rivalizáló fejlesztési megoldás, információ elrendezés, működési folyamat stb. közt.
• Elvethetjük költséges, de egyébként senkinek sem hiányzó funkciók kifejlesztését, a maradékot pedig okosan fontossági sorrendbe rendezhetjük (pl. hasznos funkció, de inkább csak a 2.0-s verzióban akarjuk látni, hogy a többi funkcióval minél hamarabb elindulhassunk)
• A felhasználóktól kaphatunk értékes visszajelzéseket általánosságban üzleti elképzeléseinkről. Még időben jönnek ezek, így talán használni is tudjuk őket, hisz ha kész termékünk tesztelésénél derül ki, hogy a költségvetés nagy részét valami butaságra költöttük, nos az több, mint kellemetlen.

Miért csak viszonylag olcsó?
Hazugság lenne azt állítani, hogy a papír prototípus tesztelés nagyon olcsó. El kell tölteni egy két napot a képek előkészítésével, kellenek hozzá tesztrésztvevők és egyszerre két szakembernek kell jelen lennie a felhasználói teszteknél megszokott egy ember helyett. Ez vitathatatlanul egy picit drágábbá teszi, mint a klasszikus felhasnálói tesztelés, de több pénzt takarít is meg, mint az, hisz még idejekorán lemetszi elképzeléseink vadhajtásait.
Miket nehezebb vele tesztelni

• Görgetés modellezése nehézkes
• Félrekattintás, elgépelés okozta rendellenes működés nem jöhet ki
• A válaszidő túl lassú az elvárthoz képest, mivel a számítógépnek idő kell, amíg kikeresheti a megfelelő képernyőt.