Co to jest test akceptacji użytkownika (UAT): kompletny przewodnik

Dowiedz się, co to jest test akceptacji użytkownika (UAT) , Wraz z definicją, typami, krokami i przykładami:

Moja zasada numer jeden, gdy próbuję zrozumieć nową koncepcję, jest taka, że: nazwa zawsze będzie istotna i głównie w znaczeniu dosłownym (w kontekst techniczny).

Dowiedzenie się, co to jest, da mi wstępne zrozumienie i pomoże mi zacząć.

= > Kliknij tutaj, aby zobaczyć całą serię samouczków dotyczących planu testów

Przetestujmy tę koncepcję.

= > Przeczytaj wszystkie samouczki z naszej serii testów akceptacyjnych.

Co to jest test akceptacji użytkownika?

Wiemy, czym jest testowanie, akceptacja oznacza akceptację lub zgodę. Użytkownik w kontekście oprogramowania jest albo konsumentem oprogramowania, albo osobą, która zażądała jego zbudowania (klienta).

A więc zgodnie z moją zasadą – definicja będzie :

Testy akceptacyjne użytkowników (UAT), znane również jako testy beta lub testy użytkowników końcowych, są definiowane jako testowanie oprogramowania przez użytkownika lub klienta w celu ustalenia, czy można je zaakceptować, czy nie. Jest to ostatnie testowanie wykonywane po zakończeniu testów funkcjonalnych, systemowych i regresyjnych.

Głównym celem tych testów jest sprawdzenie zgodności oprogramowania z wymaganiami biznesowymi. Ta walidacja jest przeprowadzana przez użytkowników końcowych, którzy są zaznajomieni z wymaganiami biznesowymi.

UAT, testy alfa i beta to różne rodzaje testów akceptacyjnych.

Ponieważ test akceptacyjny użytkownika jest ostatnim testem przeprowadzanym przed uruchomieniem oprogramowania, jest to oczywiście ostatnia szansa dla klienta na przetestowanie oprogramowania i sprawdzenie, czy jest odpowiednie do celu.

Kiedy jest wykonywane?

Zazwyczaj jest to ostatni krok przed uruchomieniem produktu lub przed odebraniem dostawy. Odbywa się to po dokładnym przetestowaniu samego produktu (tj. Po przetestowaniu systemu).

Kto przeprowadza UAT?

Użytkownicy lub klient – może to być osoba kupująca produkt ( w przypadku oprogramowania komercyjnego) lub kogoś, kto zlecił wykonanie oprogramowania na zamówienie przez dostawcę usług oprogramowania lub użytkownika końcowego, jeśli oprogramowanie jest im udostępniane z wyprzedzeniem i gdy jest wymagana ich opinia.

Zespół może składać się z testerów wersji beta lub klient powinien wewnętrznie wybrać członków UAT z każdej grupy organizacji, aby można było odpowiednio przetestować każdą rolę użytkownika.

Potrzeba testów akceptacji użytkowników

Programiści i testerzy funkcjonalni to osoby techniczne, które weryfikują oprogramowanie pod kątem specyfikacji funkcjonalnych. Interpretują wymagania zgodnie ze swoją wiedzą i opracowują / testują oprogramowanie (tutaj jest znaczenie znajomości domeny).

To oprogramowanie jest kompletne zgodnie ze specyfikacjami funkcjonalnymi, ale istnieją pewne wymagania biznesowe i procesy, które są znane tylko użytkownikom końcowym, albo brakuje komunikacji, albo są błędnie interpretowane.

Testy te odgrywają ważną rolę w sprawdzaniu, czy wszystkie wymagania biznesowe są spełnione, czy nie, przed wprowadzeniem oprogramowania do użytku rynkowego. Korzystanie z rzeczywistych danych i rzeczywistych przypadków użycia sprawia, że testowanie to jest ważną częścią cyklu wydawania.

Wiele firm, które poniosły duże straty z powodu problemów po wydaniu, wie, jak ważny jest pomyślny test akceptacji użytkowników. Koszt naprawy usterek po wydaniu jest wielokrotnie większy niż naprawianie go wcześniej.

Czy UAT jest naprawdę konieczne?

Po wykonaniu wielu testów systemu, integracji i testów regresyjnych można by się zastanawiać konieczność tego badania. Właściwie jest to najważniejsza faza projektu, ponieważ jest to czas, w którym użytkownicy, którzy faktycznie będą używać systemu, sprawdzą system pod kątem jego zgodności z przeznaczeniem.

UAT to test faza, która w dużej mierze zależy od punktu widzenia użytkowników końcowych i wiedzy domeny działu, który reprezentuje użytkowników końcowych.

W rzeczywistości byłoby to naprawdę pomocne dla zespołów biznesowych, gdyby byli zaangażowani w projekt dość wcześnie, aby mogli przedstawić swoje opinie i wkład, które pomogłyby w efektywnym wykorzystaniu systemu w prawdziwym świecie.

Proces testowania akceptacji użytkowników

Najłatwiejszym sposobem zrozumienia tego procesu jest myślenie o nim jako o autonomicznym projekcie testowym – co oznacza, że będzie on zawierał plan, projekt i fazy wykonania.

Poniżej przedstawiono wymagania wstępne przed fazą planowania zaczyna się:

# 1) Zbierz kluczowe kryteria akceptacji

Mówiąc prościej, kryteria akceptacji to lista tych ng, które zostaną ocenione przed przyjęciem produktu.

Mogą to być dwa typy:

(i) Funkcjonalność aplikacji lub związane z biznesem

W idealnym przypadku wszystkie kluczowe funkcje biznesowe powinny zostać zweryfikowane, ale ze względu na z różnych powodów, w tym czasu, nie jest praktyczne, aby to wszystko zrobić. Dlatego spotkanie lub dwa z klientem lub użytkownikami, którzy będą zaangażowani w te testy, mogą dać nam wyobrażenie o tym, ile testów będzie wymagało i jakie aspekty będą testowane.

(ii) Umowa – nie będziemy się w to zagłębiać, a zaangażowanie zespołu kontroli jakości w to wszystko to prawie nic. Wstępna umowa, która jest sporządzana jeszcze przed rozpoczęciem SDLC, jest weryfikowana i osiągane jest porozumienie co do tego, czy wszystkie aspekty umowy zostały dostarczone, czy nie.

Skoncentrujemy się tylko na funkcjonalności aplikacji .

2) Zdefiniuj zakres zaangażowania w zapewnianie jakości.

Rola zespołu ds. kontroli jakości jest jedną z następujących:

(i) Brak zaangażowania – jest to bardzo rzadkie.

(ii) Pomoc w tych testach – Większość wspólny. W tym przypadku naszym zaangażowaniem mogłoby być szkolenie użytkowników UAT w zakresie korzystania z aplikacji i pozostawania w trybie gotowości podczas tych testów, aby upewnić się, że możemy pomóc użytkownikom w przypadku jakichkolwiek trudności. Lub w niektórych przypadkach, oprócz bycia w gotowości i pomocy, możemy udostępniać ich odpowiedzi i rejestrować wyniki lub rejestrować błędy itp., Podczas gdy użytkownicy przeprowadzają rzeczywiste testy.

(iii) Wykonaj UAT i obecne wyniki – w takim przypadku użytkownicy wskażą obszary AUT, które chcą ocenić, a sama ocena jest wykonywana przez zespół ds. zapewnienia jakości. Po wykonaniu tych czynności wyniki są przedstawiane klientom / użytkownikom, a oni podejmą decyzję, czy wyniki, które mają w ręku, są wystarczające, czy nie i zgodne z ich oczekiwaniami, aby zaakceptować AUT. Decyzja nigdy nie należy do zespołu kontroli jakości.

W zależności od przypadku decydujemy, które podejście jest najlepsze.

Główne cele i oczekiwania:

Zwykle UAT jest przeprowadzany przez eksperta merytorycznego (SME) i / lub użytkownika biznesowego, który może być właścicielem lub klientem testowanego systemu. Podobnie jak w przypadku fazy testowania systemu, faza UAT obejmuje również fazy religijne przed jej zamknięciem.

Kluczowe działania każdej fazy UAT są zdefiniowane poniżej:

Zarządzanie UAT

Podobnie jak w przypadku testowania systemu, skuteczne zarządzanie jest egzekwowane w UAT, aby zapewnić silne bramki jakości wraz ze zdefiniowanymi kryteriami wejścia i wyjścia (podane poniżej **).

** Należy pamiętać, że jest to tylko wskazówka. Można to zmodyfikować w zależności od potrzeb i wymagań projektu.

Planowanie testów UAT

Proces jest prawie taki sam, jak w przypadku zwykłego planu testów w fazie systemowej.

Najczęstszym podejściem stosowanym w większości projektów jest wspólne planowanie fazy testowania systemu i UAT. Aby uzyskać więcej informacji na temat planu testów UAT wraz z próbką, zapoznaj się z sekcjami dotyczącymi UAT załączonego dokumentu planu testów.

Plan testów akceptacji użytkownika

(To jest to samo, co znaleźć w naszej witrynie serię szkoleń dotyczących kontroli jakości).

Kliknij poniższy obrazek i przewiń w dół, aby znaleźć przykładowy dokument planu testów w różnych formatach. W tym szablonie sprawdź sekcję UAT.

Daty, środowisko, aktorzy (którzy), protokoły komunikacyjne, role i obowiązki, szablony, wyniki i ich proces analizy, kryteria wejścia-wyjścia – wszystko z to i wszystko inne, co jest istotne, znajdzie się w planie testów UAT.

Niezależnie od tego, czy zespół ds. kontroli jakości uczestniczy, częściowo czy nie uczestniczy w tym teście, naszym zadaniem jest zaplanowanie tej fazy i upewnij się, że wszystko jest brane pod uwagę.

= > Oto przykładowy dokument planu testów akceptacji użytkownika

Projekt testów akceptacji użytkowników

W tym kroku wykorzystywane są kryteria akceptacji zebrane od użytkowników. Próbki mogą wyglądać tak, jak pokazano poniżej.

(To są fragmenty z CSTE CBOK. Jest to jedna z najlepszych dostępnych referencji na temat tego testu).

Szablon testowania akceptacji użytkownika:

W oparciu o kryteria, my (zespół QA) dajemy użytkownikom listę przypadków testowych UAT. Te przypadki testowe nie różnią się od naszych zwykłych przypadków testowych systemu. To tylko podzbiór, ponieważ testujemy wszystkie aplikacje, a nie tylko kluczowe obszary funkcjonalne.

Oprócz tego dane, szablony do zapisywania wyników testów, procedury administracyjne, mechanizm rejestrowania defektów, itd., musi być na miejscu, zanim przejdziemy do następnej fazy.

Wykonanie testu

Zazwyczaj, jeśli to możliwe, testy te odbywają się na konferencji lub w sali wojennej. skonfiguruj, w którym użytkownicy, PM, przedstawiciele zespołu QA siedzą razem przez dzień lub dwa i pracują nad wszystkimi przypadkami testów akceptacyjnych.

Lub w przypadku zespołu QA wykonującego testy, przeprowadzamy test sprawy na AUT.

Po wykonaniu wszystkich testów i uzyskaniu wyników podejmowana jest decyzja o akceptacji. Nazywa się to również decyzją Go / No-Go. Jeśli użytkownicy są usatysfakcjonowani, oznacza to, że jest to „Gotowe” lub „Nie”.

Zwykle osiągnięcie decyzji o akceptacji jest końcem tej fazy.

Narzędzia & Metodologie

Zazwyczaj rodzaj narzędzi programowych używanych podczas tej fazy testowania jest podobny do narzędzi używanych podczas przeprowadzania testów funkcjonalnych.

Narzędzia:

Ponieważ ta faza obejmuje walidację pełnego przepływu aplikacji od początku do końca, posiadanie jednego narzędzia do całkowitej automatyzacji tej walidacji może być trudne. Jednak do pewnego stopnia moglibyśmy wykorzystać zautomatyzowane skrypty opracowane podczas testowania systemu.

Podobnie jak w przypadku testowania systemu, użytkownicy korzystaliby również z narzędzi do zarządzania testami i defektami, takich jak QC, JIRA itp. narzędzia można skonfigurować tak, aby gromadziły dane dla fazy akceptacji użytkownika.

Metodologie:

Chociaż konwencjonalne metodologie, takie jak określeni użytkownicy biznesowi wykonujący UAT produktu, są nadal aktualne, w prawdziwie globalnym tak jak dzisiaj, testy akceptacji użytkowników czasami muszą obejmować różnych klientów z różnych krajów w zależności od produktu.

Na przykład witryna handlu elektronicznego byłaby używana przez klientów na całym świecie. W takich scenariuszach testy zbiorowe byłyby najlepszą realną opcją.

Testy zbiorowe to metodologia, w której ludzie z całego świata mogą uczestniczyć i weryfikować użycie produktu oraz przekazywać sugestie i zalecenia.

Platformy do testowania społeczności są obecnie budowane i są używane przez wiele organizacji. Witryna internetowa lub produkt, który musi zostać przetestowany, jest hostowany na platformie, a klienci mogą wyznaczyć się do weryfikacji. Dostarczone informacje zwrotne są następnie analizowane i uszeregowane pod względem ważności.

Metodologia testowania tłumu okazuje się być bardziej skuteczna, ponieważ można łatwo zrozumieć puls klienta na całym świecie.

UAT w zwinnym środowisku

Zwinne środowisko ma bardziej dynamiczny charakter. W zwinnym świecie użytkownicy biznesowi będą zaangażowani w przebieg sprintów projektu, a projekt zostanie ulepszony w oparciu o informacje zwrotne od nich.

Na początku projektu użytkownicy biznesowi byliby kluczowymi interesariuszami dostarczyć wymagania, aktualizując w ten sposób zaległości produktowe Pod koniec każdego sprintu użytkownicy biznesowi braliby udział w demonstracji sprintu i byliby dostępni do przekazywania wszelkich opinii.

Ponadto przed zakończeniem sprintu zaplanowano fazę UAT, w której użytkownicy biznesowi mogliby walidacje.

Informacje zwrotne, które są otrzymywane podczas demonstracji sprintu i UAT sprintu, są zestawiane i dodawane z powrotem do rejestru produktu, który jest stale weryfikowany i uszeregowany pod względem ważności. Dlatego w zwinnym świecie użytkownicy biznesowi są bliżej projektu i częściej oceniają to samo pod kątem jego wykorzystania, w przeciwieństwie do tradycyjnych projektów kaskadowych.

Zespół UAT – Role & Obowiązki

Typowa organizacja UAT miałaby następujące role i obowiązki. Zespół UAT byłby wspierany przez kierownika projektu, zespoły programistyczne i testujące w zależności od ich potrzeb.

7 wyzwań UAT I plan łagodzenia skutków

Nie ma znaczenia, czy jesteś częścią wydania wartego miliardy dolarów, czy zespołu start-upowego, powinieneś przezwyciężyć wszystkie te wyzwania, aby dostarczyć udane oprogramowanie dla użytkownika końcowego.

# 1) Konfiguracja i proces wdrażania środowiska:

Przeprowadzenie tego testu w tym samym środowisku, którego używa zespół testów funkcjonalnych, z pewnością zakończy się przeoczeniem rzeczywistych przypadków użycia. Ponadto kluczowe czynności testowe, takie jak testy wydajnościowe, nie mogą być przeprowadzane w środowisku testowym z niekompletnymi danymi testowymi.

Dla tego testu należy skonfigurować oddzielne środowisko podobne do produkcyjnego.

Po oddzieleniu środowiska UAT od środowiska testowego należy skutecznie kontrolować cykl wydawniczy. Niekontrolowany cykl wydawniczy może prowadzić do różnych wersji oprogramowania w środowisku testowym i UAT. Cenny czas testów akceptacyjnych jest marnowany, gdy oprogramowanie nie jest testowane w najnowszej wersji.

Tymczasem czas potrzebny na śledzenie problemów w niewłaściwej wersji oprogramowania jest długi.

# 2) Test Planowanie:

To testowanie należy zaplanować z jasnym planem testów akceptacyjnych w fazie analizy wymagań i projektowania.

W planowaniu strategii należy zidentyfikować zestaw rzeczywistych przypadków użycia do wykonania. Zdefiniowanie celów testów jest bardzo ważne, ponieważ pełne wykonanie testów nie jest możliwe w przypadku dużych aplikacji w tej fazie testowania. Testowanie powinno być przeprowadzane najpierw poprzez ustalenie priorytetów krytycznych celów biznesowych.

Testowanie to jest przeprowadzane na koniec cyklu testowania. Oczywiście jest to najbardziej krytyczny okres dla wydania oprogramowania. Opóźnienie w którymkolwiek z poprzednich etapów rozwoju i testowania pochłonie czas UAT.

Nieprawidłowe planowanie testów, w najgorszych przypadkach, prowadzi do nakładania się testów systemowych i UAT. Ze względu na mniej czasu i presję dotrzymywania terminów oprogramowanie jest wdrażane w tym środowisku, nawet jeśli testy funkcjonalne nie zostały zakończone. W takich sytuacjach nie można osiągnąć głównych celów tego testu.

Plan testów UAT powinien zostać przygotowany i przekazany zespołowi na długo przed rozpoczęciem testu. Pomoże im to w planowaniu testów, pisaniu przypadków testowych & skryptów testowych i tworzeniu środowiska UAT.

# 3) Obsługa nowych wymagań biznesowych jako incydentów / defektów:

Niejednoznaczności w wymaganiach są wychwytywane w fazie UAT. Testerzy UAT znajdują problemy wynikające z niejednoznacznych wymagań (patrząc na cały interfejs użytkownika, który nie był dostępny podczas fazy zbierania wymagań) i rejestrują go jako defekt.

Klient oczekuje, że zostaną one poprawione w bieżącej wersji bez uwzględnienia czasu na żądania zmian. Jeśli kierownictwo projektu nie podejmie na czas decyzji w sprawie tych wprowadzonych w ostatniej chwili zmian, może to doprowadzić do niepowodzenia wydania.

# 4) Niewykwalifikowani testerzy lub testerzy bez wiedzy biznesowej:

Gdy nie ma stałego zespołu, firma wybiera pracowników UAT z różnych wewnętrznych działów.

Nawet jeśli pracownicy dobrze znają potrzeby biznesowe lub nie są przeszkoleni w zakresie nowych wymagań, które są są rozwijane, nie mogą wykonywać efektywnego UAT. Ponadto nietechniczny zespół biznesowy może napotkać wiele trudności technicznych podczas wykonywania przypadków testowych.

Tymczasem przydzielanie testerów na koniec cyklu UAT nie wnosi żadnej wartości do projektu. Niewiele czasu na przeszkolenie personelu UAT może znacznie zwiększyć szanse na sukces UAT.

# 5) Niewłaściwy kanał komunikacji:

Komunikacja między zdalnym programistą, testowaniem i zespołem UAT jest trudniejsza . Komunikacja e-mailowa jest często bardzo trudna, gdy masz zespół techniczny offshore. Mała niejednoznaczność w raportach incydentów może opóźnić naprawę o jeden dzień.

Właściwe planowanie i skuteczna komunikacja mają kluczowe znaczenie dla efektywnej współpracy zespołowej. Zespoły projektowe powinny używać narzędzia internetowego do rejestrowania defektów i pytań. Pomoże to równomiernie rozłożyć obciążenie i uniknąć zgłaszania podwójnych problemów.

# 6) Poproszenie zespołu testerów funkcjonalnych o wykonanie tego testu:

Nie ma gorszej sytuacji niż zadanie testu funkcjonalnego zespół do wykonania UAT.

Klienci przerzucają swoją odpowiedzialność na zespół testowy z powodu braku zasobów. W takich przypadkach cały cel tego testu jest zagrożony. Gdy oprogramowanie zostanie uruchomione, użytkownicy końcowi szybko zauważą problemy, które nie są traktowane jako rzeczywiste scenariusze przez testerów funkcjonalnych.

Rozwiązaniem tego problemu jest przydzielenie tych testów dedykowanym i wykwalifikowanym testerzy posiadający wiedzę biznesową.

# 7) Gra w obwinianie

Czasami użytkownicy biznesowi po prostu próbują znaleźć powody do odrzucenia oprogramowania. Może to być ich samoświadomość, aby pokazać, jak są lepsi lub obwiniać zespół programistów i testerów o zdobycie szacunku w zespole biznesowym. Jest to bardzo rzadkie, ale zdarza się w zespołach o wewnętrznej polityce.

Bardzo trudno jest poradzić sobie w takich sytuacjach. Jednak budowanie pozytywnych relacji z zespołem biznesowym zdecydowanie pomogłoby w uniknięciu obwiniania.

Mam nadzieję, że te wskazówki z pewnością pomogą Ci zrealizować plan akceptacji użytkowników, pokonując różne wyzwania. Właściwe planowanie, komunikacja, wykonanie i zmotywowany zespół są kluczem do pomyślnego testowania akceptacji przez użytkownika.

Testowanie systemu a testowanie akceptacji przez użytkownika

Zaangażowanie zespołu testowego zaczyna się dość wcześnie projektu już od fazy analizy wymagań.

