Prezentacja ISTQB FL Dzień 1

Certyfikowany tester – poziom podstawowy ISTQB Dzień pierwszy
Certyfikowany tester
Poziom podstawowy
Program kursu
Wstęp
1. Podstawy testowania
2. Testowanie w cyklu życia oprogramowania
3. Statyczne techniki testowania
4. Techniki projektowania testów
5. Zarządzanie testowaniem
6. Testowanie wspierane narzędziami
Przykładowe zadania egzaminacyjne
Wstęp - Certyfikat
Po co się certyfikować?
•Z punktu widzenia osoby testera:
• zasób wiedzy;
• rozwój zawodowy;
• dowód specjalizacji zawodowej.
•Z punktu widzenia zawodu testera:
• wspólna terminologia;
• właściwe określenie statusu testera;
• wspólny zasób wiedzy.
•Z punktu widzenia pracodawcy:
• szybszy (łatwiejszy) proces zatrudniania;
• możliwość budowy ścieżki rozwojowej testera.
Wstęp - Certyfikat
Wady certyfikacji:
• egzamin ukierunkowany na terminologię;
• za dużo teorii, za mało praktyki;
• niemożliwa do przeprowadzenia bez
zdefiniowanych standardów;
• nie jest jedyną drogą do bycia dobrym
testerem.
Wstęp - Certyfikat
Certyfikat ISEB (1/3)

•BCS: www.bcs.org
•ISEB: www.bcs.org/iseb/st
•Historia:
• BCS SIGIST (www.sigist.org.uk)
• BS 7925-2, Software Component Testing
• BS 7925-1, Software Testing Vocabulary
• ISEB Software Testing Foundation Certificate od 1998
Wstęp - Certyfikat
Certyfikat ISEB (2/3)

•Trzy poziomy:
• SW Testing Foundation Certificate (od 1998);
• SW Testing Practitioner Certificate (od 2002);
• SW Testing Practitioner Diploma (planowany)
• Podstawa do międzynarodowego certyfikatu
• Pierwszy stopień to:
• Certyfikowany tester - Poziom podstawowy
Wstęp - Certyfikat
Certyfikat ISTQB (3/3)

•ISTQB (www.istqb.org) od 2002
•W ISTQB współpracuje ponad 30 narodowych
organizacji:
• amerykańska, australijska, austriacka, duńska,
fińska, francuska, hiszpańska, holenderska, indyjska,
izraelska, japońska, koreańska, niemiecka, norweska,
polska (SJSI), portugalska, szwedzka, szwajcarska i
inne.
Wstęp - Certyfikat
Cele ISTQB:
•Wspólny międzynarodowy słownik pojęć –
tłumaczony na język danego państwa;
•Wspólny sylabus;
•Egzamin oparty o sylabus przetłumaczony na język
danego państwa;
•Akredytacja oparta o organizację w danym państwie
– w Polsce: SJSI.
Wstęp - Certyfikat
•Materiały akceptowane przez komisję akredytacyjną

danego państwa;
•Trenerzy akceptowani przez komisję akredytacyjną
danego państwa;
•Komisja akredytacyjna sprawdza jakość materiałów i
umiejętności nauczających.
Wstęp – Egzamin
• Egzamin na Certyfikat Podstawowy (Foundation

Level) jest oparty na sylabusie;
• Odpowiedzi na pytania egzaminacyjne mogą
wymagać skorzystania z materiału bazującego na
więcej niż jednym rozdziale sylabusa;
• W egzaminie uwzględnione są wszystkie rozdziały
sylabusa;
Wstęp – Egzamin
• Egzamin trwa 60 minut;

• 40 pytań – ZAWSZE tylko JEDNA odpowiedź jest
prawidłowa (z czterech);
• Wszystkie pytania mają jednakową wagę;
• Nie ma punktów ujemnych.
Wstęp – Egzamin
• Podczas egzaminu nie wolno korzystać z żadnych

materiałów;
• By zdać, należy podać minimum 65% (= 26)
poprawnych odpowiedzi;
• Zdający otrzymuje informację o wyniku egzaminu
bezpośrednio po jego zakończeniu.
Program kursu
Wstęp
• Dlaczego testowanie jest niezbędne?

• Co to jest testowanie?
• Podstawowe zasady testowania
• Podstawowy proces testowy
• Psychologia testowania
1.1. Dlaczego testowanie jest niezbędne?
Czy istnieją dziś branże przemysłu, w

których nie używa się oprogramowania?
Praktycznie NIE
Systemy informatyczne odgrywają coraz
większą rolę w życiu, począwszy od
rozwiązań dla biznesu (sektor bankowy) aż
do urządzeń dla konsumenta (samochody,
rozrywka).
Większość z nas zetknęła się z

oprogramowaniem, które nie działało tak jak
powinno.
Prosty błąd w
grze:
Koszt błędu:
praktycznie żaden
- włączenie i
wyłączenie
aplikacji.
Przypadek rakiety Ariane 5 (1/2)

4 czerwca 1996 rakieta Ariane 5,
przygotowana przez Europejska Agencję
Kosmiczną (European Space Agency) eksplodowała
40 sekund po starcie w Kourou, w Gujanie
Francuskiej.
Był to pierwszy lot tej rakiety - po dekadzie
przygotowań, które kosztowały 7 miliardów USD.
Rakieta i jej ładunek były warte 500 milionów
USD.
Przypadek rakiety Ariane 5 (2/2)

Po dwutygodniowym śledztwie okazało się,
że błąd tkwił w oprogramowaniu:
64 bitowa liczba zmiennoprzecinkowa (64 bit
floating point number) określająca poziomą
prędkość rakiety była konwertowana na
16-bitową liczbę całkowitą (16 bit signed integer).
Ponieważ liczba była większa niż 32 767,
konwersja zawiodła.
Przypadek rakiety Patriot (1/3)

25 lutego 1991 w Dhahran w Arabii Saudyjskiej
podczas pierwszej wojny w Zatoce Perskiej, amerykańska
rakieta Patriot nie przechwyciła irackiego Scuda. Scud trafił
w barak armii amerykańskiej, zabijając 28 i raniąc
ponad 100 osób.
Raport General Accounting Office, GAO/IMTEC-92-
26, zatytułowany Patriot Missile Defense: Software Problem
Led to System Failure at Dhahran, Saudi Arabia podaje
przyczynę tego zdarzenia…

Okazało się, że przyczyną był błąd arytmetyczny.
System mierzył czas w dziesiątych częściach sekundy,
używając 24 bitowego stałoprzecinkowego rejestru (24 bit
fixed point register). Po około 100 godzinach pracy błąd
numeryczny skumulował się do 0,34 sekundy, co przy
prędkości Scud’a ponad 1 676 metrów na sekundę dawało
odległość ponad ½ kilometra.
System Patriot uznał więc, że Scud jest poza jego
zasięgiem.
Problem był uprzednio wykryty.

Spowodował włączenie do instrukcji obsługi
zalecenia, by restartować aplikację co 20 godzin.
Dziś „raczej” nie popełnia się tak dużych błędów, ale

oprogramowanie z błędami może:
1. spowodować utratę zaufania klientów,
2. utrudnić zdobycie nowych klientów,
3. wyeliminować z rynku.
Podstawowe definicje:
• pomyłka,
pomyłka błąd (mistake, error): Działanie człowieka
powodujące powstanie nieprawidłowego wyniku.
• defekt,
defekt, usterka, pluskwa (defect, fault, bug): Skutek błędu
twórcy oprogramowania. Usterka może, ale nie musi
spowodować awarii.
• awaria (failure, problem, incident):

Odchylenie od spodziewanego zachowania albo wyniku
działania oprogramowania.
pomyłka,
(błąd)
mistake defekt,
(error) (usterka,
pluskwa)
defect awaria
(fault, bug) failure
(problem, incident)
pomyłka defekt awaria

mistake defect failure
Tylko wspólne zaistnienie tych

