Podpowiedzi, tips and tricks dla zdawania egzaminu ISTQB

Jak zdać egzamin ISTQB?

Poziom Podstawowy.

Egzamin ISTQB Certyfikowany Tester Poziom Podstawowy jest pierwszym i najważniejszych
egzaminem w tej strukturze certyfikacyjnej.

Radosław Smilgin

Wersja 1.0 (21.04.2017)

WPROWADZENIE

Niniejsza  publikacja  ma  na  celu  przygotowanie  czytelnika  do  zdania  egzaminu  ISTQB  Certyfikowany
Tester  Poziom  Podstawowy.  Może  być  ona  traktowana  jako  uzupełnienie  materiału  kursowego,  ale
może być również podręcznikiem pomagającym w samodzielnym przygotowaniu do zdania egzaminu.
Publikacja  stanowi  doszczegółowienie  informacji  dostępnych  w  publikacji  „Jak  zdać  egzamin  ISTQB”
dostępnej na stronie

http://edu.ittraining.pl/material/jak-zdac-egzamin-ISTQB

STRUKTURA CERTYFIKACJI

Certyfikat Poziomu Podstawowego jest pierwszym stopniem wtajemniczenia w strukturę ISTQB. Jego
posiadanie jest wymagane do podejścia do każdego z innych egzaminów w tej organizacji.

Struktura certyfikacji na dzień 10.04.2017.

Nie można więc uzyskać żadnego certyfikatu poziomu zaawansowanego, ani żadnego z dodatków do
poziomu podstawowego bez posiadana certyfikatu Poziomu Podstawowego.

MATERIAŁY

Każdy z sylabusów udostępniany jest wraz z:

▪ podręcznikiem

(sylabusem):

http://edu.ittraining.pl/material/Sylabus-ISTQB-Poziomu-

Podstawowego-PL

▪ przykładowymi pytaniami:

http://edu.ittraining.pl/material/Przykladowy-egzamin-ISTQB-

Poziomu-Podstawowego

▪ dodatkowo

udostępnionym

uniwersalnym

słownikiem

testerskim:

http://edu.ittraining.pl/material/Slownik-terminow-testowych-ISTQB

Elementy podręcznika

Na podręcznik składa się kilka elementów, które szczególnie często zdarza się uczestnikom egzaminu
pomijać, a na które warto zwrócić uwagę.

Wstęp do planu

Opisuje podstawy samej certyfikacji oraz grupy docelowe tego certyfikatu jak testerzy, analitycy testów,
inżynierowie  testów,  konsultanci  testów,  menedżerowie  testów,  testerzy  akceptacji  użytkownika  i
programiści. Wskazuje również inne grupy, które mogą skorzystać z certyfikacji jak kierownicy projektu,
kierownicy  jakości,  kierownicy  oprogramowania,  analitycy  biznesowi,  dyrektorzy  IT  i  konsultanci
zarządu.

Dodatkowo rozdział ten opisuje tzw. cele uczenia się/poziom wiedzy, klasyfikowane jako:

K1: zapamiętać, rozpoznać, wiedzieć;
K2: podsumowywać, klasyfikować, porównywać, przypisywać, przeciwstawiać, podawać przykłady,
interpretować, reprezentować, wnioskować, kategoryzować;
K3: zastosować;
K4: analizować.

Jest to dość ważna informacja, ponieważ cele nauczania opisane są w poszczególnych rozdziałach
znacznikami K1, K2 i K3. Oznacza to, że pytania te wymagają od uczestników albo nauki pamięciowej
(K1) albo rozpoznania elementów na liście (K2) albo zastosowania wiedzy na bardziej praktycznym
przykładzie (K3).

Poziomy te są szczegółowo opisane w Załączniku B. sylabusa.

Organizacja rozdziałów

Sam dokument zawiera sześć głównych rozdziałów. Rozdziały opisane są pod względem:

▪ dominującego poziomu wiedzy zawartego wewnątrz rozdziału (K1, K2, K3)
▪ czasu trwania wykładów dla danego rozdziału (np. 135 minut).

Wewnątrz każdego rozdziału znajdują się sekcje, a każda sekcja ma również cele uczenia się i ilość
wymaganego czasu. Podsekcje, dla których nie podano czasu, wliczają się do czasu dla całej sekcji.

Dodatkowo  każdy  rozdział  ma  również  wskazane  kluczowe  dla  niego  „pojęcia”.  Ponieważ  większość
z nich będzie nowością lub będzie też redefinicją znanego już hasła, ISTQB odsyła nas do słownika w celu
ich  dokładnego  poznania.  Przykładowo  w  sylabusie  "ISTQB  Certyfikowany  tester.  Plan  poziomu
podstawowego. Wersja 2011.1.1" w podrozdziale: 1.1 "Dlaczego testowanie jest niezbędne?" znajdują
się następujące terminy, które tester, zanim przystąpi do czytania zawartości rozdziału, powinien znać.
Są to: pluskwa, defekt, błąd, awaria, usterka, pomyłka, jakość, ryzyko. Na pierwszy rzut oka wydaje się,
że  hasła  te  będą  nam  znane,  ale  warto  odwołać  się  do  słownika,  aby  upewnić  się,  że  w  pełni  je
rozumiemy. Przykładowo  pomyłka  i  błąd  traktowane  są  zamiennie,  tak  jak  defekt  i usterka.  Definicje
ISTQB bazują na wielu wartościowych źródłach, a sam słownik jest najpełniejszą ich kompilacją. Jest to
bardzo wartościowe źródło pojęć z zakresu testowania.

Cele nauczania

Cele nauczania służą do opisania tego, co zawiera dany rozdział, ale są również podpowiedzią dla
twórców pytań egzaminacyjnych, o co powinni pytać. Jednym z wymogów ISTQB jest to, aby wszystkie
pytania były bezpośrednio zmapowane na cele nauczania. Każdy rozdział w sylabusie ISTQB zaczyna się
od celów nauczania, które dodatkowo skategoryzowane są na różnych poziomach wiedzy. Poniżej
przykład z rozdziału czwartego.

4.5

Techniki

oparte

doświadczeniu

(K2)

LO-4.5.1 Kandydat pamięta powody pisania przypadków testowych opierających się na intuicji,
doświadczeniu

oraz

wiedzy

temat

często

spotykanych

usterek.

(K1)

LO-4.5.2 Kandydat potrafi porównać techniki oparte na doświadczeniu z technikami opartymi na
specyfikacji. (K2)

