jak zdac egzamin ISTQB Poziom Podstawowy

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.

ŹRÓDŁA

http://testerzy.pl/baza-wiedzy/jak-sylabus-istqb-proces-testowy

http://testerzy.pl/baza-wiedzy/jak-czytac-sylabus-istqb-model-iteracyjny-czy-inkrementacyjny

http://testerzy.pl/baza-wiedzy/defekt-blad

http://testerzy.pl/baza-wiedzy/jak-sylabus-istqb-slownictwo

http://testerzy.pl/artykuly/egzamin-istqb-foundation-podstawowy-faq

http://testerzy.pl/baza-wiedzy/czy-mozna-zdawac-egzamin-istqb-bez-podejscia-do-kursu-tak

http://sjsi.org/ist-qb/statystyki-egzaminow/

http://edu.ittraining.pl/material/Pytania-przykladowe-egzamin-ISTQB-Poziomu-Podstawowego

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

Wyszukiwarka

Podobne podstrony:
Egzamin 2015 poziom podstawowy
jak zdac egzamin
Jak zdać egzamin(1)
EGZAMIN USTNY POZIOM PODSTAWOWY
Egzamin 2016 poziom podstawowy
Egzamin 2012 poziom podstawowy
Jak Zdać Egzamin Zawodowy na Technika Elektronika, Etap Praktyczny
(8853) jak zdac egzamin cd
Egzamin 2012 poziom podstawowy
Egzamin 2010 poziom podstawowy
jak zdac egzamin
PPP jak zdac egzamin
Egzamin 2006 poziom podstawowy transkrypcja
Egzamin 2011 poziom podstawowy

więcej podobnych podstron