trzech czynników powoduje
nieprawidłowe działanie TP
(Testowanego Produktu).
Defekty (usterki
usterki)
usterki istnieją, ponieważ:
ludzie są z natury omylni;
wytwórcy działają:
• pod presją czasu;
• na skomplikowanym kodzie;
• w skomplikowanej infrastrukturze;
• przy zmieniających się technologiach;
jest wiele interakcji wewnątrz systemu i
pomiędzy współpracującymi systemami.
Awarie mogą być wywołane także przez

czynniki środowiska:
• promieniowanie;
• pola magnetyczne;
• pola elektryczne;
• skażenie.
Może to powodować awarie w

oprogramowaniu wbudowanym lub
wpływać na działanie oprogramowania
przez zmianę warunków działania sprzętu.
• Rygorystyczne testowanie systemów i

dokumentacji może zredukować ryzyko wystąpienia
awarii w środowisku produkcyjnym i przyczynić się
do osiągnięcia wysokiej jakości systemu.
• Konieczne jest, aby znalezione defekty były
poprawione przed dopuszczeniem systemu do
działania w środowisku produkcyjnym.
Uwaga: Testowanie oprogramowania może być również

wymagane przez zapisy kontraktowe, wymogi prawne
lub standardy przemysłowe.

Testowanie a jakość produktu (1/4)
Testowanie umożliwia:
określenie jakości produktu:
o atrybuty funkcjonalne;
o atrybuty niefunkcjonalne:
• niezawodność;
• użyteczność;
• efektywność;
• utrzymywalność.
Testowanie podnosi zaufanie co do jakości

oprogramowania, jeżeli znaleziono mało lub nie
znaleziono błędów.

Testowanie umożliwia:
poprawę jakości, gdy błędy są znalezione i
usunięte;
zwiększenie zaufania do produktu;
Testowanie ułatwia zapobieganie awariom:
prawidłowo zaprojektowany test, który przechodzi
bez znalezienia błędu, redukuje poziom ryzyka w
systemie;
jeśli testowanie znajduje błędy i błędy te zostają
naprawione, jakość systemu informatycznego
wzrasta.

Z poprzednich projektów powinny być wyciągane
wnioski.
Proces wytwórczy można doskonalić poprzez
zrozumienie przyczyn błędów znalezionych w
poprzednich projektach.
W konsekwencji powinno to zapobiec ponownemu
pojawieniu się podobnych defektów, a tym samym
poprawić jakość przyszłych systemów.

Samo testowanie nie podnosi jakości
oprogramowania i dokumentacji;
Testowanie ułatwia zapobieganie awariom.
ALE
Testowanie jest tylko jednym z wielu środków
służącym zapewnieniu jakości, inne to:
standardy kodowania;
szkolenia;
analiza błędów.
Decyzja o tym, ile trzeba testować, powinna brać

pod uwagę poziom ryzyka, włączając w to ryzyko
techniczne, biznesowe i projektowe oraz ramy
projektu takie jak czas i budżet.
Testowanie powinno dostarczyć interesariuszom
(stakeholders) informacji wystarczającej do podjęcia
decyzji o:
dopuszczeniu testowanego produktu do następnej
fazy produkcji;
przekazaniu go klientowi.

1.2. Co to jest testowanie?
Testowanie to proces składający się z wszystkich

czynności cyklu życia oprogramowania –
zarówno statycznych jak i dynamicznych;
skoncentrowany na planowaniu,
przygotowaniu i ewaluacji oprogramowania
oraz powiązanych produktów w celu
określenia, czy spełniają one
wyspecyfikowane wymagania […].
Testowanie to technologiczne badanie

pozwalające otrzymać informacje o jakości TP
(Testowanego Produktu).
technologiczne - bo używamy technologicznego
podejścia, wykorzystując eksperyment,
matematykę, logikę, narzędzia (programy
wspomagające), pomiary itp.
badanie - bo zorganizowane poszukiwanie
informacji.

Testowanie to:
Wykrywanie podstawowych błędów w
celu ich usunięcia;
Sprawdzanie zgodności aplikacji z innymi
aplikacjami;
Ułatwianie interesariuszom podjęcia
decyzji o wypuszczaniu / niewypuszczaniu
produktu;
Minimalizacja kosztów pomocy
technicznej
Kontrola zgodności z wymaganiami i
uregulowaniami prawnymi.
Różne cele wymagają różnych

strategii testowania.
Testowanie obejmuje również:

przeglądy dokumentów i kodu (reviews);
analizę statyczną.

Testowanie dynamiczne: Testowanie statyczne:
testowanie, podczas którego testowanie TP bez

wykonuje się kod modułu lub wykonywania kodu:
systemu. techniki ręczne (przeglądy);
zautomatyzowane (analiza statyczna).

Czym testowanie NIE JEST?
Debagowaniem (debugging)
(które jest procesem wyszukiwania, analizowania i
usuwania przyczyn awarii oprogramowania)
(testowanie zaś jest wyszukiwaniem awarii, przez co
wykazuje ono obecność defektów)
„Udowodnieniem”, że oprogramowanie działa „bezbłędnie”;
(Bo tego się nie da dowieść.)
„Udowodnieniem”, że oprogramowanie nie działa;

Cele testowania:
Określenie poziomu ryzyka związanego z TP;
Znajdowanie defektów (poprzez uruchamianie TP
i odnajdowanie awarii);
Ocena jakości TP (poprzez uruchamianie TP
i wykonywanie scenariuszy testowych);
Budowanie zaufania odnośnie jakości oraz
dostarczanie informacji o jakości (poprzez
uruchamianie TP i raportowanie wyników testów);
Zapobieganie awariom w produkcji. (poprzez
uruchamianie TP i raportowanie postępu napraw);
Zapobieganie powstawaniu błędów (poprzez analizę TP
i dokumentacji).
Walidacja i Weryfikacja -
- nie są etapami procesu testowania,
lecz są jego ogólnymi celami.
Walidacja: [por. z ang. „valid”] = ważny,
obowiązujący, przekonywający
Weryfikacja: [por. z łac. „verum”] = prawda.

Weryfikacja Walidacja
(Verification) (Validation)
Proces kontroli systemu lub Określenie poprawności
modułu polegający na produktów procesu tworzenia
sprawdzeniu, czy produkty oprogramowania pod względem
danego etapu produkcji spełniają potrzeb i wymagań użytkownika.
warunki zadane na początku Sprawdzenie, czy aplikacja jest
tego etapu. poprawna;
Sprawdzenie, czy poprawnie Sprawdzenie, czy spełnione są
zbudowano aplikację; życzenia klienta.
Aplikacja jest zgodna z jej
specyfikacją.

Czynności związane z testowaniem:
• planowanie;
• nadzorowanie;
• ustalanie warunków testowych;
• projektowanie zadań testowych;
• porównywanie wyników;
• ocena kryteriów zakończenia;
• raporty dotyczące procesu testowego i testowanej aplikacji;
• zakończenie i zamykanie testów (po zakończeniu fazy
testów);
występują zarówno przed jak i po wykonaniu testów.

Testowanie dostarcza informacji koniecznych

do:
poprawy testowanego oprogramowania;
poprawy procesów tworzenia i testowania
oprogramowania.

Różne rodzaje testów i ich cele: (1/3)
Testy modułowe (jednostkowe), integracyjne i
systemowe (module (unit, component), integration, system testing):
podstawowy cel: identyfikacja defektów w
oprogramowaniu i ich poprawianie.
Testy regresywne (regresyjne) (regression testing)
podstawowy cel: upewnienie się, że nie
wprowadzono żadnych nowych błędów podczas
implementacji zmian.

Testy potwierdzajace (retesty) (re-testing)
podstawowy cel: potwierdzenie dokonania naprawy
ponownym wykonaniem testu, który wykrył błąd.
Testy produkcyjne (operational tests)
podstawowy cel: ocena modułu lub systemu w jego
środowisku produkcyjnym.
Testy pielęgnacyjne (maintenance tests):
podstawowy cel: testowanie zmian w już
wdrożonym systemie, bądź wpływu zmienionego
środowiska na wdrożony system.

Testy akceptacyjne (acceptance tests, ‚UAT’):

podstawowy cel: formalne potwierdzenie działania
systemu zgodnie z oczekiwaniami i wymaganiami
użytkowników.
Testy regresyjne Retesty

