Każdy z nas uwielbia historie. Wynika to bezpośrednio z budowy naszego mózgu – badania wskazują, że najlepiej uczymy się, słuchając opowieści. To dzięki nim efektywnie zdobywamy wiedzę, przekazujemy informacje, żartujemy czy mówimy o naszych emocjach.
Jednym z aspektów testowania jest wchodzenie w rolę użytkownika czy systemu oraz zinterpretowanie czyichś potrzeb. W grach RPG, w których to gracze wcielają się w postacie, na samym początku rozgrywki każdy tworzy swojego bohatera. Opisuje go szereg cech i umiejętności, ekwipunek, historia, pochodzenie. Stworzenie postaci jest niezbędne do tego, aby zagrać w grę RPG.
Zauważyłem, że podobny proces, czyli tworzenie Persony, jest używany w Design Thinking – narzędziu wykorzystywanym do prototypowania nowych produktów lub usług. I właśnie o testowaniu zestawionym z opowiadaniem historii w grach RPG jest niniejszy artykuł.
Persona – kto to?
Persona, czyli inaczej bohater albo postać, którą tworzymy, aby zaprezentować idee, koncepcje, problemy badawcze. W świecie gier RPG będzie to bohater odgrywany przez gracza. Każda dobra historia ma w sobie bohatera, z którym się identyfikujemy. Użycie persony, czyli reprezentacji osoby, która będzie korzystać z systemu, pomoże zrozumieć potrzeby, zachowania i cele użytkownika.
Dzięki jej wykorzystaniu, jesteśmy w stanie lepiej wczuć się w to, w jak różny sposób użytkownik korzysta z aplikacji i co jest dla niego najważniejsze. Ponadto, pozwala uporządkować cele biznesowe na użytek testów End to End.
W Design Thinking persona jest wykorzystywana na początku procesu, podczas fazy badania potrzeb klienta. To wtedy, na podstawie danych takich jak:
- pochodzenie,
- finanse,
- przyzwyczajenia,
ją tworzymy. Jest to osoba bądź grupa osób o pewnych potrzebach, ograniczeniach i cechach. Dzięki temu możemy sobie wyobrazić, dla kogo powstaje produkt/usługa.
Również w nauczaniu to narzędzie może być wykorzystywane do przedstawienia pewnych pojęć lub agregacji danych.
Dobrze skonstruowany bohater powieści czy gry RPG ma jasno przedstawiony cel przed sobą, tak jak w testowaniu, czy projektowaniu oprogramowania. Każdemu z głównych procesów biznesowych aplikacji możem przypisać cele, które potem zaprezentujemy jako persony. Na przykład celem pilota samolotu jest bezpiecznie dolecenie samolotem z pasażerami z jednego lotniska na drugie, a celem pracownika banku jest poprawne rozpatrzenie wniosku kredytowego.
Persona nie tylko pomoże nam w takim wypadku określić, co jest ważne, ale też lepiej zrozumieć potrzeby klienta np. dla niektórych linii lotniczych najważniejsze będą oszczędności, a dla innych komfort podróży.
Jak stworzyć personę?
Zaczynamy od zebrania informacji na temat naszego użytkownika. Zachęcam do kontaktu z klientem końcowym, a nawet, jeżeli to możliwe, poproszenia o wspólną sesję, w której zaznajomimy się z tym, w jaki sposób on/ona korzystają z testowanego systemu. Poza tym możemy użyć specyfikacji, historyjek użytkownika, błędów zgłoszonych przez klienta.
Następnie, na podstawie wcześniej zgromadzonych danych, wyodrębnimy najważniejsze cechy i cele użytkowników. Pracownik linii lotniczej planujący lot samolotu będzie potrzebował aktualnych danych aeronautycznych takich jak: pogoda, otwarte/zamknięte przestrzenie lotniczce itp. Pracownik banku będzie potrzebował informacji potwierdzających zdolność kredytową, będzie zwracał uwagę na białe i czarne listy użytkowników.
Karta postaci
Każda persona powinna mieć:
- Imię i Zdjęcie – to ważny etap, który możemy przeprowadzić zrobić na końcu, kiedy już wiemy, z kim mamy do czynienia. Korzystając ze sztucznej inteligencji, da się wygenerować każde zdjęcie. Jest to ważny punkt, dlatego, że będzie nam się łatwiej zidentyfikować z potrzebami danej postaci, zidentyfikować właściwy scenariusz użycia.
- Opis (płeć, wiek, zainteresowania) – ważne, żeby nasza persona była z krwi i kości. Może interesować się starymi poduszkowcami, zbierać modele japońskich robotów, słuchać malezyjskiej muzyki elektronicznej. Im barwniejszy opis, tym ciekawiej.
- Wyzwania i problemy – tutaj opiszemy na przykład: że nasza persona prawie wcale lub rzadko korzysta z komputerów (zwiększony nacisk na testy użyteczności i wszelkiego rodzaju podpowiedzi), że bardzo szybko, przez co niedokładnie, wykonuje pracę (ważne będą wszystkie udogodnienia związane ze skrótami, z szybkością działania), czy może zależy jej na pozyskaniu danych wrażliwych (wtedy zwracamy uwagę na testy bezpieczeństwa, ataki).
- Potrzeby i cele – z punktu wykonania testów najważniejsza jest charakterystyka persony. Każdy z głównych celów biznesowych powinien mieć przypisaną personę i potrzeby, jakie realizuje użytkownik końcowy. Pozwala to połączyć wymagania klienckie z testami oraz lepiej zrozumieć, co jest priorytetem dla naszego klienta końcowego.
Tworzenie persony
Kiedy wiemy już, co jest ważne, możemy stworzyć personę:
- Nadajemy naszej postaci imię. Może to być pseudonim albo główna cecha naszej persony, np. Pan Pospieszalski, kiedy celem użytkownika jest jak najszybsze otrzymanie wyniku.
- Dodajemy zdjęcie. To ważny punkt – ma na celu ułatwić nam zidentyfikowanie się z kreowaną postacią
- Następnie definiujemy najważniejsze cechy oraz cele, które będą miały znaczenie dla naszych testów. Na przykład: ważne z punktu widzenia klienta jest szybkie działanie aplikacji, w takim przypadku skupimy się na wszystkich ułatwieniach w pracy: skrótach klawiszowych, możliwości korzystania z gotowych szablonów. Dla innych najważniejszym będzie wsparcie dla analizy wyników dostarczanych przez system – wówczas skupimy się na tworzeniu dodatkowych notatek, wywoływaniu kilku instancji aplikacji, aby zrobić porównanie.
- Powołujemy personę do życia. Piszemy przypadki testowe lub wybieramy istniejące, które realizują cele z punktu powyżej. Zdefiniowane scenariusze testowe powinny układać się w scenariusz użycia. Dobrą praktyką jest dodanie kilku scenariuszy negatywnych, które będą odzwierciedlać codzienność pracy naszego użytkownika. Cechy persony będą też wskazówką dotyczącą wymagań środowiska testowego.
Każdy z głównych procesów biznesowych powinien mieć stworzoną osobną personę. Możemy powiązać główne cele użytkowników z wymaganiami i stworzyć mapę pokrycia.
Nasze persony wraz z rozwojem oprogramowania będą też się rozwijać i ich cele też mogą się zmieniać.
Zastosowanie persony podczas testów klienckich, czyli „Aby wyruszyć w podróż, musisz zebrać drużynę”
Gdy już mamy gotowe persony, możemy przystąpić do zaplanowania i wykonania testów. Każda z przygotowanych postaci ma do wykonania swoje cele i ma swoje potrzeby, które możemy połączyć ze scenariuszami testowymi albo kartami testów eksploracyjnych.
Tak jak w grach RPG przygotowujemy scenariusz użycia – możemy nawet pokusić się o symulację biura klienta z odzwierciedlonymi procesami biznesowymi, np. w systemie do zarządzania produkcją możemy przeprowadzić symulację dnia wysyłki. Testując system do planowania trasy lotu, możemy zamykać różne lotniska z powodu wybuchu wulkanów czy lądowania nieznanej floty latających wielorybów. W systemie bankowym możemy przeprowadzić pełną obsługę klienta wraz z próbą zakupienia przez niego uranu do przydomowego reaktora.
Używanie person i innych mechanizmów z gier RPG takich jak rozwój postaci jako kolejna iteracja użycia person, czy wykorzystanie metod śledczych do raportowania defektów pomaga nie tylko w ustrukturyzowaniu procesu testowego wedle potrzeb klienta, ale też może mieć pozytywny wpływ na motywację testerów oraz lepsze zrozumienie przez nich produktu.
Plusy i minusy podejścia
Aby opowiedzieć dobrą historię, potrzebujemy bohatera. Na początku każdej sztuki mamy opisane Dramatis Personae, czyli kto jest kim. Na początku powieści poznajemy jej bohaterów. W testowaniu będziemy chcieli zrozumieć, komu testowany system zostanie dostarczony.
Wykorzystanie person może ułatwić po pierwsze zrozumienie systemu, jego architektury oraz zależności, a po drugie wykonanie dodatkowych testów, które przyczynią się do podniesienia satysfakcji klienta. Problemem przy wprowadzeniu takiego narzędzia może być brak informacji na temat klienta i jego preferencji oraz czas potrzebny na analizę potrzeb użytkownika. Trudnością może być również przekonanie managementu do takiego stylu pracy, który niektórym za bardzo kojarzy się z zabawą.
Podsumowanie
Podsumowując, chciałbym nawiązać do mojego doświadczenia – wprowadzenie person w procesie testowym pomogło w rozpoznaniu wymagań klientów. Bazą do lepszego poznania klienta były odwiedziny w ich siedzibie i zmapowanie ich procesu biznesowego. Rozpoznaliśmy najważniejsze procesy i w ten sposób stworzyliśmy klienckie testy End to End.
Mając na uwadze potrzeby klienta, analitycy biznesowi mogli lepiej skonstruować wymagania funkcjonalne i niefunkcjonalne. Wprowadzenie zaprezentowanego podejścia może być kluczowe nie tylko dla testerów, ale też analityków i programistów.
Bibliografia
Zostaw komentarz