Przez cały cykl życia projektu przeprowadzana jest pewnego rodzaju walidacja projektu, tj. testy statyczne, testy jednostkowe, testy systemowe, testy integracyjne, testy od końca do końca lub testy regresji. To daje nam lepsze zrozumienie testów przeprowadzonych w fazie UAT i tego, jak różnią się one od innych testów przeprowadzonych wcześniej.

Chociaż widzimy różnice w SIT i UAT, ważne jest, abyśmy wykorzystali synergie ale nadal zachować niezależność między obiema fazami, co umożliwiłoby szybsze wprowadzenie na rynek.

Wniosek

# 1) W UAT nie chodzi o strony, pola czy przyciski. Podstawowym założeniem, jeszcze przed rozpoczęciem tego testu, jest to, że wszystkie podstawowe rzeczy są testowane i działają dobrze. Nie daj Boże, użytkownicy uważają błąd za tak prosty – to bardzo zła wiadomość dla zespołu kontroli jakości. 🙁

# 2) To testowanie dotyczy podmiotu, który jest podstawowym elementem w biznesie.

Podam przykład: Jeśli AUT jest systemem biletowym, UAT nie będzie polegać na szukaniu menu otwierającego stronę itp. Chodzi o bilety i ich rezerwację, stany, które może zabrać, jego podróż przez system itp.

Inny przykład: jeśli witryna jest witryną dealera samochodowego, wówczas nacisk kładzie się na „samochód i jego sprzedaż”, a nie na witrynę. Dlatego podstawową działalnością jest to, co jest zweryfikowane i zatwierdzone, a kto lepiej to zrobić niż właścicieli firm. Dlatego to testowanie jest najbardziej sensowne, gdy klient jest w dużym stopniu zaangażowany.

# 3) UAT jest również formą testowania w swej istocie, co oznacza, że istnieje duża szansa na identyfikacja niektórych błędów również na tym etapie. Czasami się zdarza. Poza faktem, że jest to poważna eskalacja w zespole ds. kontroli jakości, błędy UAT zwykle oznaczają spotkanie, w którym należy posiedzieć i omówić, jak sobie z nimi poradzić. skrzydło tych testów zwykle nie ma czasu na naprawę i ponowne przetestowanie.

Decyzja byłaby taka, aby:

• Przesłać datę uruchomienia, najpierw naprawić problem, a następnie przejdź dalej.
• Zostaw błąd tak, jak jest.
• Potraktuj to jako część prośby o zmianę dla przyszłych wersji.

# 4) UAT jest klasyfikowany jako testy alfa i beta, ale ta klasyfikacja nie jest tak ważna w kontekście typowych projektów rozwoju oprogramowania w branży usługowej.

• Testy alfa mają miejsce, gdy UAT jest przeprowadzany w środowisku konstruktora oprogramowania i ma większe znaczenie w kontekście komercyjnej gotówki oprogramowania.
• Testy beta mają miejsce, gdy UAT jest przeprowadzany w środowisku produkcyjnym lub środowisku klienta. Jest to bardziej powszechne w przypadku aplikacji przeznaczonych dla klientów. Użytkownicy są tutaj rzeczywistymi klientami, takimi jak ty i ja w tym kontekście.

# 5) W większości przypadków w zwykłym projekcie tworzenia oprogramowania UAT jest przeprowadzane w środowisku kontroli jakości, jeśli to nie jest środowisko przejściowe ani UAT.

Krótko mówiąc, najlepszym sposobem na sprawdzenie, czy produkt jest akceptowalny i czy nadaje się do celu, jest pokazanie go użytkownikom.

Organizacje wkraczają w zwinny sposób dostarczania, użytkownicy biznesowi są coraz bardziej zaangażowani, a projekty są ulepszane i dostarczane za pośrednictwem pętli informacji zwrotnych. Po wykonaniu tych czynności faza akceptacji użytkownika jest uważana za bramę do wdrożenia i produkcji.

Jakie były Twoje doświadczenia związane z UAT? Czy byłeś w trybie gotowości, czy testowałeś dla swoich użytkowników? Czy użytkownicy znaleźli jakieś problemy? Jeśli tak, jak sobie z nimi radziłeś?

= > Przeczytaj również WSZYSTKIE samouczki z tej serii tutaj

= > Odwiedź tutaj, aby zapoznać się z serią samouczków dotyczących pełnego planu testów