LO to skrót od angielskiego learning objective i oznacza właśnie cele nauczania.

Cele nauczania pokazują nam, jakie są najważniejsze tematy w danym rozdziale i co każdy kandydat do
certyfikatu powinien z danego rozdziału wiedzieć. Powyższy przykład pokazuje, że dla LO-4.5.1 należy
sobie utrwalić, dlaczego powstają przypadki testowe. Potencjalne pytanie z tego zakresu powinno
odnosić się bezpośrednio do konkretnego zapisu z sylabusa lub też terminu słownikowego. Aby zdać
egzamin należy przeczytać cele nauczania dla każdego z rozdziałów i odpowiedzieć na zawarte w nim
pytanie lub określić, czy posiada się przytoczoną w nim wiedzę.

Cele nauczania służą osobom pragnącym zdać egzamin ISTQB, a ich znajomość jest kluczem do uzyskania
przynajmniej 65% poprawnych odpowiedzi (lub też punktów), które z kolei stanowią gwarant
otrzymania certyfikatu.

Literatura

Rekomendowane publikacje, które można (ale nie trzeba) poznać, aby przygotować się do egzaminu.
Większość z propozycji jest cytowanych albo w sylabusie, albo w słowniku. Jest to miejsce, które
wskazuje standardy i normy warte uwagi.

Wiedza podręcznika

Najważniejszą częścią sylabusa jest oczywiście jego zawartość merytoryczna. Ponieważ sam sylabus to
około 70 stron, to postanowiłem go skrócić do absolutnego minimum. Powstała kompilacja pod tytułem
„Co każdy tester ISTQB wiedzieć powinien”. Ubrałem to w formę narracyjną oraz formę wypunktowania.

Streszczenie sylabusa - opis

Ludzie popełniają pomyłki, które prowadzą do usterek (inaczej błędu lub pluskwy), a te mogą prowadzić
do awarii. Skutki usterki w oprogramowaniu mogą wyrządzić szkodę osobie, środowisku lub firmie.
Usuwanie usterek (debagowanie) nie jest obowiązkiem testowania.

Testowanie jest częścią zapewnienia jakości, przyczynia się do zwiększenia jakości i jest niezbędne w
procesie  wytwarzania  oprogramowania.  Celem  testowania  jest  znajdowanie  usterek,  nabieranie
zaufania  do  poziomu  jakości,  dostarczanie  informacji  potrzebnych  do  podejmowania  decyzji  oraz
zapobieganie defektom. Cele testowania są różne w wytwarzaniu oprogramowania i jego utrzymaniu
(wykonujemy je w celu zmiany, migracji i/lub wycofania systemu). W utrzymaniu dokonujemy analizy
wpływu,  polegającej  na  określeniu  zakresu  testów  regresywnych.  Istnieją  silne  powiązania  między
rozwojem oprogramowania, wytwarzanymi produktami i czynnościami testowymi. Modele wytwarzania
oprogramowania, a wraz z nimi testowanie, muszą zostać dostosowane do specyfiki projektu i produktu,
w związku z tym dzielimy testowanie na różne kategorie. Wyróżniamy poziomy testów: testy modułowe
(jednostkowe), testy integracyjne, testy systemowe i testy akceptacyjne. Istnieją również typy testów:
funkcjonalne,  niefunkcjonalne  (wydajnościowe,  obciążeniowe,  przeciążeniowe,  użyteczności,
pielęgnowalności, niezawodności oraz przenaszalności), strukturalne oraz związane ze zmianami. Testy
funkcjonalne  i  strukturalne  występują  na  każdym  poziomie  testów.  Istnieją  testy  potwierdzające,
których  celem  jest  sprawdzenie,  czy  poprawka  zadziałała  oraz  regresywne,  które  weryfikują,  czy
poprawka nie wprowadziła niepożądanych zmian.

Sukces testowania zależy od umiejętności miękkich testera w komunikacji z programistami, którzy
inaczej postrzegają oprogramowanie. Testowanie jest tym bardziej obiektywne, czym bardziej
niezależne od programowania. Korzyścią testowania niezależnego jest brak nacisków na testerów, a jego
wadą - odizolowanie od programistów.

Testowanie opisane jest za pomocą siedmiu zasad, które można przedstawić procesowo przy pomocy
faz: planowanie i nadzór nad testami, analiza i projektowanie testów, implementacja i wykonanie
testów, ocena kryteriów zakończenia i raportowanie, czynności zamykające test.

Typowym zadaniem lidera jest planowanie i kontrolowanie testów, a testera projektowanie testów i ich
wykonywanie.  Planowanie wykonuje  się  na różnych  poziomach  testowania.  Celem  planu  testów  jest
zaplanowanie  testowania,  czyli:  oszacowanie  zasobów,  czasu  oraz  pracochłonności,  określenie  ryzyk,
stworzenie  harmonogramu  testów,  określenie  czynności  przygotowania  i  wykonania  testów.
Harmonogram  wykonania  testów  pokazuje,  kiedy  dane  przypadki  testowe  i/lub  procedury  zostaną
wykonane  i  uwzględnia  ich  priorytety  oraz  zależności  logiczne  i  techniczne.  Szacowanie  w  ramach
planowania  może  bazować  na  metrykach  i  daje  nam  konkretne  wzory  do  obliczenia  niezbędnych
zasobów.  W  podejściu  wykorzystującym  ekspertów  określamy  zasoby  bazując  na  wiedzy  i
doświadczeniu.  W  planie  każdego  poziomu  lub  typu  testów  możemy  określić  kryteria  wejścia  (kiedy
może  się  zacząć)  oraz  zakończenia  (kiedy  się  skończy).  W  planie  umieścimy  również  metryki  do
monitorowania  przygotowania  i  wykonania  testów  (np.  liczba napisanych  testów)  oraz  raportowania
i kontroli  testów  (np.  znalezione  i  poprawione  usterki,  zaliczone  i  niezaliczone  testy).  Planowanie  to

