Spisu treści:
Demo And Die!
Czy kiedykolwiek przeprowadziłeś prezentację lub szkolenie dla klienta i coś się przebija? Lub czy kiedykolwiek dałeś komuś zestaw instrukcji i zdałeś sobie sprawę, że coś przeoczyłeś, czy też nie działało to tak, jak się spodziewałeś? Podczas każdego z tych przypadków przyjmujesz perspektywę użytkownika końcowego i pracujesz z oprogramowaniem w tej osobie. Możliwe, że zrobiłeś coś inaczej, ponieważ myślałeś jako użytkownik, a nie jako programista.
Krok do butów użytkownika
Unikalnym kątem testów akceptacji użytkownika (UAT) jest testowanie oprogramowania jako użytkownika końcowego. Oprogramowanie zostało zbudowane, aby dać użytkownikom wymierne rezultaty. Na przykład witryny handlu elektronicznego pozwalają klientom kupować produkty. Gdy klient składa zamówienie, oprogramowanie witryny e-commerce powiadamia administratora sklepu, dzięki czemu wybrany towar można wyciągnąć i zapakować do wysyłki. Mogą istnieć różne typy użytkowników oprogramowania, więc ten etap testowania pozwala zespołowi programistycznemu zweryfikować, czy użytkownicy końcowi osiągają oczekiwane wyniki oprogramowania.
Krótka historia UAT
Przed pojawieniem się Internetu większość oprogramowania została wdrożona dla znanej grupy użytkowników. Jeśli firma opracowała oprogramowanie dla klienta, wyznaczony menedżer miał uprawnienia do sprawdzenia, czy oprogramowanie spełnia warunki umowy. Miało to stanowić punkt, w którym oprogramowanie było „odpowiednie do celu”, co osiągnięto poprzez wybranie przedstawicieli użytkowników końcowych do przeprowadzenia testów i dostarczenia raportu z wynikami. Ponieważ użytkownicy byli znaną, zamkniętą grupą, każdy z nich mógł zostać przeszkolony w zakresie korzystania z oprogramowania, zazwyczaj poprzez bardzo szczegółowe kroki testowe. Motto dnia brzmiało, że więcej szczegółów jest lepszych.
