Sylabus dla modułu specjalistycznego

Poziom podstawowy - Tester Akceptacyjny

wersja 1. 0.0.3 (2019)

International Software Testing Qualifications Board®

© Stowarzyszenie Jakości Systemów Informatycznych

Opracowane przez International Qualification Board for Business Analysis

Informacja o prawach autorskich:

Niniejszy dokument może być kopiowany w całości lub częściach pod warunkiem podania źródła.

Wszelkie prawa dla wersji angielskiej zastrzeżone dla © International Software Testing Qualifications Board (dalej nazywane ISTQB®).

Grupa Robocza ds. Testów Akceptacyjnych: Bruno Legeard (chair), Olivier Denoo, Debbie Friedenberg, Anne Kramer, Karolina Zmitrowicz; 2019.

Prawa autorskie dla polskiego tłumaczenia zastrzeżone ©Stowarzyszenie Jakości Systemów Informatycznych (SJSI).

Tłumaczenie z języka angielskiego oraz udział w przeglądach wersja 2019: Karolina Zmitrowicz, Jan Sabak, Lucjan Stapp.

Przegląd końcowy: Karolina Zmitrowicz, Monika Petri–Starego, Adam Roman, Jan Sabak, Lucjan Stapp.

Historia zmian

Wersja

Data

Uwagi

Wersja 1.0.0.3

10.04.2024

Podrozdział 0.8: poprawka dotycząca informacji nt. Słownika terminów testowych ISTQB ®.

Wersja 1.0.0.2

10.10.2023

Zmiana tłumaczenia podcharakterystyki jakościowej (podlegający analizie – analizowalność, łatwość ponownego użycia – możliwość ponownego wykorzystania).

Wersja 1.0.0.1

06.03.2023

Zmiana tłumaczenia podcharakterystyki jakościowej (łatwość ponownego użycia).

Zmiana numeru wersji sylabusa (wprowadzenie nowego standardu opisu wersji dla zmian wersji polskiej - czwarta liczba numeru wersji).

Wersja 1.0 (PL)

30.06.2020

Publikacja wersji polskiej.

ISTQB® publikacja

wersja 1.0.

21.06.2019

Wersja finalna.

ISTQB® GA 2019

18.03.2019

Wersja uwzględniająca komentarze z przeglądu wersji beta.

Spis treści

Historia zmian

Spis treści

Podziękowania

0. Wprowadzenie do sylabusa (planu nauczania)

0.1. Cel

0.2. Zakres

0.3. Rezultaty biznesowe

0.4. Cele nauczania objęte egzaminem

0.5. Rekomendowany czas trwania szkolenia

0.6. Standardy

0.7. Wymagania wstępne

0.8 Źródła informacji

1.      Wprowadzenie i podstawy – 80 minut

1.1. Podstawowe powiązania

1.1.1. Cele biznesowe, potrzeby biznesowe i wymagania

1.1.2. Wymagania / historyjki użytkownika, kryteria akceptacji i testy akceptacyjne

1.1.3. Znaczenie jakości wymagań

1.2. Analiza biznesowa i testy akceptacyjne

1.2.1. Relacje między czynnościami analizy biznesowej a testowaniem

1.2.2. Współpraca pomiędzy analitykami biznesowymi a testerami w testach akceptacyjnych

1.2.3. Jak testy akceptacyjne mogą kierować procesem wytwarzania: ATDD i BDD

2. Kryteria akceptacji, testy akceptacyjne  i techniki oparte  na doświadczeniu – 165 minut

2.1. Pisanie kryteriów akceptacji

2.2. Projektowanie testów akceptacyjnych

2.2.1. Techniki testowania dla testów akceptacyjnych

2.2.2. Używanie języka Gherkin do pisania przypadków testowych

2.3. Podejścia oparte na doświadczeniu w testach akceptacyjnych

2.3.1. Testowanie eksploracyjne

2.3.2. Testowanie beta

3. Modelowanie procesów i reguł biznesowych – 150 minut

3.1. Modelowanie procesów i reguł biznesowych

3.2. Pozyskiwanie testów akceptacyjnych z modeli procesów/reguł biznesowych

3.3. Modelowanie procesów biznesowych dla potrzeb testów akceptacyjnych

3.3.1. Dobre praktyki modelowania procesów biznesowych dla potrzeb testów akceptacyjnych

3.3.2. Wykorzystanie modeli procesów biznesowych dla ATDD

4. Testowanie akceptacyjne dla wymagań niefunkcjonalnych – 95 minut

4.1. Charakterystyki niefunkcjonalne i jakość w użytkowaniu

4.1.1. Charakterystyki niefunkcjonalne i podcharakterystyki jakościowe

4.1.2. Jakość w użytkowaniu

4.2. Użyteczność i doświadczenie użytkownika

4.2.1. Analiza wymagań UX

4.2.2. Testowanie użyteczności

4.3. Wydajność

4.3.1. Wysokopoziomowe testy akceptacyjne wydajności

4.3.2. Kryteria akceptacji dla testów akceptacyjnych wydajności

4.4. Zabezpieczenia

5. Wspólne testy akceptacyjne – 110 minut

5.1. Współpraca

5.2. Czynności

5.2.1. Analiza defektów

5.2.2. Raportowanie

5.2.3. Czynności zapewnienia jakości w testowaniu akceptacyjnym

5.3. Wsparcie narzędziowe

6. Skróty

7. Zarejestrowane znaki towarowe

8. Odniesienia

Standardy

Dokumenty IQBBA®

Dokumenty ISTQB®

Bibliografia

Dodatek A – Podzbiór BPMN 2.0.1 oraz DMN 1.2

A.1 Podzbiór BPMN 2.0.1

A.2. Podzbiór DMN 1.2

Podziękowania

Dokument ten został przygotowany przez główny zespół składający się z wolontariuszy z organizacji IQBBA® i ISTQB® .

Główny zespół składa podziękowania następującym osobom z Rad Krajowych IQBBA® i ISTQB®, które uczestniczyły w recenzowaniu, komentowaniu i głosowaniu nad tym sylabusem (planem nauczania): Chris Van Bael, Graham Bath, Renzo Cerquozzi, Ernst von Düring, Florian Fieber, Karol Frühauf, Beata Karpinska, Ine Lutterman, Elke Mai, Rik Marselis, Judy McKay, Jörn Münzel, Petr Neugebauer, Ingvar Nordström, Monika S. Olsen, Tal Pe'er, Lara Pellegrino, G. Pistarini, Meile Posthuma, Miroslav Renda, Jan Sabak, Lucjan Stapp, Richard M. Taylor, Stephanie Ulrich, Robert Werkhoven, Paul Weymouth.

Dokument ten został zatwierdzony do publikacji przez ISTQB® 3 maja 2019 roku. Dokument został również zatwierdzony w ramach programu certyfikacji kwalifikacji analityków biznesowych IQBBA®.

0. Wprowadzenie do sylabusa (planu nauczania)

0.1. Cel

Niniejszy sylabus (plan nauczania) jest podstawą do certyfikacji ISTQB® Tester Akceptacyjny Poziomu Podstawowego.

ISTQB® udostępnia niniejszy sylabus:

1. Radom Krajowym, celem tłumaczenia na ich języki lokalne i dokonania akredytacji dostawców szkoleń. Rady Krajowe mogą dostosowywać sylabus do potrzeb danego języka i dodawać odwołania do literatury w celu uwzględnienia publikacji lokalnych;

2. organom certyfikacyjnym w celu sformułowania pytań egzaminacyjnych w językach lokalnych (dostosowanych do celów nauczania niniejszego sylabusa);

3. dostawcom szkoleń w celu opracowania materiałów dydaktycznych i określenia odpowiednich metod nauczania;

4. kandydatom ubiegającym się o certyfikat w celu przygotowania się do egzaminu certyfikacyjnego (w ramach szkoleń lub samodzielnie);

5. międzynarodowej społeczności specjalistów w dziedzinie inżynierii oprogramowania i systemów informatycznych w celu rozwijania zawodu testera oprogramowania i systemów informatycznych oraz opracowywania książek i artykułów.

6. ISTQB® może również zezwolić innym podmiotom na korzystanie z niniejszego sylabusa do innych celów pod warunkiem wystąpienia przez te podmioty o stosowną, pisemną zgodę.

0.2. Zakres

Ocena i walidacja rozwiązania biznesowego to ważne i częste czynności wykonywane przez właścicieli produktów (Product Owner – PO), analityków biznesowych (Business Analyst – BA) i testerów. Częścią ich obowiązków jest zdefiniowanie kryteriów akceptacji wymagań, niezależnie od rodzaju cyklu życia oprogramowania - zwinnego lub tradycyjnego. Kryteria akceptacji są definiowane poprzez dekompozycję wymagań na bardziej atomową i testowalną formę. Następnie projektowane są przypadki testowe, które mają na celu sprawdzenie rozwiązania w odniesieniu do tych kryteriów. Projektowanie testów akceptacyjnych na podstawie kryteriów akceptacji powinno być czynnością silnie opartą na współpracy, angażującą analityków biznesowych i testerów, w celu zapewnienia wysokiej wartości biznesowej fazy testów akceptacyjnych i ograniczenia ryzyka związanego z wydaniem produktu.

Wspieranie tej współpracy, a tym samym unikanie efektu „silosu”[1] pomiędzy właścicielami produktów/analitykami biznesowymi a testerami, jest kluczowym celem tego sylabusa.

Kwalifikacja w zakresie testów akceptacyjnych jest skierowana do wszystkich osób zaangażowanych w czynności związane z testowaniem akceptacyjnym oprogramowania. Obejmuje ona osoby pracujące w takich rolach, jak właściciele produktów, analitycy biznesowi, testerzy, analitycy testów, inżynierowie testów, konsultanci testów, kierownicy testów, testerzy wykonujący testy akceptacyjne użytkownika i programiści.

Program nauczania skupia się na koncepcjach, metodach i praktykach współpracy pomiędzy właścicielami produktów/analitykami biznesowymi, a testerami w testach akceptacyjnych. Odnosząc się do różnych form testów akceptacyjnych zdefiniowanych w sylabusie [ISTQB_FL_SYL], sylabus ten obejmuje testy akceptacyjne użytkownika (User Acceptance Testing – UAT), testy akceptacyjne zgodności z umową i zgodności

z przepisami prawa, jak również testy  beta. Ten sylabus celowo nie obejmuje produkcyjnych testów akceptacyjnych (Operational Acceptance Testing – OAT), ponieważ są one zazwyczaj wykonywane przez zespoły przyszłych użytkowników, a nie przez testerów i analityków biznesowych.

0.3. Rezultaty biznesowe

Ten podrozdział zawiera listę rezultatów (umiejętności biznesowych) oczekiwanych od kandydata, który uzyskał certyfikat z obszaru testów akceptacyjnych Tester Akceptacyjny Poziom Podstawowy. Z uwagi na fakt, że kwalifikacja ta obejmuje trzy role: analityka biznesowego, właściciela produktu i testera, docelowe umiejętności biznesowe zostały przedstawione dla poszczególnych ról.

Dla analityków biznesowych i właścicieli produktów przewidziano następujące umiejętności biznesowe:

AcT-1

Wnoszenie wkładu w działania organizacji związane z testami akceptacyjnymi poprzez udział w fazie projektowania testów akceptacyjnych i wspieranie dostosowania produktu do wymagań biznesowych.

AcT-2