również  definiowanie  ryzyka  jako  potencjalnego  problemu,  który  może  zagrażać  osiągnięciu  celów
projektowych jednego lub kilku interesariuszy projektu. Poziom ryzyka wylicza się przez przemnożenie
prawdopodobieństwa wystąpienia oraz wpływu (potencjalna szkoda, jaką problem może uczynić,  gdy
wystąpi).  Ryzyka  projektowe  związane  są  z  prowadzeniem  projektu  (np.  niedotrzymanie  terminu),
a ryzyko  produktowe  jest  związane  z  jakością  produktu  (np.  niedziałająca  funkcja).  Analiza  ryzyka
i zarządzanie ryzykiem mogą zostać wykorzystane do planowania testów. Lider musi również zarządzać
konfiguracją wspierającą testowanie poprzez wersjonowanie wytwarzanych przez nie produktów oraz
innych  produktów  projektowych.  W  ramach  planowania  lider  definiuje  również  podejścia  (strategie)
testowania:  analityczne,  oparte  na  modelach,  metodyczne,  zgodne  z  procesem  lub  standardem,
dynamiczne/heurystyczne, konsultatywne oraz regresywne.

Standard dokumentacji testowania oprogramowania IEEE STD 829-1998 opisuje m.in. projekt testów,
przypadek testowy, procedurę testową, plan testów, raport incydentu oraz raport podsumowujący
testy.

Istnieją  techniki  testowania  statycznego  mogące  sprawdzać  dokumenty  lub  kod  źródłowy  i  mogące
wpływać  na  jego  końcową  jakość  oraz,  w  przeciwieństwie  do  testów  dynamicznych,  nie  wymagają
uruchomienia  kodu.  Techniką  statyczną  są  przeglądy  (nieformalny,  przegląd  techniczny,  przejrzenie
i inspekcja), w których możemy wyróżnić następujące kroki: planowanie, rozpoczęcie, przygotowanie
indywidualne, spotkanie przeglądowe, poprawki, zakończenie oraz role: kierownik, moderator, autor,
przeglądający, protokólant.

Typowe  błędy  wykrywane  przez  analizę  statyczną  to:  niespójne  interfejsy,  niewykorzystywane  lub
niepoprawnie  zadeklarowane  zmienne, martwy kod, błędna  logika,  zbyt skomplikowane konstrukcje,
naruszenie standardów kodowania, słabe punkty zabezpieczeń. Typowe korzyści z analizy  statycznej:
wczesne wykrycie usterek i podejrzanych aspektów kodu, identyfikacja defektów trudnych do wykrycia
przez  testowanie  dynamiczne,  wykrywanie  zależności  i  niespójności  w  modelach  oprogramowania,
zwiększenie pielęgnowalności kodu i projektu, zapobieganie defektom.

Proces  powstawania  testów  rozpoczyna  się  od  określenia  warunku  testowego,  który  przygotowuje
projekt  testów,  który  przekształca  się  w  specyfikację  przypadków  testowych  przy  użyciu  technik.
Przypadki  testowe  układa się  w  procedury  testowe. Przypadki  testowe  są  wysokiej  jakości  jeśli  mają
jednoznaczne  powiązania  z  wymaganiami  i  zawierają  wynik  oczekiwany.  Wyróżniamy  techniki
projektowania  oparte  na  specyfikacji  (czarnoskrzynkowe,  bazujące  na  dokumentach  napisanych
w języku  naturalnym)  oraz  oparte  na  strukturze  (białoskrzynkowe,  bazujące  na  dostępie  do  kodu
i architektury) oraz techniki bazujące na doświadczeniu, które czerpią z wiedzy i doświadczeń testera.

Przypadki  testowe  czarnoskrzynkowe  piszemy  w  oparciu  o  techniki  klas  równoważności  (jeden
przypadek  na  jeden  zbiór  danych),  analizy  wartości  brzegowych  (przypadki  na  poprawnych
i niepoprawnych  granicach),  testowanie  w  oparciu  o  tablicę  decyzyjną (jeden  przypadek  na  kolumnę
tablicy), testowanie przejść pomiędzy stanami (przypadek testowy na stan i przejście między nimi). Gdy
wymagania mają formę przypadków użycia, używa się tej notacji do tworzenia przypadków i procedur
testowych. Przypadki testowe białoskrzynkowe uruchamiają 100% instrukcji i/lub decyzji w minimalnej
liczbie  testów.  Nazywamy  to  pokryciem.  Można  również  pisać  przypadki  testowe  opierające  się  na
intuicji, doświadczeniu oraz wiedzy na temat usterek.

Dobór techniki projektowania testów bazuje na analizie kontekstu, podstawach testowania, modelach
oraz cechach oprogramowania.

Narzędzie testowe ma na celu wsparcie testera w szybszym i dokładniejszym testowaniu. Użycie
narzędzi ma swoje korzyści (np. podniesienie efektywności) i ryzyka (np. uzależnienie się od narzędzia).

Narzędzia  testowe  dzieli  się  według  ich  celów  i  czynności:  narzędzia  do  zarządzania  testami,  do
zarządzania  wymaganiami,  do  zarządzania  incydentami,  do  zarządzania  konfiguracją,  narzędzia
wspierające  przeglądy,  do  analizy  statycznej,  do  modelowania,  do  projektowania  testów,  do
przygotowania  danych  testowych,  do  wykonania  testów,  do  testów  jednostkowych,  komparatory
testowe mierzące pokrycie, narzędzia do testowania zabezpieczeń, do analizy dynamicznej, do testów
wydajnościowych, do monitorowania, do testów użyteczności.

Automatyzacja testów niesie za sobą korzyści (np. szybsze uruchomienie testów regresji) oraz ryzyka
(np. niedoszacowanie kosztów utrzymania automatów). Wprowadzenie narzędzi do organizacji wymaga
zarówno udowodnienia słuszności pomysłu (proof-of-concept), czyli pokazania, że przyniesie to korzyści
oraz przeprowadzenia fazy pilotażowej, by nauczyć organizację użycia narzędzia. Narzędzie po
wdrożeniu wymaga stworzenia organizacji wsparcia jego użycia.

Streszczenie sylabusa - wypunktowanie

Poniżej przedstawiam najważniejsze elementy sylabusa wynikające z celów nauczania oraz zawartości
samego sylabusa.

Rozdział 1.

▪  Usterka w oprogramowaniu może wyrządzić szkodę osobie, środowisku lub firmie. (K2)
▪  Usterka i jej skutki to różne rzeczy. (K2)
▪  Testowanie jest niezbędne. (K2)
▪  Testowanie jest częścią zapewnienia jakości i przyczynia się do zwiększenia jakości.
▪  Ludzi popełniają pomyłki, które prowadzą do usterek (inaczej błędu lub pluskwy), a te mogą

prowadzić do awarii. (K2)

▪ Cele testowania to: znajdowanie usterek, nabieranie zaufania do poziomu jakości, dostarczanie

