Gotowa strona internetowa nie powinna trafiać na serwer produkcyjny tylko dlatego, że wszystkie zaplanowane podstrony zostały zaprogramowane i projekt wygląda zgodnie z makietami. Przed publikacją trzeba jeszcze sprawdzić, czy rozwiązanie rzeczywiście realizuje uzgodnione wymagania i pozwala użytkownikom wykonać najważniejsze działania.
Temu służą testy akceptacyjne.
W przypadku strony firmowej może to oznaczać sprawdzenie, czy użytkownik jest w stanie znaleźć właściwą usługę, wysłać formularz, a zapytanie trafia do odpowiedniego działu. W sklepie internetowym scenariusz może obejmować znalezienie produktu, dodanie go do koszyka, wybór dostawy, płatność i poprawne utworzenie zamówienia. W systemie B2B testy mogą dotyczyć logowania, uprawnień, pobierania dokumentów czy przekazywania danych do ERP lub CRM.
Testy akceptacyjne nie są audytem UX ani zamiennikiem testów technicznych. Są elementem procesu odbioru rozwiązania i odpowiadają przede wszystkim na pytanie:
Czy przygotowana strona lub system działa zgodnie z ustalonym zakresem i może zostać zaakceptowany przez zamawiającego?
W tym poradniku wyjaśniamy:
Testy akceptacyjne służą potwierdzeniu, że gotowe rozwiązanie realizuje uzgodnione wymagania oraz najważniejsze scenariusze biznesowe. Często stosuje się określenie UAT – User Acceptance Testing, czyli testy akceptacyjne użytkownika.
Ich celem nie jest przede wszystkim analiza jakości kodu. Chodzi o sprawdzenie rozwiązania z perspektywy jego rzeczywistego wykorzystania.
Przykład: specyfikacja zakłada, że użytkownik strony może wysłać zapytanie ofertowe, a dane mają trafić do wskazanego działu sprzedaży i systemu CRM.
Test akceptacyjny powinien więc potwierdzić nie tylko, że przycisk „Wyślij” reaguje na kliknięcie.
Trzeba sprawdzić cały proces:
Dopiero wtedy można stwierdzić, że uzgodniony scenariusz działa.
Dobrze przeprowadzone testy akceptacyjne zaczynają się znacznie wcześniej niż na kilka dni przed publikacją. Podstawą są wymagania projektu. Jeżeli wcześniej nie określono, co strona ma robić, podczas odbioru trudno jednoznacznie odpowiedzieć, czy działa prawidłowo.
Dlatego logiczny proces wygląda następująco:
wymaganie → kryterium akceptacji → scenariusz testowy → wynik testu → ewentualna poprawka → ponowny test → odbiór
Przykładowe wymaganie: Formularz kontaktowy ma przesyłać zapytania do działu handlowego.
To nadal dość ogólne.
Przed testami warto ustalić m.in.:
Im dokładniejsze wymaganie, tym łatwiej później określić jednoznaczny wynik testu.
Więcej o przygotowaniu zakresu opisujemy w artykule Wymagania funkcjonalne strony internetowej.
Kryteria akceptacji określają warunki, które muszą zostać spełnione, aby wymaganie można było uznać za wykonane poprawnie.
Bez nich testowanie łatwo zamienia się w: „przeklikaliśmy stronę i wygląda dobrze”.
To za mało.
Załóżmy, że wymaganie brzmi: Użytkownik może zapisać się do newslettera.
Kryteria akceptacji mogą mówić, że:
Dopiero takie kryteria dają podstawę do jednoznacznego testu.
Pojęcia te są ze sobą powiązane, ale nie oznaczają dokładnie tego samego.
Sprawdzają, czy konkretna funkcja działa zgodnie z wymaganiami.
Przykład: Czy formularz poprawnie waliduje pole e-mail?
albo: Czy użytkownik może dodać produkt do koszyka?
Takie testy są zwykle wykonywane przez wykonawcę, QA lub zespół developerski jeszcze przed przekazaniem rozwiązania klientowi.
Odpowiadają szerzej: Czy rozwiązanie realizuje uzgodniony scenariusz biznesowy i może zostać zaakceptowane?
Przykład: Czy potencjalny klient może przejść od strony usługi do wysłania poprawnego zapytania, które trafia do działu sprzedaży?
Testy funkcjonalne powinny więc poprzedzać UAT.
Klient nie powinien być pierwszą osobą, która odkrywa, że podstawowe funkcje strony nie działają.
Podeślij adres - przeprowadzimy audyt strony. Wskażemy elementy, które warto poprawić.
Testy techniczne dotyczą innych aspektów rozwiązania.
Mogą sprawdzać między innymi:
Test akceptacyjny natomiast może brzmieć: Czy użytkownik może poprawnie ukończyć proces rezerwacji?
Ten proces może przejść UAT, mimo że w kodzie nadal znajduje się drobny problem techniczny niemający wpływu na uzgodnione działanie.
Może być również odwrotnie.
Strona może nie generować żadnych błędów technicznych, a mimo to nie przejść testu akceptacyjnego, bo np. formularz wysyła dane do niewłaściwego działu. Dlatego testy techniczne i akceptacyjne uzupełniają się, ale nie zastępują wzajemnie.
To również dwa różne procesy.
Test akceptacyjny odpowiada przede wszystkim: Czy funkcja działa tak, jak została uzgodniona?
Audyt UX pyta natomiast: Czy sposób działania jest wygodny, zrozumiały i można go poprawić z perspektywy użytkownika?
Przykład: formularz ma dziesięć pól.
Jeżeli specyfikacja dokładnie tak go definiuje, wszystkie pola działają, a dane trafiają do właściwego systemu, formularz może przejść test akceptacyjny.
Nie oznacza to jednak, że jego UX jest optymalny.
Być może część pól jest niepotrzebna, użytkownicy nie rozumieją etykiet albo zbyt często porzucają formularz. To już temat do analizy UX, a nie powód do stwierdzenia, że wykonawca nie zrealizował uzgodnionego wymagania.
Odpowiedzialność nie powinna spoczywać wyłącznie na jednej osobie.
Przed przekazaniem rozwiązania do testów akceptacyjnych powinien samodzielnie sprawdzić między innymi:
UAT nie powinien zastępować kontroli jakości po stronie wykonawcy.
To klient najlepiej zna:
Dlatego powinien zweryfikować przede wszystkim, czy rozwiązanie odpowiada uzgodnionym potrzebom biznesowym.
W bardziej rozbudowanych projektach warto zaangażować osoby, które po uruchomieniu faktycznie będą korzystać z systemu.
Może to być:
Każdy z nich może zweryfikować inny fragment procesu.
UAT powinien rozpocząć się dopiero wtedy, gdy rozwiązanie jest wystarczająco kompletne i wcześniej przetestowane przez wykonawcę.
Nie ma sensu przekazywać klientowi strony, jeżeli wiadomo, że:
Przed rozpoczęciem UAT warto również ustalić:
Dzięki temu odbiór nie zamienia się w chaotyczną wymianę komentarzy przez e-mail.
Najlepiej na środowisku testowym możliwie zbliżonym do produkcyjnego.
Pozwala to sprawdzić rozwiązanie bez ryzyka, że:
Środowisko powinno jednak możliwie dobrze odwzorowywać warunki docelowe. Jeżeli przykładowo integracja CRM działa tylko na produkcji, trzeba uwzględnić to w planie odbioru i wskazać, które elementy wymagają dodatkowej weryfikacji po uruchomieniu.
Więcej o takim podejściu opisujemy w artykule Staging WordPress i środowisko testowe – jak bezpiecznie testować zmiany na stronie?
Dobry scenariusz powinien opisywać rzeczywistą sytuację, a nie pojedyncze kliknięcie.
Powinien określać:
Nie trzeba przygotowywać skomplikowanej dokumentacji dla każdej prostej strony.
Ważne jednak, aby dla procesów istotnych biznesowo istniało jasne kryterium: zaliczony / niezaliczony.
Sprawdzenie, czy potencjalny klient może wysłać zapytanie ofertowe.
Warunki początkowe – Użytkownik znajduje się na stronie wybranej usługi.
Załóżmy, że strona jest zintegrowana z systemem CRM.
Samo stwierdzenie: integracja działa nie wystarcza.
Scenariusz powinien sprawdzić:
Właśnie takie testy wykrywają problemy, których użytkownik strony często nawet nie widzi.
Testy akceptacyjne są tylko jednym z elementów odbioru. Przed publikacją warto przejść szerszą listę kontrolną.
Sprawdź funkcje przewidziane w projekcie, np.:
Nie testuj wyłącznie idealnego scenariusza. Sprawdź również typowe błędy i sytuacje nietypowe.
Zweryfikuj:
Sprawdź:
Przed odbiorem nie powinny zostać:
Sprawdź również:
Nie wystarczy zmniejszyć okna przeglądarki na komputerze. Przetestuj rzeczywiste scenariusze na telefonie.
Szczególną uwagę zwróć na:
Zakres powinien wynikać z ustaleń projektowych i danych o użytkownikach. W praktyce najważniejsze jest sprawdzenie serwisu w aktualnych wersjach kluczowych przeglądarek używanych przez grupę docelową.
Nie należy zakładać, że poprawne działanie w jednej przeglądarce oznacza automatycznie poprawne działanie we wszystkich pozostałych.
Odbiór strony powinien obejmować również część, której nie widzi użytkownik końcowy.
Sprawdź np.:
Jeżeli klient nie jest w stanie samodzielnie wykonać działań, które miały być dostępne w CMS, zakres nie został w pełni zweryfikowany.
W zależności od projektu mogą to być:
Nie wystarczy sprawdzić, czy połączenie technicznie istnieje. Trzeba zweryfikować rzeczywisty przepływ danych.
Jeżeli konfiguracja analityki znajduje się w zakresie projektu, przed publikacją warto potwierdzić m.in.:
Przed publikacją warto sprawdzić między innymi:
Szczególnie ważne jest upewnienie się, że ustawienia blokujące roboty na środowisku testowym nie zostaną przypadkowo przeniesione na produkcję.
Sprawdź przede wszystkim:
Dokładny zakres testów wydajnościowych powinien wynikać z wymagań projektu.
W zależności od projektu sprawdzenia może wymagać również:
Przy małym projekcie wystarczy uporządkowana lista testów.
W większym warto każdy problem opisać przynajmniej przez:
Status może być prosty:
Najważniejsze, aby klient i wykonawca rozumieli status w taki sam sposób.
Niezaliczony test nie powinien kończyć się komentarzem: „nie działa”.
Dobrze opisane zgłoszenie powinno pozwolić wykonawcy odtworzyć problem.
Przykład: Oczekiwane zachowanie – po wysłaniu formularza dane trafiają do CRM.
Rzeczywiste zachowanie: użytkownik otrzymuje potwierdzenie, ale rekord nie pojawia się w CRM.
Warunki: formularz „Zapytaj o ofertę” na stronie usługi.
Priorytet: wysoki – brak danych uniemożliwia obsługę zapytania.
Po wprowadzeniu poprawki scenariusz powinien zostać wykonany ponownie.
To ważne, ponieważ sama informacja:
nie potwierdza jeszcze, że problem został skutecznie rozwiązany.
W Webtom.pl realizujemy projekty kompleksowo – od analizy wymagań i UX/UI, przez development i integracje, aż po testy, wdrożenie oraz dalszy rozwój. Proces testowania i odbioru planujemy jako część realizacji projektu, a nie działanie wykonywane dopiero przed publikacją.
Nie każda uwaga musi mieć taką samą wagę.
To problemy uniemożliwiające realizację kluczowego celu.
Przykłady:
Takie błędy powinny zostać rozwiązane przed publikacją.
Nie blokują całej strony, ale poważnie wpływają na jej działanie.
Przykładowo:
Decyzja o publikacji zależy od wpływu problemu na biznes i zakres ustaleń.
Mogą dotyczyć:
Takie uwagi nie zawsze muszą blokować start.
Kluczowe jest jednak, aby zostały udokumentowane i jednoznacznie ustalone pomiędzy stronami.
W idealnym świecie tak. W praktyce większe systemy mogą posiadać drobne, znane uwagi, które nie wpływają na kluczowe procesy. Decyzja o publikacji powinna więc wynikać z oceny ryzyka.
Najważniejsze jest, aby:
Uruchomienie projektu ze znanymi drobnymi uwagami jest czym innym niż publikacja rozwiązania, którego podstawowych procesów nikt wcześniej nie sprawdził.
Nie wtedy, gdy: „wygląda już dobrze”.
Stronę można uznać za gotową do uruchomienia, jeżeli m.in.:
Dla bardziej rozbudowanych projektów warto dodatkowo przygotować checklistę uruchomieniową niezależną od samych testów UAT.
Zakończony UAT nie oznacza automatycznie, że można natychmiast przełączyć domenę.
Przed uruchomieniem mogą być jeszcze potrzebne:
Dlatego odbiór rozwiązania i publikacja mogą być dwoma osobnymi momentami procesu.
Protokół odbioru jest dokumentem potwierdzającym wynik procesu odbioru. Nie powinien zastępować testów.
Powinien je podsumowywać.
W praktyce protokół może potwierdzać:
Zakres i skutki protokołu powinny odpowiadać postanowieniom umowy dotyczącej danego projektu.
W zależności od projektu warto uwzględnić:
Jeżeli protokół dotyczy konkretnego etapu, powinno to wynikać z dokumentu jednoznacznie.
Nie warto stosować ogólnego „strona została odebrana” jeśli w rzeczywistości odbierany jest tylko np. etap projektowy albo określony moduł.
Nie musi. To zależy od zasad określonych w umowie i przyjętego sposobu odbioru. Możliwe jest przykładowo zaakceptowanie rozwiązania z listą drobnych uwag, które nie blokują jego używania.
Istotne jest natomiast, aby dokładnie wiadomo było:
Protokół powinien porządkować odpowiedzialność, a nie zastępować faktyczną weryfikację.
Przy prostej stronie firmowej często wystarczy jeden odbiór końcowy. Przy większych realizacjach lepiej podzielić projekt.
Odbiór częściowy może dotyczyć np.:
Pozwala to zamknąć określony zakres bez czekania na ukończenie całego przedsięwzięcia. Ważne jednak, aby każdy odbierany etap miał jasno określony zakres i kryteria akceptacji.
Jeżeli zakres nie został jasno określony, każda ze stron może inaczej rozumieć pojęcie „gotowe”.
Klient nie powinien pełnić roli podstawowego QA wykonawcy.
Do UAT powinno trafiać rozwiązanie wcześniej sprawdzone technicznie i funkcjonalnie.
Problemy najczęściej pojawiają się w procesach:
Sama kontrola wyglądu kilku widoków nie jest odbiorem.
Strona może wyglądać prawidłowo na komputerze, a mieć problemy z:
Użytkownik może:
Takie przypadki również trzeba przewidzieć.
Formularz może wyglądać na działający, ale:
Dlatego warto testować proces od początku do końca.
Lista 50 punktów nie mówi wykonawcy, które problemy blokują publikację. Priorytety pomagają właściwie zaplanować poprawki.
Protokół powinien dokumentować rezultat procesu, a nie być formalnością wykonywaną bez sprawdzenia rozwiązania.
Więcej o ryzykach projektowych opisujemy w artykule Najczęstsze błędy przy wdrożeniach IT – jak ich uniknąć?
W profesjonalnym procesie odbiór nie powinien zaczynać się od wysłania klientowi linku z komunikatem: „gotowe, proszę sprawdzić”.
W zależności od wielkości projektu proces może wyglądać tak:
W bardziej złożonych realizacjach poszczególne etapy mogą być odbierane osobno. Taki proces ogranicza sytuacje, w których dopiero po publikacji okazuje się, że klient i wykonawca inaczej rozumieli zakres projektu. To również jeden z powodów, dla których wybór software house powinien uwzględniać nie tylko technologię, ale także sposób prowadzenia projektu, testowania i odbioru.
W realizowanych projektach odbiór traktujemy jako część procesu wdrożeniowego, a nie formalność na jego końcu. Zakres testów zależy od charakteru rozwiązania. Inaczej wygląda odbiór strony firmowej z kilkoma formularzami, inaczej sklepu internetowego z płatnościami i integracją ERP, a jeszcze inaczej systemu B2B z wieloma rolami użytkowników.
W zależności od projektu sprawdzamy między innymi:
Po stronie klienta pozostaje natomiast potwierdzenie, że rozwiązanie odpowiada rzeczywistym procesom jego firmy i może zostać zaakceptowane.
Po zakończeniu odbioru zakres może zostać formalnie potwierdzony protokołem odbioru, zgodnie z zasadami ustalonymi dla danego projektu.
Testy akceptacyjne nie powinny polegać na przypadkowym „przeklikaniu” strony dzień przed publikacją.
Ich zadaniem jest potwierdzenie, że przygotowane rozwiązanie:
Najlepszym punktem odniesienia są wcześniej przygotowane wymagania i kryteria akceptacji.
Proces można sprowadzić do: wymaganie → kryterium → test → wynik → poprawka → ponowny test → akceptacja → protokół → publikacja
Testy akceptacyjne nie zastępują QA, audytu UX ani testów technicznych. Łączą te działania z perspektywą klienta i pozwalają odpowiedzieć na najważniejsze pytanie:
Czy rozwiązanie rzeczywiście jest gotowe do użycia zgodnie z celem, dla którego zostało stworzone?
Testy akceptacyjne służą potwierdzeniu, że przygotowana strona lub system realizuje uzgodnione wymagania i najważniejsze scenariusze biznesowe oraz może zostać zaakceptowany przez zamawiającego.
UAT to skrót od User Acceptance Testing, czyli testów akceptacyjnych użytkownika. Ich celem jest sprawdzenie rozwiązania z perspektywy jego rzeczywistego wykorzystania.
Po wcześniejszych testach wykonawcy UAT powinien być realizowany przede wszystkim przez klienta, właściciela biznesowego lub przedstawicieli użytkowników, którzy znają rzeczywiste procesy firmy.
Testy techniczne sprawdzają działanie systemu od strony kodu, konfiguracji i infrastruktury. Testy akceptacyjne potwierdzają, czy rozwiązanie realizuje uzgodnione scenariusze i wymagania biznesowe.
Test funkcjonalny sprawdza konkretną funkcję, np. walidację formularza. Test akceptacyjny może obejmować cały proces, np. wysłanie zapytania od wejścia na stronę aż do zapisania danych w CRM.
Tak, choć ich zakres może być niewielki. Nawet prosta strona może posiadać niedziałający formularz, błędne linki, nieprawidłowe dane kontaktowe albo problemy mobilne.
Nie należy utożsamiać tych procesów. UAT sprawdza przede wszystkim zgodność z wymaganiami, natomiast testy i audyty UX oceniają użyteczność oraz jakość doświadczenia użytkownika.
To warunki określające, kiedy wymaganie można uznać za zrealizowane prawidłowo. Dzięki nim klient i wykonawca mogą jednoznacznie ocenić wynik testu.
Należy zweryfikować m.in. kluczowe funkcje, formularze, wersję mobilną, treści, CMS, integracje, analitykę, podstawy SEO technicznego oraz konfigurację produkcyjną.
Przede wszystkim błędy uniemożliwiające realizację kluczowych procesów, np. niedziałające formularze, płatności, logowanie, zamówienia czy integracje wymagane do obsługi klienta.
Może, jeśli problemy nie wpływają na kluczowe funkcje, strony świadomie akceptują ryzyko, a pozostałe uwagi zostały udokumentowane i mają ustalony sposób obsługi.
To dokument potwierdzający wynik procesu odbioru projektu lub jego etapu. Może określać zakres odbioru, wynik testów, ewentualne uwagi oraz ustalenia dotyczące ich usunięcia.
Po przeprowadzeniu procesu odbioru i ustaleniu, czy rozwiązanie spełnia kryteria przewidziane w umowie. Protokół powinien dokumentować wynik testów, a nie zastępować ich przeprowadzenie.
Nie zawsze. Zależy to od warunków umowy i przyjętego sposobu odbioru. Możliwy jest np. odbiór z listą drobnych uwag, jeżeli nie blokują one korzystania z rozwiązania.
To formalne zaakceptowanie konkretnego etapu lub modułu przed zakończeniem całego projektu. Może dotyczyć np. UX/UI, integracji, określonej funkcji lub wersji MVP.
Najlepiej na środowisku testowym możliwie zbliżonym do produkcyjnego. Pozwala to sprawdzić rozwiązanie bez wystawiania niegotowej wersji użytkownikom.
Tak. Po uruchomieniu warto ponownie sprawdzić kluczowe scenariusze, ponieważ część problemów może wynikać z domeny produkcyjnej, konfiguracji serwera, integracji lub migracji.
Ten wpis stworzył
Ekspert od wycen dedykowanych rozwiązań i zarządzania projektami. Posiada ogromne doświadczenie w tworzeniu ofert idealnie dopasowanych do potrzeb i oczekiwań klientów, specjalista łączący pasję do nowych wyzwań z analitycznym podejściem do każdego szczegółu projektu.
Sprawdź, jak wygląda współpraca z software house – od analizy po wdrożenie i rozwój. Poznaj proces krok po kroku i uniknij kosztownych błędów.
Zastanawiasz się wg jakich kryteriów wybrać software house do współpracy? Poznaj istotne kryteria.
Masz projekt w Figmie i chcesz wdrożyć go do WordPress? Sprawdź, jak przygotować Figma, RWD, CMS i funkcje oraz jakich błędów uniknąć przy wdrożeniu.
Czym są wymagania funkcjonalne strony internetowej i jak je opisać? Zobacz przykłady, checklistę, kryteria akceptacji i wpływ wymagań na wycenę.
Share:
