Menu

Dokumentacja testów akceptacyjnych ze scenariuszami w czasie rzeczywistym

acceptance testing documentation with real time scenarios

Dokumentacja testów akceptacyjnych (część II):



Poprzedni samouczek | NEXT Tutorial



Ten samouczek jest kontynuacją naszego poprzedniego samouczka, w którym omawialiśmy, czym są testy akceptacyjne, kiedy należy je wykonać, kto to robi, ich znaczenie, rodzaje, proces, wpływ na różne zespoły itp.

Dokumenty odgrywają bardzo ważną rolę w testach akceptacyjnych, a wszelkie kwestie związane z dokumentem mają ogromny negatywny wpływ. Brak odpowiedniej kontroli może nawet doprowadzić do Awarii Produktu.



=> Kliknij tutaj, aby uzyskać pełną serię samouczków dotyczących planu testów

W tym samouczku dowiemy się więcej o różnych dokumentach związanych z testami akceptacyjnymi, tj. Plan testów akceptacyjnych, lista kontrolna przeglądu planu testów, szablon testów akceptacyjnych, przykłady oparte na scenariuszach w czasie rzeczywistym, jak szczegółowo identyfikować i pisać testy akceptacyjne itp. .



Dokumentacja testów akceptacyjnych

Czego się nauczysz:

Plan testów akceptacyjnych

Podobnie jak każdy inny plan testów, plan testów akceptacyjnych zawiera również niektóre elementy, takie jak zakres, podejście, środowisko testowe, zasoby, obowiązki, odniesienia do testów akceptacyjnych, kryteria wejściowe, kryteria zakończenia, narzędzia itp.

Jedyną rzeczą, która odróżnia plan testów akceptacyjnych od zwykłego planu testów, są czynniki, które skutkują Decyzją Biznesową. Plan testów akceptacyjnych jest jedną z najważniejszych dokumentacji, która zawiera wskazówki dotyczące przeprowadzania testów akceptacyjnych dla konkretnego projektu.

Plan testów akceptacyjnych musi zostać przejrzany i zatwierdzony przed wykonaniem testu akceptacyjnego. Wszystkie kolejne zmiany muszą ponownie przejść proces przeglądu i zatwierdzenia i muszą być śledzone.

Przegląd planu testów akceptacyjnych jest zwykle wykonywany przez menedżerów / analityków biznesowych / klientów.

Kluczowe kwestie, które należy wziąć pod uwagę podczas projektowania planu testów akceptacyjnych:

  • Powinno być Szczegółowe i szczegółowe. Musi zawierać tylko to, co jest wymagane do testowania i jakie informacje są niezbędne zespołowi do przeprowadzenia testów.
  • Powinno być Jasne i zwięzłe . Żadnej dwuznaczności. Jeśli w ogóle jest coś, co może prowadzić do nieporozumień, opowiedz o tym, ale niech będzie krótkie i skuteczne.
  • Każdy element w dokumencie powinny być napisane z uwzględnieniem tylko wymagań biznesowych.
  • Niezawodny i elastyczny - Powinien być aktualizowany zgodnie z wymaganiami w przyszłych wersjach.
  • Zgodny - Nie powinno mieć więcej zmian w przyszłości.
  • Postępuj zgodnie z szablonem dostarczonym przez Organizację lub Klienta.

Szablon planu testów akceptacyjnych

Tutaj przyjrzymy się wspólnemu szablonowi planu testów akceptacyjnych, który można dalej modyfikować zgodnie z wymaganiami projektu.

Tytuł

Cel

Na przykład: Jeśli projekt ma służyć obsłudze pracowników Banku / Sprzedawcy / Instytutu Edukacyjnego itp., To trzeba to wyraźnie zaznaczyć. Należy również wspomnieć o przyczynie, dla której wybrano ten konkretny wymóg.>

Historia zmian / dziennik zmian

