Menu

Przykładowy szablon raportu z testu akceptacji z przykładami

sample template acceptance test report with examples

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Przegląd raportu z testów akceptacyjnych (część III):

Poprzedni samouczek | NEXT Tutorial

W naszym poprzednim samouczku dotyczącym „ Dokumentacja testów akceptacyjnych ze scenariuszami w czasie rzeczywistym ”Omawialiśmy plan testów akceptacyjnych.

W tym samouczku przyjrzymy się dogłębnie raportowaniu statusu testu akceptacji, podsumowaniu testu akceptacji i podpisaniu.

W tym samouczku zawarto kilka ogólnych szablonów, które mają na celu lepsze zrozumienie. Umieścimy również kursor myszy nad koncepcją testów akceptacyjnych w programowaniu zwinnym i programowaniu opartym na testach akceptacji.

W skrócie, ten samouczek wyjaśni Ci raport stanu testów akceptacyjnych i raport podsumowujący wraz z niektórymi ogólnymi szablonami dla jasnego zrozumienia, a także w łatwy do zrozumienia sposób omówi koncepcję testów akceptacyjnych w programowaniu zwinnym i sterowanym testami.

Szablon testu akceptacji

Czego się nauczysz:

Raport ze stanu testu akceptacji

Raport z testu akceptacyjnego powinien zawsze zawierać podsumowanie przeprowadzonych testów akceptacyjnych wraz z ich wynikami. Powinien być skierowany do wszystkich zidentyfikowanych interesariuszy, którzy uczestniczą w fazie testów akceptacyjnych. Po rozpoczęciu wykonywania testów akceptacyjnych postęp powinien być codziennie raportowany.

Ogólny szablon raportu o stanie testu akceptacji:

Data :Data raportu ze stanu testu akceptacji

Szczegóły wykonania dzisiejszych testów akceptacyjnych:

  • Liczba zdanych testów
  • Liczba testów zakończonych niepowodzeniem
  • Liczba testów w toku

Szczegóły wykonania testów akceptacyjnych do daty:

  • Całkowita liczba testów
  • Liczba zdanych testów
  • Liczba testów zakończonych niepowodzeniem
  • Liczba testów w toku
  • Liczba oczekujących testów

Szczegóły usterek:

zmień char na int c ++
  • Liczba zarejestrowanych usterek
  • Każda wada powinna zawierać poniższe szczegóły:
    • ID, podsumowanie, składnik, ważność
  • Całkowita liczba usterek zarejestrowanych do tej pory (w fazie testów akceptacyjnych).

Raport ten musi być codziennie weryfikowany, aby upewnić się, że realizacja przebiega zgodnie z planem i nie ma odchyleń od zaplanowanych harmonogramów.

Raport podsumowujący test akceptacji

To jest raport podsumowujący stan całej fazy testów akceptacyjnych. Obejmuje to szczegóły, takie jak przeprowadzone czynności testowe, odniesienia do spełnionych kryteriów, specyfikacje wymagań, reguły biznesowe, wyniki wykonania, planowane harmonogramy, odchylenia itp.

Ogólny szablon raportu podsumowującego test akceptacji:

Podsumowanie

Różnice

Różnice

Wyniki

Raporty

Ocena

Rekomendacje

stopień wady , a wskaźnik pozytywnego wyniku wpływa na rekomendację produktu do wprowadzenia na rynek.>

Starania

Starania

Raport z podpisu

Gdy Produkt przejdzie testy akceptacyjne, zostanie zalecony, aby rozpocząć transmisję na żywo. Zanim zostanie wprowadzony do produkcji, musi zostać formalnie podpisany.

Ogólny szablon raportu z podpisu:

Nazwa produktu, wersja wydania, numer kompilacji

Najnowszy raport

Data recenzji

Zrecenzowany przez

Komentarze do recenzji

Data podpisania

Podpisanie przez

Komentarze do podpisu

Ogólnie rzecz biorąc, każdy z powyższych raportów powinien zostać przejrzany przez głównych interesariuszy pod kątem jego wzoru i musi zostać uzgodniony, jakie informacje mają znaleźć się w nim.

Wszystkie szczegóły zawarte w raporcie powinny zostać sprawdzone krzyżowo przed udostępnieniem go zainteresowanym stronom. Wszelkie rozbieżności w raporcie będą miały duży wpływ na decyzję biznesową i mogą spowodować awarię produktu na rynku.

Dlatego raportowaniem powinni zawsze zajmować się specjaliści lub starsi członkowie zespołu.

Testy akceptacyjne w Agile

W Zwinny , Kryteria akceptacji każdej historyjki użytkownika są przeznaczone do testów akceptacji, tj. Testy akceptacji są wyprowadzane z kryteriów akceptacji historyjki użytkownika. Każde kryterium akceptacji może mieć jeden lub więcej testów akceptacji obejmujących scenariusz.

Testy akceptacyjne są zwykle projektowane przez osobę odpowiedzialną za kontrolę jakości, która jest ekspertem w danej dziedzinie. Testy akceptacyjne w Agile rozpoczynają się znacznie wcześnie w porównaniu z innymi podejściami, zwykle w ramach samych sprintów.

Jest wykonywany bardzo często, ponieważ przy każdym sprincie pojawią się nowe historie użytkownika, a także ulepszenia / kontynuacja poprzednich historii.