informacji potrzebnych do podejmowania decyzji oraz zapobieganie defektom. (K1)

▪  Cele testowania różnią się w wytwarzaniu oprogramowania i jego utrzymaniu. (K2)
▪  Debagowanie to usuwanie usterek, a testowanie to ich znajdywanie. (K2)
▪  Istnieje siedem zasad testowania.
▪  Proces testowy składa się z: planowania i nadzoru nad testami, analizy i projektowania testów,

implementacji i wykonania testów, oceny kryteriów zakończenia i raportowania, czynności
zamykających test. (K1)

▪ Sukces testowania zależy również od umiejętności miękkich testera. (K1)
▪ Testerzy i programiści również postrzegają oprogramowanie. (K2)

Rozdział 2.

▪ Istnieją silne powiązania między rozwojem oprogramowania, wytwarzanymi produktami

i czynnościami testowymi. (K2)

▪ Modele wytwarzania oprogramowania muszą zostać dostosowane do specyfiki projektu

i produktu. (K1)

▪ Istnieją następujące poziomy testów: testy modułowe (jednostkowe), testy integracyjne, testy

systemowe i testy akceptacyjne. (K2)

▪ Istnieją następujące typy testów: funkcjonalne, niefunkcjonalne, strukturalne oraz związane ze

zmianami. (K2)

▪ Testy funkcjonalne i strukturalne występują na każdym poziomie testów. (K1)

▪ Typy testów niefunkcjonalnych to testowanie: wydajnościowe, obciążeniowe, przeciążeniowe,

użyteczności, pielęgnowalności, niezawodności oraz przenaszalności. (K2)

▪ Celem wykonywania testów potwierdzających jest sprawdzenie, czy poprawka zadziałała,

a regresywnych, czy poprawka nie wprowadziła niepożądanych zmian. (K2)

▪ Testy pielęgnacyjne wykonujemy w celu zmiany, migracji i/lub wycofania systemu. (K1)
▪ Analiza wpływu polega na określeniu zakresu testów regresywnych. (K2)

Rozdział 3.

▪ Techniki testowania statycznego mogą sprawdzać dokumenty lub kod źródłowy. (K1)
▪ Statystyczne techniki testowania, weryfikując dokument opisujący produkt, mogą wpływać na

jego końcową jakość. (K2)

▪ Testy statyczne, w przeciwieństwie do dynamicznych, nie wymagają uruchomienia kodu. (K2)
▪ Kroki w przeglądzie formalnym to: planowanie, rozpoczęcie, przygotowanie indywidualne,

spotkanie przeglądowe, poprawki, zakończenie. (K2)

▪  Role w przeglądzie formalnym to: kierownik, moderator, autor, przeglądający, protokólant . (K2)
▪  Istnieją różne typy przeglądów: nieformalny, przegląd techniczny, przejrzenie i inspekcja. (K2)
▪  Typowe błędy wykrywane przez analizę statyczną to: niespójne interfejsy, niewykorzystywane

lub niepoprawnie zadeklarowane zmienne, martwy kod, błędna logika, zbyt skomplikowane
konstrukcje, naruszenie standardów kodowania, słabe punkty zabezpieczeń. (K1)

▪ Typowe korzyści z analizy statycznej: wczesne wykrycie usterek i podejrzanych aspektów kodu,

identyfikacja defektów trudnych do wykrycia przez testowanie dynamiczne, wykrywanie
zależności i niespójności w modelach oprogramowania, zwiększenie pielęgnowalności kodu
i projektu, zapobieganie defektom. (K1)

Rozdział 4.

▪ Przez określenie warunku testowego przygotowujemy się do projektu testów, który

przekształca się w specyfikację przypadków testowych przy użyciu technik. Przypadki testowe
układa się w procedury testowe. (K2)

▪ Przypadki testowe są wysokiej jakości jeśli mają jednoznaczne powiązania z wymaganiami

i zawierają wynik oczekiwany. (K2)

▪ Istnieją techniki projektowania oparte na specyfikacji (czarnoskrzynkowe) oraz oparte na

strukturze (białoskrzynkowe). (K1)

▪ Techniki oparte na specyfikacji bazują na dokumentach napisanych w języku naturalnym,

techniki oparte na strukturze bazują na dostępie do kodu i architektury, techniki bazujące na
doświadczeniu czerpią z wiedzy i doświadczeń testera. (K2)

▪ Przypadki testowe czarnoskrzynkowe piszemy w oparciu o techniki klas równoważności, analizy

wartości brzegowych, testowanie w oparciu o tablicę decyzyjną, testowanie przejść pomiędzy
stanami. (K3)

▪ Testowanie w oparciu o przypadki użycia używa formy notacji przypadków użycia do tworzenia

przypadków i procedur testowych. (K2)

▪  Przypadki testowe białoskrzynkowe uzyskują pokrycie instrukcji i/lub decyzji. (K4)
▪  Pojęcie kodu to zdolność do zaprojektowania testów, które go uruchomią. (K2)
▪  Kompletność testów białoskrzynkowych zazwyczaj wymaga 100% pokrycia instrukcji i decyzji.

(K4)

▪ Można pisać przypadki testowe opierające się na intuicji, doświadczeniu oraz wiedzy na temat

usterek. (K1)

▪ Dobór techniki projektowania testów bazuje na analizie kontekstu, podstawach testowania,

modelach oraz cechach oprogramowania. (K2)

Rozdział 5.

▪ Testowania jest tym bardziej obiektywne czym bardziej niezależne jest od programowania. (K1)
▪ Korzyścią testowania niezależnego jest brak nacisków na testerów, a jego wadą odizolowanie

od programistów. (K2)

▪ Typowym zadaniem lidera jest planowanie i kontrolowanie testów, a testera - projektowanie

testów i ich wykonywanie. (K1)

▪ Planowanie wykonuje się na różnych poziomach testowania. (K1)
▪ Celem planu testów jest zaplanowanie testowania, czyli: oszacowanie zasobów, czasu oraz

pracochłonności, określenie ryzyk, stworzenie harmonogramu testów, określenie czynności
przygotowania i wykonania testów.

▪ Standard dokumentacji testowania oprogramowania IEEE STD 829-1998 opisuje m.in. projekt

testów, przypadek testowy, procedurę testową, raport incydentu oraz raport podsumowujący
testy. (K2)

▪ Istnieją różne podejścia (strategie) testowania jak: analityczne, oparte na modelach,