< Powinno to mieć formę tabelaryczną i zawierać poniższe informacje:

  • Data - data modyfikacji dokumentu.
  • Modyfikowane przez - Kto zmienił treść dokumentu.
  • Cel, powód - Dlaczego dokument został zmodyfikowany.
  • Wersja - Aktualna wersja dokumentu po modyfikacjach (dla konkretnego wydania 1.0, 1.1, 1.2, 1.3,…. Następne wydanie rozpocznie się od 2, 2.1, 2.2, 2.3,…, Lista jest długa).
  • Zaakceptowany przez - Kto zatwierdził wprowadzone zmiany (oznacza to niejawnie, że dokument został przejrzany i zatwierdzony).

W pierwszym wierszu tej tabeli powinny znajdować się szczegóły dotyczące utworzonego dokumentu. Następnie następuje szczegółowe informacje dotyczące wprowadzonych zmian.>

Spis treści

Bibliografia

Zakres

Przykład : Wszystkie scenariusze biznesowe).>

Wprowadzenie

Testy negatywne (nie zawsze) itp.>

Elementy testowe

Przykład : Aplikacja kliencka, aplikacja serwerowa itp.)>

Funkcje do przetestowania

Przykład : Wyszukiwanie według różnych słów kluczowych, nawigacja między modułami i podmodułami itp.), Funkcje bezpieczeństwa ( Przykład : Rejestracja na stronie, logowanie na stronie, transakcje itp.)>

Funkcje, których nie należy testować

Podejście

Przykład : Po wykonaniu wszystkich testów akceptacyjnych, testowanie eksploracyjne będą wykonywane przez bardzo krótki czas, aby ocenić łatwość i użycie produktu. Każdy napotkany błąd zostanie zarejestrowany w narzędziu do zarządzania błędami i omówiony na spotkaniach selekcji błędów dla RCA…)>

Szczegóły środowiska testowego

Przejdź do testów akceptacyjnych - część 1 ).>

Kryteria wejścia

Testy - jeśli nie ma napisanych oddzielnych testów akceptacyjnych

Każdy test musi zawierać:

  • Test #.
  • Opis tego, co jest testowane ( Przykład : Sprawdź, czy użytkownik może pomyślnie utworzyć konto).
  • Wymóg biznesowy, do którego jest mapowany ten test ( Macierz identyfikowalności ) - Bardzo ważne.
  • Warunki wstępne:
    • Stan produktu przed rozpoczęciem testów (użytkownik powinien zarejestrować się pomyślnie, ale nie aktywować konta, użytkownik powinien uzyskać dostęp do produktu co najmniej 30 dni temu itp.)
    • Dowolne warunki serwera - jeśli serwer nie działa przez jakiś czas.
  • Kroki testowe: Szczegółowy numerowany przepływ ( Przykład: patrz poniżej
    • Otwórz aplikację.
    • Spróbuj zalogować się przy użyciu prawidłowych danych logowania z zaznaczonym polem Zapamiętaj mnie).
  • Spodziewany wynik : Jakie jest oczekiwane zachowanie kroku>

Testy akceptacyjne - jeśli są napisane oddzielne testy akceptacyjne

Kryteria wyjścia

brama domyślna nie jest stale dostępna

Zasoby

Role i obowiązki

Przybory

Czynniki podejmowania decyzji biznesowych

Idź lub nie idź .>

Procedura podpisywania

Punktem kontaktowym

Plan testów akceptacyjnych jest uważany za Główny plan testów dla fazy .

Przeglądanie planu testów akceptacyjnych

Gdy plan jest gotowy, należy go przejrzeć pod kątem kompletności, niejednoznaczności, jasności, jakości itp. Bez wątpienia cała zawartość planu testów akceptacyjnych musi zostać dokładnie przejrzana w celu uzyskania odpowiednich informacji, ale musi być porównane z kilkoma innymi punktami, powiedzmy, punkty listy kontrolnej.

W tym miejscu skategoryzujmy zawartość i zobaczmy listę kontrolną, w której znajdują się punkty.

KategoriaPunkty listy kontrolnej
Tytuł Czy tytuł pasuje do tytułu projektu, o którym mowa wszędzie

Jest tytułem zgodnym z konwencjami nazewnictwa projektu
Historia wersji, spis treści Czy wszystkie modyfikacje wersji są odpowiednio śledzone w ramach planu

Czy każda zmiana wersji przeszła odpowiednią recenzję i została wspomniana

Czy konwencja wersjonowania jest poprawna

Czy spis treści jest zgodny z rzeczywistą zawartością planu

Czy numer strony dla każdej treści jest poprawny

Czy numer strony jest aktualizowany, jeśli modyfikacje wprowadzone w planie zmieniły numer strony treści
Bibliografia Czy odniesienia istnieją i są ważne

Czy pasują do zakresu

Czy są kompletne i uwzględnione przy identyfikacji testów
Elementy testowe, funkcje do przetestowania, funkcje, które nie mają być testowane Czy są policzone

Czy każda funkcja / moduł / podmoduł wchodzi w zakres

Czy zaplanowany harmonogram może obejmować wszystkie zidentyfikowane pozycje testowe w ramach?
Kryteria wejścia, kryteria wyjścia Czy są policzone

Czy wszystkie kryteria zostały szczegółowo wymienione
Szczegóły środowiska testowego Czy ma wszystkie wymienione wymagane konfiguracje

Czy wersja dla każdej konfiguracji jest specyficzna czy najnowsza do rozważenia

Czy maszyny wirtualne, środowisko istnieje (jeśli nie, podaj możliwą datę dostępności)

Czy wspomniano o metodzie udostępniania poświadczeń dla określonego dostępu do środowiska
Test wstępny Czy testy są ponumerowane

Czy warunki wstępne są ponumerowane

Czy etapy testu są zrozumiałe

Czy etapy testu zostały zakończone

Czy oczekiwany wynik jest kompletny

Czy w testach jest jakieś otwarte pytanie (jeśli takie istnieją, sprawdź je i uzupełnij)

Czy odniesienie do testów akceptacyjnych (jeśli jest napisane osobno) jest ważne i istnieje

Czy identyfikowalność jest prawidłowa

Czy brakuje jakichkolwiek wymagań biznesowych, które należy uwzględnić podczas testu?
Zasoby, role i obowiązki Czy obowiązki poszczególnych ról są ponumerowane

Czy obowiązki mogą zostać wypełnione

Czy zidentyfikowany zasób jest w stanie poradzić sobie z wymienionymi obowiązkami
Przybory Czy wszystkie wymienione narzędzia

Czy wszystkie narzędzia są ponumerowane

Czy wszystkie narzędzia są wersjonowane

Czy któreś z narzędzi wymaga licencji, czy też istniejąca licencja ważna na etapie?

Czy wskazówki dotyczące użytkowania narzędzia są prawidłowe i wystarczające?
Czynniki podejmowania decyzji biznesowych Ma wszystkie wymienione czynniki

Czy wszystkie czynniki są policzone
Procedura podpisywania Czy procedura jest prawidłowa

Czy procedura jest do przyjęcia

Czy procedura jest jasna do zrozumienia
Punktem kontaktowym Czy zasób określony jako punkt kontaktowy jest dostępny w organizacji na etapie?

Czy zidentyfikowany zasób jest w stanie obsłużyć tę fazę

Każdy plan testów spełniający powyższą listę kontrolną będzie służył jako solidny dokument również dla audytów wewnętrznych.

Test wstępny

Testy akceptacyjne były wcześniej znane jako testy funkcjonalne. Aby nazwa była bardziej odpowiednia dla fazy testów akceptacyjnych i służyła temu celowi, zmieniono jej nazwę na Test wstępny. Czasami jest również określany jako Testy klientów.

Testy akceptacji są zawsze wyprowadzane z historyjek użytkownika, kryteriów akceptacji i przypadków użycia. Są to testy systemu czarnoskrzynkowego i przedstawiają tylko te testy biznesowe, które muszą zostać zweryfikowane. Powinny być przeznaczone głównie do zachowania produktu, użytkowania i przepływów.