Sprawdzanie czy nie powstały
Upewnianie się, czy znany
nowe, jeszcze nieznane
nam już błąd został usunięty.
błędy, czyli czy nie doszło do
cofnięcia się (łac. „regressio”)
generalnie w procesie (na
przykład po modyfikacji, po
naprawach błędów, itp.)

Debagowanie i testowanie to nie to samo:
Testerzy testują, a programiści debagują.
Testowanie ma ujawnić awarie spowodowane
defektami.
Debagowanie jest czynnością programistyczną
wykonywaną w celu zidentyfikowania przyczyny
defektu, poprawienia kodu i sprawdzenia czy defekt
został poprawnie naprawiony.
Późniejsze testowanie potwierdzające
wykonywane przez testera upewnia, że poprawka
rzeczywiście usunęła awarię.

1.3. Podstawowe zasady testowania

7 podstawowych zasad testowania:
I. Testowanie ujawnia usterki (a nie ich nieobecność).

II. Testowanie gruntowne jest niewykonalne.
III. Wczesne testowanie.
IV. Kumulowanie się błędów.
V. „Paradoks pestycydów”
VI. Testowanie jest zależne od kontekstu.
VII. Mylne przekonanie o braku błędów

I.
Testowanie ujawnia obecność defektów
(a nie ich nieobecność).
Testowanie może wykazać, że TP zawiera usterki.
Testowanie nie może wykazać, że TP nie zawiera
usterek.
Testując nie jesteśmy w stanie udowodnić, że
system nie ma usterek. Jedyne, co możemy osiągnąć
testując, to zmniejszyć prawdopodobieństwo, że w
systemie pozostały niezidentyfikowane błędy.
Niewykrycie defektów nie jest dowodem na
poprawność TP.

I.
Testowanie ujawnia obecność defektów
(a nie ich nieobecność).
Testowanie może wykazać, że TP zawiera usterki.
Testowanie nie może wykazać, że TP nie zawiera
usterek.
Testując nie jesteśmy w stanie udowodnić, że
system nie ma usterek. Jedyne, co możemy osiągnąć
testując, to zmniejszyć prawdopodobieństwo, że w
systemie pozostały niezidentyfikowane błędy.
Niewykrycie defektów nie jest dowodem na
poprawność TP.

II. Testowanie gruntowne (1/7)
W ramach testu kompletnego należy przetestować:
każdą możliwą wartość wejściową dla każdej zmiennej
(włączając zmienne wynikowe i robocze);
każdą możliwą sekwencję wykonania programu;
każdą konfigurację sprzętu (hardware) /
oprogramowania (software) włączając konfiguracje np.
serwerów - gdzie niczego nie możemy zmodyfikować;
wszystkie możliwe – ale na ogół niewyobrażalne –
użycia TP przez użytkownika końcowego.

(kompletne, wyczerpujące) (complete, exhaustive)
Douglas Hoffman pracował używając MASPAR (the Massively Parallel
computer, 64K równoległych procesorów). Ten komputer jest używany
głównie do aplikacji typu „life–critical”.
By przetestować 32-bitową funkcję obliczającą część całkowitą z
pierwiastka kwadratowego na 32 bitowym procesorze, Hoffman sprawdził
wszystkie wartości (wszystkie 232 = 4 294 967 296). Komputer
potrzebował około 6 minut na obliczenie i porównanie wyników.
Były 2 (dwa) defekty, oba nie leżące w pobliżu żadnej → wartości
granicznej. (Powodem błędu był źle obliczany bit, który w większości
przypadków nie zmieniał wyniku końcowego). Bez testów gruntownych te
błędy prawdopodobnie nie zostałyby odkryte.
Co zrobi Hoffman, gdy zmienią mu procesory z 32 bitowych na 64
bitowe?
(264 = 18 446 744 073 709 551 616) www.kaner.com

Przetestowany ma
być prosty
program.
Program zawiera 4
pętle IF.
Pomiędzy punktem A
a punktem I6 jest
pętla.
Pętla wykonuje się
maksymalnie 20
razy.
Wszystkie ścieżki są
niezależne.
Myers,
Sztuka testowania oprogramowania.
Hellion 2005

W każdej pętli
jest 5 ścieżek
wykonania
A I1 I6
!A C D I2 I6
!A C !D I3 I6
!A !C E I4 I6
!A !C !E I5 I6
Myers,
Sztuka testowania oprogramowania.
Hellion 2005

Należy sprawdzić
51 + 52 + ... + 519 + 520 =119 209 289 550 780 > 1014
ścieżek.
Załóżmy, że potrzebujemy 0,001 sekundy dla
sprawdzenia jednej ścieżki.
Daje to około 3 815 lat.


Pełne pokrycie kodu wymaga przetestowania każdej

linii kodu / rozgałęzienia / podstawowej ścieżki.
Kompletne testowanie musi oznaczać, że po

zakończeniu testów wszyscy są pewni, że nie
będzie żadnych awarii.

Testowanie kompletne jest w praktyce

niemożliwe, albo skrajnie nieopłacalne,
dlatego testerzy oprogramowania są niezbędni w
cyklu wytwórczym oprogramowania;
dlatego testerzy muszą mieć opanowane

pewne techniki testowania.

Testowanie kompletne jest w praktyce

niemożliwe, albo skrajnie nieopłacalne,
dlatego testerzy oprogramowania są niezbędni w
cyklu wytwórczym oprogramowania;
dlatego testerzy muszą mieć opanowane

pewne techniki testowania.

III. Testowanie powinno zacząć się jak najwcześniej
Czynności testowe powinny rozpoczynać

się:
jak najwcześniej;
jak tylko jest to możliwe w przypadku danego
oprogramowania.

Faza Koszt usunięcia błędu
Analiza 1 6 min
Projekt 5 0,5 h
Kodowanie 10 1h
Testy modułowe 15 1,5 h
Testy integracyjne 22 2,2 h
Testy systemowe 50 5h
Po wdrożeniu 100+ 10 h +


IV. Kumulowanie się defektów blisko siebie.
(A tendency to cluster together)
Większość defektów znalezionych podczas
testowania przed wypuszczeniem
oprogramowania lub powodujących awarie
produkcyjne znajduje się w małej liczbie
modułów.
Błędy prawie nigdy nie są równo
rozmieszczone.
Znalezienie błędu w danym module
powinno skupić uwagę testera na
tym module na dłużej.

IV. Kumulowanie się defektów blisko siebie.
(A tendency to cluster together)
Większość defektów znalezionych podczas
testowania przed wypuszczeniem
oprogramowania lub powodujących awarie
produkcyjne znajduje się w małej liczbie
modułów.
Błędy prawie nigdy nie są równo
rozmieszczone.
Znalezienie błędu w danym module
powinno skupić uwagę testera na
tym module na dłużej.

V. „Paradoks pestycydów”
Jeżeli powtarzamy ciągle te same testy, to nie
znajduje się już żadnych nowych błędów; dane
testy „tracą” swoją efektywność.
Żeby przezwyciężyć paradoks pestycydów,
przypadki testowe muszą być regularnie
przeglądane i modyfikowane;
By sprawdzić nowe / inne części TP należy
stworzyć nowe testy.

VI. Testowanie jest zależne od kontekstu
Testowanie powinno być wykonywane w różny
sposób w różnych sytuacjach. Konieczne jest
indywidualne podejście do każdego systemu.
Inaczej testujemy np.:
systemy od których zależy bezpieczeństwo i życie
ludzkie (life – critical);
systemy bankowe;
gry komputerowe.

VII. Mylne przekonanie o bezbłędności. (1/2)
TP wolny od defektów może nie spełniać
wymagań użytkownika:
o poprawna weryfikacja
ale
o niepoprawna walidacja;
Konieczne jest testowanie w oparciu o

wymagania – regularna kontrola spełnienia
wymagań.

VII. Mylne przekonanie o bezbłędności. (2/2)
Atrybuty niefunkcjonalne takie jak np.:

• wydajność;
• użyteczność;
• pielęgnowalność;
• niezawodność;
• przenaszalność
nie są na ogół wyspecyfikowane w wymaganiach, a
od ich spełnienia w dużym stopniu zależy
satysfakcja użytkownika.