metodyczne, zgodne z procesem lub standardem, dynamiczne/heurystyczne, konsultatywne
oraz regresywne. (K2)

▪ Harmonogram wykonania testów pokazuje, kiedy dane przypadki testowe i/lub procedury

zostaną wykonane i uwzględnia priorytety oraz zależności logiczne i techniczne między testami.
(K2)

▪ Szacowanie bazujące na metrykach daje nam konkretne wzory do obliczenia niezbędnych

zasobów, a podejście wykorzystujące ekspertów określa zasoby, bazując na wiedzy
i doświadczeniu. (K2)

▪ Każdy poziom lub typ testów może mieć swoje kryteria wejścia (kiedy może się zacząć) oraz

zakończenia (kiedy się skończy). (K2)

▪ Istnieją metryki do monitorowania przygotowania i wykonania testów (np. liczba napisanych

testów) oraz raportowania i kontroli testów (np. znalezione i poprawione usterki, zaliczone
i niezaliczone testy). (K1)

▪ Zarządzanie konfiguracją wspiera testowanie poprzez wersjonowanie wytwarzanych przez nie

produktów oraz innych produktów projektowych. (K2)

▪ Ryzyko to potencjalny problem, który może zagrażać osiągnięciu celów projektowych jednego

lub kilku interesariuszy projektu. (K2)

▪ Poziom ryzyka wylicza się przez przemnożenie prawdopodobieństwa wystąpienia oraz wpływu

(potencjalna szkoda, jaką problem może uczynić, gdy wystąpi). (K1)

▪ Ryzyka projektowe związane są z prowadzeniem projektu (np. niedotrzymanie terminu),

a ryzyka produktowe są związane z jakością produktu (np. niedziałająca funkcja). (K2)

▪ Analiza ryzyka i zarządzanie ryzykiem mogą zostać wykorzystane do planowania testów. (K2)

Rozdział 6.

▪ Typy narzędzi testowych według ich celów i czynności: narzędzia do zarządzania testami, do

zarządzania  wymaganiami,  do  zarządzania  incydentami,  do  zarządzania  konfiguracją,
wspierające  przeglądy,  do  analizy  statycznej,  do  modelowania,  do  projektowania  testów,  do
przygotowania  danych  testowych,  do  wykonania  testów,  do  testów  jednostkowych,
komparatory  testowe  mierzące  pokrycie,  narzędzia  do  testowania  zabezpieczeń,  do  analizy
dynamicznej, do testów wydajnościowych, do monitorowania, do testów użyteczności. (K2)

▪ Narzędzie testowe ma na celu wsparcie testera w szybszym i dokładniejszym testowaniu. (K2)
▪ Użycie narzędzi ma swoje korzyści (np. podniesienie efektywności) i ryzyka (np. uzależnienie się

od narzędzia). (K2)

▪ Automatyzacja testów niesie za sobą korzyści (np. szybsze uruchomienie testów regresji) oraz

ryzyka (np. niedoszacowanie kosztów utrzymania automatów). (K2)

▪ Wprowadzenie narzędzi do organizacji wymaga udowodnienia słuszności pomysłu (proof-of-

concept), czyli pokazania, że przyniesie to korzyści oraz przeprowadzenia fazy pilotażowej,
by nauczyć organizację użycia narzędzia. (K1)

▪ Narzędzie po wdrożeniu wymaga stworzenia organizacji wsparcia jego użycia. (K1)

Zmiany podręcznika

Podręcznik nie był modyfikowany od 2011 roku, więc spodziewana jest jego aktualizacja w najbliższych
latach. W przygotowaniu do egzaminu należy zawsze korzystać z jego najnowszej wersji. Dodatkowym
problemem dla osób, które dopiero poznają świat testowania z perspektywy ISTQB może być różne
opisywanie teoretycznie tych samych zagadnień w różnych podręcznikach. Przykładem może być proces
testowania, który na poziomie podstawowym podzielony jest na następujące fazy:

▪  planowanie i kontrola
▪  analiza i projektowanie
▪  implementacja i wykonanie
▪  ocena kryterium zakończenia i raportowanie
▪  czynności zamykające testy.

Proces ten jednak prezentuje się inaczej na poziomie zaawansowanym. ZAWSZE więc korzystaj jedynie
z sylabusa właściwego (i najbardziej aktualnego) dla egzaminu podstawowego.

Nieścisłości i błędy podręcznika

Przez wiele lat funkcjonowania w podręczniku udało się znaleźć wiele błędów i nieścisłości. Będą one
zapewne poprawione, ale ponieważ obowiązująca wersja ciągle je zawiera, warto pokazać te
najważniejsze.

Błąd czy defekt

ISTQB  zaproponowało,  aby  rozróżnić  błędy  od  defektów.  Błędy  popełniają  ludzie,  a  defekty  są  ich
konsekwencją.  Choć ISTQB jest rozpowszechnione  również w Polsce, terminologia ta nie przyjęła się
w projektach  informatycznych.  W  wielu  źródłach,  szczególnie  tych  spoza  nurtu  ISTQB,  zarówno  od
praktyków  testowania,  jak  i  amatorów,  przyjęło  się  mówić  o  problemach  oprogramowania  jako

o błędach. Stąd też słyszymy z wielu stron błąd oprogramowania. Teoretycy zebrani wokół certyfikacji
przyjmują, że błąd musi zostać popełniony. Oprogramowanie nie może popełniać błędów. To człowiek
popełnia  błąd,  a  jego  konsekwencją  jest  defekt,  który  prowadzi  do  awarii.  Praktycy  upraszczają.
Wszystko  jest  błędem.  Błąd  człowieka,  błąd  oprogramowania,  błąd  w  interfejsie.  Same  błędy.
Przykładowo  popularnonaukowe  publikacje  w  mediach  głównego  nurtu  napiszą:  "Błąd
w oprogramowaniu doprowadził do problemów systemu bankowego". Nie rozróżnia się więc przyczyny
od konsekwencji.

Niestety również w sylabusie ISTQB zawarte są błędy odnośnie stosowania pojęć. Przykłady:

▪ „Szeroko wykorzystywaną techniką opartą na doświadczeniu jest zgadywanie błędów. Ogólnie

rzecz biorąc testerzy przewidują usterki bazując na swoim doświadczeniu. Ustrukturalizowane
podejście do zgadywania błędów polega na sporządzeniu listy możliwych defektów i na
zaprojektowaniu testów, które atakują te defekty.” - czyli autorowi chodziło o technikę
zgadywania defektów.