Wnoszenie wkładu w przygotowanie czynności związanych z testami akceptacyjnymi, w tym dotyczących procesu, artefaktów, komunikacji, raportowania, monitorowania i zarządzania takimi czynnościami oraz współpraca z testerami i innymi właściwymi interesariuszami tego procesu.

AcT-3

Wnoszenie wkładu w jakość procesu testowania akceptacyjnego, w tym

w walidację i weryfikację wytworzonych artefaktów.

Dla testerów:

AcT-4

Wnoszenie wkładu w definiowanie kryteriów akceptacji podczas fazy definiowania wymagań.

AcT-5

Efektywna współpraca z analitykami biznesowymi i innymi interesariuszami podczas wszystkich czynności związanych z testami akceptacyjnymi.

AcT-6

Rozumienie celów biznesowych, komunikowanie się z jednostkami biznesowymi i wyznaczanie wspólnych celów testowania akceptacyjnego.

0.4. Cele nauczania objęte egzaminem

Cele nauczania wspierają rezultaty (umiejętności biznesowe) i są wykorzystywane do tworzenia egzaminów służących uzyskaniu certyfikatu ISTQB® Tester Akceptacyjny Poziomu Podstawowego. Cele nauczania są przypisane do poziomu poznawczego wiedzy (K-Level).

Poziom K, czyli poziom poznawczy, jest wykorzystywany do klasyfikacji celów nauczania zgodnie ze zmienioną taksonomią Blooma [Anderson01]. ISTQB® wykorzystuje tę taksonomię do projektowania swoich programów nauczania.

Ten sylabus uwzględnia trzy różne poziomy K (od K1 do K3):

- K1 – Zapamiętać. Kandydat powinien zapamiętać lub rozpoznać termin lub pojęcie.

- K2 – Zrozumieć. Kandydat powinien wskazać wyjaśnienie dla stwierdzenia związanego z tematem pytania.

- K3 – Zastosować. Kandydat powinien wskazać właściwe zastosowanie koncepcji lub techniki i zastosować ją w danym kontekście.

Ogólnie rzecz ujmując, wszystkie części tego sylabusa (planu nauczania) mogą być przedmiotem egzaminu na poziomie K1. Oznacza to, że kandydat rozpozna, zapamięta i przypomni sobie dany termin lub pojęcie. Cele nauczania na poziomie K2 i K3 są przedstawione na początku odpowiedniego rozdziału.

0.5. Rekomendowany czas trwania szkolenia

W niniejszym sylabusie określono minimalny czas szkolenia dla każdego celu nauczania. W nagłówku rozdziału podano całkowity czas trwania każdego rozdziału.

Dostawcy szkoleń powinni zwrócić uwagę na to, że inne sylabusy (plany nauczania) ISTQB® stosują podejście „standardowego czasu”, które przypisuje określony czas trwania zgodnie z poziomem K (K-Level). Sylabus dla testowania akceptacyjnego nie stosuje się ściśle do tego schematu. W rezultacie, dostawcy szkoleń otrzymują bardziej elastyczne i realistyczne wskazanie minimalnego czasu szkolenia.

0.6. Standardy

W tym sylabusie przywoływane są różne standardy (IEEE, ISO itp.). Celem tych odniesień jest dostarczenie źródła dodatkowych informacji, jeśli kandydat będzie miał potrzebę zgłębienia zagadnienia. Prosimy zwrócić uwagę na to, że przedmiotem egzaminów mogą być tylko te elementy standardów, które są wyszczególnione

w sylabusie. Dokumenty standardów nie są przedmiotem egzaminu i są dołączane wyłącznie w celach informacyjnych.

Lista standardów, do których odwołuje się plan, znajduje się w rozdziale 8.

0.7. Wymagania wstępne

Przed przystąpieniem do egzaminu ISTQB® Tester Akceptacyjny Poziomu Podstawowego należy uzyskać certyfikat ISTQB® Certyfikowany Tester Poziomu Podstawowego.

0.8 Źródła informacji