1.4. Podstawowy proces testowy
Proces testowy jest częścią procesu

wytwórczego oprogramowania
podlega ograniczeniom wynikającym z
podporządkowania procesowi wytwórczemu.

Proces testowy
może – ale nie musi – być zdefiniowany formalnie;
składa się z minimum 5 czynności (faz):
1. planowanie i nadzór;
2. analiza i projektowanie;
3. implementacja i wykonanie;
4. ocena stopnia spełnienia warunków zakończenia i
raportowanie;
5. czynności zamykające test.
w niektórych organizacjach proces jest bardziej złożony.
Fazy procesu testowego są logicznie sekwencyjne, w procesie
wytwórczym mogą się zazębiać lub występować jednocześnie.

1. Planowanie i nadzór (1/3)
W ramach planowania określa się:
o cel i zakres testów (co podlega testowaniu);
o metodologię testów (techniki testowania, metryki,
pokrycie itp.);
o strategię testów;
o zasoby (ludzie, narzędzia, sprzęt, środowisko);
buduje się harmonogramy dla
o analizy testów i zadań projektowych;
o implementacji;
o wykonania;
o oceny testów;
dokonuje się analizy ryzyka związanego z testami;
określa się kryteria zakończenia.

W ramach planowania następuje:
o przypisanie ról do zadań,
o ustalenie tego jak zadania będą wykonywane,
o ustalenie, jak będą oceniane wyniki,
o przydzielanie zasobów do zadań,
o definiowanie ilości, szczegółowości, struktury oraz
wzorców dokumentacji testowej,
o wybór metryk do monitorowania, kontroli
przygotowania i wykonania testów, naprawy
defektów oraz elementów ryzyka.
o decydowanie o poziomie szczegółowości procedur
testowych
o integrowanie i koordynowanie zadań testowych z
innymi zadaniami cyklu życia oprogramowania,
o oraz zdefiniowanie ogólnego podejścia do
testowania.

Nadzór nad testami polega na:
mierzeniu i analizie rezultatów;
monitorowaniu i dokumentowaniu:
o postępu prac;
o pokrycia testowego;
o kryteriów zakończenia;
podejmowaniu decyzji.

2. Analiza i projektowanie (1/2)
Ogólne cele testowania zostają przekształcone w

konkretne warunki testowe i projekty testów.
Główne zadania:
zdefiniowanie i przeglądanie podstawy testów
(wymagania, architektura, projekt, interfejsy);
identyfikacja i priorytetyzacja: Cele
ogólne
o warunków testowych; Warunek T.

1
Warunek T.
2
o wymagań testowych;
o potrzebnych danych testowych; TC1 TC2 TC3
na podstawie analizy przedmiotów testu, specyfikacji,

zachowania i struktury.

Główne zadania (c.d.):

projektowanie i priorytetyzacja przypadków testowych
wysokiego poziomu;
ocena testowalności wymagań i systemu;
projektowanie środowiska testowego;
identyfikacja całej potrzebnej infrastruktury oraz narzędzi.

Główne zadania (c.d.):

projektowanie i priorytetyzacja przypadków testowych
wysokiego poziomu;
ocena testowalności wymagań i systemu;
projektowanie środowiska testowego;
identyfikacja całej potrzebnej infrastruktury oraz narzędzi.
„Tworzenie dwukierunkowego śledzenia
pomiędzy podstawą testów oraz przypadkami
testowymi”

3. Implementacja i wykonanie (1/4)
Warunki testowe (test conditions) są przekształcane:

w przypadki testowe (test cases)
testalia (testware);
tworzone jest środowisko testowe (test environment).
Cele ogólne
Warunek T. Warunek T.
1 2
TC1 TC2 TC3


Wykonanie testów składa się z następujących czynności:

wytwarzania przypadków testowych i określania priorytetów;
tworzenia danych testowych;
pisania procedur testowych;
przygotowywanie jarzma testowego (test harness)* i pisanie
skryptów automatyzujących testy (opcjonalnie);
tworzenia scenariuszy testowych na podstawie przypadków
testowych celem efektywnego wykonania testu;
weryfikacji poprawności utworzonego środowiska testowego;
wykonania przypadków testowych ręcznie lub przy pomocy
narzędzi, w zaplanowanej kolejności.
*Jarzmo testowe – środowisko testowe
złożone z zaślepek i sterowników
koniecznych do wykonania testów.

Wykonanie testów składa się z następujących czynności:

wytwarzania przypadków testowych i określania priorytetów;
tworzenia danych testowych;
pisania procedur testowych;
przygotowywanie jarzma testowego (test harness)* i pisanie
skryptów automatyzujących testy (opcjonalnie);
tworzenia scenariuszy testowych na podstawie przypadków
testowych celem efektywnego wykonania testu;
weryfikacji poprawności utworzonego środowiska testowego;
wykonania przypadków testowych ręcznie lub przy pomocy
narzędzi, w zaplanowanej kolejności.
*Jarzmo testowe – środowisko testowe
złożone z zaślepek i sterowników
koniecznych do wykonania testów.

Wykonanie testów składa się z następujących czynności

(c.d.):
logowania wyniku wykonania testu w dzienniku testów oraz
rejestrowanie jednostek i wersji testowanego
oprogramowania, narzędzi testowych oraz testaliów;
porównywania wyników rzeczywistych z oczekiwanymi;
raportowania rozbieżności jako incydentów i ich analizy
mającej na celu znalezienie przyczyny wystąpienia:
błędu w kodzie;
błędu w specyficznych danych testowych;
błędu w dokumencie testowym;
pomyłki w sposobie wykonania testu.

Wykonanie testów składa się z następujących czynności

(c.d.):
Powtarzania czynności testowych:
o testowania potwierdzającego (powszechnie nazywanego

re-testami): ponownego wykonania testu, który poprzednio
wykrył awarię celem potwierdzenia usunięcia usterki;
o testów regresywnych: wykonania testów celem upewnienia
się, że nowe defekty nie zostały wprowadzone do
niezmienionych obszarów oprogramowania lub, że usuwanie
usterek nie powoduje innych awarii;
o wykonania poprawionego testu.

4. Ocena stopnia spełnienia kryteriów
zakończenia i raportowanie
Wykonanie testu jest oceniane względem zdefiniowanych

celów.
Ocena powinna być wykonywana dla każdego poziomu testów.
Oceniany jest stopień spełnienia kryteriów zakończenia.
Ocena składa się z następujących głównych czynności:
sprawdzenia dziennika testów pod względem warunków
zakończenia określonych podczas planowania testów;
określenia:
o czy potrzebne jest więcej testów;
o czy należy zmienić warunki zakończenia;
napisania końcowego raportu testowania dla interesariuszy.

5. Czynności zamykające testowanie:
Zbierane są dane z zakończonych czynności testowych
celem zgromadzenia doświadczenia, testaliów, faktów i
metryk.
Czynności zamykające:
sprawdzenie, które zaplanowane dostawy zostały
dostarczone;
zamknięcie raportów incydentów lub zgłoszenie zmian do
tych, które pozostały otwarte;
wyliczenie potrzebnych metryk;
dokumentowanie akceptacji systemu;
zakończenie i archiwizacja testaliów, środowiska testowego i
infrastruktury testowej celem ponownego wykorzystania;
przekazanie testaliów do zespołu serwisowego;
analiza wniosków na potrzeby przyszłych projektów, oraz
poprawy zdolności / dojrzałości testów.

5. Czynności zamykające testowanie:
Zbierane są dane z zakończonych czynności testowych
celem zgromadzenia doświadczenia, testaliów, faktów i
metryk.
Czynności zamykające:
sprawdzenie, które zaplanowane dostawy zostały
dostarczone;
zamknięcie raportów incydentów lub zgłoszenie zmian do
tych, które pozostały otwarte;
wyliczenie potrzebnych metryk;
dokumentowanie akceptacji systemu;
zakończenie i archiwizacja testaliów, środowiska testowego i
infrastruktury testowej celem ponownego wykorzystania;
przekazanie testaliów do zespołu serwisowego;
analiza wniosków na potrzeby przyszłych projektów, oraz
poprawy zdolności / dojrzałości testów.