▪ „Typowo kryteria zakończenia mogą składać się z: […] estymat gęstości błędów” - nie możemy

określić gęstości błędów, ale możemy określać gęstość defektów lub awarii.

▪ „Zasada 7 - Mylne przekonanie o braku błędów. Znajdowanie i naprawa usterek nie pomoże,

jeżeli produkowany system nie nadaje się do użytkowania lub nie spełnia wymagań i oczekiwań
użytkownika.” - chodzi więc o mylne przekonanie o braku defektów (usterek).

Inkrementacja czy iteracja

Sylabus  ISTQB  poziomu  podstawowego  zawiera  pojęcie  modelu  rozwoju  oprogramowania  zarówno
iteracyjnego,  jak  i  inkrementacyjnego.  Z  perspektywy  dzisiejszego  stanu  wiedzy  IT  inkrementacja
i iteracja  zlewają  się  w  jedno.  Są  to  po  prostu  metody  budowania  oprogramowania,  rozwoju
oprogramowania,  gdzie  w  cyklach  dostarczamy  jego  kolejne  wersje.  Spoglądając  na  definicję  można
powiedzieć, że nie różnią się one niczym za wyjątkiem  dużej lub małej liczby iteracji potrzebnych do
dostarczenia działającego  oprogramowania.    Kłopot polega  na  tym,  że modele inkrementacyjne były
zdefiniowane  dużo  wcześniej  niż  iteracyjne.  Inkrementacja  oprogramowania  to  wprowadzenie
cykliczności  dostawy  oprogramowania  do  modelu  kaskadowego  z  uwzględnieniem  ciężkich  metodyk
pracy  takich  jak  PMI  czy  Prince.  Odchodzące  do  lamusa  RUP  czy  RAD  nazywane  były  modelami
inkrementacyjnymi i powiedzieć o nich dzisiaj, że są iteracyjne nie będzie dużym grzechem. Nie będzie
to  jednak  też  do  końca  prawdą.  Iteracyjność  to  odbiurokratyzowanie  pojęcia  inkrementacji.  Jest  to
usunięcie  elementów  obciążających  proces  wytwarzania  oprogramowania  takich  jak  rozbudowana
specyfikacja,  centralne  sterowanie,  czy  formalne  zarządzanie  ryzykiem  i  orientacja  na  szybkie
dostarczanie rozwiązań informatycznych.

Z powodów historycznych utrzymuje się oba pojęcia razem, czasami posługując się hasłem iteracyjno-
inkrementacyjny  (inkrementacyjno-iteracyjny)  dla  podkreślenia  podobieństwa  między  nimi.  Jest  to
ewolucyjne  przejście  od  inkrementacji  do  iteracji,  które  jest  naturalną  zmianą  i  nowym  myśleniem
o cykliczności.

STRUKTURA EGZAMINU

Egzamin ISTQB poziomu podstawowego składa się z 40 pytań, w których tylko jedna odpowiedź jest
poprawna. Liczba punktów, jaką uczestnik może uzyskać to 40. Aby zdać egzamin, należy zdobyć
minimum 26 punktów (65%). Na napisanie egzaminu w języku ojczystym jest 60 minut. W przypadku
wyboru pytań w innej wersji językowej, uczestnik egzaminu otrzymuje dodatkowe 15 minut.

Wytyczne dla podchodzących do egzaminu

Nie ma żadnych specjalnych wymagań dla osób, które chcą przystąpić do egzaminu ISTQB na poziomie
podstawowym, ale rekomendowane jest „jakieś” doświadczenie w testowaniu. Nie jest również
konieczne ukończenie kursu przed podejściem do egzaminu.

Forma egzaminu

Egzamin może mieć formę elektroniczną lub pisemną. Forma zdawania egzaminu nie wpływa na czas
trwania egzaminu. Formę egzaminu dobierz do swoich preferencji.

Siadając do egzaminu otrzymuje się wydrukowane pytania oraz kartę odpowiedzi. Egzamin pisemny to
obcowanie z papierem i tym osobom, które wolą dźwięk szeleszczących kartek oraz wielowymiarową
„nawigację”  po  pytaniach  polecamy  to  rozwiązanie.  Egzamin  pisemny  wymaga  trochę  większej
samodyscypliny  przy  końcowej  weryfikacji  udzielonych  odpowiedzi.  Zawsze  powinniśmy  na  koniec
sprawdzić,  czy  udzieliliśmy  odpowiedzi  na  wszystkie  pytania  oraz  czy  kartki  w  arkuszu  są  dobrze
poukładane (jeśli je rozdzieliliśmy). Jeśli chcemy porównać dwa pytania to jest to odrobinę łatwiejsze niż
w egzaminie elektronicznym. Dodatkowo pamiętajmy, że w egzaminie pisemnym jedyne, co może się
popsuć to długopis, a i na to możemy się łatwo przygotować mając w zanadrzu drugi.

Wybierając  formę  elektroniczną  uczestnik  zdaje  egzamin  na  specjalnie  przygotowanym  stanowisku
komputerowym.  Zdający  korzysta  z  internetowej  aplikacji  do  egzaminów.  Egzamin  elektroniczny  to
nawigacja  jednowymiarowa  z  możliwością  wyboru  konkretnego  pytania,  do  którego  chcemy  przejść.
Możemy dowolnie przechodzić do pytań, na które już udzieliliśmy odpowiedzi, a dodatkowo będą one
na  liście  pytań  oznaczone  jako  te  z  udzieloną  odpowiedzią.  Ułatwia  nam  to  więc  sprawdzenie,  czy
wszystkie pytania mają swoje odpowiedzi.

Ponieważ egzamin elektroniczny odbywa się online oraz bazuje na sprzęcie komputerowym, może się
zdarzyć, że pojawią się dodatkowe problemy, które mogą zwiększyć stres podczas egzaminu. Brak sieci
doprowadzi do przerwania egzaminu. Podobnie może się stać przy nieprzewidzianych problemach z
komputerem. Może to być zwykła aktualizacja, która nagle zmusi nas do restartu lub, w ekstremalnych
przypadkach, może pojawić się krytyczny wyjątek.

Największą zaletą egzaminu elektronicznego jest natychmiastowe otrzymanie wyniku. Nie musisz więc
czekać, aby uzyskać informację o tym, czy egzamin zakończył się wynikiem pozytywnym czy
negatywnym.