Zaprojektowane testy akceptacyjne można również uwzględnić w fazie testowania systemu w cyklach regresji, aby uzyskać zaufanie do produktu przed przekazaniem go do fazy testów akceptacyjnych.

Test wstępny

Najważniejsze kwestie, o których należy pamiętać przed napisaniem testów akceptacyjnych:

  • Zachowaj wszystkie dokumenty referencyjne na miejscu: Specyfikacja wymagań oprogramowania, dokument wymagań biznesowych, przypadki użycia, historie użytkowników, macierz danych (w przypadku logiki) itp.
  • Skoncentruj się tylko na wymaganiach biznesowych (testowalne wymagania biznesowe).
  • Rozwiąż wszystkie wątpliwości, pytania dotyczące wymagań biznesowych jak najwcześniej.
  • Upewnij się, że nie ma zmian w wymaganiach co najmniej dla bieżącej wersji.

Ogólny i prosty szablon do pisania testów akceptacyjnych:

Szablon testów akceptacyjnych

Ten szablon można ponownie dostosować zgodnie z potrzebami projektu i dodać więcej informacji.

Teraz weźmy kilka typowych scenariuszy i zobaczmy, jak można na nich zapisać scenariusze testów akceptacyjnych.

Przypadek 1: Obsługa konta użytkownika

Jest to scenariusz, w którym użytkownicy mogą tworzyć, wyświetlać, aktualizować i dezaktywować swoje konto. Ogólnie jest to operacja CRUD (tworzenie, odczytywanie, aktualizowanie i usuwanie). Więc bezpośrednio otrzymamy 4 główne scenariusze do przetestowania.

Oprócz tego w obsłudze kont użytkowników w czasie rzeczywistym mamy wiele obszarów, jeśli chodzi o przeglądanie i aktualizację.

Przystąpienie do pisania testów akceptacyjnych:

Test 1: Rejestracja / Zarejestruj się / Utwórz konto, sprawdź, czy Użytkownik jest w stanie:

  • Utwórz konto.
  • Aktywuj konto.
  • Aktywuj konto tylko raz (tutaj link aktywacyjny musi zostać przetestowany na 2ndChociaż jest to test negatywny, jest to jeden z głównych punktów weryfikacji, które należy wziąć pod uwagę).

Test 2: aby uzyskać dostęp do informacji o koncie i je wyświetlić, sprawdź, czy użytkownik może:

  • Zaloguj się do konta.
  • Wyświetl różne sekcje w profilu (jeśli sekcja Profil jest podzielona na kategorie, każda kategoria powinna być widoczna).
  • Sprawdź, czy dane wyświetlane w profilu są poprawne, zgodnie z danymi wprowadzonymi przez użytkownika.

Test 3: Aby zaktualizować informacje o koncie, sprawdź, czy użytkownik może:

  • Zaktualizuj informacje o koncie (profil):
    • Zaktualizuj każdą kategorię profilu.
  • Sprawdź, czy informacje o aktualizacji są poprawnie odzwierciedlone w profilu.
  • Sprawdź, czy użytkownik nie jest w stanie zaktualizować informacji w profilu (w niektórych aplikacjach imię, nazwisko, nazwa użytkownika itp. Nie będzie mogło zaktualizować. Mimo że jest to test negatywny, jest to jeden z głównych punktów weryfikacji do rozważenia).
  • Anuluj przepływ aktualizacji (mimo że jest to test negatywny, jest to również jeden z głównych punktów weryfikacji, które należy wziąć pod uwagę).

Test 4: Jeśli Dezaktywacja konta jest dozwolona, ​​sprawdź, czy Użytkownik może:

  • Dezaktywuj konto.
  • Anuluj przepływ dezaktywacji (mimo że jest to test negatywny, jest to jeden z głównych punktów weryfikacji, które należy wziąć pod uwagę).
  • Dostęp do konta po anulowaniu dezaktywacji.