Testy akceptacyjne są wykonywane na dwóch różnych etapach w Agile:

  • Kiedy funkcja jest tworzona i na jej początkowym etapie - podstawowa.
  • Gdy funkcja jest zintegrowana i ustabilizowana z innymi funkcjami produktu.

Każda historia użytkownika tutaj musi przejść test akceptacji i powinna zostać przekazana do rozpatrzenia. Wszelkie błędy w teście akceptacji powinny być traktowane jako priorytetowe i natychmiast naprawiane, a ten z kolei będzie miał test akceptacyjny, aby go wykonać.

Punkty za historię są przyznawane za każdą historyjkę użytkownika w oparciu o sukces wyników testu akceptacji dla każdego z kryteriów akceptacji. Testowanie akceptacyjne definiuje również zakończenie na poziomie historii użytkownika, stwierdzając, że kryteria akceptacji dla narracji są spełnione.

Kto przeprowadza testy akceptacyjne w Agile?

Zazwyczaj menedżerowie produktu, eksperci w zakresie zagadnień (mogą to być klienci ORAZ testerzy wersji beta) przeprowadzają testy akceptacyjne w środowisku zwinnym. Czasami QA również angażuje się w tę czynność wraz z jej zwykłymi zadaniami regresji.

Korzyści z testów akceptacyjnych w Agile

Testowanie akceptacyjne w Agile ma kilka zalet.

Korzyści to:

  • Bliższa współpraca między menedżerem produktu a zespołem.
  • Buduje zaufanie na poziomie historii użytkownika.
  • Pomoże w uzyskaniu większej liczby scenariuszy obejmujących wszystkie kryteria akceptacji.
  • Zwiększone prawdopodobieństwo improwizacji rozwiązań produktu poprzez kryteria akceptacji w Historiach użytkowników.

Wady

Chociaż jest kilka zalet, są też pewne wady.

Wady obejmują:

  • Nie wszystkie historie można wziąć pod uwagę do testów akceptacyjnych. Tylko historie funkcjonalne do omówienia - relacje fabularne mogą spaść.
  • Nie wszystkie kryteria akceptacji mogą być brane pod uwagę w testach akceptacji. Uwzględniane są tylko kryteria funkcjonalne - Kryteria akceptacji mądre uwzględnienie w Historii użytkownika może spaść.
  • Ponieważ zaangażowani są interesariusze z różnych środowisk, a testy akceptacyjne oparte na fabule są przeprowadzane bezpośrednio, trudno jest wszystkim być na tej samej stronie (zasadniczo w zrozumieniu poziomu w indywidualnej historii użytkownika).
  • Ponieważ czas trwania wydania jest krótszy w porównaniu z innymi podejściami, dość trudno jest uwzględnić testy akceptacyjne w sprintach.

Rozwój oparty na testach akceptacyjnych (ATDD)

Jest to jedna z praktyk rozwoju Agile, w której cały zespół wspólnie omawia każde z kryteriów akceptacji historii użytkownika i tworzy wokół nich silne testy akceptacji.

Dzieje się tak, ponieważ różne punkty widzenia każdego członka zespołu dadzą nowy sposób myślenia dla każdego z kryteriów akceptacji i przyniosą dużą liczbę testów akceptacyjnych obejmujących więcej scenariuszy. Czasami, ATDD nazywany jest również Story Test Driven Development (STDD).

W rzeczywistości ATDD ma miejsce przed rozpoczęciem rozwoju. Tak więc programiści w tym podejściu będą wiedzieć, czego faktycznie się oczekuje i jak to osiągnąć. Cały zespół podzieli się wspólnym zrozumieniem funkcji i tego, co jest budowane.

Opisuje, w jaki sposób produkt jest budowany, a z kolei daje rzetelne wyobrażenie o tym, jak produkt będzie faktycznie funkcjonował, zanim zostanie przekazany do testów. Dlatego jest określany jako „ Rozwój oparty na testach akceptacyjnych ”.

Wniosek

Testy akceptacyjne w każdym podejściu mają wspólny cel, jakim jest budowanie zaufania Klienta i satysfakcji z produktu, który został opracowany przed wprowadzeniem go na rynek. Osiąga się to tylko wtedy, gdy w produkcie nie ma / jest mniej wad o niewielkim nasileniu, które nie utrudniają żadnej funkcjonalności.

W skrócie:

  • Testy akceptacyjne są zaliczone.
  • Wady są na akceptowalnym poziomie.
  • Osiągnięto pokrycie według przepływu / scenariusza.
  • Produkt i jego rozwiązania są akceptowane.
  • Klient jest wystarczająco pewny produktu.
  • Wszystkie dokumenty produktu są aktualizowane, aby odpowiadały najnowszym funkcjom.
  • Wynik za wysiłek zespołu.
  • Dobrze iść naprzód z uruchomieniem produkcji.

Poprzedni samouczek | NEXT Tutorial

Mam nadzieję, że dzięki tym samouczkom dotyczącym testów akceptacyjnych zdobyłbyś ogromną wiedzę. Zapraszam do podzielenia się swoimi przemyśleniami i zadawania pytań w sekcji komentarzy poniżej.

rekomendowane lektury

^