Pomoce na egzaminie

Na egzamin należy przynieść długopis.

W każdym wypadku uczestnik egzaminu otrzymuje jedną czystą kartkę, która służy do robienia notatek.
Jeśli robisz wyjątkowo dużo notatek, to istnieje szansa na otrzymanie kolejnej kartki. Wszystkie
otrzymane kartki muszą być zwrócone na koniec egzaminu. Nie są one sprawdzane i zaraz po egzaminie
zostaną zniszczone.

Osoby  przystępujące  do  egzaminu  w  języku  obcym  mogą  dodatkowo  korzystać  ze  słownika  języka,
w jakim  zdają  egzamin  i  może  to  być  słownik  dwujęzyczny  (np.  słownik  angielsko-polski)  lub
jednojęzyczny  (np.  angielsko-angielski).  Zasada  ta  nie  dotyczy  osób  przystępujących  do  egzaminu
w języku ojczystym.

Korzystanie z innych pomocy naukowych w czasie trwania egzaminu jest niedozwolone.

Wyjście z egzaminu

Podczas egzaminu wyjście z sali jest niedozwolone i opuszczenie pomieszczenia jest równoważne z jego
zakończeniem. Nie ma znaczenia, jaki jest cel opuszczenia sali - wyjście do toalety również kończy
egzamin. Zazwyczaj w przypadku egzaminu ISTQB Poziom Podstawowy nie jest to duży kłopot, ponieważ
egzamin trwa maksymalnie 75 minut.

Pytania na egzaminie

Pytania egzaminacyjne pochodzą z puli pytań i zarówno pytania, jak i odpowiedzi często są generowane
losowo. Może to różnić się w zależności od dostawcy egzaminu, ale zazwyczaj zasada ta dotyczy
większości dostawców. Poziom trudności pytań jest porównywalny. Nowe pytania są stale układane
przez komisje egzaminacyjne.

Szanse na zdanie egzaminu

Szanse zdania egzaminu ISTQB Poziom Podstawowy mogą być kalkulowane w oparciu o zdawalność dla
tego egzaminu. SJSI, które jest polskim przedstawicielstwem ISTQB, opublikowało dane, które mówią,
że jego ogólna zdawalność kształtuje się na poziomie około 90%. Dane zbierane są od 2007 roku
i pokazują, że trend ten jest stabilny. Dane o zdawalności dla kursów przygotowujących do egzaminu
i prowadzonych przez testerzy.pl są bliskie 99%.

Zakończony egzamin i co dalej?

Po zdaniu egzaminu otrzymasz jego wynik. W przypadku formy elektronicznej otrzymujesz informacje
od razu. W przypadku egzaminu papierowego na wynik czekasz nawet do 7 dni, a informacja jest
przesyłana na podany przez Ciebie adres mailowy.

Czas oczekiwania na certyfikat ISTQB to okres do maksymalnie dwóch miesięcy od daty egzaminu. Czas
ten może się wydłużyć jeśli Ty lub firma, która wysłała Cię na egzamin nie opłaciła Twojego udziału
w egzaminie.

W zależności od miejsca zadawania egzaminu certyfikat zostanie wystawiany albo w języku polskim, albo
angielskim. W przypadku wystawienia certyfikatu w języku polskim możliwe, że angielskojęzyczny
certyfikat będzie dodatkowo płatny. Certyfikat dostarczany jest w postaci pliku PDF, wysyłanego na
adres mailowy uczestnika egzaminu. Każda osoba posiadająca certyfikat w postaci elektronicznej może
samodzielnie go drukować i kopiować.

Certyfikat ISTQB Poziom Podstawowy jest bezterminowy.

Nie zdałeś egzaminu i co dalej?

Jeśli nie zdasz egzaminu, możesz podejść do niego ponownie. Niestety za każde podejście pobierana jest
nowa opłata egzaminacyjna.

PRZYKŁADOWE PYTANIA

Pytania można podzielić na dwie grupy - te spoza ISTQB, które zazwyczaj mają prostą konstrukcję oraz
(niestety również) błędy oraz przykładowe pytania, udostępniane przez ISTQB i ich polskie tłumaczenia,
udostępniane przez SJSI.

Pytania spoza ISTQB

W  Internecie  i  w  książkach  znajdziecie  wiele  przykładowych  pytań  egzaminacyjnych  ISTQB.  Problem
większości z nich jest taki, że zawierają błędy. Zamiast stać się pomocą naukową w przygotowaniu do
egzaminu mogą stać się dodatkowym utrudnieniem, mylnie wskazując, co jest poprawne. Jeśli uczysz
się  w  oparciu  o  pytania,  warto  mieć  świadomość  ich  ograniczeń.  Oto  rekomendowana  przeze  mnie
forma uczenia się jeśli zdecydujesz się sięgać po pytania ze źródeł innych niż ISTQB:

1.  Poszukaj przykładowych pytań w Internecie, w książkach i innych publikacjach.
2.  Odpowiedz na pytania.
3.  Nie ufaj poprawnym odpowiedziom podanym w źródłach.
4.  Jeśli  nie  masz  wiedzy  i  pewności,  że  odpowiedź  jest  poprawna,  znajdź  właściwą  odpowiedź

w sylabusie (jeśli jej tam nie ma, sprawdź w innych źródłach w Internecie).

Nie należy ufać zarówno pytaniom, jak i odpowiedziom z Internetu jeśli pochodzą ze źródeł innych niż
ISTQB. Pytania te często mają błędy, są nieaktualne, albo nie mają za wiele wspólnego z sylabusem
ISTQB. Inne powody mogą wynikać z:

▪  struktury niezgodnej z sylabusem (wybór dwóch poprawnych odpowiedzi),
▪  nieudolnego tłumaczenia,
▪  odniesienia do starych sylabusów i braku aktualizacji,
▪  odniesienia do nieaktualnych słowników.

Pamiętaj również, że jak wspominaliśmy wcześniej, sylabus ma błędy i niejasności w wielu miejscach,
a to z kolei przekłada się na interpretację.

Poniżej znajduje się kilka przykładów błędów w pytaniach w języku angielskim, pochodzących
z hinduskich stron. Tam zazwyczaj znajdziemy najwięcej błędnych pytań i odpowiedzi.

PYTANIE ZA KRÓTKIE – zawiera zbyt mało odpowiedzi.

It is an unfair test to perform stress testing at the same time you perform load testing.

a. True
b. False

