• Nie Znaleziono Wyników

7. Testowanie aplikacji pod względem spełnienia wymagań

7.3. Wyniki testowania

Testowanie aplikacji „Mobilne Miasto” miało na celu przede wszystkim znalezienie błędów funkcjonalnych oraz słabych i mocnych stron aplikacji.

Przed rozpoczęciem testowania brano pod uwagę, że aktywni użytkownicy apli-kacji mobilnych mają już pewne doświadczenie w korzystaniu z dostępnych rozwiązań cząstkowych testowanej aplikacji. Istniało duże prawdopodobień-stwo, że badani, przyzwyczajeni do znanych rozwiązań, będą je porównywali z testowaną aplikacją webową.

Wyniki testowania przedstawiono, jako spójne wyniki każdego z trzech ko-lejnych etapów testowania aplikacji „Mobilne Miasto”. Testy nie odbywały się na reprezentatywnej grupie osób i ich wyników nie należy traktować jako da-nych istotda-nych statystycznie.

Etap I

W pierwszym etapie testowania, w pierwszej turze badań laboratoryjnych zidentyfikowano kilka kategorii obszarów problemowych.

Pierwsza z nich to nawigacja, która pozwala użytkownikowi dotrzeć do wy-znaczonego miejsca. Badani nie mieli trudności ze zrozumieniem sposobu dzia-łania tej funkcji. Główne problemy dotyczyły błędów technicznych, takich jak: niedziałające, niepodświetlone lub zbyt małe przyciski, brak ikon poszczegól-nych funkcji czy nachodzące na siebie (niewidoczne) przyciski.

Wyszukiwarka to jedna z najważniejszych funkcji w aplikacji „Mobilne Miasto”. Ze względu na ograniczoną liczbę danych w aplikacji trafność wyszu-kiwania była bardzo mała. W tym obszarze wskazano przede wszystkim nastę-pujące problemy: ograniczona liczba danych, niezrozumiały algorytm wyszuki-wania2, błędna interpretacja zakresu wyszukiwania, nieintuicyjne wyszukiwanie z użyciem mapy.

W przypadku korzystania z funkcji wyszukiwania tras dojazdu użytkowni-cy, przyzwyczajeni do rozwiązań zastosowanych w aplikacjach mapy Google lub jakdojade.pl, napotkali liczne problemy. Po zrozumieniu zasad działania wyszukiwarki tras dojazdu mieli trudności ze zmianą punktu automatycznej lokalizacji GPS. Najważniejsze problemy zdiagnozowane w tym obszarze to m.in.: problemy z ustawieniem punktu startowego, brak wyraźnej informacji o bieżącym punkcie startowym, brak opcji wyszukiwania „z… do…”.

Treść, w tym opis szczegółowych punktów POI, powinna być tak zaprezen-towana, aby dostarczyć użytkownikowi potrzebnych informacji, także o właści-wościach poszczególnych obszarów serwisu. Badani mieli trudności ze zrozu-mieniem niektórych funkcji, w tym m.in. z interpretacją uszeregowania wyni-ków wyszukiwania, oraz ze znaczeniem nazw etykiet i ikon. Zwracali również uwagę na irytujące ich zdaniem komunikaty o błędach w lokalizacji GPS i na brak komunikatów informujących o zmianach.

2 Zaproponowany w aplikacji domyślny algorytm wyszukiwania wskazywał prawidłowo wyniki tylko w przypadku dużej liczby danych w repozytorium plików aplikacji.

Po zdiagnozowaniu obszarów problemowych zasugerowano niżej wymie-nione modyfikacje:

ƒ poprawę widoczności pełnych nazw zakładek własnych z uwzględnieniem jak najszerszego wyboru urządzeń o zróżnicowanej rozdzielczości,

ƒ zmianę logiki podziału kategorii: przyporządkowanie wszystkich usług do jednej nadrzędnej kategorii, połączenie kategorii lub zmianę logiki ich podzia-łu: „czas wolny”, „kultura” i „wydarzenia”,

ƒ podkreślenie w formie wizualnej, że aplikacja działa na terenie miasta Poznań (rys. 7.3),

ƒ zwrócenie uwagi na dane dotyczące miasta Poznania,

ƒ ustawienie wszystkich przycisków w taki sposób, by nie zasłaniały innych pól, w tym tych wyświetlanych jako wyniki wyszukiwania,