Terminy użyte w sylabusie są zdefiniowane w aplikacji: Słownik terminów testowych ISTQB® [ISTQB_GLOSSARY, https://glossary.istqb.org]. W aplikacji dostępna jest polska wersja słownika.

1. Wprowadzenie i podstawy – 80 minut

Słowa kluczowe

historyjka użytkownika, kryteria akceptacji, testowanie akceptacyjne

Cele nauczania

.1 Podstawowe powiązania

AcT-1.1.1.       (K1) Kandydat potrafi przywołać związki pomiędzy celami biznesowymi, potrzebami biznesowymi a wymaganiami.

AcT-1.1.2.       (K2) Kandydat potrafi wyjaśnić związki pomiędzy wymaganiami / historyjkami użytkownika a kryteriami akceptacji oraz testami akceptacyjnymi

AcT-1.1.3.       (K2) Kandydat potrafi wyjaśnić, w jaki sposób jakość wymagań / historyjek użytkownika oraz kryteriów akceptacji wpływa na testy akceptacyjne.

.2 Analiza biznesowa i testy akceptacyjne

AcT-1.2.1.       (K2) Kandydat potrafi podać zależności pomiędzy czynnościami testów akceptacyjnych a czynnościami analizy biznesowej.

AcT-1.2.2.      (K2) Kandydat potrafi wyjaśnić, w jaki sposób testerzy i analitycy biznesowi współpracują w ramach czynności testowych.

AcT-1.2.3.       (K2) Kandydat potrafi opisać wytwarzanie sterowane testami akceptacyjnymi (ang. Acceptance Test-Driven Development – ATDD) oraz wytwarzanie sterowane zachowaniem (ang. Behaviour-Driven Development – BDD).

1.1. Podstawowe powiązania

Z pewnością prawdą jest to, że role i obowiązki testera i analityka biznesowego są różne, prawdą jest również to, że ich działania się uzupełniają: praca wykonywana przez jedną grupę może mieć duży wpływ, zarówno pozytywny, jak i negatywny, na pracę drugiej grupy. Dotyczy to w szczególności testów akceptacyjnych, które są przeprowadzane, by ocenić gotowość systemu do wdrożenia i zakres jego wykorzystania przez klienta (użytkownika końcowego). Dobra współpraca pomiędzy analitykami biznesowymi a testerami jest szczególnie ważna dla właściwego uwzględnienia konsekwencji biznesowych na tym poziomie testów.

1.1.1. Cele biznesowe, potrzeby biznesowe i wymagania

W pierwszej kolejności analitycy biznesowi muszą zrozumieć ogólne cele biznesowe organizacji klienta oraz zidentyfikować bieżące procesy biznesowe i interesariuszy. Następnie opisują oni konkretne potrzeby biznesowe i określają uzasadnienie biznesowe, które odnosi się do tych potrzeb. Po zakończeniu tej wysokopoziomowej pracy można pozyskać wymagania dla rozwiązania biznesowego, które będzie wytwarzane.

Cele biznesowe, potrzeby biznesowe, wymagania biznesowe i wymagania produktowe (definicja tych czterech terminów znajduje się w [Słownik IQBBA®]) na różnych poziomach abstrakcji opisują, co należy osiągnąć. W wytwarzaniu zwinnym (Agile) obowiązują te same zasady, ale mogą być używane różne terminy (np. cechy i historyjki użytkownika).

W niniejszym dokumencie termin „wymagania” odnosi się zarówno do wymagań biznesowych, jak i do wymagań produktowych.

1.1.2. Wymagania / historyjki użytkownika, kryteria akceptacji i testy akceptacyjne

Podczas pozyskiwania wymagań, analitycy biznesowi i testerzy (ewentualnie wspólnie  z programistami) powinni zacząć tworzyć szczegółowe kryteria akceptacji i wspólnie opracowywać testy akceptacyjne. Zapewnia to wzajemne zrozumienie już na samym początku projektu tego, co pojęcie „akceptowalne” oznacza z punktu widzenia biznesu, procesu wytwórczego i testowania.

Kryteria akceptacji odnoszą się bezpośrednio do konkretnych wymagań lub historyjek użytkownika. Są one albo częścią szczegółowego opisu, albo atrybutem powiązanego wymagania. Jeśli stosowane są historyjki użytkownika, kryteria akceptacji są częścią definicji historyjki użytkownika i rozszerzają daną historyjkę [ISTQB_FL_SYL].

We wszystkich przypadkach kryteria akceptacji to mierzalne kryteria sformułowane w formie stwierdzenia (lub zbioru stwierdzeń), prawdziwych lub fałszywych. Służą one do sprawdzenia, czy wymaganie lub historyjka użytkownika zostały zaimplementowane zgodnie z oczekiwaniami. Kryteria akceptacji reprezentują warunki testowe, które określają to, „co” należy testować. Nie zawierają one szczegółowych przypadków testowych.

Przypadki testowe opracowane dla potrzeb testów akceptacyjnych wynikają z kryteriów akceptacji. Przypadki te określają, w jaki sposób należy przeprowadzić sprawdzenie kryteriów akceptacji.

1.1.3. Znaczenie jakości wymagań

Jeśli kryteria akceptacji i testy oparte są na niejasnych lub niejednoznacznych wymaganiach, historyjkach użytkownika, a same testy oparte są na niejasnych kryteriach akceptacji, istnieje prawdopodobieństwo, że testerzy przyjmą pewne założenia dotyczące oczekiwań interesariuszy i potrzeb biznesowych. W tym przypadku wyniki testów akceptacyjnych mogą być błędne. Doprowadzi to do ich ponownego opracowania lub, co gorsza, przeprowadzenia nieprawidłowych testów, co spowoduje wygenerowanie zarówno niepotrzebnych kosztów, jak i wystąpienie ryzyka i niepewności co do zapewnienia jakości produktu.

Istotne jest, aby testerzy ściśle współpracowali z analitykami biznesowymi w celu upewnienia się, że wymagania są jasne i dobrze zrozumiałe dla wszystkich interesariuszy. Niejasności powinny zostać rozwiązane, a założenia powinny zostać wyjaśnione tak, aby opracowane testy akceptacyjne były poprawne i stanowiły skuteczny sposób określenia gotowości do wydania produktu.

W podejściu zwinnym kryteria INVEST [Cohn04] (ang. INVEST Independent, Negotiable, Valuable, Estimable, Small, Testable) określają zestaw kryteriów lub listę kontrolną służącą do tego, aby ocenić jakość historyjek użytkownika. Mogą one być wykorzystywane przez analityków biznesowych/właścicieli produktu, programistów i testerów w celu zapewnienia jakości historyjek użytkownika (por. ISTQB® Foundation Level Agile Tester syllabus [ISTQB_FL_AT_SYL]). Standard ISO/IEC/IEEE 29148:2011 [ISO/IEC 29148:2011] opisuje dobre praktyki procesu inżynierii wymagań mające na celu zapewnienie wymagań o wysokiej jakości.

1.2. Analiza biznesowa i testy akceptacyjne

Zbyt często analitycy biznesowi i testerzy pracują we własnych "silosach"[2], co może prowadzić do nieporozumień dotyczących oczekiwań biznesu i oczekiwań klientów. Te nieporozumienia mogą być ukryte, aż do momentu wydania produktu. Wykorzystując uzupełniające się umiejętności i współpracując ze sobą analitycy biznesowi i testerzy mogą pozytywnie wpłynąć na proces wytwarzania. Można to osiągnąć zarówno poprzez jak najwcześniejsze rozpatrzenie kryteriów akceptacji i projektów testów akceptacyjnych, jak i poprzez koordynację wysiłków mających na celu upewnienie się, że produkt został odpowiednio przetestowany na poziomie testów akceptacyjnych przed jego wydaniem.

1.2.1. Relacje między czynnościami analizy biznesowej a testowaniem

Poniżej przedstawiono główne elementy analizy biznesowej wg IQBBA® [IQBBA_FL_SYL]:

- Definicja strategii,

- Zarządzanie procesami analizy biznesowej,

- Inżynieria wymagań w analizie biznesowej,

- Ocena i optymalizacja rozwiązania.

Analityk biznesowy jest odpowiedzialny za identyfikację potrzeb biznesowych interesariuszy i określanie rozwiązań dla ich problemów biznesowych, by wprowadzić zmiany wnoszące wartość dodaną dla biznesu [IQBBA_FL_SYL]. Ważnym aspektem roli analityka biznesowego jest doprowadzenie do konsensusu pomiędzy inżynierami jakości, testerami, programistami, integratorami systemów, kierownikami produktów a kierownikami projektów.

Proces testowy składa się z następujących głównych grup czynności [ISTQB_FL_SYL]:

- Planowanie testów,

- Monitorowanie testów i nadzór nad testami,

- Analiza testów,

- Projektowanie testów,

- Implementacja testów,

- Wykonanie testów,

- Ukończenie testów.

Sporo czynności i zadań związanych z procesem testowym dotyczy zarówno analizy biznesowej, jak i testowania. Poniższe przykłady ilustrują związek pomiędzy tymi dwiema dyscyplinami w kontekście testów akceptacyjnych.

Inżynieria wymagań w analizie biznesowej a planowanie testów, analiza testów i projektowanie testów:

- Podczas działań związanych z inżynierią wymagań w analizie biznesowej analitycy biznesowi przygotowują szczegółowe wymagania biznesowe

i produktowe. Wymagania te stanowią część podstawy testów służącej planowaniu testów, analizie testów i projektowaniu testów, ponieważ testerzy definiują swoje cele i planują swoją pracę, oceniając specyfikacje i wymagania, identyfikując warunki testowe i projektując przypadki testowe oraz procedury testowe.

- Testerzy mogą przyczynić się do zdefiniowania i oceny poprawności kryteriów akceptacji w ramach analizy i projektowania testów. Pracując razem, przedstawiciele obu ról upewniają się, że rozwiązanie jest właściwie rozumiane

i uzgadniają odpowiednie podejście do testów akceptacyjnych.

- Kiedy wymagania ulegają zmianie, analitycy biznesowi i testerzy mogą współpracować, by ocenić wpływ zmian.

Ocena rozwiązania w analizie biznesowej a implementacja, wykonanie i ukończenie testów:

- Podczas fazy oceny rozwiązania w analizie biznesowej analitycy biznesowi wspierają czynności implementacji i wykonania testów. Dokonują oni przeglądu procedur/skryptów testowych opracowanych przez testerów, wyjaśniają problemy, mogą także pomóc w tworzeniu danych testowych wspierających testy biznesowe.

- Analitycy biznesowi mogą pomóc w implementacji i wykonaniu testów akceptacyjnych. Mogą również wspierać testerów poprzez ocenę wyników testów. Ponadto mogą oni pomagać testerom w działaniach związanych

z ukończeniem testów.

Istnieje silna i symbiotyczna relacja pomiędzy obiema rolami i ich odpowiednimi działaniami, zaczynając od samego początku projektu i kończąc na akceptacji lub wydaniu rozwiązania.

1.2.2. Współpraca pomiędzy analitykami biznesowymi a testerami w testach akceptacyjnych

Wspólnym celem analityków biznesowych i testerów jest wsparcie wytwarzania produktów o najwyższej możliwej wartości dla klienta. Biorąc pod uwagę ich pozycję

w organizacji, analitycy biznesowi i testerzy mają różne możliwości współpracy podczas przeprowadzania testów akceptacyjnych opisanych w poprzednim punkcie. Oprócz wspólnych dyskusji i przeglądów wytworzonych artefaktów, analitycy biznesowi

i testerzy współpracują też w innych obszarach. Na przykład, współpraca w zakresie planowania testów w oparciu o analizę ryzyka jest dobrą okazją do zapewnienia, że zostaną odpowiednio opracowane i spriorytetyzowane przypadki testowe.

Oprócz bezpośrednich korzyści płynących ze wspólnej pracy i wzajemnego wsparcia podczas testów akceptacyjnych, pojawia się istotna możliwość wzajemnego szkolenia członków zespołu. Im więcej testerów zna potrzeby biznesowe i wymagania interesariuszy oraz im więcej analityków biznesowych zna się na ustrukturyzowanym testowaniu, tym większe prawdopodobieństwo, że obie grupy zrozumieją i docenią wzajemnie swoją pracę i będą lepiej współpracować w ramach projektu.

1.2.3. Jak testy akceptacyjne mogą kierować procesem wytwarzania: ATDD i BDD

Szeroka akceptacja praktyk zwinnego rozwoju oprogramowania wpłynęła na sposób,

w jaki testowanie akceptacyjne jest powiązane z pozyskiwaniem wymagań i innymi czynnościami związanymi z analizą biznesową. W modelach sekwencyjnego cyklu życia oprogramowania, analiza, projektowanie i implementacja testów akceptacyjnych są czynnościami, które mają być wykonywane przez testerów po opracowaniu wymagań. Dzięki zwinnemu modelowi cyklu życia oprogramowania, kryteria akceptacji i przypadki testowe dla testów akceptacyjnych są tworzone podczas analizy wymagań, sesji doprecyzowywania wymagań i uszczegółowienia backlogu produktu (ang. Product Backlog). Pozwala to na wdrożenie zasady "wczesne testowanie" (ang. Early Testing) poprzez wykorzystanie projektowania przypadków testowych jako elementów czynności związanych z definiowaniem wymagań.

W następujących dwóch podejściach analiza i projektowanie testów akceptacyjnych są formalnie częścią procesu inżynierii wymagań:

- W wytwarzaniu sterowanym testami akceptacyjnymi (ang. Acceptance Test-Driven Development (ATDD)) [Pugh11] testy akceptacyjne są opracowywane wspólnie podczas analizy wymagań przez analityków biznesowych, właścicieli produktu, testerów i programistów.

- Wytwarzanie sterowane zachowaniem (ang. Behaviour-Driven Development (BDD)) [Smart14] wykorzystuje specyficzny dla tej domeny język skryptowy Gherkin, oparty na stwierdzeniach w języku naturalnym. Wymagania są zdefiniowane w formacie „Mając – Kiedy – Wtedy” (ang."Given - When -Then"). Wymagania te stają się przypadkami testowymi dla testów akceptacyjnych i służą również jako podstawa przy automatyzacji testów. Więcej informacji na temat języka Gherkin znajduje się w punkcie 2.2.2.

Oba te podejścia angażują cały zespół zwinny i pomagają skoncentrować prace wytwórcze na celach biznesowych. Podejścia te traktują również przypadki testowe dla testów akceptacyjnych jako żywą dokumentację produktu, ponieważ mogą być czytane i rozumiane przez analityków biznesowych i innych interesariuszy. Przypadki testowe dla testów akceptacyjnych reprezentują scenariusze użycia produktu.

Oba te podejścia są podobne i oba terminy są czasami używane zamiennie. W praktyce, BDD jest związane z wykorzystaniem języka Gherkin do wsparcia tworzenia testów akceptacyjnych, podczas gdy ATDD w projektowaniu testów opiera się na różnych formach tekstowych lub graficznych. Na przykład graficzna reprezentacja przepływów pracy aplikacji może zostać wykorzystana w wizualnym podejściu do ATDD.

2. Kryteria akceptacji, testy akceptacyjne i techniki oparte

na doświadczeniu – 165 minut

Słowa kluczowe

przypadek testowy, techniki testowania oparte na doświadczeniu, testowanie beta, testowanie eksploracyjne, testowanie oparte na słowach kluczowych

Cele nauczania

2.1. Pisanie kryteriów akceptacji

AcT-2.1.1.       (K3) Kandydat potrafi, dla danego wymagania lub historyjki użytkownika, opracować zestaw kryteriów akceptacji, spełniających kryteria dobrych praktyk.

2.2. Projektowanie testów akceptacyjnych

AcT-2.2.1.       (K2) Kandydat potrafi wyjaśnić podejścia i techniki testowania stosowane w testach akceptacyjnych.

AcT-2.2.2.      (K3) Kandydat potrafi zaprojektować testy akceptacyjne dla danej historyjki użytkownika stosując język Gherkin.

2.3. Podejścia oparte na doświadczeniu w testach akceptacyjnych

AcT-2.3.1.       (K2) Kandydat potrafi wskazać, w jaki sposób w testach akceptacyjnych można wykorzystać technikę testowania eksploracyjnego.

AcT-2.3.2.      (K2) Kandydat potrafi wskazać związek między testami beta a testami akceptacyjnymi.

2.1. Pisanie kryteriów akceptacji

Zdefiniowanie kryteriów akceptacji jest ważnym zadaniem w testach akceptacyjnych. Pomaga dopracować wymagania lub historyjki użytkowników oraz stanowi podstawę testów akceptacyjnych. Analitycy biznesowi i testerzy powinni ściśle współpracować

w zakresie określania tych kryteriów. Współpraca ta zapewnia wysoką wartość biznesową począwszy od fazy testów akceptacyjnych i zwiększa szanse na udaną iterację lub wydanie produktu.

Tworzenie kryteriów akceptacji wymusza na analitykach biznesowych i testerach myślenie o funkcjonalności, wydajności i innych cechach produktu/rozwiązania z perspektywy danego interesariusza lub przewidywanego użycia. Wspiera to wczesną weryfikację i walidację powiązanego wymagania lub historyjki użytkownika oraz daje większe szanse na wykrycie niespójności, sprzeczności, brakujących informacji lub innych problemów.

Przy pisaniu kryteriów akceptacji należy uwzględnić następujące dobre praktyki [Cohn04]:

- Dobrze napisane kryteria akceptacji są precyzyjne, mierzalne i zwięzłe. Każde kryterium musi być napisane w taki sposób, aby tester mógł zmierzyć, czy badany obiekt spełnia kryterium akceptacji.

- Dobrze napisane kryteria akceptacji nie zawierają szczegółów technicznych rozwiązania. Koncentrują się raczej na udzieleniu odpowiedzi na pytanie: "Co należy osiągnąć?" niż na udzieleniu odpowiedzi na pytanie: "Jak należy to osiągnąć?"

- Kryteria akceptacji powinny dotyczyć zarówno wymagań niefunkcjonalnych (charakterystyk jakościowych), jak i wymagań funkcjonalnych.

Podobnie jak w przypadku wymagań i historyjek użytkownika, kryteria akceptacji powinny być weryfikowane podczas przejrzeń (ang. walkthrough), przeglądów technicznych, spotkań poświęconych planowaniu iteracji lub poprzez zastosowanie innych metod (jeśli to konieczne).

2.2. Projektowanie testów akceptacyjnych

W niniejszym podrozdziale omówiono techniki i podejścia do testów często wykorzystywane w testach akceptacyjnych.

2.2.1. Techniki testowania dla testów akceptacyjnych

W opartym na wymaganiach podejściu do testów akceptacyjnych, tester wyprowadza przypadki testowe z kryteriów akceptacji związanych z każdym wymaganiem lub historyjką użytkownika przy użyciu technik czarnoskrzynkowych, takich jak podział na klasy równoważności lub analiza wartości brzegowych ([ISTQB_FL_SYL] rozdział 4). Testowanie akceptacyjne może być rozszerzone o inne techniki lub podejścia testowe:

- W testowaniu opartym na procesach biznesowych, ewentualnie połączonym

z testowaniem w oparciu o tablicę decyzyjną, waliduje się procesy i reguły biznesowe (patrz punkt 3.2.).

- W testowaniu opartym na doświadczeniu (np. testowanie eksploracyjne) wykorzystuje się doświadczenie, wiedzę i intuicję testera (patrz punkt 2.3.1.).

- W testowaniu opartym na analizie ryzyka identyfikuje się rodzaje i poziomy ryzyka. Priorytetyzacja i staranność testowania zależy od wcześniej zidentyfikowanych ryzyk produktowych.

- W testowaniu opartym na modelu wykorzystuje się modele graficzne (lub tekstowe) do pozyskiwania testów akceptacyjnych [ISTQB_MBT_SYL].

Kryteria akceptacji powinny być weryfikowane poprzez testy akceptacyjne. Dodatkowo należy zarządzać śledzeniem powiązań pomiędzy wymaganiami/historyjkami użytkownika a powiązanymi przypadkami testowymi.

2.2.2. Używanie języka Gherkin do pisania przypadków testowych

W ATDD i BDD testy akceptacyjne są często formułowane w ustrukturyzowanym języku, zwanym Gherkin[3] [Smart14]. Przy użyciu języka Gherkin przypadki testowe są wyrażane deklaratywnie przy użyciu standaryzowanego formatu:

- Mając [sytuacja],

- Kiedy [działanie na system],

- Wtedy [spodziewany wynik].

Format ten umożliwia analitykom biznesowym, testerom i deweloperom pisanie przypadków testowych w sposób, który jest łatwy do przekazania interesariuszom

i może zostać zastosowany w testach automatycznych.

Blok „Mając” ma na celu wprowadzenie obiektu testowego w stan przed wykonaniem czynności testowych w bloku „Kiedy”. Blok „Wtedy” określa rezultaty, które można zaobserwować w wyniku działań zdefiniowanych w bloku „Kiedy”. Przypadki testowe zapisane w języku Gherkin nie odnoszą się do elementów interfejsu użytkownika, lecz raczej do działań podejmowanych przez użytkownika w systemie. Są to ustrukturyzowane przypadki testowe napisane w języku naturalnym, które mogą być zrozumiałe dla wszystkich interesariuszy.

Ponadto struktura „Mając – Kiedy – Wtedy” może być przetwarzana w sposób zautomatyzowany. Pozwala to na automatyczne tworzenie skryptów testowych przy użyciu podejścia opartego na słowach kluczowych [Certyfikowany tester Sylabus poziomu podstawowego ISTQB® 2018 V. 3.1.].

Początkowo Gherkin był specyficzny dla niektórych narzędzi wspomagających BDD, ale teraz jest synonimem wzorca „Mając – Kiedy – Wtedy” w projektowaniu testów akceptacyjnych.

2.3. Podejścia oparte na doświadczeniu w testach akceptacyjnych

Wszystkie techniki testowania oparte na doświadczeniu opisane w [ISTQB_FL_SYL]. mogą być wykorzystywane podczas przeprowadzania testów akceptacyjnych. W tym punkcie skoncentrowano się na tym, w jaki sposób technika testowania eksploracyjnego może być wykorzystywana do testów akceptacyjnych oraz do testów beta jako źródła informacji zwrotnych na temat użycia systemu.

2.3.1. Testowanie eksploracyjne

Testowanie eksploracyjne [Whittaker09] to oparta na doświadczeniu technika testowa, która nie bazuje na szczegółowych, wcześniej zdefiniowanych procedurach testowych. W testach eksploracyjnych wszystkie czynności wykonywane są w nieprzerwanym czasie zwanym sesją. Testerzy są ekspertami dziedzinowymi. Są świadomi potrzeb użytkowników, wymagań i procesów biznesowych, ale niekoniecznie znają testowany produkt.

Podczas eksploracyjnej sesji testowej, tester wykonuje następujące czynności:

- Uczy się, jak pracować z produktem,

- Projektuje testy,

- Wykonuje testy,

- Interpretuje wyniki testów.

Dobrą praktyką w testowaniu eksploracyjnym jest korzystanie z karty opisu testów (ang. Test charter). Karta opisu testów jest przygotowywana przed sesją testową (może być wspólnie przygotowywana przez analityka biznesowego i testera) i jest używana przez osobę odpowiedzialną za sesję testową (albo analityka biznesowego czy testera lub też innego interesariusza). Zawiera informacje na temat celu, przedmiotu i zakresu sesji testowania eksploracyjnego, konfiguracji testów, czasu trwania sesji i ewentualnie niektórych taktyk stosowanych podczas sesji (takich jak typ użytkownika, którego symuluje się podczas sesji). Sesje czasowe pomagają kontrolować czas i wysiłek związany z sesją testowania eksploracyjnego. Dobrą praktyką jest również wykonywanie testów eksploracyjnych w parach lub zespołowo.

W wytwarzaniu zwinnym, sesje testowe mogą być przeprowadzane podczas iteracji przez właściciela produktu i/lub testerów, po to, by przeprowadzić testy akceptacyjne historyjek użytkownika przyporządkowanych do iteracji.

Technika testowania eksploracyjnego powinna być stosowana, aby uzupełnić inne, bardziej formalne techniki testowania akceptacyjnego. Na przykład, może być ona wykorzystana do zapewnienia uzyskania szybkiej informacji zwrotnej na temat nowych funkcji przed zastosowaniem testów metodycznych.

2.3.2. Testowanie beta

Testy beta to forma testów akceptacyjnych, która jest często stosowana w przypadku oprogramowania do powszechnej sprzedaży (ang. Commercial off-the-shelf) (COTS) lub oprogramowania jako usługa (ang. Software as a Service - SaaS). Testy te są przeprowadzane w celu uzyskania informacji zwrotnej z rynku po zakończeniu prac wytwórczych i testów wewnętrznych.

W odróżnieniu od innych form testów akceptacyjnych, testy beta są przeprowadzane przez potencjalnych lub istniejących użytkowników w ich własnej lokalizacji. Testy beta nie narzucają ani predefiniowanych procedur testowych, ani karty opisu testów. Oprócz zaobserwowanych wyników, czynności testowe zazwyczaj nie są w ogóle dokumentowane.

Ponieważ produkt jest testowany w różnych realistycznych konfiguracjach przez rzeczywistych użytkowników w specyficznym kontekście procesu biznesowego, testy beta mogą umożliwić wykrycie defektów, które mogły być pominięte podczas procesu wytwarzania i podczas testów na poprzednich poziomach testów. Rozwiązanie problemów wykrytych w testach beta pomaga organizacjom uniknąć kosztownych poprawek lub wycofywania produktów na większą skalę.

Testy akceptacyjne nie powinny ograniczać się do testów beta. Testy beta nie są systematyczne ani mierzalne. Nie ma gwarancji, że testy obejmują wszystkie wymagania lub historyjki użytkownika. Co więcej, testy beta są przeprowadzane późno w procesie wytwarzania oprogramowania, podczas gdy testy oparte na kryteriach akceptacji wspierają zasadę „wczesnego testowania” (ang. Early Testing).

3. Modelowanie procesów i reguł biznesowych – 150 minut

Słowa kluczowe

pokrycie, testowanie oparte na modelu

Cele nauczania

3.1. Modelowanie procesów i reguł biznesowych

AcT-3.1.1.       (K3) Kandydat potrafi skonstruować prosty model procesu/reguł biznesowych z wykorzystaniem notacji BPMN i/lub DMN.

3.2. Pozyskiwanie testów akceptacyjnych  z modeli procesów/reguł  biznesowych

AcT-3.2.1.       (K3) Kandydat potrafi wyprowadzić zestaw testów akceptacyjnych pokrywających dane kryterium pokrycia z danego, prostego modelu[4] procesu/reguł biznesowych (w BPMN lub DMN).

3.3. Modelowanie procesów biznesowych dla potrzeb testów akceptacyjnych

AcT-3.3.1.       (K2) Kandydat potrafi wskazać dobre praktyki dotyczące modelowania procesów i reguł biznesowych na potrzeby testów akceptacyjnych.

AcT-3.3.2.      (K2) Kandydat potrafi wyjaśnić, w jaki sposób można wykorzystać modelowanie procesów i reguł biznesowych dla ATDD.

3.1. Modelowanie procesów i reguł biznesowych

Organizacje potrzebują pewności, że krytyczne procesy biznesowe, takie jak np. procedury dotyczące fakturowania, zatrudniania nowych pracowników lub planowania produkcji, są realizowane bez zakłóceń. Jest to znane jako "zapewnienie procesów biznesowych" i stanowi istotny cel testów akceptacyjnych. W tym obszarze istnieją dwa standardy, które zapewniają analitykom biznesowym i testerom wspólny graficzny język reprezentujący procesy i reguły biznesowe: Notacja i Model Procesów Biznesowych (ang. Business Process Model and Notation - BPMN) oraz Notacja i Model Decyzji (ang. Decision Model and Notation - DMN). Modele te wspierają projektowanie i implementację testów oraz pomagają określić priorytet ich wykonania. Modele procesów/reguł biznesowych opisują przepływ procesów biznesowych i oczekiwane zachowanie obiektu testowego. Użycie notacji graficznej do reprezentowania testowanych procesów i reguł biznesowych pomaga osiągnąć wspólne zrozumienie oczekiwanych wyników. Proces biznesowy odpowiada za przepływ zadań, alternatywne ścieżki i inne zdarzenia na początku, na końcu lub ewentualnie w trakcie przepływu kontroli. Reguły biznesowe definiują wyraźne kryteria dla kierowania zachowaniem, formułowania osądów lub podejmowania decyzji.

BPMN, utrzymywany przez Object Management Group (OMG), jest uznanym standardem modelowania procesów biznesowych, wykorzystującym technikę schematów blokowych (ang. flowchart) [OMG BPMN 2.0.1] [ISO/IEC 19510:2013]. W niniejszym sylabusie wykorzystywany jest podzbiór zapisu BPMN 2.0.1. Jest on wystarczający do opracowania prostych modeli procesów biznesowych w kontekście działań związanych z testowaniem akceptacyjnym. Ten podzbiór jest zdefiniowany w Dodatku A1.

DMN, również znormalizowany przez OMG, stanowi uzupełnienie standardu BPMN [OMG DMN 1.2]. Podczas gdy BPMN jest używany do reprezentowania przepływów pracy, DMN jest używany do reprezentowania decyzji, reguł biznesowych i rezultatów/wyników w ramach przepływu pracy. W tym sylabusie używany jest podzbiór notacji DMN 1.2. Jest on wystarczający do zdefiniowania reguł biznesowych

w połączeniu z prostymi modelami procesów biznesowych w BPMN 2.0.1. Ten podzbiór jest zdefiniowany w Dodatku A2.

3.2. Pozyskiwanie testów akceptacyjnych z modeli procesów/reguł biznesowych

Model procesu biznesowego z regułami biznesowymi, opisany za pomocą notacji BPMN 2.0 i/lub DMN 1.2, dostarcza precyzyjnej definicji scenariuszy, które mają być testowane, w tym przypadków testowych związanych z regułami biznesowymi. Jest to dobra podstawa do generowania testów akceptacyjnych, używając opartych na pokryciu kryteriów wyboru testów, zdefiniowanych w podejściu opartym na modelu. [ISTQB_MBT_SYL].

Wybór testów w oparciu o pokrycie opiera się na zasadzie, że analityk biznesowy i tester uzgadniają te elementy zakresu, które powinny być w pełni przetestowane. Typowe elementy pokrycia dla modeli procesów biznesowych stosowane przy generowaniu testów akceptacyjnych obejmują następujące elementy:

- Historyjki użytkownika, wymagania i ryzyka wyszczególnione w modelu procesu biznesowego.

- Decyzje w tablicach decyzyjnych opisujących reguły biznesowe.

- Scenariusze użytkownika definiowane przez różne ścieżki w modelu procesów biznesowych.

- Wszystkie ścieżki (zazwyczaj bez pętli) prowadzące przez model procesu biznesowego.

Po zdefiniowaniu elementów pokrycia tester identyfikuje zestaw przypadków testowych pokrywających te elementy. Jeżeli zestaw testów obejmuje każde wystąpienie elementu pokrycia w modelu przynajmniej raz w trakcie wykonywania testu, uzyskuje się pełne pokrycie.

Aby osiągnąć cele testów akceptacyjnych, można łączyć różne kryteria pokrycia. Na przykład celem może być pokrycie wszystkich ścieżek danego scenariusza głównego, ale tylko jednej ścieżki każdego scenariusza alternatywnego.

3.3. Modelowanie procesów biznesowych dla potrzeb testów akceptacyjnych

Modele procesów/reguł biznesowych opisują przepływ procesów biznesowych i oczekiwane zachowanie obiektu testowego. Wykorzystanie modelowania procesów/reguł biznesowych w kontekście testów akceptacyjnych opiera się na dobrych praktykach modelowania i wspiera wizualne praktyki ATDD.

3.3.1. Dobre praktyki modelowania procesów biznesowych dla potrzeb testów akceptacyjnych

Podczas używania notacji BPMN i DMN w testach akceptacyjnych należy uwzględnić następujące dobre praktyki:

- W modelu procesu biznesowego nie jest konieczne opisywanie wszystkiego. Graficzna reprezentacja procesów biznesowych w BPMN powinna koncentrować się na wymaganiach, które mają być testowane. Dlatego dopuszczalne są opisy przepływu pracy, które tylko częściowo obejmują zachowanie powiązanych systemów oprogramowania, tak długo, jak długo reprezentują one to, co ma być testowane.

- Szczególnie w przypadku procesów biznesowych opartych na regułach, wykorzystanie tablic decyzyjnych pomaga w zarządzaniu zależnościami. DMN wspiera definiowanie warunków i wyników odpowiadających testowanym regułom biznesowym.

- Diagramy powinny być jak najprostsze i w razie potrzeby zgrupowane

w podprocesy, zwłaszcza gdy trzeba ograniczyć liczbę elementów graficznych na pojedynczym diagramie procesu biznesowego. Zwiększa to czytelność i ułatwia dokonywanie przeglądów.

- Modelowanie procesów biznesowych dla potrzeb testów akceptacyjnych powinno być pracą zespołową analityków biznesowych i testerów. Powstałe artefakty powinny być współdzielone i sprawdzane przez przedstawicieli obu ról. Wczesna i bliska komunikacja pomiędzy reprezentantami obu tych ról poprawia zarówno jakość wymagań i/lub historyjek użytkowników, jak i testów (dotyczy to wszystkich poziomów testów).

- Dodatkowe informacje, takie jak linki do historyjek użytkownika, wymagań, ryzyk, priorytetów i wszelkich innych informacji przydatnych w testach akceptacyjnych, powinny być umieszczone na diagramach z wykorzystaniem adnotacji. Przechowywanie wszystkich istotnych informacji w jednym miejscu ułatwia podejmowanie decyzji, a ich uzasadnienie jest lepiej udokumentowane.

3.3.2. Wykorzystanie modeli procesów biznesowych dla ATDD

Podczas sesji uszczegóławiania wymagań i historyjek użytkowników modele procesów i reguł biznesowych pomogą zespołowi w ustaleniu szczegółów oczekiwanego zachowania i kryteriów akceptacji. Bezpośrednie przedstawienie przepływu pracy w BPMN i reguł w DMN umożliwia testerom zaprojektowanie odpowiednich przypadków testowych, które umożliwiają weryfikację kryteriów akceptacji.

Modelowanie procesów biznesowych dla potrzeb ATDD opiera się na następujących zasadach:

- Analitycy biznesowi i testerzy współpracują w celu modelowania przepływów pracy i reguł biznesowych przy użyciu notacji graficznych, takich jak BPMN i DMN.

- Te modele procesów/reguł biznesowych są poddawane przeglądowi z odpowiednimi interesariuszami i służą walidacji wymagań i kryteriów akceptacji.

- Testerzy opracowują testy na podstawie modeli procesów/reguł biznesowych, aby zapewnić i zademonstrować wymagane pokrycie różnych ścieżek i reguł biznesowych.

- Analitycy biznesowi i testerzy mogą wykorzystywać modele również do utrzymywania przypadków testowych po identyfikacji zmian oraz do wyboru przypadków testowych do testów regresji.

- Modele procesów/reguł biznesowych stworzone i utrzymywane dla podejścia ATDD mogą być postrzegane jako żywa dokumentacja, wykorzystywana przez analityków biznesowych do przedstawienia rzeczywistego zachowania obiektu testowego.

- Do tworzenia i utrzymywania skryptów testowych do testów automatycznych można wykorzystać techniki automatycznego generowania testów [ISTQB_MBT_SYL]. Oparte na modelu podejście do testowania może być również połączone z testowaniem opartym na słowach kluczowych i testowaniem sterowanym danymi [ISTQB_FL_SYL].

Modelowanie procesów/reguł biznesowych w ATDD dostarcza wizualizacji testowanych przepływów pracy. Stanowi to główną różnicę w stosunku do języka Gherkin używanego w BDD (patrz Rozdział 2).

4. Testowanie akceptacyjne dla wymagań niefunkcjonalnych – 95 minut

Słowa kluczowe

wydajność, zabezpieczenia, użyteczność, doświadczenie użytkownika

Cele nauczania

4.1. Charakterystyki niefunkcjonalne i jakość w użytkowaniu

AcT-4.1.1.       (K2) Kandydat potrafi podać przykłady charakterystyk niefunkcjonalnych wg ISO 25010, które należy uwzględnić w testach akceptacyjnych.

AcT-4.1.2.      (K1) Kandydat potrafi przywołać charakterystyki jakościowe w użytkowaniu zgodnie z normą ISO 25010.

4.2. Użyteczność i doświadczenie użytkownika

AcT-4.2.1.       (K2) Kandydat potrafi odnieść się do różnych typów scenariuszy użycia dla czterech filarów analizy wymagań UX.

AcT-4.2.2.      (K2) Kandydat potrafi wskazać różne metody testowania użyteczności w ramach poszczególnych obszarów zastosowania.

4.3. Efektywność wydajnościowa

AcT-4.3.1.      (K2) Kandydat potrafi objaśnić wysokopoziomowe testy wydajnościowe zgodnie z określonymi wymaganiami wydajnościowymi.

AcT-4.3.2.      (K2) Kandydat potrafi dostrzec wpływ różnych perspektyw na kryteria akceptacji wydajności.

4.4. Zabezpieczenia

AcT-4.4.1.      (K2) Kandydat potrafi wyjaśnić, z jakiego powodu kryteria akceptacji zabezpieczeń i związane z tym wysokopoziomowe testy zabezpieczeń mogą być wymagane w projekcie, zgodnie z określonymi wymaganiami dotyczącymi zabezpieczeń.

4.1. Charakterystyki niefunkcjonalne i jakość w użytkowaniu

Testy akceptacyjne powinny obejmować zarówno wymagania funkcjonalne, jak i niefunkcjonalne. Wymagania niefunkcjonalne nabierają coraz większego znaczenia w odniesieniu do testów akceptacyjnych ze względu na zwiększone wykorzystanie oprogramowania w życiu codziennym, procesy sterowane danymi oraz rozwój zintegrowanych usług, które w dużym stopniu opierają się na złożonych systemach oprogramowania i systemach systemów.

4.1.1. Charakterystyki niefunkcjonalne i podcharakterystyki jakościowe

Spełnienie oczekiwań dotyczących niefunkcjonalnych charakterystyk jakościowych silnie wpływa na akceptację przez użytkownika proponowanego rozwiązania. Nawet jeśli krytyczność zależy od kontekstu, niewłaściwe uwzględnienie charakterystyk jakościowych może skutkować poważnymi problemami, takimi jak niezadowolenie klienta, spadek sprzedaży, odrzucenie rozwiązania, ryzyko odpowiedzialności i publiczne ujawnianie niedoskonałości w organizacji.

Norma ISO 25010 [ISO 25010:2011] wprowadza model jakości systemu i oprogramowania, który klasyfikuje właściwości jakościowe produktów. Obejmuje on siedem charakterystyk niefunkcjonalnych, które są następnie uszczegółowione na poziomie podcharakterystyk. Poniższa tabela zawiera wykaz podcharakterystyk związan ych z charakterystykami niefunkcjonalnymi zawartymi w normie ISO 25010.

Charakterystyka niefunkcjonalna

Podcharakterystyka

Wydajność

- Zachowanie w czasie

- Wykorzystanie zasobów

- Przepustowość

Kompatybilność

- Współistnienie

- Współdziałanie

Użyteczność

- Stosowność

- Łatwość nauki

- Łatwość obsługi

- Ochrona przed błędami użytkownika

- Estetyka interfejsu użytkownika

- Dostępność

Niezawodność

- Dojrzałość

- Osiągalność

- Tolerowanie usterek

- Odtwarzalność

Zabezpieczenia

- Poufność

- Integralność

- Niezaprzeczalność

- Rozliczalność

- Autentykacja

Pielęgnowalność

- Modułowość

- Możliwość ponownego wykorzystania

- Analizowalność

- Modyfikowalność

- Testowalność

Przenaszalność

- Zdolność adaptacyjna

- Instalowalność

- Zastępowalność

Wszystkie niefunkcjonalne charakterystyki jakościowe powinny być uwzględnione w testach akceptacyjnych. Strategia testowania akceptacyjnego powinna określać zasady wyboru i priorytety dla charakterystyk i podcharakterystyk niefunkcjonalnych, które mają być testowane w danym kontekście.

W kolejnych punktach tego rozdziału użyteczność, wydajność i zabezpieczenia są opisane bardziej szczegółowo, ponieważ czasami wymagane są specyficzne podejścia do uzyskania pożądanego poziomu pokrycia.

4.1.2. Jakość w użytkowaniu

Standard ISO 25010 definiuje również model jakości w użytkowaniu o pięciu cechach związanych z wynikami interakcji z systemem: efektywność, skuteczność, satysfakcja, ryzyka i pokrycie kontekstu.

Rysunek 1. – Model jakości w użytkowaniu (wyodrębniony z [ISO 25010:2011])

Charakterystyki jakości w użytkowaniu są szczególnie pomocne w testach akceptacyjnych, ponieważ odnoszą się do doświadczeń użytkownika z systemem.

4.2. Użyteczność i doświadczenie użytkownika

Zgodnie z normą ISO 25010 użyteczność to „stopień, w jakim produkt lub system może być wykorzystywany przez określonych użytkowników do osiągnięcia określonych celów skutecznie, wydajnie i z satysfakcją w określonym kontekście użytkowania". Użyteczność może być określona lub zmierzona jako charakterystyka jakościowa produktu w kategoriach podcharakterystyk lub określona lub zmierzona bezpośrednio za pomocą środków stanowiących podzbiór jakości w użytkowaniu”. [ISO 25010:2011].

Użyteczność można ocenić w odniesieniu do celów (np. łatwość uczenia się, skuteczność, łatwość zapamiętywania, satysfakcja, zapobieganie błędom), przeważnie za pomocą heurystyk [Rubin08] [Nielsen94]. Niedostateczna użyteczność może prowadzić do frustracji, odmowy korzystania z oprogramowania, a w najbardziej krytycznych sytuacjach do urazu lub śmierci użytkownika.

Doświadczenie użytkownika (User eXperience - UX) rozszerza pojęcie użyteczności o czynniki estetyczne i emocjonalne, takie jak pociągający, atrakcyjny projekt, aspekty budowania zaufania czy satysfakcji z użytkowania (np. przyjemność, komfort). Kontekst korzystania z systemu ma silny wpływ na doświadczenie użytkownika, ponieważ może się on całkowicie różnić w zależności od szeregu czynników, takich jak lokalizacja (np. siedzenie za biurkiem, prowadzenie samochodu lub wycieczki piesze), pogoda (np. słońce, deszcz, chłód), warunki zdrowotne użytkownika (np. zmęczenie, wiek), środowisko (np. stresujące, głośne).

4.2.1. Analiza wymagań UX

Analiza wymagań UX opiera się na następujących czterech filarach:

- Analiza użytkownika: użytkownicy są klasyfikowani pod względem właściwości fizycznych  i intelektualnych, umiejętności technicznych, wiedzy biznesowej, uwarunkowań społeczno-ekonomicznych  i kulturowych. Analitycy biznesowi mogą również korzystać  z modeli (np.  model oparty na tzw. personach -wzorcach osób takich jak rodzaj przyszłego użytkownika, rola osoby   w systemie itp.) [ISTQB_FL_SYL]).

- Analiza zadań: funkcjonalność jest identyfikowana i sformalizowana (np. poprzez przypadki użycia i scenariusze). Zachowanie i oczekiwania użytkowników są analizowane w celu zaprojektowania optymalnego systemu lub produktu.

- Analiza kontekstu: analizowany jest kontekst, w którym system lub produkt będzie używany. Warunki zewnętrzne (np. światło, temperatura, ruch, wilgotność lub kurz), warunki fizyczne (np. siedzenie, stanie, leżenie, poruszanie się, praca bez użycia rąk) lub warunki “psychologiczne” (np. poziom stresu, motywacja lub różnica między prywatnym a profesjonalnym użytkowaniem) są traktowane jako wskazówki dla kolejnych etapów projektowania. Częścią kontekstu są również urządzenia, platformy i czynniki związane z formą (specyficzne dla urządzenia ekrany).

- Analiza konkurencji: jeżeli celem nie jest stworzenie przełomowego projektu, analitycy biznesowi powinni przeanalizować rozwiązania konkurencji i czerpać inspirację z udanego wdrożenia tych rozwiązań, aby zatrzymać lub przyciągnąć użytkowników i klientów. Innym źródłem inspiracji mogą być udane rozwiązania znalezione w podobnych lub nawet różnych sektorach.

Z powodu typowych ludzkich ograniczeń i uprzedzeń (np. uprzedzeń poznawczych ang. cognitive biases) lub percepcyjnych, upośledzenia wzroku, braku doświadczenia [ISTQB_UT_SYL] niektórzy użytkownicy mogą doświadczać bardziej specyficznych,

a czasami poważnych trudności w korzystaniu z oprogramowania lub produktów będących częścią rozwiązania biznesowego. Analitycy biznesowi i testerzy powinni ocenić, czy produkty lub usługi są dostępne dla wszystkich użytkowników, uwzględniając te ograniczenia przy projektowaniu kryteriów akceptacji i przypadków testowych.

4.2.2. Testowanie użyteczności

Istnieją różne podejścia do testowania użyteczności w testach akceptacyjnych:

- Oceny oparte na listach kontrolnych: użytkownicy oceniają testowany system lub produkt zgodnie z listami kontrolnymi [Rubin08], aby ocenić, porównać i określić swoje doświadczenia.

- Przeglądy eksperckie: eksperci ds. użyteczności oceniają użyteczność systemu lub produktu zgodnie z wcześniej zdefiniowanymi kryteriami lub listami kontrolnymi opartymi na heurystykach użyteczności w celu zidentyfikowania mocnych i słabych stron interfejsu.

- Techniki przejrzenia (ang. walkhrough) i głośnego myślenia (ang. think-aloud): użytkownicy badają produkt lub system i na głos omawiają i opisują swoje działania i odczucia [ISTQB_UT_SYL]. Mogą otrzymać konkretne zadania do wykonania w celu określenia sposobu ich interakcji z produktem i poznania oczekiwań lub problemów.

- Oceny oparte na danych biometrycznych: zachowanie użytkownika jest monitorowane za pomocą określonych urządzeń biometrycznych (np. rejestracja ruchu oczu, rejestracja ruchu myszy i oczu), aby zrozumieć, w jaki sposób użytkownik wchodzi w interakcję ze stroną lub systemem, co przyciąga jego uwagę lub co jest mniej lub bardziej widoczne.

- Analiza plików z logami: Przeprowadzana jest analiza retrospektywna mająca na celu sprawdzenie, w jaki sposób użytkownicy korzystali z systemu, aby odkryć obszary, w których można dokonać ulepszeń, i zweryfikować, czy faktyczne użycie odpowiada zdefiniowanemu profilowi / zamierzonemu użytkowaniu.

4.3. Wydajność

Wydajność jest istotną częścią zapewnienia „dobrego doświadczenia” użytkownikom korzystającym ze swoich aplikacji na różnych platformach stacjonarnych i mobilnych [ISTQB_PT_SYL]. Należy uwzględnić testy wydajnościowe na wszystkich poziomach testów. Podczas testów akceptacyjnych, testy wydajnościowe są w szczególności przedmiotem produkcyjnych testów akceptacyjnych (ang. Operational Acceptance Testing OAT), zazwyczaj przeprowadzanych przez zespoły operacyjne. Analitycy biznesowi i testerzy powinni być także zaangażowani w opracowywanie kryteriów akceptacji i związanych z nimi przypadków testowych. Kryteria akceptacji dla wymagań wydajnościowych powinny dostarczać obiektywnych ocen, unikając w ten sposób subiektywnej oceny wydajności podczas wykonywania testów akceptacyjnych.

4.3.1. Wysokopoziomowe testy akceptacyjne wydajności

Testy wydajnościowe mają na celu określenie reakcji i stabilności systemu

w określonych warunkach. W typowym teście wydajnościowym symuluje się użytkowników lub transakcje działające współbieżnie za pomocą określonych narzędzi w celu wygenerowania określonego obciążenia. Naśladuje ono, na ile to możliwe, rzeczywisty stan obciążenia z realnymi użytkownikami i realistyczne interakcje. Następnie mierzy się czasy reakcji kluczowych elementów testowanego systemu (np. serwera WWW, serwera aplikacji, bazy danych) i porównuje je z wcześniej zdefiniowanymi wymaganiami wydajnościowymi. To samo można zrobić dla wykorzystania pamięci, wejść/wyjść systemowych, zajętości procesora i dostępu do urządzeń zabezpieczających, w zależności od tego, jaki moduł jest (lub oczekuje się, że będzie) zatorem lub celem testu.

Na podstawie analizy wyników można modyfikować poszczególne elementy architektury (sprzęt i oprogramowanie), np. zapewniając dodatkową pojemność serwera. Cykl testowania, analizy i ulepszeń może być powtarzany aż do osiągnięcia docelowego poziomu wydajności.

Różne rodzaje testów mogą być przeprowadzane, w zależności od tego, co powinno się zmierzyć. Są to między innymi testy obciążeniowe, przeciążeniowe i wytrzymałościowe / stabilności. Obciążenie może być symulowane przy użyciu różnych modeli: stanu stabilnego, rosnącego, opartego na scenariuszach lub sztucznego (więcej szczegółów - patrz [ISTQB_PT_SYL]).

4.3.2. Kryteria akceptacji dla testów akceptacyjnych wydajności

Kryteria akceptacji wydajności mogą być wyrażone z różnych perspektyw, jak przedstawiono poniżej:

- Z perspektywy użytkownika: postrzegany czas reakcji odzwierciedla rzeczywiste doświadczenie użytkownika z systemem. Na przykład, użytkownicy mogą opuścić stronę internetową, jeśli czas reakcji przekracza 10 sekund.

- Z biznesowego punktu widzenia: należy wziąć pod uwagę liczbę użytkowników działających współbieżnie, rodzaje realizowanych scenariuszy lub transakcji oraz oczekiwany czas reakcji. Większa liczba działających współbieżnie użytkowników wykonujących transakcje wymagające dużych zasobów spowoduje wydłużenie czasu reakcji. Na czas reakcji mogą mieć również wpływ inne czynniki

w zależności od lokalizacji, czasu lub strefy czasowej.

- Z technicznego punktu widzenia: na wydajność wpływają dostępne zasoby systemowe (np. przepustowość sieci, wykorzystanie procesora, pojemność pamięci RAM) oraz architektura systemu (np. równoważenie obciążenia serwera, wykorzystanie buforowania danych). Na przykład, systemy internetowe

o ograniczonej przepustowości sieci będą miały tendencję do obniżania wydajności, szczególnie gdy będą narażone na duże obciążenia spowodowane przez dużą liczbę użytkowników wykonujących zadania generujące znaczny ruch sieciowy.

Opracowanie kryteriów akceptacji i testów akceptacyjnych dla wymagań wydajnościowych musi uwzględniać te trzy różne perspektywy (użytkownika, biznesową i techniczną).

4.4. Zabezpieczenia

Zarządzanie bezpieczeństwem informacji i ogólne wymagania dotyczące zabezpieczeń powinny być częścią ogólnej polityki bezpieczeństwa organizacji (więcej informacji na ten temat można znaleźć w sylabusie ISTQB® Tester Zabezpieczeń Poziomu Zaawansowanego [ISTQB_SEC_SYL] oraz w normie [ISO/IEC 27005:2011]). Analitycy biznesowi i testerzy powinni korzystać z polityki bezpieczeństwa w odniesieniu do zaleceń i wytycznych oraz jako podstawy do zarządzania ryzykiem bezpieczeństwa

w swoich projektach.

Wymagania dotyczące zabezpieczeń powinny być rozpatrywane na wszystkich etapach analizy biznesowej, inżynierii wymagań i związanych z nimi testów akceptacyjnych, biorąc pod uwagę co następuje:

- Bezpieczeństwo informacji powinno być częścią zarządzania ryzykiem oraz pozyskiwania i analizy wymagań niefunkcjonalnych. Należy ocenić wartość informacji w testowanym systemie lub w danym procesie biznesowym, a następnie dokonać oceny i nadać priorytet ryzyku związanemu z bezpieczeństwem.

- Należy zdefiniować wymierne kryteria akceptacji dla wymagań dotyczących bezpieczeństwa informacji. Mogą one obejmować szeroki wachlarz zagadnień, takich jak uwierzytelnianie, procedury autoryzacji i rozliczania, oczyszczanie danych wejściowych, stosowanie kryptografii oraz ograniczenia dotyczące prywatności danych.

- Zgodnie z wymaganiami zabezpieczeń i kryteriami akceptacji należy zdefiniować wysokopoziomowe przypadki testowe dotyczące bezpieczeństwa informacji. Te przypadki testowe określają kontekst testów, główne kroki i oczekiwane wyniki.

- Niektóre testy akceptacyjne zabezpieczeń mogą być przeprowadzane przez testera akceptacyjnego, a inne przez bardziej wyspecjalizowanych testerów zabezpieczeń, w zależności od poziomu technicznej złożoności testu.

5. Wspólne testy akceptacyjne – 110 minut

Słowa kluczowe

defekt, zapewnienie jakości

Cele nauczania

5.1. Współpraca

AcT-5.1.1.       (K3) Kandydat potrafi zastosować dla danej sytuacji umiejętności społeczne i komunikacyjne istotne dla wspólnych działań związanych z testami akceptacyjnymi.

5.2. Czynności

AcT-5.2.1.       (K2) Kandydat potrafi wyjaśnić, jak w danym kontekście analizować rozbieżności między rzeczywistymi a oczekiwanymi wynikami na poziomie biznesowym.

AcT-5.2.2.      (K2) Kandydat potrafi wskazać czynności raportowania dotyczące testów akceptacyjnych dla interesariuszy.

AcT-5.2.3.       (K2) Kandydat potrafi wyjaśnić różne techniki zapewnienia jakości dla czynności związanych z testowaniem akceptacyjnym.

5.3. Wsparcie narzędziowe

AcT-5.3.1.       (K1) Kandydat potrafi podać zakres i cele wsparcia narzędziowego dla czynności związanych z testowaniem akceptacyjnym.

5.1. Współpraca

Jednym z wyzwań w testach akceptacyjnych jest różnorodność i odmienność osób

i profili zaangażowanych w testowanie (analitycy biznesowi, analitycy techniczni, testerzy, przedstawiciele biznesu, sponsorzy biznesowi, specjaliści od automatyki i wielu innych), którzy mają różne cele, różne umiejętności i różne punkty widzenia w ramach tego samego projektu. Aby zebrać wymagania i oczekiwania, przełożyć je na rozwiązania tworzące wartość dodaną, dostosować organizację oraz umożliwić skuteczną i efektywną współpracę ze wszystkimi interesariuszami, niezwykle ważne są umiejętności społeczne.

Zarówno testerzy, jak i analitycy biznesowi muszą upewnić się, przy pomocy odpowiednich narzędzi i technik (np. odpowiednie gry, odgrywanie ról, specyficzne warsztaty) [Frontiera12], że członkowie zespołu:

- Poznają i rozumieją siebie nawzajem, mając na celu utrzymanie spójności zespołu na wysokim poziomie (np. kto jest kim, wspólne cele i realizacje, wspólne obszary).

- Otwarcie komunikują się ze sobą z zaufaniem i szacunkiem; wyrażają swoje wątpliwości, obawy i lęki, by identyfikować, przeanalizować i przezwyciężyć problemy (np. komunikacja bez tabu, doświadczenie, percepcja, obraz).

- Wyobrażają sobie wspólne cele i ogólną wizję oraz niezbędne kroki do ich osiągnięcia (np. co robimy, jeśli się powiedzie / co robimy, jeśli się nie powiedzie, którzy ludzie i jakie środki są niezbędne, co jest sukcesem).

- Rozwiązują istotne problemy z humorem, komunikując się ze sobą w sposób pozytywny lub przy zastosowaniu odpowiednich technik negocjacyjnych [Ury12] (np. negocjacje oparte na ustalonych zasadach, karykatury, odgrywanie ról / komiksy).

5.2. Czynności

Ważne czynności, które powinny być wykonywane podczas testów akceptacyjnych, to analiza usterek, raportowanie i zapewnienie jakości dla artefaktów testów akceptacyjnych.

5.2.1. Analiza defektów

Testerzy zbierają i zgłaszają rozbieżności pomiędzy rzeczywistym a oczekiwanym wynikiem poprzez raportowanie defektów. Raport o defekcie zawiera wszystkie istotne informacje, które tester może dostarczyć, aby pomóc analitykowi biznesowemu zrozumieć, co się stało i ocenić odchylenie.

Analiza usterek jest wspólną pracą testerów i analityków biznesowych. Zazwyczaj tester określa kryteria akceptacji, które nie zostały spełnione. Analityk biznesowy może zostać poproszony o przeanalizowanie wpływu usterki na powiązane procesy biznesowe. Obejmuje to określenie priorytetu defektu (np. niski, średni, wysoki, krytyczny) w odniesieniu do jego potencjalnego wpływu biznesowego na używanie systemu.

Aby przeanalizować biznesowy wpływ defektu, analityk biznesowy i tester mogą wykonać następujące czynności:

- Zbadanie ścieżki (ścieżek) w modelach procesów biznesowych, w których wykryto defekt(y),

- Zbadanie reguł biznesowych, które nie zostały prawidłowo zaimplementowane

i przeanalizowanie priorytetu defektu z punktu widzenia użytkowania.

Analiza wpływu i wynikająca z niej decyzja dotycząca dalszych działań, które należy podjąć, są udokumentowane w raporcie o defekcie.

5.2.2. Raportowanie

Czynności raportowania podczas testów akceptacyjnych skierowane są do określonej grupy docelowej (np. menedżerów biznesowych, menedżerów produktów lub ekspertów dziedzinowych). Interesariusze ci są ekspertami w dziedzinie aplikacji, ale nie zawsze znają szczegóły implementacji. Dlatego też informacje o postępie testów akceptacyjnych, wynikach i wykrytych defektach, powinny być prezentowane bez szczegółów technicznych, w języku zrozumiałym dla grupy docelowej.

Ważną częścią raportowania o postępie testów jest stosowanie metryk. Ogólny wynik testów jest przedstawiany w sumarycznym raporcie z testów. Oprócz podsumowanych informacji na temat wykonania testów i wyników wszystkich faz testów, sumaryczny raport z testów dostarcza dodatkowe informacje pochodzące z analizy wpływu otwartych defektów. Sumaryczny raport z testów zawiera również wskazanie, czy osiągnięto docelowe kryteria jakości.

W oparciu o sumaryczny raport z testów, decydenci powinni być w stanie określić, czy testowany system osiągnął niezbędny, wcześniej określony, poziom jakości i może zostać dopuszczony do produkcji, czy też nie. Możliwych jest kilka wyników, w tym następujące:

- System może być wydany „tak jak jest” i wdrożony bez ograniczeń.

- System może być wydany z zastrzeżeniami. Znane błędy, dla których istnieje obejście, są przedstawiane użytkownikowi i zespołowi wsparcia technicznego. W przypadku usterek, które stanowią istotne ryzyko, powiązana cecha (lub podsystem) może zostać wykluczona z wdrożenia.

- System jest odrzucony, dopóki nie zostaną naprawione i ponownie przetestowane krytyczne usterki. Wdrożenie zostaje przełożone lub zastąpione rozwiązaniami alternatywnymi.

5.2.3. Czynności zapewnienia jakości w testowaniu akceptacyjnym

Wysokiej jakości testy akceptacyjne są kluczowe dla zarządzania ryzykiem biznesowym związanym z defektami przedostającymi się na produkcję. Podczas czynności testów akceptacyjnych należy stosować następujące elementy zapewnienie jakości:

- Przegląd kryteriów akceptacji: analityk biznesowy i tester weryfikują, czy kryteria akceptacji są jasne, spójne i wyczerpujące. Kryteria akceptacji obejmują również charakterystyki niefunkcjonalne i dostarczają wymierne kryteria zaliczenia/niezaliczenia.

- Przegląd przypadków testowych dla testów akceptacyjnych: przypadki testowe dla testów akceptacyjnych powinny obejmować uprzednio zdefiniowane kryteria akceptacji, jak również procesy biznesowe, reguły biznesowe i ryzyko biznesowe.

- Śledzenie powiązań: śledzenie pomiędzy wymaganiami/historyjkami użytkownika, kryteriami akceptacji, przypadkami testowymi a defektami usprawnia przeprowadzenie testów akceptacyjnych, ponieważ wyjaśnia zależności i umożliwia łatwy dostęp do powiązanych informacji.

- Analiza pokrycia bazująca na śledzeniu: jeśli ustanowione jest śledzenie dwukierunkowe, możliwe jest przeprowadzenie systematycznej analizy pokrycia.

- Przegląd raportów z testów: raporty z testów powinny być jasne, spójne i wyczerpujące. Powinny one zawierać wszystkie dostarczone przez testera informacje wspierające decyzje dotyczące wydania produktu.

5.3. Wsparcie narzędziowe

Narzędzia do testów akceptacyjnych wywodzą się zarówno z dziedziny analizy biznesowej, jak i testowania oprogramowania.

Poniższa tabela zawiera listę niektórych rodzajów narzędzi, które mogą być wykorzystywane w testach akceptacyjnych.

Typ narzędzia

Zastosowanie dla testów akceptacyjnych

Narzędzie do zarządzania wymaganiami

Opis kryteriów akceptacji

Śledzenie powiązań pomiędzy testami a wymaganiami

Analiza pokrycia

Narzędzie do zarządzania projektami zwinnymi

Opis kryteriów akceptacji

Śledzenie powiązań pomiędzy testami a historyjkami użytkownika

Analiza pokrycia

Narzędzie do zarządzania procesami biznesowymi

Modelowanie procesów i reguł biznesowych

Analiza wpływu defektów na procesy biznesowe

Narzędzie do zarządzania testami i automatyzacją

Zarządzanie testami akceptacyjnymi i kampanią wykonania testów

Zarządzanie wynikami wykonania testów

Narzędzie do testowania opartego na modelu

Generowanie przypadków testowych na podstawie modeli procesów biznesowych

Zarządzanie śledzeniem powiązań pomiędzy modelami procesów biznesowych, regułami biznesowymi, wymaganiami a przypadkami testowymi

Narzędzie do zarządzania defektami/incydentami

Zarządzanie cyklem życia defektu / incydentu

6. Skróty

Skrót

Znaczenie

ATDD

Wytwarzanie sterowane testami akceptacyjnymi (Acceptance Test-Driven Development)

BA

Analityk biznesowy (Business Analyst)

BDD

Wytwarzanie sterowane zachowaniem (Behaviour Driven-Development)

BPMN

Notacja i model procesów biznesowych (Business Process Model and Notation)

CTFL

Certyfikowany tester poziomu podstawowego (Certified Tester Foundation Level)

COTS

Oprogramowanie do powszechnej sprzedaży (Commercial off-the-Shelf)

CPU

Procesor, (Centralna jednostka przetwarzająca) (Central Processing Unit)

DMN

Notacja i model decyzji (Decision Model and Notation)

IQBBA®

Międzynarodowa Rada Kwalifikacji w zakresie Analizy Biznesowej (International Qualification Board for Business Analysis)

ISO

International Organization for Standarization

ISTQB®

International Software Testing Qualifications Board

OMG

Grupa ds. Zarządzania Obiektowego (Object Management Group)

OAT

Produkcyjne testy akceptacyjne (Operational Acceptance Testing)

QA

Zapewnienie jakości (Quality Assurance)

UAT

Testy akceptacyjne użytkownika (User Acceptance Testing)

UX

Doświadczenie użytkownika (User eXperience)

7. Zarejestrowane znaki towarowe

Znak  towarowy

Właściciel

BPMN™

Object Management Group, Inc.

CTFL®

ISTQB®

DMN™

Object Management Group, Inc.

IQBBA®

International Qualification Board for Business Analysis

ISTQB®

International Software Testing Qualifications Board

8. Odniesienia

Standardy

[ISO/IEC 25010:2011] Software engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Software and quality in use models, 2011

[ISO/IEC 29148:2011] Systems and software engineering - Life cycle processes - Requirements engineering, 2011

[ISO/IEC 27005:2011] ISO/IEC 27005:2011 Information technology - Security techniques - Information security risk management, 2011

[ISO/IEC 9241-11:1998] ISO/IEC 9241-11:1998 - Ergonomic requirements for office work with visual display terminals (VDTs) - Part 11: Guidance on usability, 1998

[ISO/IEC 19510:2013] ISO/IEC 19510:2013 - Information technology - Object Management Group Business Process Model and Notation

[OMG BPMN 2.0] OMG BPMN 2.0 standard documentation - January 2011 http://www.omg.org/spec/BPMN/2.0/

[OMG DMN 1.2] OMG DMN 1.2 standard documentation - January 2019 https://www.omg.org/spec/DMN/1.2/

Dokumenty IQBBA®

[IQBBA_GLOSSARY] Standard glossary of terms used in Software Engineering, version 1.0 – IQBBA® 2011

[IQBBA_FL_SYL] Certified Foundation Level Business Analyst (CFLBA) Syllabus, version 3.0 – IQBBA® 2018

Dokumenty ISTQB®

[ISTQB_FL_SYL] ISTQB® Certified Tester Foundation Level Syllabus, Version 2018 V3.1 - Certyfikowany tester Sylabus poziomu podstawowego ISTQB® 2018 V. 3.1.

[ISTQB_FL_AT_SYL] ISTQB® Agile Tester Foundation Level Syllabus, Version 2014

Certyfikowany Tester Sylabus rozszerzenia poziomu podstawowego Tester zwinny.

[ISTQB_MBT_SYL] ISTQB® Foundation Level Model-Based Tester, Version 2015

[ISTQB_UT_SYL] ISTQB® Foundation Level Usability Testing, Version 2018

[ISTQB_PT_SYL] ISTQB® Foundation Level Performance Testing, Version 2018

[ISTQB_SEC_SYL] ISTQB® Advanced Level Security Tester, Version 2016

[ISTQB_GLOSSARY] Standard Glossary of Terms used in Software Testing, Słownik Terminów Testowych ISTQB®

Bibliografia

[Anderson01] Lorin W. Anderson, David R. Krathwohl (eds.) “A Taxonomy for Learning, Teaching and Assessing: A Revision of Bloom’s Taxonomy of Educational Objectives”, Allyn & Bacon, 2001, ISBN 978-0801319037

[Cohn04] Mike Cohn, “User Stories Applied: For Agile Software Development”, Addison-Wesley Professional, 2004, ISBN: 978-0321205681

[Frontiera 2012] Joe Frontiera and Daniel Leidl, “Team Turnarounds: A Playbook for Transforming Underperforming Teams”, Jossey-Bass; 1st edition (July 24, 2012), ISBN: 978-1118144787

[Nielsen94] Jakob Nielsen “Heuristic evaluation”. Nielsen, J., and Mack, R.L. (Eds.), “Usability Inspection Methods” - John Wiley & Sons, New York, NY, 1994, ISBN 0-471-01877-5

[Pugh11] Ken Pugh, “Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration”, Addison-Wesley Professional, 2011, ISBN: 978-0321714084

[Rubin08] Jeffrey Rubin and Dana Chisnell, “Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests”, Wiley; 2nd edition (May 12, 2008), ISBN: 978-0470185483

[Smart14] John Ferguson Smart, “BDD in Action: Behavior-driven development for the whole software lifecycle”, Manning Publications, 2014, ISBN: 978-1617291654

[Ury12] Roger Fisher and William Ury, “Getting to yes”, Patton Ed. Random House Business Books, 2012, ISBN: 978-1847940933

[Whittaker09] James Whittaker, “Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design”, Addison-Wesley Professional; 1st edition (September 4, 2009), ISBN: 978-0321636416

Dodatek A – Podzbiór BPMN 2.0.1 oraz DMN 1.2

Ten sylabus wykorzystuje następujące wersje standardów OMG:

- BPMN 2.0.1 opublikowany w 2011 r. i ratyfikowany jako ISO 19510 w 2013 r.

- DMN 1.2 opublikowany w 2019 r.

A.1 Podzbiór BPMN 2.0.1

Modele BPMN składają się z prostych diagramów zbudowanych z ograniczonego zestawu elementów graficznych. Dostępne są cztery podstawowe kategorie elementów: aktywne obiekty przepływu, obiekty łączące, tory i artefakty. Dla każdej z tych kategorii przedstawiono poniżej dokładny podzbiór elementów graficznych, które odnoszą się do tego planu nauczania; powinny one być wykorzystywane do celów nauczania na poziomie K3 (w rozdziale 3).

Obiekty aktywne przepływu

Zdarzenia:

Startowe

Pośrednie

Końcowe

Aktywności:

Zadanie

Podproces

W planie nauczania rozpatruje się cztery rodzaje zadań: niezdefiniowane, usługowe, użytkownika i reguły biznesowe.

Bramki logiczne:

Wyłączna

Równoległa

Obiekty łączące

Przepływ sekwencji

Tory:

Uczestnik (basen)

Tor

Artefakty:

Obiekt danych

Adnotacja

Reguły syntaktyczne, semantyczne i pragmatyczne konieczne do zastosowania tego podzbioru elementów graficznych BPMN są zdefiniowane w normie BPMN 2.0.1 [OMG BPMN 2.0] [ISO/IEC 19510:2013].

W niniejszym sylabusie mają zastosowanie wyłącznie prywatne (wewnętrzne) procesy biznesowe opisujące przepływy pracy, które mają być przetestowane podczas testów akceptacyjnych.

A.2. Podzbiór DMN 1.2

Modele DMN składają się z prostych diagramów zbudowanych z ograniczonego zestawu elementów graficznych i tablic decyzyjnych. Diagramy wspierają reprezentację wymagań związanych z decyzjami, a tablice decyzyjne reprezentują powiązaną z nimi logikę decyzyjną. W ramach standardu zdefiniowano również język deklaratywny umożliwiający formalne definiowanie decyzji. W tym sylabusie mają zastosowanie jedynie tablice decyzyjne wykorzystujące notację DMN 1.2, które odzwierciedlają reguły biznesowe związane z przepływami pracy reprezentowanymi w BPMN 2.0 (patrz poprzednia sekcja).

Tablica decyzyjna składa się z [OMG DMN 1.2]:

- Nazwa elementu informacyjnego,

- Lista klauzul wejściowych (zero lub więcej),

- Lista klauzul wyjściowych (jedna lub więcej),

- Zestaw wyjść (jedno lub więcej),

- Lista klauzul adnotacji (zero lub więcej),

- Lista reguł (jedna lub więcej).

Tablice decyzyjne DMN mogą być połączone z modelami procesów biznesowych BPMN za pomocą zadań typu reguła biznesowa (patrz Dodatek A.1).

Notatki

[←1]

dopisek tłumaczy: czyli przeciwdziałanie podziałom w firmie, likwidacja barier zniechęcających te grupy do wzajemnego dzielenia się wiedzą i doświadczeniem.

[←2]

dopisek tłumaczy: oznacza to, że istnieją podziały w firmie, bariery zniechęcające te grupy do wzajemnego dzielenia się wiedzą i doświadczeniem.

[←3]

dopisek tłumaczy: Jest to niespójność merytoryczna oryginału: Gherkin jest używany w BDD, w ATDD projektowanie testów opiera się na różnych formach tekstowych lub graficznych.

[←4]

„Prosty model procesu/reguł biznesowych" oznacza model z mniej niż 20 elementami modelu, wykorzystujący wyłącznie typy elementów określone w dodatku A do niniejszego sylabusa.

Table of Contents

Historia zmian

Spis treści

Podziękowania

0. Wprowadzenie do sylabusa (planu nauczania)

0.1. Cel

0.2. Zakres

0.3. Rezultaty biznesowe

0.4. Cele nauczania objęte egzaminem

0.5. Rekomendowany czas trwania szkolenia

0.6. Standardy

0.7. Wymagania wstępne

0.8 Źródła informacji

1. Wprowadzenie i podstawy – 80 minut

1.1. Podstawowe powiązania

1.1.1. Cele biznesowe, potrzeby biznesowe i wymagania

1.1.2. Wymagania / historyjki użytkownika, kryteria akceptacji i testy akceptacyjne

1.1.3. Znaczenie jakości wymagań

1.2. Analiza biznesowa i testy akceptacyjne

1.2.1. Relacje między czynnościami analizy biznesowej a testowaniem

1.2.2. Współpraca pomiędzy analitykami biznesowymi a testerami w testach akceptacyjnych

1.2.3. Jak testy akceptacyjne mogą kierować procesem wytwarzania: ATDD i BDD

2. Kryteria akceptacji, testy akceptacyjne i techniki oparte na doświadczeniu – 165 minut

2.1. Pisanie kryteriów akceptacji

2.2. Projektowanie testów akceptacyjnych

2.2.1. Techniki testowania dla testów akceptacyjnych

2.2.2. Używanie języka Gherkin do pisania przypadków testowych

2.3. Podejścia oparte na doświadczeniu w testach akceptacyjnych

2.3.1. Testowanie eksploracyjne

2.3.2. Testowanie beta

3. Modelowanie procesów i reguł biznesowych – 150 minut

3.1. Modelowanie procesów i reguł biznesowych

3.2. Pozyskiwanie testów akceptacyjnych z modeli procesów/reguł biznesowych

3.3. Modelowanie procesów biznesowych dla potrzeb testów akceptacyjnych

3.3.1. Dobre praktyki modelowania procesów biznesowych dla potrzeb testów akceptacyjnych

3.3.2. Wykorzystanie modeli procesów biznesowych dla ATDD

4. Testowanie akceptacyjne dla wymagań niefunkcjonalnych – 95 minut

4.1. Charakterystyki niefunkcjonalne i jakość w użytkowaniu

4.1.1. Charakterystyki niefunkcjonalne i podcharakterystyki jakościowe

4.1.2. Jakość w użytkowaniu

4.2. Użyteczność i doświadczenie użytkownika

4.2.1. Analiza wymagań UX

4.2.2. Testowanie użyteczności

4.3. Wydajność

4.3.1. Wysokopoziomowe testy akceptacyjne wydajności

4.3.2. Kryteria akceptacji dla testów akceptacyjnych wydajności

4.4. Zabezpieczenia

5. Wspólne testy akceptacyjne – 110 minut

5.1. Współpraca

5.2. Czynności

5.2.1. Analiza defektów

5.2.2. Raportowanie

5.2.3. Czynności zapewnienia jakości w testowaniu akceptacyjnym

5.3. Wsparcie narzędziowe

6. Skróty

7. Zarejestrowane znaki towarowe

8. Odniesienia

Standardy

Dokumenty IQBBA®

Dokumenty ISTQB®

Bibliografia

Dodatek A – Podzbiór BPMN 2.0.1 oraz DMN 1.2

A.1 Podzbiór BPMN 2.0.1

A.2. Podzbiór DMN 1.2