Miętowy
Quiz summary
0 z 15 pytań ukończone
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
Informacja
Pytania zawarte w quizie opracowałem na podstawie bazy pytań dostępnych na stronie Software Testing Genius.
W części pytań możesz sprawdzić prawidłową odpowiedź oraz zapoznać się z uzasadnieniem. Uzasadnienia odpowiedzi opracowałem na podstawie polskiej wersji sylabusa ISTQB poziomu podstawowego (wersja 2011.1.3 z dnia 11 listopada 2017 r.), polskiej wersji słownika terminów związanych z testowaniem (wersja 2.2.2 z dnia 8 października 2013 r.) oraz oryginalnej (anglojęzycznej) wersji sylabusa ISTQB CTFL (wersja 2011 z dnia 31 marca 2011 r.).
Kolejność odpowiedzi w pytaniach jest losowa (przy każdym uruchomieniu quizu odpowiedzi mogą być ułożone w innej kolejności).
W każdym pytaniu prawidłowa jest tylko jedna odpowiedź.
Już ukończyłeś quiz. Nie możesz rozpocząć jeszcze raz.
Ładowanie quizu…
Musisz się zalogować, aby rozpocząć quiz.
Wymóg wstępu
Musisz ukończyć następujący quiz, aby rozpocząć ten:
Wyniki
udzielono odpowiedzi dobrze na 0 z 15
Kategorie
- Podstawy testowania 0%
- Statyczne techniki testowania 0%
- Techniki projektowania testów 0%
- Testowanie w cyklu życia oprogramowania 0%
- Testowanie wspierane narzędziami 0%
- Zarządzanie testowaniem 0%
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
-
Pytań 1 z 15Podstawy testowania1
Co jest najmniej istotną cechą dobrego testera?
PoprawnieNajmniej istotną cechą dobrego testera spośród cech wymienionych w wariantach odpowiedzi jest umiejętność programowania.
NiepoprawnieNajmniej istotną cechą dobrego testera spośród cech wymienionych w wariantach odpowiedzi jest umiejętność programowania.
-
Pytań 2 z 15Podstawy testowania2
Które z poniższych stanowi korzyść z niezależnych testów?
PoprawnieCele nauczania:
- LO-1.5.1 Kandydat pamięta czynniki psychologiczne, od których zależy sukces testowania. (K1)
- LO-1.5.2 Kandydat potrafi pokazać różnice w nastawieniu testera i programisty. (K2)
- LO-5.1.1 Kandydat uznaje ważność testowania niezależnego. (K1)
- LO-5.1.2 Kandydat potrafi wyjaśnić korzyści i wady niezależnego testowania w organizacji. (K2)
Jedną z głównych korzyści wynikających z niezależnego testowania jest możliwość uniknięcia stronniczości w definiowaniu skutecznych testów. Wynika ona przede wszystkim z braku stronniczości testerów w ocenie oprogramowania, która to stronniczość mogłaby w sposób naturalny wystąpić, gdyby oceny własnego dzieła dokonywał jego autor (deweloper).
Zgodnie z rozdziałem 1.5 Psychologia testowania sylabusa:
Sposób myślenia stosowany podczas testowania i przeglądania różni się od stosowanego podczas rozwoju oprogramowania. Programiści posiadający odpowiednie nastawienie są w stanie testować swój kod, ale zwykle odpowiedzialność za testowanie przekazuje się testerom, żeby wzmocnić koncentrację wysiłków oraz uzyskać dodatkowe korzyści, takie jak niezależne spojrzenie wyszkolonych, zawodowych testerów. (…)
Niezależność do pewnego stopnia jest często bardziej skuteczna w znajdowaniu defektów i awarii (unika się stronniczości autora). Nie może ona jednak zastąpić znajomości rzeczy i z tego względu programiści są w stanie efektywnie znajdować usterki w swoim własnym kodzie.
Zaangażowanie niezależnych testerów to dobry sposób na wzrost skuteczności wykrywania usterek w testach i przeglądach. W sylabusie zdefiniowano następujące poziomy niezależności (im wyższy poziom, tym większa niezależność):
- testy zaprojektowane przez osobę, która napisała testowane oprogramowanie (niski poziom niezależności),
- testy zaprojektowane przez inną osobę (np. z zespołu programistów),
- testy zaprojektowane przez osobę z innego zespołu w organizacji (np. niezależnego zespołu testerów) lub przez specjalistów od testów (np. testów wydajnościowych lub użyteczności),
- testy zaprojektowane przez osobę z innej organizacji lub firmy (np. testy zlecone lub certyfikacja przez niezależny organ certyfikujący).
To co w rozdziale 1.5 Psychologia testowania zdefiniowano jako poziomy niezależności, w podrozdziale 5.1.1 Organizacja testów a ich niezależność opisano jako warianty niezależności:
- brak niezależnych testerów, programiści testują swój własny kod,
- niezależni testerzy wewnątrz zespołu projektowego,
- niezależny zespół testowy lub grupa testerów wewnątrz organizacji podlegająca kierownikowi projektu lub zarządowi,
- niezależni testerzy z departamentów biznesowych lub społeczności użytkowników,
- niezależni specjaliści od określonych typów testów takich jak użyteczności, zabezpieczeń lub certyfikacji oprogramowania (którzy przeprowadzają certyfikację oprogramowania na zgodność z regulacjami prawnymi lub standardami),
- niezależni testerzy, którzy zostali wynajęci lub są na zewnątrz organizacji.
W podrozdziale 5.1.1 Organizacja testów a ich niezależność wymieniono także korzyści i wady niezależności.
Korzyści niezależności:
- niezależni testerzy widzą inne i odmienne usterki niż twórcy oraz nie mają uprzedzeń,
- niezależny tester może zweryfikować założenia poczynione podczas specyfikacji i implementacji systemu.
Wady niezależności:
- izolacja od zespołu deweloperskiego (jeżeli niezależność jest całkowita),
- programiści mogą utracić poczucie odpowiedzialności za jakość,
- niezależni testerzy mogą być postrzegani jako wąskie gardło lub obwiniani za opóźnienia w wydaniach.
NiepoprawnieCele nauczania:
- LO-1.5.1 Kandydat pamięta czynniki psychologiczne, od których zależy sukces testowania. (K1)
- LO-1.5.2 Kandydat potrafi pokazać różnice w nastawieniu testera i programisty. (K2)
- LO-5.1.1 Kandydat uznaje ważność testowania niezależnego. (K1)
- LO-5.1.2 Kandydat potrafi wyjaśnić korzyści i wady niezależnego testowania w organizacji. (K2)
Jedną z głównych korzyści wynikających z niezależnego testowania jest możliwość uniknięcia stronniczości w definiowaniu skutecznych testów. Wynika ona przede wszystkim z braku stronniczości testerów w ocenie oprogramowania, która to stronniczość mogłaby w sposób naturalny wystąpić, gdyby oceny własnego dzieła dokonywał jego autor (deweloper).
Zgodnie z rozdziałem 1.5 Psychologia testowania sylabusa:
Sposób myślenia stosowany podczas testowania i przeglądania różni się od stosowanego podczas rozwoju oprogramowania. Programiści posiadający odpowiednie nastawienie są w stanie testować swój kod, ale zwykle odpowiedzialność za testowanie przekazuje się testerom, żeby wzmocnić koncentrację wysiłków oraz uzyskać dodatkowe korzyści, takie jak niezależne spojrzenie wyszkolonych, zawodowych testerów. (…)
Niezależność do pewnego stopnia jest często bardziej skuteczna w znajdowaniu defektów i awarii (unika się stronniczości autora). Nie może ona jednak zastąpić znajomości rzeczy i z tego względu programiści są w stanie efektywnie znajdować usterki w swoim własnym kodzie.
Zaangażowanie niezależnych testerów to dobry sposób na wzrost skuteczności wykrywania usterek w testach i przeglądach. W sylabusie zdefiniowano następujące poziomy niezależności (im wyższy poziom, tym większa niezależność):
- testy zaprojektowane przez osobę, która napisała testowane oprogramowanie (niski poziom niezależności),
- testy zaprojektowane przez inną osobę (np. z zespołu programistów),
- testy zaprojektowane przez osobę z innego zespołu w organizacji (np. niezależnego zespołu testerów) lub przez specjalistów od testów (np. testów wydajnościowych lub użyteczności),
- testy zaprojektowane przez osobę z innej organizacji lub firmy (np. testy zlecone lub certyfikacja przez niezależny organ certyfikujący).
To co w rozdziale 1.5 Psychologia testowania zdefiniowano jako poziomy niezależności, w podrozdziale 5.1.1 Organizacja testów a ich niezależność opisano jako warianty niezależności:
- brak niezależnych testerów, programiści testują swój własny kod,
- niezależni testerzy wewnątrz zespołu projektowego,
- niezależny zespół testowy lub grupa testerów wewnątrz organizacji podlegająca kierownikowi projektu lub zarządowi,
- niezależni testerzy z departamentów biznesowych lub społeczności użytkowników,
- niezależni specjaliści od określonych typów testów takich jak użyteczności, zabezpieczeń lub certyfikacji oprogramowania (którzy przeprowadzają certyfikację oprogramowania na zgodność z regulacjami prawnymi lub standardami),
- niezależni testerzy, którzy zostali wynajęci lub są na zewnątrz organizacji.
W podrozdziale 5.1.1 Organizacja testów a ich niezależność wymieniono także korzyści i wady niezależności.
Korzyści niezależności:
- niezależni testerzy widzą inne i odmienne usterki niż twórcy oraz nie mają uprzedzeń,
- niezależny tester może zweryfikować założenia poczynione podczas specyfikacji i implementacji systemu.
Wady niezależności:
- izolacja od zespołu deweloperskiego (jeżeli niezależność jest całkowita),
- programiści mogą utracić poczucie odpowiedzialności za jakość,
- niezależni testerzy mogą być postrzegani jako wąskie gardło lub obwiniani za opóźnienia w wydaniach.
-
Pytań 3 z 15Podstawy testowania3
Z jakiego źródła danych zazwyczaj otrzymuje się informacje potrzebne do stworzenia planu testów?
PoprawnieNiepoprawnie -
Pytań 4 z 15Podstawy testowania4
Które z poniższych NIE należy do fazy implementacji i wykonania testów?
PoprawnieCele nauczania:
- LO-1.4.1 Kandydat pamięta pięć podstawowych czynności testowych i odpowiadające im zadania od planowania do zamknięcia testów. (K1)
Zgodnie z sylabusem, podstawowy proces testowy składa się z następujących czynności (czynności te w praktyce mogą się zazębiać lub występować jednocześnie i zwykle konieczne jest ich dostosowanie do kontekstu systemu oraz projektu):
- planowanie i kontrola (nadzór) testów,
- analiza i projektowanie testów,
- implementacja i wykonanie testów,
- ocena kryteriów zakończenia i raportowanie,
- czynności zamykające testy.
Projektowanie przypadków testowych jest jednym z głównych zadań podczas projektowania i analizy testów, a nie fazy implementacji i wykonania testów.
Etap implementacji i wykonania testów, o którym mowa w pytaniu, został opisany w podrozdziale 1.4.3 Implementacja i wykonanie testów sylabusa. Zgodnie z sylabusem, implementacja i wykonanie testów to czynność, podczas której specyfikowane są – m.in. poprzez połączenie przypadków testowych w konkretnej kolejności – procedury testowe (zwane również scenariuszami testowymi lub skryptami testowymi), a także ustawiane jest środowisko testowe oraz uruchamiane są testy.
Głównymi zadaniami implementacji i wykonania testów są:
- dokończanie, implementacja i priorytetyzacja przypadków testowych (włącznie z identyfikacją danych testowych),
- przygotowanie i priorytetyzacja procedur testowych, tworzenie danych testowych oraz (opcjonalnie) przygotowywanie jarzm testowych i pisanie automatycznych skryptów testowych,
- tworzenie zestawów testowych z procedur testowych w celu efektywnego wykonania testów,
- sprawdzanie, czy środowisko testowe zostało poprawnie ustawione,
- sprawdzanie oraz uaktualnianie dwukierunkowego śledzenia pomiędzy podstawą testów i przypadkami testowymi,
- wykonywanie procedur testowych w zaplanowanej kolejności – ręcznie lub przy pomocy narzędzi do wykonywania testów,
- zapisywanie wyników wykonania testów oraz zapisywanie identyfikatorów i wersji testowanego oprogramowania, narzędzi testowych oraz testaliów,
- porównywanie wyników rzeczywistych z wynikami oczekiwanymi,
- raportowanie rozbieżności jako incydentów oraz ich analizowanie w celu ustalenia ich przyczyny (np. defekt w kodzie, defekt w danych testowych, defekt w dokumencie testowym, pomyłka w sposobie wykonania testu),
- powtarzanie czynności testowych jako rezultat akcji podjętej po stwierdzeniu rozbieżności, na przykład powtórne wykonanie testów poprzednio niezaliczonych, aby potwierdzić naprawę (testowanie potwierdzające), wykonanie poprawionych testów i/lub wykonanie testów w celu sprawdzenia, czy w niezmienianych częściach oprogramowania nie pojawiły się usterki lub czy naprawa usterek nie ujawniła innych usterek (testowanie regresywne).
NiepoprawnieCele nauczania:
- LO-1.4.1 Kandydat pamięta pięć podstawowych czynności testowych i odpowiadające im zadania od planowania do zamknięcia testów. (K1)
Zgodnie z sylabusem, podstawowy proces testowy składa się z następujących czynności (czynności te w praktyce mogą się zazębiać lub występować jednocześnie i zwykle konieczne jest ich dostosowanie do kontekstu systemu oraz projektu):
- planowanie i kontrola (nadzór) testów,
- analiza i projektowanie testów,
- implementacja i wykonanie testów,
- ocena kryteriów zakończenia i raportowanie,
- czynności zamykające testy.
Projektowanie przypadków testowych jest jednym z głównych zadań podczas projektowania i analizy testów, a nie fazy implementacji i wykonania testów.
Etap implementacji i wykonania testów, o którym mowa w pytaniu, został opisany w podrozdziale 1.4.3 Implementacja i wykonanie testów sylabusa. Zgodnie z sylabusem, implementacja i wykonanie testów to czynność, podczas której specyfikowane są – m.in. poprzez połączenie przypadków testowych w konkretnej kolejności – procedury testowe (zwane również scenariuszami testowymi lub skryptami testowymi), a także ustawiane jest środowisko testowe oraz uruchamiane są testy.
Głównymi zadaniami implementacji i wykonania testów są:
- dokończanie, implementacja i priorytetyzacja przypadków testowych (włącznie z identyfikacją danych testowych),
- przygotowanie i priorytetyzacja procedur testowych, tworzenie danych testowych oraz (opcjonalnie) przygotowywanie jarzm testowych i pisanie automatycznych skryptów testowych,
- tworzenie zestawów testowych z procedur testowych w celu efektywnego wykonania testów,
- sprawdzanie, czy środowisko testowe zostało poprawnie ustawione,
- sprawdzanie oraz uaktualnianie dwukierunkowego śledzenia pomiędzy podstawą testów i przypadkami testowymi,
- wykonywanie procedur testowych w zaplanowanej kolejności – ręcznie lub przy pomocy narzędzi do wykonywania testów,
- zapisywanie wyników wykonania testów oraz zapisywanie identyfikatorów i wersji testowanego oprogramowania, narzędzi testowych oraz testaliów,
- porównywanie wyników rzeczywistych z wynikami oczekiwanymi,
- raportowanie rozbieżności jako incydentów oraz ich analizowanie w celu ustalenia ich przyczyny (np. defekt w kodzie, defekt w danych testowych, defekt w dokumencie testowym, pomyłka w sposobie wykonania testu),
- powtarzanie czynności testowych jako rezultat akcji podjętej po stwierdzeniu rozbieżności, na przykład powtórne wykonanie testów poprzednio niezaliczonych, aby potwierdzić naprawę (testowanie potwierdzające), wykonanie poprawionych testów i/lub wykonanie testów w celu sprawdzenia, czy w niezmienianych częściach oprogramowania nie pojawiły się usterki lub czy naprawa usterek nie ujawniła innych usterek (testowanie regresywne).
-
Pytań 5 z 15Testowanie w cyklu życia oprogramowania5
Jaka jest standardowa kolejność poziomów testowania?
PoprawnieCele nauczania:
- LO-2.2.1 Kandydat potrafi porównać różne poziomy testów: główne cele, typowe przedmioty testów, typowe cele testowania (np. strukturalne lub funkcjonalne) i związane z nimi produkty, testerów, typy usterek i awarii do znalezienia. (K2)
Standardowa kolejność poziomów testowania określona w sylabusie (zob. rozdział 2.2 Poziomy testów) to:
- testy modułowe,
- testy integracyjne,
- testy systemowe,
- testy akceptacyjne.
Aby nie zapomnieć na egzaminie tej kolejności poziomów testowania, zapamiętaj akronim M.I.S.A., utworzony od pierwszych liter nazw poszczególnych poziomów.
NiepoprawnieCele nauczania:
- LO-2.2.1 Kandydat potrafi porównać różne poziomy testów: główne cele, typowe przedmioty testów, typowe cele testowania (np. strukturalne lub funkcjonalne) i związane z nimi produkty, testerów, typy usterek i awarii do znalezienia. (K2)
Standardowa kolejność poziomów testowania określona w sylabusie (zob. rozdział 2.2 Poziomy testów) to:
- testy modułowe,
- testy integracyjne,
- testy systemowe,
- testy akceptacyjne.
Aby nie zapomnieć na egzaminie tej kolejności poziomów testowania, zapamiętaj akronim M.I.S.A., utworzony od pierwszych liter nazw poszczególnych poziomów.
-
Pytań 6 z 15Testowanie w cyklu życia oprogramowania6
Który z poniższych standardów dotyczy jakości produktu programistycznego?
PoprawnieStandardem jakości produktu programistycznego jest standard ISO 9126.
Norma ISO 9126 “Software engineering – Product quality” to międzynarodowa norma opisująca model jakości oprogramowania. W marcu 2011 r. norma ISO 9126 została zastąpiona normą ISO 25010 „Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models”. Główne różnice między normami ISO 9126 i ISO 25010 zostały klarownie przedstawione w artykule „Charakterystyki jakości oprogramowania – ISO 25010” (otwórz w nowym oknie) w portalu testerzy.pl.
Warto zauważyć, że sylabus ISTQB CTFL (wersja 2011) powołuje się wyłącznie na normę ISO 9126 (nie uwzględnia normy ISO 25010). Wsród zmian, które przynosi wersja sylabusa 2018 jest m.in. odwoływanie się już do normy ISO/IEC 25010,.
Norma ISO 9126 specyfikuje sześć charakterystyk, którym przypisane są podcharakterystyki oraz definiuje przykładowe metryki jakości oprogramowania.
Charakterystyki i podcharakterystyki jakości oprogramowania według normy ISO 9126 to:
Charakterystyka Podcharakterystyka funkcjonalność - dopasowanie
- dokładność
- współdziałanie
- bezpieczeństwo
- zgodność z innymi normami
niezawodność - dojrzałość
- tolerowanie usterek
- odtwarzalność
- zgodność z innymi normami
użyteczność - zrozumiałość
- łatwość nauki
- łatwość obsługi
- atrakcyjność
- zgodność z innymi normami
efektywność - wydajność
- zużycie zasobów
- zgodność z innymi normami
pielęgnowalność - zdolność do analizy
- modyfikowalność
- stabilność
- testowalność
- zgodność z innymi normami
przenaszalność - zdolność adaptacyjna
- instalowalność
- koegzystencja
- zastępowalność
- zgodność z innymi normami
Jeśli chodzi o pozostałe wymienione w pytaniu standardy (bo zawsze warto wiedzieć więcej):
- nie ma takiego standardu jak ISO 829, jest natomiast standard IEEE 829 (IEEE, od Institute of Electrical and Electronics Engineers, to organizacja zajmująca się ustalaniem standardów konstrukcji, pomiarów itp. dla urządzeń elektronicznych, w tym standardów dla urządzeń i formatów komputerowych, zaś ISO , od International Organization for Standardization, to Międzynarodowa Organizacja Normalizacyjna) – standard IEEE 829 dotyczy dokumentacji testowej (IEEE Std 829-1998: “Standard for Software Test Documentation”, IEEE Std 829-2008: “Standard for Software and System Test Documentation”); zapisy standardu IEEE 829 zostały w 2013 r. przeniesione do standardu ISO/IEC/IEEE 29119 , przy czym w sylabusie ISTQB CTFL 2011 podstawą do określenia standardów dokumentacji jest dalej IEEE Std 829 (głównie w wersji z 1998 r., a nie rewizji z 2008 r.);
- ISO 1012 to standard „Photography – Films in sheets and rolls for general use – Dimensions”;
- ISO 1028 to standard “Information processing — Flowchart symbols” (standard ten został zastąpiony w 1985 r. standardem ISO 5807 „Information processing – Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts”).
NiepoprawnieStandardem jakości produktu programistycznego jest standard ISO 9126.
Norma ISO 9126 “Software engineering – Product quality” to międzynarodowa norma opisująca model jakości oprogramowania. W marcu 2011 r. norma ISO 9126 została zastąpiona normą ISO 25010 „Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models”. Główne różnice między normami ISO 9126 i ISO 25010 zostały klarownie przedstawione w artykule „Charakterystyki jakości oprogramowania – ISO 25010” (otwórz w nowym oknie) w portalu testerzy.pl.
Warto zauważyć, że sylabus ISTQB CTFL (wersja 2011) powołuje się wyłącznie na normę ISO 9126 (nie uwzględnia normy ISO 25010). Wsród zmian, które przynosi wersja sylabusa 2018 jest m.in. odwoływanie się już do normy ISO/IEC 25010,.
Norma ISO 9126 specyfikuje sześć charakterystyk, którym przypisane są podcharakterystyki oraz definiuje przykładowe metryki jakości oprogramowania.
Charakterystyki i podcharakterystyki jakości oprogramowania według normy ISO 9126 to:
Charakterystyka Podcharakterystyka funkcjonalność - dopasowanie
- dokładność
- współdziałanie
- bezpieczeństwo
- zgodność z innymi normami
niezawodność - dojrzałość
- tolerowanie usterek
- odtwarzalność
- zgodność z innymi normami
użyteczność - zrozumiałość
- łatwość nauki
- łatwość obsługi
- atrakcyjność
- zgodność z innymi normami
efektywność - wydajność
- zużycie zasobów
- zgodność z innymi normami
pielęgnowalność - zdolność do analizy
- modyfikowalność
- stabilność
- testowalność
- zgodność z innymi normami
przenaszalność - zdolność adaptacyjna
- instalowalność
- koegzystencja
- zastępowalność
- zgodność z innymi normami
Jeśli chodzi o pozostałe wymienione w pytaniu standardy (bo zawsze warto wiedzieć więcej):
- nie ma takiego standardu jak ISO 829, jest natomiast standard IEEE 829 (IEEE, od Institute of Electrical and Electronics Engineers, to organizacja zajmująca się ustalaniem standardów konstrukcji, pomiarów itp. dla urządzeń elektronicznych, w tym standardów dla urządzeń i formatów komputerowych, zaś ISO , od International Organization for Standardization, to Międzynarodowa Organizacja Normalizacyjna) – standard IEEE 829 dotyczy dokumentacji testowej (IEEE Std 829-1998: “Standard for Software Test Documentation”, IEEE Std 829-2008: “Standard for Software and System Test Documentation”); zapisy standardu IEEE 829 zostały w 2013 r. przeniesione do standardu ISO/IEC/IEEE 29119 , przy czym w sylabusie ISTQB CTFL 2011 podstawą do określenia standardów dokumentacji jest dalej IEEE Std 829 (głównie w wersji z 1998 r., a nie rewizji z 2008 r.);
- ISO 1012 to standard „Photography – Films in sheets and rolls for general use – Dimensions”;
- ISO 1028 to standard “Information processing — Flowchart symbols” (standard ten został zastąpiony w 1985 r. standardem ISO 5807 „Information processing – Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts”).
-
Pytań 7 z 15Testowanie w cyklu życia oprogramowania7
Które z poniższych nie należy do testów modułowych?
PoprawnieW ramach testów modułowych nie będą sprawdzane tabele decyzyjne.
Zgodnie z podrozdziałem 2.2.1 Testy modułowe sylabusa:
Testy modułowe mogą zawierać testy funkcjonalności oraz niektórych atrybutów niefunkcjonalnych, takich jak stopień wykorzystania zasobów (np. wycieków pamięci) lub odporności, jak również testy strukturalne (np. pokrycia decyzji). Przypadki testowe są projektowane na podstawie takich produktów jak specyfikacja modułu, projekt oprogramowania lub model danych.
Testy modułowe zwykle wykonuje się mając dostęp do kodu źródłowego i przy wsparciu środowiska rozwojowego (np. bibliotek do testów jednostkowych, narzędzi do debagowania) oraz, w praktyce, zwykle angażują też programistę, który jest autorem kodu. Usterki są usuwane jak tylko zostaną wykryte, bez formalnego zarządzania nimi.
NiepoprawnieW ramach testów modułowych nie będą sprawdzane tabele decyzyjne.
Zgodnie z podrozdziałem 2.2.1 Testy modułowe sylabusa:
Testy modułowe mogą zawierać testy funkcjonalności oraz niektórych atrybutów niefunkcjonalnych, takich jak stopień wykorzystania zasobów (np. wycieków pamięci) lub odporności, jak również testy strukturalne (np. pokrycia decyzji). Przypadki testowe są projektowane na podstawie takich produktów jak specyfikacja modułu, projekt oprogramowania lub model danych.
Testy modułowe zwykle wykonuje się mając dostęp do kodu źródłowego i przy wsparciu środowiska rozwojowego (np. bibliotek do testów jednostkowych, narzędzi do debagowania) oraz, w praktyce, zwykle angażują też programistę, który jest autorem kodu. Usterki są usuwane jak tylko zostaną wykryte, bez formalnego zarządzania nimi.
-
Pytań 8 z 15Statyczne techniki testowania8
Które z poniższych zdań dotyczących testów statycznych jest fałszywe?
PoprawnieFałszywe jest zdanie, według którego testy statyczne wymagają uruchamiania kodu. Zgodnie z rozdziałem 3.1 Techniki statyczne a proces testowania sylabusa:
W przeciwieństwie do technik dynamicznych, które wymagają uruchomienia oprogramowania, techniki statyczne polegają na sprawdzeniu ręcznym (przeglądy) lub analizie automatycznej (analiza statyczna) kodu lub innych dokumentów projektowych bez uruchamiania kodu.
NiepoprawnieFałszywe jest zdanie, według którego testy statyczne wymagają uruchamiania kodu. Zgodnie z rozdziałem 3.1 Techniki statyczne a proces testowania sylabusa:
W przeciwieństwie do technik dynamicznych, które wymagają uruchomienia oprogramowania, techniki statyczne polegają na sprawdzeniu ręcznym (przeglądy) lub analizie automatycznej (analiza statyczna) kodu lub innych dokumentów projektowych bez uruchamiania kodu.
-
Pytań 9 z 15Techniki projektowania testów9
System zaprojektowany w celu obliczenia podatku dochodowego opiera się na następujących zasadach:
- pracownik ma 4 000 zł wolne od podatku,
- następne 1 500 zł jest opodatkowane wg stawki 10%,
- kolejne 28 000 zł jest opodatkowane wg stawki 22%,
- każda suma powyżej jest opodatkowana stawką 40%.
Które z poniższych zbiorów wynagrodzeń należą do tej samej klasy równoważności?
PoprawnieCele nauczania:
- LO-4.3.1 Kandydat potrafi napisać przypadki testowe na podstawie podanych modeli oprogramowania używając techniki klas równoważności, analizy wartości brzegowych, testowania w oparciu o tablicę decyzyjną, testowania przejść pomiędzy stanami (K3)
W oparciu o treść pytania można wydzielić następujące klasy równoważności:
- { x ≥ 4 000 zł } – kwota wolna od podatków,
- { 4 000 zł < x ≤ 5 500 zł } – kwota opodatkowana stawką 10%,
- { 5 500 zł < x ≤ 33 500 zł } – kwota opodatkowana stawką 22%,
- { x > 33 500 zł) – – kwota opodatkowana stawką 40%.
Podział na klasy równoważności to czarnoskrzynkowa techniki projektowania przypadków testowych (zob. w sylabusie podrozdział 4.3.1 Podział na klasy równoważności).
W technice podziału na klasy równoważności wejścia programu lub systemu są dzielone na grupy, które powodują podobne zachowanie oprogramowania, więc jest bardzo prawdopodobne, że będą przetwarzane w ten sam sposób. Dzięki temu nie musimy testować wszystkich elementów w zbiorze (powinno wystarczyć sprawdzenie wartości dla jednego elementu z klasy równoważności).
Klasy równoważności można znaleźć zarówno dla danych poprawnych, jak i danych niepoprawnych:
- klasy poprawności – zbiory wartości, dla których przewidujemy poprawne działanie programu;
- klasy niepoprawności – zbiory wartości, dla których przewidujemy błędne działanie programu.
Technikę podziału na klasy równoważności można zastosować na każdym poziomie testowania.
NiepoprawnieCele nauczania:
- LO-4.3.1 Kandydat potrafi napisać przypadki testowe na podstawie podanych modeli oprogramowania używając techniki klas równoważności, analizy wartości brzegowych, testowania w oparciu o tablicę decyzyjną, testowania przejść pomiędzy stanami (K3)
W oparciu o treść pytania można wydzielić następujące klasy równoważności:
- { x ≥ 4 000 zł } – kwota wolna od podatków,
- { 4 000 zł < x ≤ 5 500 zł } – kwota opodatkowana stawką 10%,
- { 5 500 zł < x ≤ 33 500 zł } – kwota opodatkowana stawką 22%,
- { x > 33 500 zł) – – kwota opodatkowana stawką 40%.
Podział na klasy równoważności to czarnoskrzynkowa techniki projektowania przypadków testowych (zob. w sylabusie podrozdział 4.3.1 Podział na klasy równoważności).
W technice podziału na klasy równoważności wejścia programu lub systemu są dzielone na grupy, które powodują podobne zachowanie oprogramowania, więc jest bardzo prawdopodobne, że będą przetwarzane w ten sam sposób. Dzięki temu nie musimy testować wszystkich elementów w zbiorze (powinno wystarczyć sprawdzenie wartości dla jednego elementu z klasy równoważności).
Klasy równoważności można znaleźć zarówno dla danych poprawnych, jak i danych niepoprawnych:
- klasy poprawności – zbiory wartości, dla których przewidujemy poprawne działanie programu;
- klasy niepoprawności – zbiory wartości, dla których przewidujemy błędne działanie programu.
Technikę podziału na klasy równoważności można zastosować na każdym poziomie testowania.
-
Pytań 10 z 15Techniki projektowania testów10
Która z poniższych technik projektowania testów nie jest techniką czarnoskrzynkową?
PoprawnieCele nauczania:
- LO-4.2.1 Kandydat pamięta do czego przydatne są techniki projektowania testów oparte na specyfikacji (czarnoskrzynkowe) oraz techniki oparte na strukturze (białoskrzynkowe) oraz potrafi wymienić typowe dla nich techniki. (K1)
- LO-4.2.2 Kandydat potrafi objaśnić cechy, podobieństwa oraz różnice pomiędzy technikami opartymi na specyfikacji, strukturze i doświadczeniu. (K2)
Wszystkie wymienione w odpowiedziach zwroty to techniki projektowania testów, określane także jako techniki projektowania przypadków testowych, techniki specyfikacji testowej lub techniki testowe. Klasyczny podział technik projektowania testów wyróżnia techniki czarnoskrzynkowe oraz białoskrzynkowe.
Czarnoskrzynkową techniką projektowania przypadków testowych nie jest LSKiS.
Aby móc udzielać prawidłowych odpowiedzi na egzaminie na podobne pytania, należy poznać nazwy technik projektowania testów i umieć przyporządkować je do jednej z dwóch głównych kategorii: technik biało- i czarnoskrzynkowych.
W odróżnieniu technik biało- od czarnoskrzynkowych pomogą Wam poniższe dwie tabele. Dlaczego dwie? Ponieważ w jednej wymieniłem techniki, które mniej lub bardziej szczegółowo zostały opisane w sylabusie dla poziomu podstawowego i o których warto wiedzieć więcej, bo mogą być przedmiotem różnych pytań na egzaminie. W drugiej tabeli wymieniłem zaś techniki, które nie są szczegółowo omówione w sylabusie dla poziomu podstawowego (ba, mogą nawet nie być w nim wymienione), natomiast wzmianka o nich pojawia się w słowniku.
Tabela 1: Techniki umówione w sylabusie poziomu podstawowego
Białoskrzynkowe techniki projektowania testów (techniki oparte na strukturze) Czarnoskrzynkowe techniki projektowania testów (techniki oparte na specyfikacji) - testowanie decyzji,
- testowanie instrukcji,
- testowanie gałęzi (test algorytmu, testowanie krawędzi)
- testowanie warunków,
- testowanie warunków wielokrotnych (testowanie kombinacji warunków w decyzjach, testowanie kombinacji warunków).
- podział na klasy równoważności (testowanie podzbiorów),
- analiza wartości brzegowych (testowanie wartości brzegowych),
- testowanie w oparciu o tablicę decyzyjną,
- testowanie przejść pomiędzy stanami (testowanie stanów),
- testowanie w oparciu o przypadki użycia (testowanie w oparciu o scenariusze użytkownika, testowanie w oparciu o scenariusze).
Tabela 2: Techniki bez szczegółowego omówienia w sylabusie poziomu podstawowego (wspomniane tylko w słowniku)
Białoskrzynkowe techniki projektowania testów (techniki oparte na strukturze) Czarnoskrzynkowe techniki projektowania testów (techniki oparte na specyfikacji) - testowanie warunków w decyzjach,
- zmodyfikowane testowanie warunków decyzji,
- testowanie LSKiS,
- testowanie przepływu danych,
- testowanie ścieżek.
- testowanie w oparciu o historyjki użytkownika,
- testowanie losowe,
- testowanie składniowe,
- testowanie sposobem par,
- tworzenie grafów przyczynowo-skutkowych,
- analiza dziedzinowa,
- metoda drzewa klasyfikacji,
- podstawowe testowanie porównawcze,
- test cyklu procesu.
NiepoprawnieCele nauczania:
- LO-4.2.1 Kandydat pamięta do czego przydatne są techniki projektowania testów oparte na specyfikacji (czarnoskrzynkowe) oraz techniki oparte na strukturze (białoskrzynkowe) oraz potrafi wymienić typowe dla nich techniki. (K1)
- LO-4.2.2 Kandydat potrafi objaśnić cechy, podobieństwa oraz różnice pomiędzy technikami opartymi na specyfikacji, strukturze i doświadczeniu. (K2)
Wszystkie wymienione w odpowiedziach zwroty to techniki projektowania testów, określane także jako techniki projektowania przypadków testowych, techniki specyfikacji testowej lub techniki testowe. Klasyczny podział technik projektowania testów wyróżnia techniki czarnoskrzynkowe oraz białoskrzynkowe.
Czarnoskrzynkową techniką projektowania przypadków testowych nie jest LSKiS.
Aby móc udzielać prawidłowych odpowiedzi na egzaminie na podobne pytania, należy poznać nazwy technik projektowania testów i umieć przyporządkować je do jednej z dwóch głównych kategorii: technik biało- i czarnoskrzynkowych.
W odróżnieniu technik biało- od czarnoskrzynkowych pomogą Wam poniższe dwie tabele. Dlaczego dwie? Ponieważ w jednej wymieniłem techniki, które mniej lub bardziej szczegółowo zostały opisane w sylabusie dla poziomu podstawowego i o których warto wiedzieć więcej, bo mogą być przedmiotem różnych pytań na egzaminie. W drugiej tabeli wymieniłem zaś techniki, które nie są szczegółowo omówione w sylabusie dla poziomu podstawowego (ba, mogą nawet nie być w nim wymienione), natomiast wzmianka o nich pojawia się w słowniku.
Tabela 1: Techniki umówione w sylabusie poziomu podstawowego
Białoskrzynkowe techniki projektowania testów (techniki oparte na strukturze) Czarnoskrzynkowe techniki projektowania testów (techniki oparte na specyfikacji) - testowanie decyzji,
- testowanie instrukcji,
- testowanie gałęzi (test algorytmu, testowanie krawędzi)
- testowanie warunków,
- testowanie warunków wielokrotnych (testowanie kombinacji warunków w decyzjach, testowanie kombinacji warunków).
- podział na klasy równoważności (testowanie podzbiorów),
- analiza wartości brzegowych (testowanie wartości brzegowych),
- testowanie w oparciu o tablicę decyzyjną,
- testowanie przejść pomiędzy stanami (testowanie stanów),
- testowanie w oparciu o przypadki użycia (testowanie w oparciu o scenariusze użytkownika, testowanie w oparciu o scenariusze).
Tabela 2: Techniki bez szczegółowego omówienia w sylabusie poziomu podstawowego (wspomniane tylko w słowniku)
Białoskrzynkowe techniki projektowania testów (techniki oparte na strukturze) Czarnoskrzynkowe techniki projektowania testów (techniki oparte na specyfikacji) - testowanie warunków w decyzjach,
- zmodyfikowane testowanie warunków decyzji,
- testowanie LSKiS,
- testowanie przepływu danych,
- testowanie ścieżek.
- testowanie w oparciu o historyjki użytkownika,
- testowanie losowe,
- testowanie składniowe,
- testowanie sposobem par,
- tworzenie grafów przyczynowo-skutkowych,
- analiza dziedzinowa,
- metoda drzewa klasyfikacji,
- podstawowe testowanie porównawcze,
- test cyklu procesu.
-
Pytań 11 z 15Techniki projektowania testów11
Pole wejściowe formularza przyjmuje rok urodzenia pomiędzy 1900 i 2004 rokiem. Wartości brzegowe przy testowaniu tego pola to:
PoprawnieCele nauczania:
- LO-4.3.1 Kandydat potrafi napisać przypadki testowe na podstawie podanych modeli oprogramowania używając techniki klas równoważności, analizy wartości brzegowych, testowania w oparciu o tablicę decyzyjną, testowania przejść pomiędzy stanami (K3)
W oparciu o treść pytania można wydzielić następujące klasy równoważności: { x < 1900 }, { 1900 ≤ x ≤ 2004 } oraz { x > 2004 }. Dane wejściowe, które zostałyby wygenerowane przy użyciu analizy wartości brzegowych zawiera zatem odpowiedź „1899, 1900, 2004, 2005”.
Podział na klasy równoważności oraz analiza wartości brzegowych to czarnoskrzynkowe techniki projektowania przypadków testowych (zob. w sylabusie podrozdziały 4.3.1 Podział na klasy równoważności oraz 4.3.2 Analiza wartości brzegowych).
W technice podziału na klasy równoważności wejścia programu lub systemu są dzielone na grupy, które powodują podobne zachowanie oprogramowania, więc jest bardzo prawdopodobne, że będą przetwarzane w ten sam sposób. Dzięki temu nie musimy testować wszystkich elementów w zbiorze (powinno wystarczyć sprawdzenie wartości dla jednego elementu z klasy równoważności).
Klasy równoważności można znaleźć zarówno dla danych poprawnych, jak i danych niepoprawnych:
- klasy poprawności – zbiory wartości, dla których przewidujemy poprawne działanie programu;
- klasy niepoprawności – zbiory wartości, dla których przewidujemy błędne działanie programu.
W analizie wartości brzegowych zakłada się, że istnieje większe prawdopodobieństwo, że oprogramowania będzie się błędnie zachowywać dla wartości na krawędziach klas równoważności niż w ich środku, więc testowanie tych obszarów najprawdopodobniej wykryje błędy. Wartość brzegowa poprawnego przedziału jest nazywana poprawną wartością brzegową, a wartość brzegowa niepoprawnego przedziału – niepoprawną wartością brzegową. Testy można zaprojektować tak, żeby pokrywały zarówno poprawne, jak i niepoprawne wartości brzegowe.
Podczas projektowania testów tworzy się przypadek testowy dla każdej wartości brzegowej. Technika analizy wartości brzegowych jest często uważana za rozwinięcie techniki podziału na klasy równoważności lub innych technik czarnoskrzynkowych.
Obie techniki (podział na klasy równoważności, analiza wartości brzegowych) można zastosować na każdym poziomie testowania.
NiepoprawnieCele nauczania:
- LO-4.3.1 Kandydat potrafi napisać przypadki testowe na podstawie podanych modeli oprogramowania używając techniki klas równoważności, analizy wartości brzegowych, testowania w oparciu o tablicę decyzyjną, testowania przejść pomiędzy stanami (K3)
W oparciu o treść pytania można wydzielić następujące klasy równoważności: { x < 1900 }, { 1900 ≤ x ≤ 2004 } oraz { x > 2004 }. Dane wejściowe, które zostałyby wygenerowane przy użyciu analizy wartości brzegowych zawiera zatem odpowiedź „1899, 1900, 2004, 2005”.
Podział na klasy równoważności oraz analiza wartości brzegowych to czarnoskrzynkowe techniki projektowania przypadków testowych (zob. w sylabusie podrozdziały 4.3.1 Podział na klasy równoważności oraz 4.3.2 Analiza wartości brzegowych).
W technice podziału na klasy równoważności wejścia programu lub systemu są dzielone na grupy, które powodują podobne zachowanie oprogramowania, więc jest bardzo prawdopodobne, że będą przetwarzane w ten sam sposób. Dzięki temu nie musimy testować wszystkich elementów w zbiorze (powinno wystarczyć sprawdzenie wartości dla jednego elementu z klasy równoważności).
Klasy równoważności można znaleźć zarówno dla danych poprawnych, jak i danych niepoprawnych:
- klasy poprawności – zbiory wartości, dla których przewidujemy poprawne działanie programu;
- klasy niepoprawności – zbiory wartości, dla których przewidujemy błędne działanie programu.
W analizie wartości brzegowych zakłada się, że istnieje większe prawdopodobieństwo, że oprogramowania będzie się błędnie zachowywać dla wartości na krawędziach klas równoważności niż w ich środku, więc testowanie tych obszarów najprawdopodobniej wykryje błędy. Wartość brzegowa poprawnego przedziału jest nazywana poprawną wartością brzegową, a wartość brzegowa niepoprawnego przedziału – niepoprawną wartością brzegową. Testy można zaprojektować tak, żeby pokrywały zarówno poprawne, jak i niepoprawne wartości brzegowe.
Podczas projektowania testów tworzy się przypadek testowy dla każdej wartości brzegowej. Technika analizy wartości brzegowych jest często uważana za rozwinięcie techniki podziału na klasy równoważności lub innych technik czarnoskrzynkowych.
Obie techniki (podział na klasy równoważności, analiza wartości brzegowych) można zastosować na każdym poziomie testowania.
-
Pytań 12 z 15Zarządzanie testowaniem12
Co NIE jest ryzykiem projektowym?
PoprawnieZ ryzykiem projektowym nie jest związane oprogramowanie zawierające dużą liczbę błędów.
Sylabus w podrozdziale 5.5.1 Obszary ryzyka projektowego wymienia następujące ryzyka projektowe:
- czynniki organizacyjne: braki w umiejętnościach, szkoleniach lub personelu, problemy kadrowe, problemy polityczne (problemy z testerami komunikującymi swoje potrzeby oraz wyniki testów, brak reakcji zespołu w związku z informacjami pozyskanymi podczas testów i przeglądów, np. brak doskonalenia procesów produkcji i testowania) , nieprawidłowe nastawienie i oczekiwania od testowania (np. niedocenianie wartości znajdowania defektów podczas testowania),
- problemy techniczne: problemy ze zdefiniowaniem poprawnych wymagań, stopień, w jakim wymagania mogą zostać spełnione przy istniejących ograniczeniach, środowisko testowe niegotowe na czas, spóźniona konwersja danych, planowanie migracji oraz rozwój i testowanie narzędzi do migracji i konwersji danych, niska jakość projektu, kodu, danych konfiguracyjnych, danych testowych i testów,
- problemy z dostawcami: niewywiązywanie się dostawców ze zobowiązań, problemy z kontraktami.
Do ryzyk produktowych w podrozdziale 5.5.2 Obszary ryzyka produktowego sylabusa zaliczono natomiast:
- dostarczanie awaryjnego oprogramowania,
- możliwość wyrządzenia szkody człowiekowi lub firmie przez oprogramowanie lub sprzęt,
- niedostateczne atrybuty oprogramowania (np. niezawodność, użyteczność lub wydajność),
- niska jakość lub brak spójności danych (np. problemy z migracją danych, problemy z konwersją danych, problemy z przekazywaniem danych, naruszenie standardów danych),
- oprogramowanie, które nie spełnia założonych funkcji.
Sposób na egzamin: w pewnym uproszczeniu można stwierdzić, że jeśli w odpowiedziach na pytanie dotyczące ryzyk pojawi się słowo „oprogramowanie”, to mamy do czynienia z ryzykiem produktowym. Jeśli w danej odpowiedzi nie ma słowa „oprogramowanie”, będzie to pewnie ryzyko projektowe. Sposób stosować na własną odpowiedzialność.
NiepoprawnieZ ryzykiem projektowym nie jest związane oprogramowanie zawierające dużą liczbę błędów.
Sylabus w podrozdziale 5.5.1 Obszary ryzyka projektowego wymienia następujące ryzyka projektowe:
- czynniki organizacyjne: braki w umiejętnościach, szkoleniach lub personelu, problemy kadrowe, problemy polityczne (problemy z testerami komunikującymi swoje potrzeby oraz wyniki testów, brak reakcji zespołu w związku z informacjami pozyskanymi podczas testów i przeglądów, np. brak doskonalenia procesów produkcji i testowania) , nieprawidłowe nastawienie i oczekiwania od testowania (np. niedocenianie wartości znajdowania defektów podczas testowania),
- problemy techniczne: problemy ze zdefiniowaniem poprawnych wymagań, stopień, w jakim wymagania mogą zostać spełnione przy istniejących ograniczeniach, środowisko testowe niegotowe na czas, spóźniona konwersja danych, planowanie migracji oraz rozwój i testowanie narzędzi do migracji i konwersji danych, niska jakość projektu, kodu, danych konfiguracyjnych, danych testowych i testów,
- problemy z dostawcami: niewywiązywanie się dostawców ze zobowiązań, problemy z kontraktami.
Do ryzyk produktowych w podrozdziale 5.5.2 Obszary ryzyka produktowego sylabusa zaliczono natomiast:
- dostarczanie awaryjnego oprogramowania,
- możliwość wyrządzenia szkody człowiekowi lub firmie przez oprogramowanie lub sprzęt,
- niedostateczne atrybuty oprogramowania (np. niezawodność, użyteczność lub wydajność),
- niska jakość lub brak spójności danych (np. problemy z migracją danych, problemy z konwersją danych, problemy z przekazywaniem danych, naruszenie standardów danych),
- oprogramowanie, które nie spełnia założonych funkcji.
Sposób na egzamin: w pewnym uproszczeniu można stwierdzić, że jeśli w odpowiedziach na pytanie dotyczące ryzyk pojawi się słowo „oprogramowanie”, to mamy do czynienia z ryzykiem produktowym. Jeśli w danej odpowiedzi nie ma słowa „oprogramowanie”, będzie to pewnie ryzyko projektowe. Sposób stosować na własną odpowiedzialność.
-
Pytań 13 z 15Zarządzanie testowaniem13
Wybór podejścia do testów powinien brać pod uwagę:
A. Ryzyko niepowodzenia projektu, zagrożenia dla produktu i ryzyka, jakie produkt może stwarzać wobec użytkowników.
B. Umiejętności i doświadczenie osób w realizacji danej techniki, użyciu narzędzi, stosowania metod.
C. Cel działalności testowej i misję zespołu testowego.
D. Wielkość zespołu testowego.PoprawnieCele nauczania:
- LO-5.2.3 Kandydat rozróżnia odmienne podejścia do testowania, takie jak analityczne, oparte na modelach, metodyczne, zgodne z procesem lub standardem, dynamiczne/heurystyczne, konsultatywne oraz regresywne. (K2)
Zgodnie z podrozdziałem 5.2.6 Podejście do testowania, strategia testowania sylabusa:
Podejście do testów jest implementacją strategii testów w konkretnym projekcie. Podejście do testów jest definiowane i uszczegóławiane w planach testów oraz projektach testów. Zwykle zawiera decyzje podejmowane na podstawie celów projektu (testowego) oraz oceny ryzyka. Stanowi ono punkt wyjściowy do planowania procesu testowania, wyboru technik projektowania testów i stosowanych typów testów, a także do definiowania kryteriów wejścia i zakończenia.
W oparciu o informacje zawarte w sylabusie i słowniku warto zapamiętać, że podejście do testów:
- stanowi punkt wyjścia do planowania procesu testowego, do wyboru technik projektowania testów i stosowanych typów testów, a także do definiowania kryteriów wejścia i zakończenia,
- jest definiowane i udoskonalane w planach testów i projektach testów,
- jest definiowane na etapie planowania czynności testowych (zob. w sylabusie m.in. podrozdział 1.4.1 Planowanie i nadzór),
- jest implementacją strategii testów dla konkretnego projektu testowego.
Typowe podejścia do testów opisane w sylabusie to:
1. podejścia analityczne: na przykład testowanie oparte na ryzyku, w którym testowanie jest kierowane na obszary o największym ryzyku;
2. podejścia oparte na modelach – na przykład testowanie stochastyczne wykorzystujące informacje statystyczne o współczynnikach awarii (takie jak modele wzrostu niezawodności) lub informacje o wykorzystaniu oprogramowania (takie jak profile produkcyjne);
3. podejścia metodyczne – na przykład podejścia oparte na awariach (włącznie ze zgadywaniem błędów i atakami usterkowymi), oparte na doświadczeniu, oparte na listach kontrolnych lub oparte na atrybutach jakościowych;
4. podejścia zgodne ze standardem lub procesem – na przykład podejścia określone przez standardy branżowe lub metodyki wytwarzania oprogramowania (np. metodyki zwinne);
5. podejścia dynamiczne i heurystyczne – na przykład testowanie eksploracyjne, w którym testowanie bardziej reaguje na zdarzenia podczas testów niż jest wykonywane według planu i w którym wykonywanie testów i ocena wyników dzieją się równolegle;
6. podejścia konsultatywne – podejścia, w których pokrycie testowe jest sterowane (napędzane) głównie przez wskazówki i porady ekspertów technologicznych lub biznesowych z zewnątrz zespołu testowego;
7. podejścia
regresywneprzeciwregresywne – podejścia, w których używa się powtórnie istniejących materiałów testowych, rozbudowanej automatyzacji regresywnych testów funkcjonalnych oraz standardowych zestawów testów. [„Regression-averse” w sylabusie przetłumaczono na polski jako „regresywne”, natomiast w słowniku jako „przeciwregresywne”. Tłumaczenie zawarte w słowniku jest bardziej zgodne z duchem oryginału.]W razie potrzeby różne podejścia mogą być łączone, np. podejście dynamiczne oparte na ryzyku. Decyzja o tym, jak i dlaczego zostaną połączone, zależy od okoliczności rozpowszechnionych w danym projekcie. Na przykład organizacja może jako standard używać metodyk zwinnych, ale w szczególnej sytuacji mogłaby posłużyć się podejściem opartym na ryzyku, aby upewnić się, że testy są prawidłowo ukierunkowane.
Zgodnie z podrozdziałem 5.2.6 Podejście do testowania, strategia testowania, wybrane podejście do testów zależy od kontekstu i może uwzględniać (opis rozszerzony w stosunku do zawartości sylabusa):
- ryzyka, niebezpieczeństwa (zagrożenia) oraz wymogi bezpieczeństwa,
- dostępne zasoby oraz umiejętności i doświadczenie ludzi w użyciu wybranych technik, narzędzi i metod – np. nie ma sensu zastosowanie wyrafinowanego podejścia opartego na informacjach statystycznych o współczynnikach awarii lub informacji o wykorzystaniu oprogramowania, gdy jedynymi dostępnymi zasobami są użytkownicy biznesowi bez podstawowej wiedzy technicznej,
- technologię i charakter systemu (np. oprogramowanie na zamówienie vs. oprogramowanie z półki) – np. w celu sprawdzenia aplikacji do zamawiania pizzy wymagane jest inne podejście niż testowanie aplikacji do obsługi łazika marsjańskiego,
- cele testów – np. sytuację gdy celem testów jest znalezienie tylko najpoważniejszych defektów,
- uregulowania prawne (np. przepisy dotyczące oprogramowania dla szpitali, banków czy administracji publicznej).
Jeśli chcesz dowiedzieć się więcej na temat podejścia do testów, polecam artykuł What is test strategy in software testing?
NiepoprawnieCele nauczania:
- LO-5.2.3 Kandydat rozróżnia odmienne podejścia do testowania, takie jak analityczne, oparte na modelach, metodyczne, zgodne z procesem lub standardem, dynamiczne/heurystyczne, konsultatywne oraz regresywne. (K2)
Zgodnie z podrozdziałem 5.2.6 Podejście do testowania, strategia testowania sylabusa:
Podejście do testów jest implementacją strategii testów w konkretnym projekcie. Podejście do testów jest definiowane i uszczegóławiane w planach testów oraz projektach testów. Zwykle zawiera decyzje podejmowane na podstawie celów projektu (testowego) oraz oceny ryzyka. Stanowi ono punkt wyjściowy do planowania procesu testowania, wyboru technik projektowania testów i stosowanych typów testów, a także do definiowania kryteriów wejścia i zakończenia.
W oparciu o informacje zawarte w sylabusie i słowniku warto zapamiętać, że podejście do testów:
- stanowi punkt wyjścia do planowania procesu testowego, do wyboru technik projektowania testów i stosowanych typów testów, a także do definiowania kryteriów wejścia i zakończenia,
- jest definiowane i udoskonalane w planach testów i projektach testów,
- jest definiowane na etapie planowania czynności testowych (zob. w sylabusie m.in. podrozdział 1.4.1 Planowanie i nadzór),
- jest implementacją strategii testów dla konkretnego projektu testowego.
Typowe podejścia do testów opisane w sylabusie to:
1. podejścia analityczne: na przykład testowanie oparte na ryzyku, w którym testowanie jest kierowane na obszary o największym ryzyku;
2. podejścia oparte na modelach – na przykład testowanie stochastyczne wykorzystujące informacje statystyczne o współczynnikach awarii (takie jak modele wzrostu niezawodności) lub informacje o wykorzystaniu oprogramowania (takie jak profile produkcyjne);
3. podejścia metodyczne – na przykład podejścia oparte na awariach (włącznie ze zgadywaniem błędów i atakami usterkowymi), oparte na doświadczeniu, oparte na listach kontrolnych lub oparte na atrybutach jakościowych;
4. podejścia zgodne ze standardem lub procesem – na przykład podejścia określone przez standardy branżowe lub metodyki wytwarzania oprogramowania (np. metodyki zwinne);
5. podejścia dynamiczne i heurystyczne – na przykład testowanie eksploracyjne, w którym testowanie bardziej reaguje na zdarzenia podczas testów niż jest wykonywane według planu i w którym wykonywanie testów i ocena wyników dzieją się równolegle;
6. podejścia konsultatywne – podejścia, w których pokrycie testowe jest sterowane (napędzane) głównie przez wskazówki i porady ekspertów technologicznych lub biznesowych z zewnątrz zespołu testowego;
7. podejścia
regresywneprzeciwregresywne – podejścia, w których używa się powtórnie istniejących materiałów testowych, rozbudowanej automatyzacji regresywnych testów funkcjonalnych oraz standardowych zestawów testów. [„Regression-averse” w sylabusie przetłumaczono na polski jako „regresywne”, natomiast w słowniku jako „przeciwregresywne”. Tłumaczenie zawarte w słowniku jest bardziej zgodne z duchem oryginału.]W razie potrzeby różne podejścia mogą być łączone, np. podejście dynamiczne oparte na ryzyku. Decyzja o tym, jak i dlaczego zostaną połączone, zależy od okoliczności rozpowszechnionych w danym projekcie. Na przykład organizacja może jako standard używać metodyk zwinnych, ale w szczególnej sytuacji mogłaby posłużyć się podejściem opartym na ryzyku, aby upewnić się, że testy są prawidłowo ukierunkowane.
Zgodnie z podrozdziałem 5.2.6 Podejście do testowania, strategia testowania, wybrane podejście do testów zależy od kontekstu i może uwzględniać (opis rozszerzony w stosunku do zawartości sylabusa):
- ryzyka, niebezpieczeństwa (zagrożenia) oraz wymogi bezpieczeństwa,
- dostępne zasoby oraz umiejętności i doświadczenie ludzi w użyciu wybranych technik, narzędzi i metod – np. nie ma sensu zastosowanie wyrafinowanego podejścia opartego na informacjach statystycznych o współczynnikach awarii lub informacji o wykorzystaniu oprogramowania, gdy jedynymi dostępnymi zasobami są użytkownicy biznesowi bez podstawowej wiedzy technicznej,
- technologię i charakter systemu (np. oprogramowanie na zamówienie vs. oprogramowanie z półki) – np. w celu sprawdzenia aplikacji do zamawiania pizzy wymagane jest inne podejście niż testowanie aplikacji do obsługi łazika marsjańskiego,
- cele testów – np. sytuację gdy celem testów jest znalezienie tylko najpoważniejszych defektów,
- uregulowania prawne (np. przepisy dotyczące oprogramowania dla szpitali, banków czy administracji publicznej).
Jeśli chcesz dowiedzieć się więcej na temat podejścia do testów, polecam artykuł What is test strategy in software testing?
-
Pytań 14 z 15Testowanie wspierane narzędziami14
Jakie są główne korzyści ze stosowania narzędzi wspomagających testowanie?
A. Ułatwiają dostęp do informacji o testach i testowaniu.
B. Zmniejszają koszty utrzymania testaliów.
C. Są łatwe i tanie w implementacji.
D. Zwiększają spójność testów.PoprawnieCele nauczania:
- LO-6.2.1 Kandydat potrafi opisać krótko potencjalne korzyści oraz ryzyko automatyzacji testów oraz wspierania testów narzędziami. (K2)
- LO-6.2.2 Kandydat pamięta specjalne uwarunkowania dla narzędzi wspierających wykonywanie testów, analizę statyczną oraz zarządzanie testami. (K1)
Główne korzyści ze stosowania narzędzi wspomagających testowanie to m.in. ułatwienie dostępu do informacji o testach i testowaniu oraz zwiększenie spójności testów.
Zgodnie z treścią podrozdziału 6.2.1 Potencjalne korzyści i ryzyko wsparcia narzędziowego dla testów (dla wszystkich narzędzi sylabusa, potencjalne korzyści wynikające z użycia narzędzi wspierających testy to:
- zredukowana zostaje powtarzająca się praca (np. uruchamianie testów regresywnych, powtórne wprowadzanie tych samych danych testowych oraz sprawdzanie zgodności ze standardami kodowania),
- zwiększa się spójność i powtarzalność (np. testy wykonywane przez narzędzie w tej samej kolejności i z tą samą częstością oraz testy wywiedzione z wymagań),
- ocena jest obiektywna (np. miary statyczne, pokrycie),
- łatwiejszy jest dostęp do informacji o testach i testowaniu (np. statystyki i wykresy obrazujące postęp testów, współczynniki występowania incydentów oraz wydajność).
Zgodnie z sylabusem, ryzyka związane z użyciem narzędzi do testowania to:
- nierealistyczne oczekiwania względem narzędzia (co do funkcjonalności lub łatwości użycia),
- niedoszacowanieczasu, kosztów oraz pracochłonności wstępnego wdrożenia narzędzia (włączając w to szkolenia oraz zewnętrzne ekspertyzy),
- niedoszacowanie czasu i pracochłonności potrzebnych do osiągnięcia znaczących i trwałych korzyści z narzędzia (włączając w to potrzebę dokonania zmian w procesie testowym oraz ciągłe doskonalenie sposobu wykorzystania narzędzia),
- niedoszacowanie pracochłonności wymaganych do utrzymania artefaktów testowych wygenerowanych przez narzędzie,
- zbytnie poleganie na narzędziu (zastąpienie narzędziem projektowania testów lub wykorzystywanie zautomatyzowanych testów w sytuacji, gdy testowanie manualne byłoby lepsze),
- zaniedbywanie kontroli wersji artefaktów testowych w narzędziu,
- zaniedbywanie kwestii zależności i współpracy (interoperacyjności) między krytycznymi narzędziami, takimi jak narzędzia do zarządzania wymaganiami, narzędzia do kontroli wersji, narzędzia do zarządzania incydentami, narzędzia do śledzenia defektów oraz narzędzia od różnych dostawców,
- słaba reakcja dostawcy w ramach wsparcia, nowych wersji oraz poprawiania usterek,
- ryzyko wstrzymania projektu dla narzędzia darmowego / open-source,
- ryzyka nieprzewidziane, takie jak niezdolność do wspierania nowej platformy.
NiepoprawnieCele nauczania:
- LO-6.2.1 Kandydat potrafi opisać krótko potencjalne korzyści oraz ryzyko automatyzacji testów oraz wspierania testów narzędziami. (K2)
- LO-6.2.2 Kandydat pamięta specjalne uwarunkowania dla narzędzi wspierających wykonywanie testów, analizę statyczną oraz zarządzanie testami. (K1)
Główne korzyści ze stosowania narzędzi wspomagających testowanie to m.in. ułatwienie dostępu do informacji o testach i testowaniu oraz zwiększenie spójności testów.
Zgodnie z treścią podrozdziału 6.2.1 Potencjalne korzyści i ryzyko wsparcia narzędziowego dla testów (dla wszystkich narzędzi sylabusa, potencjalne korzyści wynikające z użycia narzędzi wspierających testy to:
- zredukowana zostaje powtarzająca się praca (np. uruchamianie testów regresywnych, powtórne wprowadzanie tych samych danych testowych oraz sprawdzanie zgodności ze standardami kodowania),
- zwiększa się spójność i powtarzalność (np. testy wykonywane przez narzędzie w tej samej kolejności i z tą samą częstością oraz testy wywiedzione z wymagań),
- ocena jest obiektywna (np. miary statyczne, pokrycie),
- łatwiejszy jest dostęp do informacji o testach i testowaniu (np. statystyki i wykresy obrazujące postęp testów, współczynniki występowania incydentów oraz wydajność).
Zgodnie z sylabusem, ryzyka związane z użyciem narzędzi do testowania to:
- nierealistyczne oczekiwania względem narzędzia (co do funkcjonalności lub łatwości użycia),
- niedoszacowanieczasu, kosztów oraz pracochłonności wstępnego wdrożenia narzędzia (włączając w to szkolenia oraz zewnętrzne ekspertyzy),
- niedoszacowanie czasu i pracochłonności potrzebnych do osiągnięcia znaczących i trwałych korzyści z narzędzia (włączając w to potrzebę dokonania zmian w procesie testowym oraz ciągłe doskonalenie sposobu wykorzystania narzędzia),
- niedoszacowanie pracochłonności wymaganych do utrzymania artefaktów testowych wygenerowanych przez narzędzie,
- zbytnie poleganie na narzędziu (zastąpienie narzędziem projektowania testów lub wykorzystywanie zautomatyzowanych testów w sytuacji, gdy testowanie manualne byłoby lepsze),
- zaniedbywanie kontroli wersji artefaktów testowych w narzędziu,
- zaniedbywanie kwestii zależności i współpracy (interoperacyjności) między krytycznymi narzędziami, takimi jak narzędzia do zarządzania wymaganiami, narzędzia do kontroli wersji, narzędzia do zarządzania incydentami, narzędzia do śledzenia defektów oraz narzędzia od różnych dostawców,
- słaba reakcja dostawcy w ramach wsparcia, nowych wersji oraz poprawiania usterek,
- ryzyko wstrzymania projektu dla narzędzia darmowego / open-source,
- ryzyka nieprzewidziane, takie jak niezdolność do wspierania nowej platformy.
-
Pytań 15 z 15Testowanie wspierane narzędziami15
Które z poniższych są czynnikami wpływającymi na sukces wdrożenia nowego narzędzia?
A. Wdrożenie narzędzia w całej organizacji w celu zapewnienia najszerszego użycia.
B. Unikanie zmiany istniejących procesów w celu redukcji negatywnego wpływu narzędzia.
C. Zapewnienie szkoleń dla nowych użytkowników.
D. Umożliwienie użytkownikom dokonania własnej oceny, w jakich elementach procesu narzędzie najlepiej się sprawdza.PoprawnieCele nauczania:
- LO-6.3.1 Kandydat potrafi wymienić główne zasady wprowadzania narzędzi do organizacji. (K1)
- LO-6.3.2 Kandydat potrafi wymienić cele dowodu słuszności pomysłu (proof-of-concept) w ocenie narzędzia oraz cele fazy pilotażowej we wdrażaniu tego narzędzia. (K1)
- LO-6.3.3 Kandydat uznaje, że poza samym zakupem narzędzia potrzebne jest też dobre wsparcie w jego użyciu. (K1)
Zasady wprowadzania narzędzi do organizacji zostały opisane w rozdziale 6.3 Wdrażanie narzędzi w organizacji sylabusa. W rozdziale przedstawiono główne aspekty do wzięcia pod uwagę podczas wyboru narzędzia dla organizacji, cele projektu pilotażowego wdrażania wybranego narzędzia w organizacji oraz czynniki wpływające na sukces wdrożenia narzędzia w organizacji.
Czynniki wpływające na sukces wdrożenia narzędzia w organizacji obejmują zgodnie z ww. rozdziałem sylabusa:
- stopniowe wdrażanie narzędzia w pozostałej części organizacji (tj. nieobjętej projektem pilotażowym),
- adaptowanie i udoskonalanie procesów tak, aby pasowały do sposobu używania narzędzia,
- zapewnianie szkoleń oraz doradztwa nowym użytkownikom,
- zdefiniowanie wytycznych dotyczących wykorzystania narzędzia,
- wdrożenie sposobu na zbieranie użytecznych informacji związanych z używaniem narzędzia,
- monitorowanie wykorzystania narzędzia oraz osiąganych korzyści,
- zapewnianie wsparcia dla zespołu testowego w użyciu danego narzędzia,
- zbieranie wniosków z wykorzystania narzędzia od wszystkich zespołów.
NiepoprawnieCele nauczania:
- LO-6.3.1 Kandydat potrafi wymienić główne zasady wprowadzania narzędzi do organizacji. (K1)
- LO-6.3.2 Kandydat potrafi wymienić cele dowodu słuszności pomysłu (proof-of-concept) w ocenie narzędzia oraz cele fazy pilotażowej we wdrażaniu tego narzędzia. (K1)
- LO-6.3.3 Kandydat uznaje, że poza samym zakupem narzędzia potrzebne jest też dobre wsparcie w jego użyciu. (K1)
Zasady wprowadzania narzędzi do organizacji zostały opisane w rozdziale 6.3 Wdrażanie narzędzi w organizacji sylabusa. W rozdziale przedstawiono główne aspekty do wzięcia pod uwagę podczas wyboru narzędzia dla organizacji, cele projektu pilotażowego wdrażania wybranego narzędzia w organizacji oraz czynniki wpływające na sukces wdrożenia narzędzia w organizacji.
Czynniki wpływające na sukces wdrożenia narzędzia w organizacji obejmują zgodnie z ww. rozdziałem sylabusa:
- stopniowe wdrażanie narzędzia w pozostałej części organizacji (tj. nieobjętej projektem pilotażowym),
- adaptowanie i udoskonalanie procesów tak, aby pasowały do sposobu używania narzędzia,
- zapewnianie szkoleń oraz doradztwa nowym użytkownikom,
- zdefiniowanie wytycznych dotyczących wykorzystania narzędzia,
- wdrożenie sposobu na zbieranie użytecznych informacji związanych z używaniem narzędzia,
- monitorowanie wykorzystania narzędzia oraz osiąganych korzyści,
- zapewnianie wsparcia dla zespołu testowego w użyciu danego narzędzia,
- zbieranie wniosków z wykorzystania narzędzia od wszystkich zespołów.