Test 5: Jeśli weryfikacja adresu e-mail lub numerów telefonów jest wymagana, sprawdź, czy użytkownik jest w stanie:

  • Zaktualizuj adres e-mail na inny prawidłowy.
  • Verify ”zaktualizowany adres e-mail.
  • Sprawdź, czy zaktualizowany i „zweryfikowany” adres e-mail jest rozpatrywany dalej - wyślij kilka wiadomości e-mail z aplikacji i sprawdź, czy dotarła na zaktualizowany adres e-mail. Stary nie powinien otrzymywać e-maili.
  • Dodaj nowy numer telefonu.
  • Zweryfikuj dodany numer telefonu za pomocą połączenia.
  • Zweryfikuj dodany numer telefonu przez SMS.
  • Sprawdź, czy dodany i „zweryfikowany” numer telefonu jest widoczny na koncie.
  • Zaktualizuj numer telefonu.
  • Zweryfikuj zaktualizowany numer telefonu za pomocą połączenia.
  • Verify ”zaktualizowany numer telefonu przez SMS.
  • Sprawdź, czy zaktualizowany i „zweryfikowany” numer telefonu jest widoczny na koncie.

Przypadek 2: Zakup produktu

Zakup produktu ma zwykle ogólny przebieg.

Oto kilka ogólnych scenariuszy, na które patrzą użytkownicy końcowi:

Warunek wstępny: Użytkownik powinien być zalogowany do aplikacji.

Test 1: Szczegóły produktu, sprawdź, czy użytkownik może:

  • Zobacz stronę szczegółów produktu.
  • Wyświetl wszystkie podsekcje na stronie szczegółów produktu (opis, funkcja, informacje o marce itp.).
  • Wybierz ilość produktu, kolor, rozmiar itp. Dostępne na stronie szczegółów produktu.
  • Przejdź do kategorii, stron podkategorii ze strony Szczegóły produktu (jeśli jest dostępna na stronie Szczegóły produktu).
  • Przejdź do strony szczegółów innego produktu (jeśli podano odpowiednią sekcję produktów).
  • Zobacz komentarze i oceny produktu.
  • Sortuj komentarze dotyczące produktu na podstawie ocen.
  • Wyświetl ogólną ocenę produktu.
  • Dodaj komentarz do produktu.
  • Zaktualizuj swój komentarz do produktu.
  • Usuń jego / jej komentarz do produktu (jeśli podano).

Test 2: Dodaj do koszyka, sprawdź, czy użytkownik:

  • Możliwość dodania produktu do koszyka:
    • Poprzez stronę szczegółów produktu.
    • Poprzez stronę listy produktów.
  • Możliwość dodania wymaganej ilości do koszyka (od 1 do maksymalnego ustawionego limitu).
  • Nie można dodać produktu do koszyka, jeśli jest niedostępny.

Test 3: Na stronie koszyka sprawdź, czy użytkownik jest w stanie:

  • Wyświetl produkt w koszyku ze szczegółami ceny dla dodanej ilości.
  • Zaktualizuj ilość (od 1 do maksymalnego ustawionego limitu).
  • Usuń produkt z koszyka.
  • Wróć do zakupów.
  • Kontynułuj żeby sprawdzić.
  • Wyświetl pusty koszyk, gdy nie dodano żadnego produktu,

Test 4: na stronie szczegółów konta sprawdź, czy użytkownik może:

  • Kontynuuj z istniejącymi szczegółami wysyłki.
  • Zaktualizuj adres wysyłki.
  • Dodaj nowy adres dostawy.
  • Kontynuuj z istniejącym numerem telefonu.
  • Zaktualizuj numer telefonu do zamówienia.
  • Dodaj nowy numer telefonu do zamówienia.
  • Wróć do strony koszyka.
  • Przejdź do strony Płatności.