1.5. Psychologia testowania

Testowanie autorskie (programiści) a testowanie
niezależne (niezależny zespół testowy):
Niemal każdy programista podpisze się pod
stwierdzeniem:
„JA nie robię błędów ” .
Autor najczęściej nie widzi własnych błędów (pewnym
rozwiązaniem jest wzajemne testowanie np. w parach
programistów)
Testowanie niezależne daje:
zwiększenie nacisku na testy;
większą skuteczność w znajdowaniu defektów i awarii;
dodatkowe korzyści, takie jak niezależne spojrzenie
wyszkolonego i profesjonalnego zespołu testowego;
możliwość zastosowania na każdym poziomie testowania.

Poziomy niezależności:
niski
testy projektowane przez osoby, które pisały testowany

program;
testy projektowane przez inną osobę (np. z zespołu
wytwórczego);
testy projektowane przez osoby z innej grupy
organizacyjnej;
o niezależny zespół testowy.
testy projektowane przez osoby z innej organizacji lub z
innego przedsiębiorstwa:
o outsourcing;
o certyfikacja wykonywana przez jednostkę zewnętrzną.
wysoki

Poziomy niezależności – inne podejście:
Metodyki zwinne (agile)

wytwarzanie sterowane testowaniem (test-driven
development);
testowanie eksploracyjne;
Testowanie przez użytkownika końcowego.
Ludzie oraz projekty kierują się określonymi celami.

Ludzie mają skłonność do dopasowywania planów do
celów określonych przez kierownictwo lub innych
interesariuszy:
do znajdowania defektów i awarii („odrzucamy”);
do potwierdzania, że oprogramowanie działa („Wszystko
jest OK”).
Konieczne jest dokładne i jasne określenie celów
testowania (aby uniknąć sporów, czy coś jest, czy nie jest
błędem).
Cechy dobrego testera:

ciekawość;
„profesjonalny pesymizm”;
krytyczne spojrzenie;
przywiązywanie wagi do szczegółów;
czujność utrzymywana mimo monotonii testów;
doświadczenie, na którym można oprzeć
zgadywanie błędów;
znajomość podstaw psychologii:
o dobra komunikacja z programistami.

Tworzymy jeden zespół (1/3)
Identyfikacja awarii podczas testowania może być
postrzegana jako krytyka skierowana pod adresem
produktu lub jego autora.
Testowanie jest często postrzegane jako czynność
destrukcyjna, nawet, jeżeli jest ona bardzo
konstruktywna w świetle zarządzania ryzykiem
projektu.
Jeżeli błędy, defekty lub awarie są komunikowane w
konstruktywny sposób, można uniknąć spięć
pomiędzy testerami, analitykami, projektantami i
programistami:
odnosi się to zarówno do przeglądów, jak i do testów
dynamicznych.

Tester (a zwłaszcza kierownik testów) potrzebują dobrych
zdolności interpersonalnych, aby móc informować o
faktycznym stanie defektów, o postępie prac oraz o ryzyku w
konstruktywny sposób.
Dla autorów oprogramowania lub dokumentu, informacja o
błędzie może okazać się pomocna w doskonaleniu
umiejętności.
Znalezione podczas testowania i usunięte defekty pozwalają
zaoszczędzić czas i środki w przyszłości, i zmniejszają
ryzyko projektu.
Problemy komunikacyjne mogą wystąpić zwłaszcza wtedy,
gdy testerzy są postrzegani jako osoby przekazujące
informacje wyłącznie o awariach.

W celu poprawy komunikacji należy:
współpracować (nie walczyć) – przypominać wszystkim o
wspólnym celu, jakim jest lepsza jakość produktu;
informować o nieprawidłowościach produktu w neutralny
sposób; zorientowany na fakty, bez krytykowania osoby,
która stworzyła produkt:
o pisać obiektywne, faktyczne i rzeczowe raporty
incydentów;
o opisywać obiektywnie nieprawidłowości znalezione
podczas przeglądów;
spróbować zrozumieć, co czuje inna osoba i dlaczego
reaguje w określony sposób;
upewnić się, że inna osoba zrozumiała to, co zostało
powiedziane.
Program kursu
Wstęp

1. Modele wytwarzania oprogramowania

2. Poziomy testów
3. Typy testów. Cele testowania
4. Testowanie w fazie utrzymania
2.1. Modele wytwarzania oprogramowania
Testowanie nie ma sensu w oderwaniu od czynności

procesu wytwarzania oprogramowania, z którym jest
powiązane. Bezpośredni wpływ na proces testowania
mają:
plany jakości w projekcie i organizacji;
harmonogram projektu;
specyfikacja wymagań, projektowanie,
implementacja;
strategia integracji;
zarządzanie ryzykiem;
zarządzanie zmianami
Różne modele wytwarzania oprogramowania wymagają
różnych metodologii testowania.

Model kaskadowy (waterfall model)
Definiowanie
wymagań
Projektowanie
systemu
Specyfikacja
funkcjonalna
Implementacja
Testy

Model V
Specyfikacja Testy
akceptacyjne
Projektowanie Testy
Systemu systemowe
Specyfikacja Testy
funkcjonalna integracyjne
Testy
modułów
Implementacja
Model V został zaproponowany w latach 80-ych

w USA w odpowiedzi na potrzebę usprawnienia
kontroli jakości systemów kontroli lotów
(Hughes AAS).
Niezależnie przez Development Standard for IT
Systems of the Federal Republic of Germany,
General Directive No. 25. W 1992 wdrożono go
w niemieckim Ministerstwie Spraw
Wewnętrznych.
Istnieje wiele jego wariantów zależnych od

potrzeb, ale jego idea pozostaje niezmienna.
Model V – zalety (1/2):

Wyraźne związki pomiędzy poszczególnymi fazami
produkcji i testowania.
Wyraźne rozgraniczenie poszczególnych etapów.
Każdy poziom testów ma specyficzne dla siebie cele.
Łatwość planowania i przygotowywania testów.
Czytelność poszczególnych faz.
Wyniki z poprzedniego etapu podstawą do
następnego.
Możliwość wczesnego rozpoczęcia testowania – a
przynajmniej przygotowania się do nich.
Model V – zalety (2/2):

Analiza i projektowanie testów dla danego poziomu
powinny rozpoczynać się już podczas
odpowiadającej im fazy wytwarzania.
Testerzy powinni uczestniczyć w przeglądach wczesnych
wersji dokumentacji tworzonej podczas wytwarzania.
Zapewnia to wyższą jakość produktów pośrednich i
produktu końcowego.
Łatwiejsze i lepsze planowanie.
Mniej zmian i poprawek w późniejszych fazach
projektu.
W oparciu o model V można budować własne
modele testowania, np. łącząc różne fazy w jedną
(testy systemowe i akceptacyjne).

„Iteracyjno-inkrementalne wytwarzanie oprogramowania
toModel
procesVzbierania
– zalety (2/2):
wymagań,
Analiza i projektowanie
projektowania, budowania oraz testów dla danego
testowania poziomu
systemu
powinny rozpoczynać
zorganizowany w krótszesię już podczas
cykle
odpowiadającej im fazy wytwarzania.
rozwojowe. Na przykład: prototypowanie, RAD, Rational
Testerzy powinni uczestniczyć w przeglądach wczesnych
Unified Process
wersji (RUP)tworzonej
dokumentacji oraz podczas wytwarzania.
metodyki zwinne.
Zapewnia System
to wyższą może
jakość być przetestowany
produktów pośrednich i
na kilku poziomach
produktu w każdej iteracji. Przyrost, dodany do
końcowego.
innych wytworzonych
Łatwiejsze i lepszewcześniej,
planowanie.
staje się rosnącym systemem
Mniej zmian i poprawek w późniejszychczęściowym, który
fazach
również powinien
projektu. być przetestowany.
Testowanie
W oparciu regresywne jest bardzo
o model V można ważne
budować w każdej
własne
iteracji oprócz
modele pierwszej.np.
testowania, Każdy przyrost
łącząc różne fazy w jedną
może podlegać
(testy zarówno
systemowe weryfikacji jak i walidacji.”
i akceptacyjne).
1. Modele wytwarzania oprogramowania