ƒ zwiększenie intuicyjności obsługi ręcznie ustawianej lokalizacji GPS (rys. 7.3),

Rys. 7.3. Przykładowe zrzuty ekranów aplikacji „Mobilne Miasto” wykonane podczas I etapu testów

ƒ rozszerzenie bazy o wszystkie punkty POI na terenie Poznania, repertuar kin i rozkład jazdy MPK,

ƒ dodanie do opisu dojazdu do wyznaczonego miejsca komunikacją publiczną trasy alternatywnej, wyraźne zaznaczanie na mapie punktów przesiadkowych oraz dokładne odwzorowanie trasy poruszania się pieszo,

ƒ powiększenie przycisków powiększania i zmniejszania mapy,

ƒ stosowanie zrozumiałych symboli interpretujących określone funkcje, np. symbolu komunikacji miejskiej,

ƒ ujednolicenie oraz poprawne formułowanie i wyświetlanie komunikatów dla wybranych filtrów,

ƒ rozszerzenie filtrowania m.in. o takie pozycje, jak cena, opcje płatności, go-dziny otwarcia.

Modyfikacje, które nie wymagały czasochłonnych i pracochłonnych zmian, wprowadzono tuż po zakończeniu tego etapu badań. Ponieważ dane są pobierane do systemu z różnych źródeł (patrz rozdział 6) i zespół projektowy nie miał możliwości istotnej ingerencji w ich edytowanie3, wprowadzono „ręcznie” do-datkową grupę danych testowych, które miały uzupełnić i ułatwić testowanie aplikacji w kolejnych etapach.

Etap II

Drugi etap badania to pierwsza tura badań dzienniczkowych oraz badania w terenie.

W trakcie badań dzienniczkowych zwrócono uwagę na cztery główne ob-szary problemowe. Badania pozwoliły na lepsze zrozumienie kontekstu użycia zaprojektowanej aplikacji. Respondenci twierdzili, że korzystanie z aplikacji webowej jest trudne, a jej uruchamianie za pomocą przeglądarki – kłopotliwe.

Rodzaj wyszukiwanych informacji zależał od kontekstu sytuacyjnego, np. podczas weekendu badani poszukiwali miejsc, które mogą odwiedzić wieczorem (puby, kluby). Badani zwrócili uwagę na ubogą bazę (m.in. brak repertuarów kin i teatrów oraz informacji o imprezach i pubach). Dla testujących niezrozumiały był również podział danych w kategorii „transport”.

Najczęstszym sposobem wyszukiwania informacji było korzystanie z wy-szukiwarki. Z powodu niezrozumienia wyników badani korzystali również z zakładek dostępnych na ekranie głównym. Bardzo cenili sobie możliwość fil-trowania i sortowania wyników. Zgłaszane uwagi dotyczyły przede wszystkim braku filtrów w zakładce „kultura” oraz niejasnego podziału kategorii. Ze względu na mały wybór grupy danych testowych, które znajdowały się podczas badania w bazie danych aplikacji, zgłaszano również takie uwagi, jak nieatrakcyjne opisy miejsc czy nieaktualna baza danych. W bazie znajdowały się również miejsca spoza miasta Poznania.

Podczas badań w terenie respondenci nie mieli trudności ze zrozumieniem sposobu nawigacji. Spodobała im się szczególnie szybka możliwość powrotu do ekranu głównego aplikacji mobilnej. Większość zgłoszonych uwag dotyczyła rozwiązań technicznych, jednak po wprowadzeniu zmian po pierwszym etapie ich liczba istotnie się zmniejszyła. Krytyczne uwagi dotyczyły zazwyczaj paska

3 Z wyjątkiem panelu, gdzie można uzupełnić dane o kolejne kryteria, z założenia nie jest to domyślne poprawnie działająca funkcja dla wszystkich pobieranych danych tej samej kategorii.

filtrowania zasłaniającego pasek nawigacyjny, trudności ze zmianą lokalizacji, niewielkich przycisków umożliwiających powiększanie i zmniejszanie mapy.

