Tanie testy użyteczności

Oryginalny post: Low-Fi Usability Testing

Autor: Jeff Atwood

Szybki quiz. Skąd wiesz, że Twoja aplikacja działa? Możliwe, że się kompiluje. Możliwe, iż wszystkie testy jednostkowe przechodzą. Możliwe też, że przeszła próbę w dziale QA. Możliwe, iż została szczęśliwie wdrożona na serwer produkcyjny bądź spakowana do instalera. Może nawet beta testerzy potwierdzili jej poprawność.

Ale to nie oznacza, że aplikacja działa.

Czy tak naprawdę użytkownicy rozumieją Twoją aplikację? Czy potrafią oni wykonać swoją pracę za pomocą Twojej aplikacji? To jest to, co definiuje działającą aplikację. Cała reszta rzeczy, które wymieniłem, to tylko szum. Nie masz pewności, czy Twoja aplikacja naprawdę działa, dopóki nie przeprowadzisz testów użyteczności z prawdziwymi użytkownikami.

A Ty systematycznie przeprowadzasz takie testy na swojej aplikacji, prawda?

Tak jak myślałem. Jedną z najważniejszych koncepcji przedstawionych w książce Steve'a Krug'a Don't Make Me Think jest to, że testy użyteczności są istotne w każdym tworzonym oprogramowaniu. Krug określa swoje uproszczone podejście do testów użyteczności mianem supertanich testów użyteczności:

Testowanie użyteczności jest już znane od jakiegoś czasu i podstawowe założenie jest dosyć proste: jeśli chcesz wiedzieć, czy Twoje oprogramowanie, aplikacja internetowa, czy pilot do video są dostatecznie proste w użyciu, obserwuj ludzi używających ich i zwracaj uwagę na to, kiedy mają problemy. Następnie popraw to i przetestuj ponownie.

Niemniej jednak kiedyś testy użyteczności były bardzo drogim przedsięwzięciem. Musiałeś mieć laboratorium razem z pokojem obserwacyjnym z weneckim lustrem oraz co najmniej dwie kamery, abyś mógł nagrywać reakcje użytkowników oraz rzeczy, których używają. Musiałeś zatrudnić sporo ludzi, aby wyniki miały jakieś znaczenie w świetle statystyki. To była Nauka. Jednorazowy koszt czegoś takiego wynosił od $20000 do $50000. Nie zdarzało się to zbyt często.

W 1989 roku Jakob Nielsen napisał publikację zatytułowaną "Usability Engineering at a Discount" i zaznaczył, że wcale nie musi tak być. Nie potrzebowałeś laboratorium oraz mogłeś osiągnąć te same wyniki z pomocą o wiele mniejszej liczby użytkowników. Idea tanich testów użyteczności była olbrzymim krokiem naprzód. Problemem było to, że dekadę później większość ludzi nadal postrzegało testowanie jako coś problematycznego, a zatrudnienie kogoś do przeprowadzania takich testów kosztowało od $5000 do $15000 i w rezultacie też nie zdarzało się to dostatecznie często.

To co chciałem Ci polecić w tym rozdziale jest nawet bardziej drastyczne: supertanie testy użyteczności. Zamierzam spróbować Ci wytłumaczyć, jak przeprowadzić testy, kiedy nie ma się ani pieniędzy, ani czasu. Jeśli stać Cię na zatrudnienie profesjonalistów do testowania, zrób to -- ale nie rób tego, jeśli miałoby to oznaczać, że przeprowadzisz mniej testów.

Krug zaznacza, iż testowanie użyteczności jest tylko tak trudne, jak chcesz żeby było. Możliwym jest otrzymanie pożytecznych wyników testów użyteczności nawet za pomocą pojedynczego użytkownika:

Testy [użyteczności] zawsze się sprawdzają, a nawet najgorszy test ze złym użytkownikiem jest w stanie wykazać rzeczy, które mógłbyś poprawić na swojej stronie. Zawsze kładę nacisk na wykonywanie testów z użytkownikami podczas moich warsztatów, aby uczestnicy zobaczyli, iż jest to bardzo łatwe, i że efektem jest mnóstwo wartościowych spostrzeżeń. Proszę o ochotnika i przekonuję go, aby wykonał zadanie na stronie należącej do jednego z uczestników. Testy te trwają mniej niż 10 minut, ale osoba, której strona jest testowana, robi zazwyczaj kilka stron notatek. I zawsze proszą o to, czy mogą dostać nagranie tego testu, aby mogli je pokazać po powrocie swojemu zespołowi. Kiedyś jedna osoba powiedziała mi, że po tym jak jej zespół zobaczył nagranie, zrobili jedną zmianę na swojej stronie, która według nich zaowocowała oszczędnościami rzędu $100000.

Aby jeszcze bardziej uzmysłowić Wam, że do wykonania skutecznych testów użyteczności nie potrzeba dużej ilości użytkowników, Jakob Neilsen dostarczył następujący wykres:

problemy użyteczności wykres

Oczywiście nie robienie żadnych testów użyteczności to katastrofa. Ale co nie jest oczywiste, to że testy użyteczności z jedynie kilkoma użytkownikami są nadzwyczaj skuteczne. A przeprowadzanie ich według wskazówek Krug'a dotyczących tanich testów użyteczności może okazać się względnie przyjemne:

  • Kiedy powinienem testować? Najlepiej raz w miesiącu. Powinieneś ciągle przeprowadzać drobne testy użyteczności podczas procesu tworzenia. Testy powinny być krótkie i proste, tak abyś mógł je przeprowadzać kiedy tylko chcesz bez nadmiernego planowania.
  • Jak wielu użytkowników potrzebuję? Maksymalnie trzech bądź czterech.
  • Jakiego rodzaju użytkowników? Po prostu jakichś ludzi. Wystarczy ktoś, kto potrafi korzystać z komputera. Najlepiej strzeżoną tajemnicą testów użyteczności jest to, że nie ma zbyt wielkiego znaczenia, kto testuje. Dobrze jest mieć reprezentatywnych użytkowników, ale ważniejsze jest testowanie wczesne i częste. Nie wstydź się prosić przyjaciół i sąsiadów.
  • Jak dużo czasu to zajmie? 45 minut do godziny na jednego użytkownika. Staraj się, aby to było proste i nieskomplikowane. Mimo iż przeprowadzanie testów użyteczności, nawet tych prostych, zabiera trochę czasu, to ostatecznie go zaoszczędzisz. Wyniki testów użyteczności zapobiegną traceniu czasu na niekończących się kłótniach, czy poprawianiu projektu pod koniec terminu.
  • Gdzie mam przeprowadzić testy? W biurze bądź sali konferencyjnej. Wszystko czego potrzebujesz, to pokój z biurkiem, komputer i dwa krzesła, gdzie nikt nie będzie Ci przeszkadzał.
  • Kto powinien robić testy? Jakakolwiek rozsądnie cierpliwa osoba. Wybierz kogoś, kto jest cierpliwy, spokojny i potrafi słuchać. Z odrobiną praktyki, większość ludzi stanie się w tym dobra.
  • Jakiego oprzyrządowania będę potrzebował? Wszystko czego potrzebujesz, to jakieś oprogramowanie do nagrywania ekranu takie, jak na przykład Camtasia. Jeśli masz na to ochotę, możesz przynieść kamerę, aby nagrywać zarówno osobę testującą jak i ekran.
  • Jak przygotować się do testów? Zdecyduj się na to, co chcesz pokazać. Miej przygotowany krótki scenariusz (doc), który poprowadzi uczestników przez test.
  • Jaki będzie koszt testów? Jeśli nie liczyć czasu moderatora, to $50-$100 wynagrodzenia na użytkownika.
  • Jak interpretować wyniki? Zdaj sprawozdanie swojemu zespołowi i interesariuszom podczas lunchu tego samego dnia. Jedną z najfajniejszych rzeczy odnośnie testów użyteczności jest to, że wyniki są oczywiste dla kogoś, kto się im przyglądał. Poważne problemy są trudne do pominięcia.

Jeśli jeszcze nie posiadasz kopii książki Don't Make Me Think, wstydź się. Tymczasem, gorąco polecam ściągnięcie Rozdziału 9 tej książki (pdf), który zawiera znacznie więcej szczegółów, niż to co zaprezentowałem.

Testy użyteczności nie muszą być skomplikowane. Jeśli naprawdę chcesz się dowiedzieć, czy to nad czym pracujesz działa, zapytaj kogokolwiek, aby tego poużywał, a Ty będziesz się przyglądać. Jeśli nie masz kogo, poproś kogoś z księgowości albo działu marketingu, kogokolwiek, kto jest blisko, a nie jest uwikłany w projekt, aby spróbował użyć Twojego oprogramowania. Nie mów im, co mają robić. Daj im zadanie i zaznacz, aby myśleli na głos podczas jego wykonywania. Następnie usiądź i w ciszy obserwuj co się dzieje. Mogę Wam powiedzieć z doświadczenia, że wyniki są czasem niczym objawienie.

Korzyści wynikające z testów użyteczności są jasne. Aby zdać sobie z nich sprawę, musisz tylko je przeprowadzać.

Data publikacji oryginału: 31 stycznia, 2007

2 komentarze:

Tomasz Kowalczyk pisze...

Niestety nie zawsze w programowaniu testy sprowadzają się do wykonania paru poleceń w naszym programie / skrypcie. Artykuł bardzo dobrze podsumowuje dużą grupę produktów, które można sprawdzić w ten sposób, jednak niektóre programy są na tyle skomplikowane / specyficzne, że jednak trzeba będzie wydać trochę więcej pieniędzy na testowanie niż tutaj napisano.

Anonimowy pisze...

no ale też tego typu programy mają większy budżet

Prześlij komentarz

Related Posts with Thumbnails