2. Poziomy testów
3. Typy testów. Cele testowania
4. Testowanie w fazie utrzymania
2.2. Poziomy testów

Dla każdego poziomu testów można określić następujące
parametry:
ogólne cele;
produkty procesu wytwarzania, z których wywodzą się
przypadki testowe (podstawa testów);
przedmiot testowania (co będzie testowane);
typowe defekty i awarie;
wymagania dotyczące jarzma testowego;
wsparcie narzędziowe;
metodologia testowania;
określenie odpowiedzialnych za poszczególne zadania.
Poziomy testów:
testy modułowe (module / component / unit testing);
testy integracyjne (integration testing);
testy systemowe (system testing);
testy akceptacyjne (acceptance testing, User Acceptance, UAT)
wg TMap (Testing Management Approach)
Poziomy testów można łączyć ze sobą lub organizować na

różne sposoby zależnie od specyfiki projektu lub architektury
systemu.
Podstawowe definicje :
pokrycie (pokrycie testowe) (test coverage) - Stopień,

wyrażany w procentach, określający, w jakim zakresie
zestaw przypadków testowych wykorzystał przedmiot
pokrycia.
przedmiot pokrycia - Obiekt lub właściwość będąca
przedmiotem testowania.
Podstawowe definicje : (IEEE 1008-1987)
testowanie modułowe: polega na wyszukiwaniu błędów

i weryfikacji funkcjonalności oprogramowania (np. modułów,
programów, obiektów, klas), które można testować
oddzielnie. Może być wykonywane w izolacji od reszty
systemu, w zależności od kontekstu
cyklu rozwoju oprogramowania i od samego systemu.
Można podczas nich użyć zaślepek,
sterowników testowych oraz symulatorów.
Testy modułowe (1/12)
Inne nazwy to testy jednostkowe lub testy

komponentów lub testy modułów.
Testy modułowe to pierwszy element testów

dynamicznych.

Cel przeprowadzania testów modułowych:

Wyodrębnienie składowych elementów TP takich jak metody,
klasy, moduły.
Weryfikacja sposobu działania tych elementów niezależnie (w
odosobnieniu) od reszty aplikacji (używa się sterowników
testowych, symulatorów i zaślepek).
Eliminacja wszelkich wpływów innych elementów systemu na
testowaną jednostkę, które mogą zafałszować (przykryć)
rzeczywisty sposób działania TP.
Testowanie strukturalne w celu osiągnięcia odpowiedniego
pokrycia.
Weryfikacja właściwości niefunkcjonalnych.

Sposób przeprowadzenia testów modułowych powinien

zależeć od wagi samego przedsięwzięcia.
Im większe nakłady, tym testy modułowe powinny być
bardziej sformalizowane.
W małych projektach informatycznych można stosować
(i stosuje się) mniej sformalizowane podejście, bo
popełnienie błędu nie pociąga za sobą tak znacznych strat.
Bez względu na stopień sformalizowania testy modułów
powinny być przeprowadzane dla każdego produktu
informatycznego.

Testowanie modułowe to wprowadzenie elementów

zapewnienia jakości już we wczesnym etapie
wytwarzania TP:
na ogół bez czekania na gotowość całego systemu;
umożliwia wczesne wykrycie błędów:
o umożliwia jednoznaczne określenie miejsca wystąpienia
błędu;
o niskie koszty naprawy błędów;
o możliwość wskazania nieefektywnych linijek kodu
programu na poziomie poszczególnych modułów.

Testy modułowe zwykle powinien wykonywać
programista ponieważ:
najlepiej zna kod danego elementu systemu;
potrzebna jest „biała” znajomość TP;
zmiany w kodzie mogą pociągnąć za sobą efekty
uboczne, łatwe do zauważenia przez twórcę kodu,
dużo trudniejsze dla osoby z zewnątrz (nie znającej
kodu);
defekty są naprawiane natychmiast po znalezieniu, bez
formalnego zgłaszania incydentów.

Problemy:
Opór ze strony zespołu programistycznego.
Programiści nie chcą testować kodu gdyż:
nie mają czasu na testy;
testy są „nudne” i „bezcelowe” ;
„mój kod jest bezbłędny”;
TP „i tak będzie testowany” przez zespół testowy;
Gdy do testów dojdzie, programiści:
mogą wykazywać brak kompetencji w zakresie testowania;
mogą wykazywać brak obiektywności - gdy ta sama osoba, która
implementowała moduł, zajmuje się również jego testami.

Dziś próbuje się zastępować testy modułowe metodologią
pochodzącą z eXtreme Programming:
wytwarzanie sterowane testowaniem (Test Driven Development,
TDD) lub
„najpierw przygotuj testy” (test-first programming)
TDD to rozwojowe podejście do wytwarzania oprogramowania.
Polega na idei: najpierw napisz testy, a następnie twórz kod.
Dwa cele:
o dodatkowe przemyślenie problemu przed stworzeniem kodu
(bardziej specyfikacja niż walidacja);
o zwiększenie poprawności tworzonego kodu od samego
początku jego powstawania;

TDD Krok pierwszy:
1. Przemyśl sprawę
2. Przemyśl jak to testować
3. Napisz prosty test z
dobrym interfejsem
TDD Krok drugi:

1. Napisz tylko tyle kodu, by
uruchomić test
2. Obserwuj, dlaczego test nie
„przeszedł” – stąd pobierz
wiedzę co naprawdę masz
zaprogramować

TDD Krok trzeci:

1. Napisz tylko tyle kodu, by
test „przeszedł”
2. Uruchom ponownie test,
sprawdź czy napisany
moduł „przechodzi” test
(a także wszystkie
poprzednie testy)

TDD Krok czwarty:
1. Usuń wszelkie
powtórzenia, zwiększ
czytelność kodu
2. Ponownie wykonaj testy
3. Jak wszystko OK, to zapisz
wykonywany moduł
Uwaga: to nie jest

wcale proste i wymaga
większej uwagi przy
pracy, żeby dobrze
przygotować testy.

TDD zalety:
łatwość ponownego użycia kodu;
podatność na refaktoryzację (refactoring);
odkrywanie wzorców;
nieduży koszt dodatkowy na początku;
zwiększenie poprawności kodu.
TDD wady:
zwinna metodyka;
nie zastępuje testów jednostkowych w 100%;
wymaga znajomości zagadnień merytorycznych przez

programistów.

Podstawa testów dla testów
modułowych:
· wymagania na moduły
· projekt szczegółowy
· kod”
Typowe obiekty testów:

· moduły
· programy
· programy do konwersji lub
migracji danych
· moduły bazodanowe”

Testy integracyjne (1/13)
Testowanie wykonywane w celu wykrycia błędów w
interfejsach i interakcjach pomiędzy integrowanymi
elementami.
Testy integracyjne mogą być wykonywane na wielu
poziomach, a ich przedmiotem mogą być części
rozmaitej wielkości:
Testy integracyjne w małej skali (wewnętrzne) – integracja
modułów – po zakończeniu testów modułów;
Testy integracyjne w dużej skali (zewnętrzne) – integracja
systemów – po zakończeniu testów systemowych.

Cel testów integracyjnych:
Testowanie integracyjne
ukierunkowane jest na
znajdowanie błędów w
interfejsach pomiędzy
poszczególnymi integrowanymi
elementami, GŁÓWNIE w
wymianie danych pomiędzy
nimi.

Cel testów integracyjnych:
Podstawa testów dla t. integracyjnych:
· projekt oprogramowania i systemu
· architektura
Testowanie integracyjne
· przepływy procesów
ukierunkowane jest na
· przypadki użycia”
znajdowanie błędów w
interfejsach pomiędzy
poszczególnymi integrowanymi
· implementacja baz danych
elementami, GŁÓWNIE
podsystemów
w
wymianie danych pomiędzy
· infrastruktura
nimi.
· interfejsy
· konfiguracja systemu i dane
konfiguracyjne

Testy integracyjne w małej skali

(„małe”)
(integration testing in the small):
Zwykle przeprowadzane są przez
programistów;
podczas łączenia poszczególnych
komponentów w system sprawdzane jest
współdziałanie modułów.

