Testowanie

Testowanie to niezbędny element każdego procesu wytwarzania oprogramowania dobrej jakości. Nie inaczej jest w przypadku stron i aplikacji internetowych. Rzekłbym wręcz, że w ich przypadku testowanie jest specjalnie ważne, bo Sieć ze swojej natury jest dostępna dla niemal dowolnego człowieka na Ziemi. Nigdy nie wiadomo, kto zawita na naszą stronę i należy dołożyć jak największych starań, żeby mimo tej niepewności wszystko działało jak należy. I tutaj w sukurs przychodzą testy.

Dobre testy są sposobem na komunikację w projekcie. W jasny sposób informują o tym, jakie wymagania musi spełniać dany fragment aplikacji. Te automatyczne wyjaśniają także, jak to wszystko działa pod spodem. A z kolei te z udziałem osób użytkowniczych pozwalają nawiązać dialog z osobami, które ostatecznie naszej aplikacji będą używać. Taki dialog powinien trwać nieustannie: zmienia się aplikacja, pytamy na nowo osoby użytkownicze (ale też i inne osoby webdeveloperskie), analizujemy ich opinie, po czym zmieniamy na nowo, pytamy… I tak w kółko, iteracja po iteracji. W końcu zawsze coś da się poprawić.

Automatyczne

Podstawowym typem testów są testy automatyczne. To one są najbliżej kodu i developmentu. Ale też – najmniej są w stanie powiedzieć o tym, jak aplikacja jest odbierana przez osoby użytkownicze. Ten typ testów zdecydowanie bardziej sprawdza się w wyszukiwaniu i rozwiązywaniu problemów technicznych, niż związanych choćby z użytecznością czy dostępnością. To bardziej rozwiązanie dla osób webdeveloperskich. Niemniej wciąż niezwykle istotne dla zapewnienia poprawnego technicznie działania aplikacji.

Ale, jak już wspomniałem, nie do końca potrafią zbadać użyteczność i dostępność. Owszem, są narzędzia pokroju Lighthouse’a, ale potrafią wykrywać tylko część problemów. Wyniki prezentowane przez takie rozwiązania są ostatecznie syntetyczne. Trochę tak jakbyśmy przetestowali ciastko czekoladowe w sterylnym laboratorium i potwierdzili przy pomocy serii eksperymentów, że zawiera najczystszą czekoladę na świecie i najdrobniej zmieloną mąkę, jaką tylko da się uzyskać. Po czym dalibyśmy to ciastko losowej osobie na ulicy, która by wypluła je od razu po ugryzieniu, bo byłoby najzwyczajniej w świecie niedobre. Punkciki są dobrym, nomen omen, punktem wyjścia – zwłaszcza, jeśli pewne rzeczy da się zmierzyć w miarę obiektywnie (jak np. współczynnik kontrastu). Ale są właśnie tym – punktem wyjścia do głębszych testów. Maksimum punktów w Lighthouse’ie oznacza tylko tyle, że udało nam się spełnić wszystkie wymagania sprawdzane przez Lighthouse. A zapewne pierwsza prawdziwa osoba użytkownicza naszej aplikacji od razu znajdzie jakieś wymaganie, którego jednak nie spełniamy.

Z osobami użytkowniczymi

Dlatego niezwykle istotne jest testowanie produktu przy udziale osób użytkowniczych. W końcu to one będą używać naszego produktu i one najlepiej odpowiedzą na pytanie, czy spełnia on ich potrzeby i wymagania. Często pozwolą wykryć błędy, o których nikt nie pomyślał w trakcie developmentu.

Taką najprostszą metodą, która może być wstępem do bardziej profesjonalnych testów z osobami użytkowniczymi, jest metoda korytarzowa. Polega na tym, że w momencie skończenia jakiegoś większego fragmentu aplikacji, wychodzi się na korytarz, łapie ~niewinną ofiarę~ akurat przechodzącą osobę i sadza przed komputerem, każąc wykonać jakieś proste zadanie dotyczące danego fragmentu aplikacji. Dzięki temu można niskim kosztem dostać opinię dotyczącą naszej pracy. Co prawda w postpandemicznym świecie praca zdalna jest dość częstym zjawiskiem i niekoniecznie jest jakiś korytarz, na który można wyjść i kogoś zastać. Ale na szczęście nie żyjemy w XIX wieku i narzędzia do wideorozmów powstały już dawno! Aczkolwiek wideorozmowa zabija dość mocno aspekt spontaniczności takich testów, bo jednak wymaga wcześniejszego dogadania się obydwu stron.

Bardziej profesjonalne testy z osobami użytkowniczymi wymagają już pewnych przygotowań. Warto sobie usiąść i podumać nad tym, co osoba użytkownicza mogłaby chcieć od naszej aplikacji. Można też przygotować persony, na podstawie których będzie się dalej takie testy przeprowadzać. Potem trzeba zastanowić się nad typem testów: czy mają to być testy moderowane, czy może jednak nie.

Ale i tak najważniejszy jest dobór odpowiednich osób uczestniczących – tak, aby zebrane dane były jak najbardziej reprezentatywne. Jeśli chcemy przetestować dostępność aplikacji, to wypada współpracować z osobami z niepełnosprawnościami – i to różnymi, bo ich potrzeby mogą się diametralnie różnić. Ale przecież nie tylko niepełnosprawność może wpływać na to, jak będzie odbierana nasza aplikacja. Testowanie z osobami z niepełnosprawnościami wymaga też, by same testy odbyły się w dostępnym środowisku. Alternatywą mogą być tutaj testy zdalne, które pociągają jednak za sobą inne wyzwania, np. część osób testujących może mieć niskie zdolności techniczne i potrzebować pomocy z odpowiednim ustawieniem urządzenia.

Sama liczba osób uczestniczących też jest powodem do dyskusji. Ela Gorla sugeruje 12 osób:

For moderated usability testing, we generally recommend clients recruit 12 participants. This allows to include people with a range of disabilities, who use a variety of specialised technology or settings. However, we appreciate this may not always be possible. As a general rule, you should ensure that at least 20% of participants have a disability; considering that 15% of the World population has a disability, this would be a representative sample.

[Na potrzebę moderowanych testów użyteczności generalnie rekomendujemy osobom klienckim, żeby zrekrutowały 12 osób. To pozwoli na rekrutację osób z różnymi niepełnosprawnościami, które używają różnych wyspecjalizowanych technologii i ustawień. Niemniej zdajemy sobie sprawę, że nie zawsze jest to możliwe. Ogólną zasadą jest, że powinno upewnić się, że co najmniej 20% osób uczestniczących w badaniu ma niepełnosprawność, co, biorąc pod uwagę, że 15% światowej populacji ma niepełnosprawność, powinno stanowić reprezentatywną próbę.]

Z kolei Jakob Nielsen twierdzi, że nie warto testować z więcej niż pięcioma użytkownikami. Sam jednak zaznacza przy tym, że jeśli strona ma kilka znacząco różniących się od siebie grup osób użytkowniczych, należy wówczas badać na większej próbie. Osobiście stoję na stanowisku, że strona zawsze ma kilka znacząco różniących się od siebie grup osób użytkowniczych – bo tak naprawdę nigdy nie wiadomo, kto naszą stronę odwiedzi. I to jest tym bardziej prawdziwe, im popularniejsza jest strona, ale także – w przypadku wszystkich stron instytucji publicznych.

Zatem – testujmy! Najlepiej z osobami użytkowniczymi.

Źródła

Dodatkowe materiały