Test 5: Na stronie Płatności sprawdź, czy użytkownik może:

  • Sprawdź poprawność kwoty do rozliczenia.
  • Przetwarzaj zamówienie ze wszystkimi dostępnymi opcjami (jedna opcja dla każdego oddzielnego zamówienia).
  • Przetwórz transakcję pomyślnie. Przejdź do strony Potwierdzenie zamówienia.
  • Niepowodzenie transakcji (mimo że jest to test negatywny, należy go traktować jako poważny scenariusz).
  • Zastosuj kupony:
    • Ważne kupony - sukces. Tutaj zweryfikuj zmianę kwoty do rozliczenia.
    • Nieprawidłowe kupony - niepowodzenie
  • Kupony, których ważność wygasła - niepowodzenie.
  • Wróć do strony Szczegóły konta.

Przeglądanie testów akceptacyjnych

Przeglądanie testów akceptacyjnych jest ważnym zadaniem, ponieważ musi być poprawne i rzeczowe w odniesieniu do wymagań biznesowych. Ponieważ mogą być one przeprowadzane przez samych Klientów i / lub użytkowników końcowych, bardzo konieczne jest, aby były kompletne, jednoznaczne, poprawne i wystarczająco szczegółowe, aby każdy mógł je zrozumieć i wykonać.

jak pisać historyjki użytkowników i kryteria akceptacji

Przegląd Testy akceptacji muszą być przeprowadzane przez analityków biznesowych, klientów, a wszelkie komentarze do recenzji powinny być traktowane jako priorytetowe.

Na poziomie poszczególnych testów przegląd należy przeprowadzić w odniesieniu do poniższych:

  • Czy test obejmuje wymaganie biznesowe, czy nie.
  • Czy warunki wstępne są jasne?
  • Czy kroki testu są łatwe do zrozumienia i szczegółowe?
  • Czy oczekiwany wynik jest prawidłowy i jasny?
  • Czy jest odwzorowany na wymagania biznesowe dotyczące identyfikowalności?
  • Czy test jest wystarczająco kompletny, aby objąć określony przepływ lub zastosowanie?
  • Czy dany test jest wymagany jako część testów akceptacyjnych.
  • Czy istnieje punkt weryfikacji, który nie jest potrzebny do testów akceptacyjnych?
  • Czy to jest czysto funkcjonalne, czy jakikolwiek GUI jest objęty zakresem (powinien być tylko funkcjonalny).
  • Czy potrzebne są specjalne dane wejściowe? Jeśli tak, czy jest to określone dla szczegółów?

Ogólnie rzecz biorąc, cały przegląd zestawu testów akceptacyjnych powinien obejmować:

  • Dwukierunkowa identyfikowalność: Wymagania biznesowe dotyczące testów ORAZ Testy zgodności z wymaganiami biznesowymi.
  • Czy są spełnione wszystkie wymagania biznesowe?
  • Czy każde wymaganie biznesowe jest objęte co najmniej jednym testem?
  • Czy zasady biznesowe są objęte?
  • Czy rozpatrywany jest specjalny przypadek danych?
  • Ile testów jest napisanych w celu spełnienia każdego wymagania lub reguły?
  • Czy testy można grupować i klasyfikować pod kątem przepływów.
  • Czy testy są odpowiednio uporządkowane, aby wykonanie było wydajne?

Wniosek

Krótko mówiąc, jak wspomniano wcześniej, dokumenty odgrywają bardzo drastyczną rolę w testach akceptacyjnych.

Dlatego każdy napisany test akceptacyjny powinien być dobrze skonstruowany i zgodny z jego użyciem, tak aby testerzy akceptacji byli zainteresowani tym, co testują i jak to robią. To z kolei automatycznie przyniosłoby sukces.

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

Poprzedni samouczek | NEXT Tutorial

Bądź na bieżąco i uważaj na nadchodzący samouczek dotyczący testów akceptacyjnych, aby dowiedzieć się więcej o raportach z testów akceptacyjnych, a także o niektórych szablonach ogólnych. Daj nam również znać, jeśli masz jakieś pytania.

rekomendowane lektury

^