Typowe odnajdywane problemy:
nie następuje przekazanie danych brak
komunikacji;
moduł wysyłający przekazuje syntaktycznie
nieprawidłowe dane, tak że moduł odbierający
nie może ich odczytać brak komunikacji.
komunikacja ma miejsce, lecz jest nieprawidłowa
semantycznie - przekazywane dane rozumiane są w
nieprawidłowy sposób;
dane przekazywane są prawidłowo, natomiast w
złym czasie, z dużym opóźnieniem lub w zbyt
krótkich odstępach czasu.

Podstawowe zasady integracji:
poszczególne moduły / systemy powinny być
integrowane tylko raz;
kolejność i terminy integracji kolejnych elementów
TP powinny być udokumentowanie;
możliwie mała ilość modułów powinna być
integrowana w jednym czasie;
TYLKO dwa systemy mogą być integrowane na
raz;
minimalizacja nakładów związanych z budową
→zaślepek i →sterowników.

zaślepka (stub) - Szkieletowa albo specjalna
implementacja modułu używana podczas
produkcji lub testów innego modułu, który tę
zaślepkę wywołuje albo jest w inny sposób od
niej zależny.
sterownik testowy (test driver) Program lub
narzędzie testowe używane do uruchamiania
oprogramowania w celu wykonania zestawu
przypadków testowych.

wyrocznia testowa (test oracle) – Źródło
dostarczające oczekiwanych rezultatów,
umożliwiające porównanie ich z rezultatami
rzeczywistymi.
komparator testowy (test comparator) Narzędzie
testowe do przeprowadzania automatycznego
porównania rezultatów rzeczywistych z
oczekiwanymi.

Podstawowe czynniki, na podstawie których

wybierana jest strategia integracji:
architektura systemu (liczba integrowanych

elementów, rodzaj zależności pomiędzy nimi);
plan projektu (terminy dostaw poszczególnych
elementów systemu);
strategia testowania (intensywność testowania
poszczególnych elementów).

Metody integracji:
Integracja
Integracja krytycznych
ad hoc elementów systemu
Integracja
Integracja Metody podstawowych
wstępująca integracji funkcjonalności
systemu
Integracja
Integracja
zstępująca „wielki
wybuch”

Metody integracji:
Moduły łączone są w takiej
Integracja
ad hoc kolejności, w jakiej zostaje
ukończona ich budowa.
Łączenie modułów rozpoczęte zostaje od

Integracja
wstępująca modułów, które wywołują inne moduły, a które
nie są wywoływane przez żadne inne moduły.
Integracja
Łączenie modułów w większe całości rozpoczyna
zstępująca się od modułów, które leżą najwyżej w strukturze
systemu i nie wywołują żadnych innych modułów.

Metody integracji:
Integracja Procesowi integracji jako pierwsze podlegają moduły
krytycznych zawierające najbardziej krytyczną funkcjonalność.
elementów systemu
Integracja
Procesowi integracji jako pierwsze podlegają
podstawowych
moduły zawierające podstawową funkcjonalność
funkcjonalności
(niekoniecznie krytyczną).
systemu
Integracji podlegają wszystkie elementy naraz.

Podejście bardzo ryzykowne – główne wady to:
Integracja
czekanie z testami do ostatniej chwili
”wielki wybuch”
duży problem z ustaleniem przyczyn błędów (pojawiają się
jednocześnie i pokrywają ze sobą)

Im większy jest zakres integracji, tym trudniejsze
może być określenie, który moduł lub system jest
przyczyną danej awarii, co powoduje zwiększone
ryzyko („wielki wybuch” to przykład ekstremalny
takiego problemu)
Najlepiej byłoby, aby testerzy rozumieli architekturę
systemu oraz mieli wpływ na planowanie
integracji.
Planowanie testów integracyjnych przed
przystąpieniem do wytwarzania systemu i jego
modułów pozwala na przyjęcie takiej kolejności
wytwarzania, która umożliwia najsprawniejsze
testowanie.

Testy systemowe (1/7)
Są to testy w pełni zintegrowanego systemu.
Jest to proces testowania sprawdzający, czy

zintegrowany system spełnia wyspecyfikowane
wymagania.*
Weryfikacja systemu pod względem kompletności
i spełnienia wymagań klienta w środowisku
podobnym do środowiska docelowego /
produkcyjnego.
Testowanie w środowisku jak najbardziej zbliżonym do
produkcyjnego, by zminimalizować ryzyko, że nie
zostaną znalezione błędy zależne od specyfiki
środowiska.
* Hetzel, Bill, Complete Guide to Software Testing

Przygotowanie, przeprowadzenie i zarejestrowanie wyników z
testów systemowych zwykle spoczywa na niezależnym
zespole testującym, ponieważ:
jest on w stanie bardziej obiektywnie ocenić TP dzięki:
o niezależności organizacyjnej;
o brakowi więzi emocjonalnej z TP typowej dla twórców kodu;
powinien być nastawiony na kontrolę systemu z
perspektywy klienta;
Powyższe wymogi są trudne do spełnienia dla programistów
uczestniczących bezpośrednio w budowie systemu.

Przygotowanie, przeprowadzenie
Podstawa testów: i zarejestrowanie wyników z
testów systemowych
· wymagania zwykle spoczywa
na system na niezależnym
i oprogramowanie
zespole testującym, ponieważ:
· przypadki użycia
jest on· w
specyfikacja funkcjonalna
stanie bardziej obiektywnie ocenić TP dzięki:
· raporty z analizy ryzyka
o niezależności organizacyjnej;
o brakowiTypowe
więzi emocjonalnej z TP typowej dla twórców kodu;
obiekty testów:
· podręczniki
powinien systemowe,
być nastawiony użytkownika
na kontrolę systemu zi
perspektywy klienta;
operacyjne
Powyższe· wymogi
konfiguracje systemu
są trudne i dane dla programistów
do spełnienia
konfiguracyjne
uczestniczących bezpośrednio w budowie systemu.

Konieczna jest obecność kierownika testów (test
leader) ze względu na:
potrzebę zapobiegania potencjalnym komplikacjom i
sporom kompetencyjnym;
ogólne spojrzenie na jakość systemu jako całości;
ktoś musi podjąć decyzję „to działa” i udzielić
jednoznacznej informacji na temat stanu systemu
upoważnionym osobom.

Podział testów systemowych:
Testy
systemowe
Testy Testy
funkcjonalne niefunkcjonalne
Testy Testy
Testy Testy Testy
oparte na w oparciu
wymaganiach o proces biznesowy wydajnościowe użyteczności przenaszalności

Testowanie funkcjonalne należy rozpocząć od

projektowania przypadków testowych przy
pomocy najbardziej stosownej dla danego
systemu techniki czarnoskrzynkowej.
Można stosować techniki testowania

strukturalnego (białoskrzynkowe), aby ocenić
staranność testowania w odniesieniu do pokrycia
wybranych elementów.

Znaczenie testów systemowych dla zapewnienia

jakości TP:
są to pierwsze testy całego TP;
są to pierwsze testy potwierdzające zgodność
TP z wymaganiami użytkownika;
na ogół są to pierwsze testy wykonywane przez
niezależny zespół testujący.

Kryteria sukcesu:
wymagania stawiane systemowi (zarówno
funkcjonalne, jak i niefunkcjonalne) muszą być
dokładnie ustalone i dokładnie opisane;
TP powinien spełniać warunki wejściowe przed
rozpoczęciem testów systemowych (np. przejść
test dymny (smoke test)).

Testy akceptacyjne (1/7)
(testy akceptacji produkcyjnej, testy akceptacji instalacji)
przeprowadza się w celu umożliwienia użytkownikowi, klientowi
lub innemu uprawnionemu podmiotowi ustalenia, czy można
zaakceptować system lub moduł. (→ Walidacja)
Dobór testów wykonywanych w ramach testów akceptacyjnych
zależy od:
charakterystyki TP;
przeznaczenia TP;
ustaleń z odbiorcą systemu.
Uwaga: Nieformalnym celem testów akceptacyjnych jest
„dostać podpis”.