Po raz kolejny testujący zwrócili uwagę na słabą jakość danych oraz na niewielki ich zakres. Nieodpowiednie wyniki wyszukiwania były przyczyną niskiej oceny całej aplikacji. Uwagi dotyczyły m.in.: wyświetlania informacji o wydarzeniach odbywających się poza Poznaniem, niezrozumiałego algorytmu wyświetlania wyników wyszukiwania czy błędnych danych adresowych punktów POI.

Badani nie mieli większych trudności, testując funkcję wyznaczania tras do-jazdu i dotarcia do wybranego punktu. Gdy respondenci starali się dotrzeć do wybranej ulicy, nie uzyskiwali jednak satysfakcjonujących wyników. Zgłaszano m.in. takie uwagi, jak: brak wskazania na mapie punktu, w którym wysiada się ze środków komunikacji miejskiej, wskazywanie linią prostą drogi do wyzna-czonego punktu na mapie (a nie ulicami), nieintuicyjny sposób działania wyszu-kiwarki po wpisaniu nazw ulic.

Treść i sposób prezentacji wyników wyszukiwania nie zawsze były dla ba-danych satysfakcjonujące. Zgłaszano kolejne obszary problemowe: dopasowanie wszystkich obiektów do dostępnych filtrów, brak możliwości wyświetlania trasy alternatywnej, nieintuicyjność danych w zakładce „transport” oraz brak rozpo-znawalności ikony komunikacji miejskiej.

W drugim etapie badań użyteczności i ergonomiczności aplikacji wskazano kolejne modyfikacje:

ƒ zmiana aplikacji webowej na natywną instalowaną na smartfonach,

ƒ uatrakcyjnienie szaty graficznej aplikacji i nadanie jej bardziej nowoczesnego wyglądu,

ƒ usunięcie z zakładki „transport” punktów, które nie są dla użytkowników źródłem cennych informacji,

ƒ poprawa jakości opisów punktów i rozszerzenie opisów m.in. o godziny otwarcia sklepów czy terminy wydarzeń,

ƒ rozszerzenie bazy danych o repertuary kin czy teatrów,

ƒ rozszerzenie bazy danych o grupę „nocna rozrywka”, m.in. z danymi o pu-bach czy klupu-bach muzycznych,

ƒ rozszerzenie bazy danych w zakładce „zakupy”,

ƒ ograniczenie wykazu dostępnych miejsc do znajdujących się w Poznaniu i w jego najbliższych okolicach,

ƒ dodanie filtrów w zakładce „kultura”,

ƒ jasny podział danych w poszczególnych kategoriach,

ƒ ciągłe aktualizowanie bazy danych oraz zwracanie uwagi na jakość danych. Podczas badań w terenie zasugerowano kolejne zmiany:

ƒ rozmieszczenie etykiet na ekranie głównym w taki sposób, by wyświetlały się pełne nazwy wszystkich kolejnych kategorii,

ƒ umieszczenie na stronie głównej nazwy miasta lub symbolu kojarzonego z Poznaniem,

ƒ ustawienie paska nawigacyjnego zawsze „na wierzchu” (rys. 7.4),

ƒ zmiany domyślnych ustawień i sposobu zapisywania lokalizacji w oknie „ustawienia GPS”,

ƒ poprawa algorytmu wyświetlania trasy dojazdu i możliwość wyświetlania „trasy alternatywnej”,

ƒ dodanie informacji o liczbie aktualnie stosowanych filtrów,

Rys. 7.4. Przykładowe zrzuty ekranów aplikacji „Mobilne Miasto” wykonane podczas II etapu testów ƒ wskazanie na mapie punktów przesiadkowych, przystanków i miejsc zmiany

sposobu poruszania się (rys. 7.4),

ƒ dokładniejsze uwzględnianie topografii miasta w przypadku tras pieszych, ƒ powiększenie przycisków zmiany wielkości mapy,

ƒ zmiana ikony komunikacji publicznej na bardziej intuicyjną,

ƒ zmiana etykiety „usuń filtr” w przypadku, kiedy możliwe jest zastosowanie tylko jednego filtra,

ƒ umieszczenie informacji o datach wydarzeń czy godzinach otwarcia w jak największej liczbie pozycji,

ƒ ograniczenie punktów w bazie do Poznania i najbliższych okolic, ƒ usprawnienie działania wyszukiwarki,

ƒ dopasowanie wszystkich kryteriów obiektów do funkcji filtrowania, ƒ poprawa błędnych danych teleadresowych.

Etap III