BŁĄD MERYTORYCZNY – pojęcia niezgodne z sylabusem ISTQB.

Testing error message fall under __________ category of testing.

a.  Incremental Testing
b.  Thread Testing
c.  Documentation Testing
d.  Stress Testing

DEFEKT JĘZYKOWY – niepoprawnie sformułowane pytanie.

Defects are least costly as what stage of Development cycle.

a.  Analysis and Design
b.  Construction
c.  Requirements
d.  Implementation

NIEJEDNOZNACZNE PYTANIE - które posługuje się skrótem, który może być odczytywany na wiele
sposobów.

QC is

a.  Phase building activity
b.  Intermediate activity
c.  End of Phase activity
d.  Design activity

NIEPOWIĄZANE Z ISTQB – pytanie dotyczące konkretnego narzędzia.

Status Reports in Test Director can be generated using

a.  Document Viewer
b.  Document Generator
c.  Document Tracker
d.  None of the above

ODWOŁANIE DO STAREGO SYLABUSA – wiedza, która była dostępna we wcześniejszych wersjach
sylabusa, ale została z niego usunięta.

The standard that gives definitions of testing terms is:

a.  ISO/IEC 12207
b.  BS 7925-1
c.  ANSI/IEEE 829
d.  ANSI/IEEE 729

Należy  pamiętać,  że  błędy  mogą  dotykać  również  uznanych  publikacji,  które  można  by  uważać  za
poprawne ze względu na źródło lub autora. Książki współtwórcy sylabusów ISTQB, Rexa Blacka, nie tylko
zawierają pytania i odpowiedzi, z którymi ciężko się zgodzić, ale również nie pokazują uzasadnienia dla
odpowiedzi.  Nie  wiadomo  więc,  czy  są  to  błędy  redakcyjne,  czy  też  merytoryczne.  Co  jest  jednak
najbardziej irytujące to fakt, że na część pytań nie można znaleźć samodzielnie odpowiedzi, ponieważ
Rex Black posługuje się pojęciami niezgodnymi z sylabusem i słownikiem.

Pytania ISTQB

Przykładowe  pytania  udostępniane  na  stronach  ISTQB  lub  ich  polskie  tłumaczenia  również  mogą
zawierać  błędy  lub  są  niejednoznaczne.  Na  początku  należy  więc  upewnić  się,  że  pytania,  jakie
analizujesz rzeczywiście są w najnowszej, udostępnionej wersji.

Poniżej prezentujemy oficjalne pytania ISTQB wraz z omówieniem typowej struktury.

1. Pytanie z pozorną pojedynczą odpowiedzią, gdzie realnie należy wskazać więcej niż jedną

odpowiedź przez zaznaczenie grupy odpowiedzi.

Które z poniższych stwierdzeń NAJLEPIEJ obrazują główne cele Zarządzania Konfiguracją?

Wszystkie testalia (ang.: testware) są zidentyfikowane i poddane kontroli wersji;

ii.

Wszystkie testalia zostaną użyte w końcowych testach akceptacyjnych;

iii.

Wszystkie testalia są składowane we wspólnym repozytorium;

iv.

Wszystkie testalia są śledzone pod względem zmian;

Wszystkie testalia są przypisane do odpowiedniego właściciela;

vi.

Wszystkie testalia są odpowiednio powiązane ze sobą oraz z odpowiednimi elementami
wydania.

A.  ii, iii, v.
B.  i, iii, iv.
C.  iv, v, vi.
D.  i, iv, vi.

Odpowiedź poprawna to D.

Pytanie o podobnej strukturze jak powyżej, ale z koniecznością pogrupowania odpowiedzi.

Rozważ poniższe techniki. Które z nich są technikami statycznymi a które dynamicznymi?

Podział na klasy równoważności

ii.

Testowanie w oparciu o przypadki użycia

iii.

Analiza przepływu danych

iv.

Testowanie eksploracyjne

Testowanie decyzji

vi.

Inspekcje

A.  iii oraz vi są statyczne, i, ii, iv oraz v są dynamiczne.
B.  vi jest statyczna, i-v są dynamiczne.
C.  i - iv są dynamiczne, v - vi są statyczne.
D.  ii, iii oraz vi są statyczne, i, iv oraz v są dynamiczne.

Odpowiedź poprawna to A.

2. Pytania niejednoznaczne, gdzie więcej niż jedna odpowiedź jest poprawna, ale jedna z nich jest

„poprawniejsza”. ISTQB próbuje od lat odchodzić od takich pytań, ale niestety ciągle są bardzo
popularne.

Które z poniższych stwierdzeń ZAZWYCZAJ się sprawdza?

A. A Testowanie modułowe jest ważną częścią testów akceptacyjnych.
B. B Testowanie modułowe wyszukuje usterki w programach, które można testować

oddzielnie.

C. C Przeglądy kodu źródłowego są często wykorzystywane w testowaniu modułowym.
D. D Testowanie modułowe jest skierowanie na wykazanie problemów w interakcji

pomiędzy oprogramowaniem a elementami sprzętowymi.

Odpowiedź poprawna to B.

Które z poniższych narzędzi najprawdopodobniej zawiera komparator?

A.  Narzędzie do analizy dynamicznej.
B.  Narzędzie do wykonywania testów.
C.  Narzędzie do analizy statycznej.
D.  Narzędzie do testowania bezpieczeństwa.

Odpowiedź poprawna to B.

3. Pytania niezgodne z najnowszymi wytycznymi ISTQB, zakazującymi odpytywania przez negację.

Ciągle bardzo popularne w zestawach egzaminacyjnych.

Co najprawdopodobniej NIE znajdzie się w zgłoszeniu incydentu?

A.  Faza cyklu życia, w którym wystąpił incydent.
B.  Sugestie dotyczące naprawy problemu.
C.  Data wystąpienia incydentu.
D.  Stopień wpływu incydentu na interesy interesariuszy

Odpowiedź poprawna to B.

Które z poniższych twierdzeń na temat testowania regresywnego jest FAŁSZYWE?

A. Testowanie regresywne powinno być wykonywane po każdej zmianie w aplikacji.
B. Należy dokonywać przeglądów testów regresywnych, w celu zapewnienia ich zgodności

z wymaganiami biznesowymi.

C. Zautomatyzowane testowanie regresywne jest zawsze bardziej efektywne od

manualnego.

D. Testy regresywne mogą być uruchamiane wiele razy.

Odpowiedź poprawna to C.