(testy akceptacji produkcyjnej, testy akceptacji instalacji)
Podstawa testów:
przeprowadza się w celu umożliwienia użytkownikowi, klientowi
· wymagania użytkownika
lub innemu uprawnionemu podmiotowi ustalenia, czy można
· wymagania systemowe
zaakceptować system lub moduł. (→ Walidacja)
· przypadki użycia
Dobór testów
· procesy wykonywanych w ramach testów akceptacyjnych
biznesowe
zależy od:
· raporty z analizy ryzyka
charakterystyki TP;
przeznaczenia TP;na systemie w pełni zintegrowanym
· proces biznesowy
· procesy utrzymania i obsługi
ustaleń z odbiorcą
· procedury systemu.
pracy użytkowników
· formularze
Uwaga: Nieformalnym celem testów akceptacyjnych jest
· raportypodpis”.
„dostać
· dane konfiguracyjne

Podstawowe założenia:
Testy akceptacyjne powinny być przeprowadzane w
ewentualnie w środowisku testowym jak najbardziej
zbliżonym do przyszłego środowiska docelowego;
Testy przeprowadza zespół pracowników odbiorcy i
twórcy systemu.
testy przeprowadzane są na podstawie dokumentu
zawierającego specyfikację testów akceptacyjnych:
powstaje w oparciu o ścieżki funkcjonalne;
podpisana jest przez obie strony:
o odbiorcę;
o dostawcę systemu.

Podstawowe założenia:
Testy akceptacyjne powinny być przeprowadzane w
ewentualnie w środowisku testowym jak najbardziej
zbliżonym do przyszłego środowiska docelowego;
Testy przeprowadza zespół pracowników odbiorcy i
twórcy systemu.
testy przeprowadzane są na podstawie dokumentu
zawierającego specyfikację testów akceptacyjnych:
powstaje w oparciu o ścieżki funkcjonalne;
podpisana jest przez obie strony:
o odbiorcę;
o dostawcę systemu.

Podział testów akceptacyjnych ze względu na charakter
akceptacji:
Testowanie Testowanie Testowanie Testowanie
akceptacyjne zgodności zgodności zgodności
przez oprogramo- legislacyjnej operacyjnej
użytkownika wania z
kontraktem
Akceptacja Akceptacja Akceptacja Akceptacja

użytkownika zgodności z zgodności zgodności
kontraktem legislacyjnej operacyjnej
biznesowym

Testowanie akceptacyjne wykonywane przez
użytkownika (UAT):
przeprowadzane jest na TP projektowanym na
potrzeby konkretnego odbiorcy;
stosowane jest głównie, gdy odbiorca nie jest
jednocześnie użytkownikiem końcowym.
Testowanie zgodności oprogramowania z
kontraktem biznesowym (BAT) to weryfikacja
zgodności wytworzonego oprogramowania z
zawartym wcześniej kontraktem między producentem
a odbiorcą oprogramowania.

Testy akceptacyjne zgodności legislacyjnej
wykonuje się na podstawie obowiązujących
przepisów prawnych, branżowych lub bezpieczeństwa.
Operacyjne testy akceptacyjne
To akceptacja systemu przez jego (przyszłych)
administratorów: W tym celu testuje się np.:
o tworzenie kopii zapasowych i odtwarzania z nich
systemu;
o odtworzenia systemu po awariach;
o podatność na zadania pielęgnacji systemu;
o zarządzanie kontami użytkowników;
o odporność na zagrożenia bezpieczeństwa.

α Podział produkcyjnych testów akceptacyjnych ze względu
na miejsce, środowisko i profil działalności testerów: β
Testy ALFA Testy BETA
Testy produkcyjne przeprowadzane u Testy produkcyjne przeprowadzane w
producenta bez udziału twórców środowisku niezależnym od twórców
oprogramowania. oprogramowania.
Przeprowadzane: Przeprowadzane głównie w przypadku
dużych systemów, gdzie nie ma jednego
•w środowisku maksymalnie zbliżonym do
konkretnego odbiorcy, a liczba
środowiska docelowego
potencjalnych środowisk docelowych jest
•na produkcie dostatecznie stabilnym duża.
•w siedzibie producenta oprogramowania Testują potencjalni użytkownicy a nie
Testują potencjalni użytkownicy a nie twórcy
twórcy. Celem jest: wykrycie tych błędów, które
Celem jest: zbudowanie zaufania klienta. można wykryć jedynie w wielu
różnorodnych środowiskach testowych. .

Kryteria sukcesu:
produkty poddawane testom powinny być
stabilne, tak aby klienci (potencjalni klienci)
nie stracili w czasie testów zaufania do
testowanego produktu;
stopień sformalizowania testów powinien
być dopasowany do celu testów (bardzo
sformalizowany dla testów zgodności z
kontraktem biznesowym, mniej
sformalizowany dla testów akceptacyjnych
użytkownika);
testy powinny być przeprowadzane przez
połączony zespół – przedstawiciele
dostawcy i odbiorcy oprogramowania.

Prezentacja ISTQB FL Dzień 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Prezentacja ISTQB FL Dzień 1

Uploaded by

Copyright:

Available Formats

Certyfikowany tester – poziom podstawowy ISTQB Dzień pierwszy

Certyfikat ISEB (1/3)

Certyfikat ISEB (2/3)

Certyfikat ISTQB (3/3)

•Materiały akceptowane przez komisję akredytacyjną

• Egzamin na Certyfikat Podstawowy (Foundation

• Egzamin trwa 60 minut;

• Podczas egzaminu nie wolno korzystać z żadnych

• Dlaczego testowanie jest niezbędne?

1.1. Dlaczego testowanie jest niezbędne?

Czy istnieją dziś branże przemysłu, w

1.1. Dlaczego testowanie jest niezbędne?

Większość z nas zetknęła się z

1.1. Dlaczego testowanie jest niezbędne?

1.1. Dlaczego testowanie jest niezbędne?

Przypadek rakiety Ariane 5 (1/2)

1.1. Dlaczego testowanie jest niezbędne?

Przypadek rakiety Ariane 5 (2/2)

1.1. Dlaczego testowanie jest niezbędne?

Przypadek rakiety Patriot (1/3)

1.1. Dlaczego testowanie jest niezbędne?

Przypadek rakiety Patriot (2/3)

1.1. Dlaczego testowanie jest niezbędne?

Przypadek rakiety Patriot (3/3)

Problem był uprzednio wykryty.

1.1. Dlaczego testowanie jest niezbędne?

Dziś „raczej” nie popełnia się tak dużych błędów, ale

1. spowodować utratę zaufania klientów,

2. utrudnić zdobycie nowych klientów,

1.1. Dlaczego testowanie jest niezbędne?

• awaria (failure, problem, incident):

1.1. Dlaczego testowanie jest niezbędne?

1.1. Dlaczego testowanie jest niezbędne?

pomyłka defekt awaria

Tylko wspólne zaistnienie tych

1.1. Dlaczego testowanie jest niezbędne?

1.1. Dlaczego testowanie jest niezbędne?

Awarie mogą być wywołane także przez

Może to powodować awarie w

1.1. Dlaczego testowanie jest niezbędne?

• Rygorystyczne testowanie systemów i

Uwaga: Testowanie oprogramowania może być również

1.1. Dlaczego testowanie jest niezbędne?

Testowanie podnosi zaufanie co do jakości

1.1. Dlaczego testowanie jest niezbędne?

1.1. Dlaczego testowanie jest niezbędne?

1.1. Dlaczego testowanie jest niezbędne?

1.1. Dlaczego testowanie jest niezbędne?

Decyzja o tym, ile trzeba testować, powinna brać

• Dlaczego testowanie jest niezbędne?

1.2. Co to jest testowanie?

Testowanie to proces składający się z wszystkich

1.2. Co to jest testowanie?

Testowanie to technologiczne badanie

1.2. Co to jest testowanie?

1.2. Co to jest testowanie?

Różne cele wymagają różnych

1.2. Co to jest testowanie?

Testowanie obejmuje również:

1.2. Co to jest testowanie?

testowanie, podczas którego testowanie TP bez

1.2. Co to jest testowanie?

1.2. Co to jest testowanie?