sample template acceptance test report with examples
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.
Czego się nauczysz:
- Raport ze stanu testu akceptacji
- Raport podsumowujący test akceptacji
- Testy akceptacyjne w Agile
- Kto przeprowadza testy akceptacyjne w Agile?
- Korzyści z testów akceptacyjnych w Agile
- Wady
- Rozwój oparty na testach akceptacyjnych (ATDD)
- Wniosek
- rekomendowane lektury
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
Wyniki
Ocena
Rekomendacje
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
- Przykładowy raport o błędzie
- Przykładowy szablon przypadku testowego z przykładami przypadków testowych (Pobierz)
- ISTQB Testing Certification Przykładowe pytania z odpowiedziami
- Jak napisać tygodniowy raport o stanie testów oprogramowania
- Jak napisać efektywny raport podsumowujący test (pobieranie przykładowego raportu)
- Co to jest test akceptacyjny (kompletny przewodnik)
- Najlepsze narzędzia do testowania oprogramowania 2021 (Narzędzia do automatyzacji testów QA)
- Testy funkcjonalne a testy niefunkcjonalne