Kiedy testować?

Steve Krug swojej książce pt.: “Nie każ mi myśleć! O życiowym podejściu do funkcjonalności stron internetowych” zaleca przeprowadzanie testów z użytkownikami na jak najwcześniejszym etapie prac.

Generalnie zgadzam się z takim podejściem do projektowania i budowania aplikacji i serwisów internetowych. Pojawiła się jednak sytuacja, w projekcie nad którym obecnie pracuję, która wymogła zmiany w interfejsie. Zmienić się ma sposób w jaki klient konfiguruje i kupuje produkt. Zmian w kodzie dużo nie ma, ale dochodzi konieczność dopisania kilku funkcji w javascript. Intuicja podpowiada że zmiana będzie korzystna (dlatego na nią się zdecydowaliśmy). Nie bardzo widzę możliwości przetestowania jej na makietach papierowych (duża ilość ajaxowych elementów). Czas nas goni, budżet jest mały, więc intuicja musi wystarczyć.

I tutaj jest miejsce na moje pytanie. Testować jak najwcześniej: przy pomocy “sąsiadów” wersję “zabugowaną”; czy doprowadzić kod do porządku i dopiero wtedy testować?

  • Pierwsza wersja oszczędzi potencjalnie niepotrzebnej pracy i może wskazać pułapki których nie widzimy. Niestety ewentualne błędy w kodzie będą miały wpływ na testowanie i test może być niemiarodajny.
  • Wersja druga pokaże prawdziwszą prawdę co do ergonomii nowego rozwiązania ale na późniejszym etapie. A konieczne zmiany do zmian mogą kosztować i co najgorsze zająć dodatkowy czas którego nie mamy.

Ponieważ serwis budowany jest w ramach sił własnych, nie stać nas na zatrudnienie specjalisty ux. Z drugiej strony jakąś tam wiedzę w temacie mam więc nie powinno być tragedii.

Jeśli więc macie jakieś doświadczenia z podobnymi sytuacjami chętnie przeczytam Wasze sugestie.

Tags: praca ux