W trakcie drugiego etapu badań dzienniczkowych najważniejszymi i naj-częstszymi problemami zidentyfikowanymi przez badanych były trudności z ustawieniem automatycznej lokalizacji oraz z ładowaniem mapy i brak możli-wości pobierania aplikacji w formie natywnej.

Zwracano również uwagę na braki w bazach danych, dotyczące m.in. klu-bów muzycznych i puklu-bów. Podobnie jak w pierwszej turze badań, podczas wy-szukiwania punktów badani najczęściej korzystali z pola wywy-szukiwania. Re-spondenci nie rozumieli kryteriów wyszukiwania według dopasowania i podzia-łu danych na kategorie: kultura, czas wolny i wydarzenia.

Jakość treści aplikacji „Mobilne Miasto” była najgorzej ocenianym elemen-tem całego rozwiązania. Baza miejsc zawierała często nieaktualne informacje, wiele punktów pozbawionych było opisu czy informacji o godzinach otwarcia. Badani podkreślali, że wysoka jakość publikowanych treści jest podstawowym warunkiem korzystania z tej aplikacji w przyszłości. Zwrócono uwagę na kilka kluczowych obszarów problemowych: wskazywanie miejsc odległych od miasta Poznania, brak filtrów w zakładce „kultura”, nieatrakcyjna grafika, niezrozumia-ła zakniezrozumia-ładka „transport”.

W drugiej turze badań w laboratorium użytkownicy zauważyli mniej obsza-rów problemowych dotyczących nawigacji. Najbardziej kłopotliwym elemen-tem, stanowiącym źródło licznych błędów, był ekran służący do zmiany usta-wień GPS. Ponadto badani wskazali następujące problemy: zbyt małe pole wy-szukiwania, zbędny przycisk usuwający wpisane słowo w polu wyszukiwania oraz zbyt mała przestrzeń pomiędzy mapą a brzegiem ekranu podczas zmiany ustawień lokalizacji.

Podczas próby znalezienia wybranego punktu badani znacznie częściej ko-rzystali z pola wyszukiwania niż z zakładek na stronie głównej. Zgłaszane błędy dotyczyły: wyników wyszukiwania, braku funkcji podpowiadania podczas wpi-sywania fraz w wyszukiwarce oraz konieczność podawania nazwy miasta pod-czas wyszukiwania ulicy.

Najmniej problemów przysparzało badanym wyznaczanie trasy dojazdu. Ze względu na przyzwyczajenie do wyszukiwania tras z punktu A do punktu B w dotychczasowych rozwiązaniach badani musieli poświęcić trochę czasu na poznanie sposobu wyszukiwania tras w testowanej aplikacji. Jedyna uwaga do-tyczyła nieintuicyjnego działania wyszukiwarki po wpisaniu nazwy ulicy.

Badani po raz kolejny wskazali, że jednym z najważniejszych elementów aplikacji jest właściwa baza danych i wysoka jakość prezentowanych treści. Dane powinny mieć właściwe adresy i opis szczegółowy. Mało atrakcyjne miej-sca nie powinny się pojawiać na początku listy wyników wyszukiwania. Podczas badania wskazano również, że nazwy wydarzeń nie mieszczą się na ekranie.

W ostatniej turze badań zaproponowano kolejne zmiany aplikacji:

ƒ pozostawienie tylko jednej ikony symbolizującej lupę i usunięcie funkcji szybkiego usuwania frazy (rys. 7.5),

ƒ dodanie przykładu informacji, którą powinno się wpisywać w polu wyszuki-wania,

ƒ zmniejszenie rozmiaru mapy w oknie ustawień GPS, ƒ umieszczenie informacji o liczbie ocen,

ƒ usuwanie przeszłych wydarzeń z bazy aplikacji, ƒ dodanie czasu zakończenia wydarzenia (rys. 7.5),

ƒ dodanie funkcji podpowiedzi przy wpisywaniu nazwy miejsca, ƒ zmniejszenie liczby zakładek dotyczących czasu wolnego,

ƒ wprowadzenie oddzielnych symboli zarówno dla „moich punktów”, jak i dla „ulubionych punktów”.

Rys. 7.5. Przykładowe zrzuty ekranów aplikacji „Mobilne Miasto” wykonane podczas III etapu testów

Powiązane dokumenty