Ochra
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 każdym pytaniu 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
- Nieskategoryzowany 0%
- 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 awarią?
PoprawnieCele nauczania:
- LO-1.1.2 Kandydat rozróżnia przyczynę usterki od jej skutków. (K2)
- LO-1.1.5 Kandydat potrafi wyjaśnić i porównać pojęcia pomyłka, usterka, awaria oraz odpowiadające im pojęcia błąd i pluskwa, podając przykłady. (K2)
Awarią jest odchylenie rezultatu otrzymanego od oczekiwanego.
Sylabus w podrozdziale 1.1.2 Przyczyny usterek w oprogramowaniu określa następująco:
Człowiek może popełnić błąd (pomyłkę), która powoduje powstanie defektu (usterki, pluskwy) w kodzie programu lub dokumencie. Jeżeli kod zawierający defekt zostaje wykonany, system nie zrobi tego co powinien (lub wykona to czego nie powinien) powodując awarię. Usterki w oprogramowaniu, systemach lub dokumentach mogą prowadzić do wystąpienia awarii, ale nie wszystkie usterki powodują awarie.
Defekty istnieją, ponieważ ludzie są omylni, działają pod presją, pracują ze złożonym kodem, w skomplikowanej infrastrukturze, ze zmieniającymi się technologiami oraz z dużą ilością interakcji pomiędzy systemami.
Awarie mogą zostać spowodowane też przez warunki środowiskowe. Na przykład promieniowanie, pole magnetyczne i elektryczne oraz zanieczyszczenia mogą spowodować awarie oprogramowania wbudowanego lub wpływać na oprogramowanie przez zmianę warunków działania sprzętu.
NiepoprawnieCele nauczania:
- LO-1.1.2 Kandydat rozróżnia przyczynę usterki od jej skutków. (K2)
- LO-1.1.5 Kandydat potrafi wyjaśnić i porównać pojęcia pomyłka, usterka, awaria oraz odpowiadające im pojęcia błąd i pluskwa, podając przykłady. (K2)
Awarią jest odchylenie rezultatu otrzymanego od oczekiwanego.
Sylabus w podrozdziale 1.1.2 Przyczyny usterek w oprogramowaniu określa następująco:
Człowiek może popełnić błąd (pomyłkę), która powoduje powstanie defektu (usterki, pluskwy) w kodzie programu lub dokumencie. Jeżeli kod zawierający defekt zostaje wykonany, system nie zrobi tego co powinien (lub wykona to czego nie powinien) powodując awarię. Usterki w oprogramowaniu, systemach lub dokumentach mogą prowadzić do wystąpienia awarii, ale nie wszystkie usterki powodują awarie.
Defekty istnieją, ponieważ ludzie są omylni, działają pod presją, pracują ze złożonym kodem, w skomplikowanej infrastrukturze, ze zmieniającymi się technologiami oraz z dużą ilością interakcji pomiędzy systemami.
Awarie mogą zostać spowodowane też przez warunki środowiskowe. Na przykład promieniowanie, pole magnetyczne i elektryczne oraz zanieczyszczenia mogą spowodować awarie oprogramowania wbudowanego lub wpływać na oprogramowanie przez zmianę warunków działania sprzętu.
-
Pytań 2 z 15Podstawy testowania2
Kiedy można powiedzieć, że wystarczy już testowania?
PoprawnieDecyzja o zakończeniu testowania powinna zależeć od kontraktu z klientem, specjalnych wymagań oprogramowania lub ryzyka, jakie organizacja jest gotowa ponieść, wynikającego z ew. zbyt wczesnego zakończenia testów.
Zgodnie z podrozdziałem 1.1.5 Jak dużo testowania jest potrzebne? sylabusa:
Podczas podejmowania decyzji jak dużo testów należy wykonać, powinno się wziąć pod uwagę poziom ryzyka, włączając w to ryzyko techniczne, ryzyko związane z bezpieczeństwem, a także ryzyko biznesowe oraz ograniczenia projektowe takie jak czas i budżet.
Testowanie powinno dostarczać interesariuszom informacji wystarczających do podjęcia świadomych decyzji o dopuszczeniu testowanego oprogramowania lub systemu do następnej fazy rozwoju lub przekazaniu go klientowi.
Wiemy, że nie możemy przetestować wszystkiego, nawet jeśli diablo tego chcemy. Zgodnie z jedną z siedmiu podstawowych zasad testowania (zob. rozdział 1.3 Ogólne zasady testowania sylabusa), testowanie gruntowne jest niewykonalne. Wiemy również, że każdy system podlega ryzyku takiego czy innego rodzaju oraz że istnieje pewien poziom jakości, który jest akceptowalny dla danego systemu.
Kluczowym aspektem osiągnięcia akceptowalnego wyniku w ramach skończonej i ograniczonej liczbie testów jest nadawanie priorytetów (priorytetyzacja). Najważniejsze testy należy wykonać w pierwszej kolejności, tak żeby w każdej chwili mieć pewność, że testy już wykonane są ważniejsze od tych, które są jeszcze do zrobienia. Dzięki temu nawet jeśli aktywność testowa zostanie zmniejszona o połowę, będziemy mogli zapewnić klienta lub kierownika, że najważniejsze testy zostały wykonane. Najważniejsze testy to te, które testują najbardziej istotne aspekty systemu: testują najważniejsze funkcje zdefiniowane przez użytkowników lub sponsorów systemu lub najważniejsze atrybuty niefunkcjonalne, a także dotyczą najbardziej ryzykownych obszarów.
Innym ważnym aspektem jest ustalenie kryteriów, które pozwolą w sposób najbardziej obiektywny określić, czy można bezpiecznie przerwać testy – kryteria te znane są jako kryteria zakończenia (wyjścia).
Priorytety i kryteria zakończenia stanowią podstawę planowania. W rezultacie pożądany poziom jakości i ryzyka może być zagrożony, ale nasze podejście zapewnia, że możemy jeszcze określić, ile testów jest wymaganych w celu osiągnięcia uzgodnionych poziomów i nadal możemy mieć pewność, że każda redukcja czasu lub wysiłku nie wpłynie na ostateczny bilans – najważniejsze testy będą nadal tymi, które zostały już wykonane, gdy tylko się zatrzymamy.
NiepoprawnieDecyzja o zakończeniu testowania powinna zależeć od kontraktu z klientem, specjalnych wymagań oprogramowania lub ryzyka, jakie organizacja jest gotowa ponieść, wynikającego z ew. zbyt wczesnego zakończenia testów.
Zgodnie z podrozdziałem 1.1.5 Jak dużo testowania jest potrzebne? sylabusa:
Podczas podejmowania decyzji jak dużo testów należy wykonać, powinno się wziąć pod uwagę poziom ryzyka, włączając w to ryzyko techniczne, ryzyko związane z bezpieczeństwem, a także ryzyko biznesowe oraz ograniczenia projektowe takie jak czas i budżet.
Testowanie powinno dostarczać interesariuszom informacji wystarczających do podjęcia świadomych decyzji o dopuszczeniu testowanego oprogramowania lub systemu do następnej fazy rozwoju lub przekazaniu go klientowi.
Wiemy, że nie możemy przetestować wszystkiego, nawet jeśli diablo tego chcemy. Zgodnie z jedną z siedmiu podstawowych zasad testowania (zob. rozdział 1.3 Ogólne zasady testowania sylabusa), testowanie gruntowne jest niewykonalne. Wiemy również, że każdy system podlega ryzyku takiego czy innego rodzaju oraz że istnieje pewien poziom jakości, który jest akceptowalny dla danego systemu.
Kluczowym aspektem osiągnięcia akceptowalnego wyniku w ramach skończonej i ograniczonej liczbie testów jest nadawanie priorytetów (priorytetyzacja). Najważniejsze testy należy wykonać w pierwszej kolejności, tak żeby w każdej chwili mieć pewność, że testy już wykonane są ważniejsze od tych, które są jeszcze do zrobienia. Dzięki temu nawet jeśli aktywność testowa zostanie zmniejszona o połowę, będziemy mogli zapewnić klienta lub kierownika, że najważniejsze testy zostały wykonane. Najważniejsze testy to te, które testują najbardziej istotne aspekty systemu: testują najważniejsze funkcje zdefiniowane przez użytkowników lub sponsorów systemu lub najważniejsze atrybuty niefunkcjonalne, a także dotyczą najbardziej ryzykownych obszarów.
Innym ważnym aspektem jest ustalenie kryteriów, które pozwolą w sposób najbardziej obiektywny określić, czy można bezpiecznie przerwać testy – kryteria te znane są jako kryteria zakończenia (wyjścia).
Priorytety i kryteria zakończenia stanowią podstawę planowania. W rezultacie pożądany poziom jakości i ryzyka może być zagrożony, ale nasze podejście zapewnia, że możemy jeszcze określić, ile testów jest wymaganych w celu osiągnięcia uzgodnionych poziomów i nadal możemy mieć pewność, że każda redukcja czasu lub wysiłku nie wpłynie na ostateczny bilans – najważniejsze testy będą nadal tymi, które zostały już wykonane, gdy tylko się zatrzymamy.
-
Pytań 3 z 15Podstawy testowania3
Co nie jest celem testowania?
PoprawnieCele nauczania:
- LO-1.2.1 Kandydat pamięta ogólne cele testowania. (K1)
- LO-1.2.3 Kandydat rozróżnia testowanie od debagowania. (K2)
Celem testowania nie jest debagowanie defektów.
Zgodnie z sylabusem (rozdział 1.2 Co to jest testowanie?):
Debagowanie różni się od testowania. Testowanie dynamiczne może pokazać awarie, których źródłem są usterki. Debagowanie jest czynnością programistyczną, która znajduje, analizuje i umożliwia usunięcie przyczyny awarii. Późniejsze testy potwierdzające (retesty) wykonywane przez testera gwarantują, że poprawka rzeczywiście usunęła usterkę. Odpowiedzialność za każdą z tych czynności jest zwykle inna tj. testerzy testują, a programiści debagują.
Zgodnie z sylabusem testowanie może mieć następujące cele:
- znajdowanie defektów,
- nabieranie zaufania do poziomu jakości,
- dostarczanie informacji potrzebnych do podejmowania decyzji,
- zapobieganie defektom.
NiepoprawnieCele nauczania:
- LO-1.2.1 Kandydat pamięta ogólne cele testowania. (K1)
- LO-1.2.3 Kandydat rozróżnia testowanie od debagowania. (K2)
Celem testowania nie jest debagowanie defektów.
Zgodnie z sylabusem (rozdział 1.2 Co to jest testowanie?):
Debagowanie różni się od testowania. Testowanie dynamiczne może pokazać awarie, których źródłem są usterki. Debagowanie jest czynnością programistyczną, która znajduje, analizuje i umożliwia usunięcie przyczyny awarii. Późniejsze testy potwierdzające (retesty) wykonywane przez testera gwarantują, że poprawka rzeczywiście usunęła usterkę. Odpowiedzialność za każdą z tych czynności jest zwykle inna tj. testerzy testują, a programiści debagują.
Zgodnie z sylabusem testowanie może mieć następujące cele:
- znajdowanie defektów,
- nabieranie zaufania do poziomu jakości,
- dostarczanie informacji potrzebnych do podejmowania decyzji,
- zapobieganie defektom.
-
Pytań 4 z 15Podstawy testowania4
Będąc kierownikiem testów zbierasz metryki dotyczące defektów. Zauważasz, że po pierwszym cyklu testowania – pokrywającym wszystkie wymagania – podsystem C ma gęstość usterek większą o 150% niż średnia dla całego systemu. Z drugiej strony podsystem A ma gęstość usterek niższą o 60% niż średnia. Jakie wnioski dla następnego cyklu testowania wyciągasz z tych danych?
PoprawnieOdpowiedź na pytanie związana jest z zasadą mówiącą o kumulowaniu się
błędówdefektów, czyli jedną z siedmiu podstawowych zasad testowania (zob. w sylabusie rozdział 1.3 Ogólne zasady testowania).Z zasady kumulowania się defektów wynika założenie, że wysiłek związany z testowaniem należy rozłożyć proporcjonalnie do przewidywanej i zaobserwowanej gęstości defektów w modułach. Niewielka liczba modułów zwykle zawiera większość usterek znalezionych podczas testowania prowadzonego przed wydaniem oprogramowania lub jest odpowiedzialna za większość awarii po wdrożeniu oprogramowania (awarii w fazie produkcyjnej).
Powyższa zasada testowania odwołuje się do znanej zasady Pareta, zgodnie z którą 20% badanych obiektów związanych jest z 80% pewnych zasobów (stąd inna nazwa tej zasady: zasada 80/20 lub zasada 80 na 20). Przykłady zastosowania tej zasady to np. 20% klientów przynosi 80% zysków czy 20% pracowników generuje 80% produktów. Zasada pozwala ustalać priorytety oraz ułatwia organizację czasu, przez co osiąga się maksymalne wyniki w minimalnym czasie. Ułatwia też organizację pracy w grupie, zależnie od użyteczności i umiejętności jej członków.
Zasadę Pareta można zastosować podczas testowania, stwierdzając, że około 80% usterek jest znajdowanych w 20% modułów. Tym samym dzięki identyfikacji tych 20% modułów (tj. modułów najbardziej „ryzykownych”) można znaleźć większość (80%) defektów, ponieważ – i tu przechodzimy do meritum tej zasady – defekty lubią się kumulować (grupować, zbierać).
Zgodnie z powyższym, prawidłowa jest odpowiedź zakładająca, że w przypadku zauważenia, że dany moduł (część systemu) ma więcej usterek od innych, należy go przetestować dokładniej.
NiepoprawnieOdpowiedź na pytanie związana jest z zasadą mówiącą o kumulowaniu się
błędówdefektów, czyli jedną z siedmiu podstawowych zasad testowania (zob. w sylabusie rozdział 1.3 Ogólne zasady testowania).Z zasady kumulowania się defektów wynika założenie, że wysiłek związany z testowaniem należy rozłożyć proporcjonalnie do przewidywanej i zaobserwowanej gęstości defektów w modułach. Niewielka liczba modułów zwykle zawiera większość usterek znalezionych podczas testowania prowadzonego przed wydaniem oprogramowania lub jest odpowiedzialna za większość awarii po wdrożeniu oprogramowania (awarii w fazie produkcyjnej).
Powyższa zasada testowania odwołuje się do znanej zasady Pareta, zgodnie z którą 20% badanych obiektów związanych jest z 80% pewnych zasobów (stąd inna nazwa tej zasady: zasada 80/20 lub zasada 80 na 20). Przykłady zastosowania tej zasady to np. 20% klientów przynosi 80% zysków czy 20% pracowników generuje 80% produktów. Zasada pozwala ustalać priorytety oraz ułatwia organizację czasu, przez co osiąga się maksymalne wyniki w minimalnym czasie. Ułatwia też organizację pracy w grupie, zależnie od użyteczności i umiejętności jej członków.
Zasadę Pareta można zastosować podczas testowania, stwierdzając, że około 80% usterek jest znajdowanych w 20% modułów. Tym samym dzięki identyfikacji tych 20% modułów (tj. modułów najbardziej „ryzykownych”) można znaleźć większość (80%) defektów, ponieważ – i tu przechodzimy do meritum tej zasady – defekty lubią się kumulować (grupować, zbierać).
Zgodnie z powyższym, prawidłowa jest odpowiedź zakładająca, że w przypadku zauważenia, że dany moduł (część systemu) ma więcej usterek od innych, należy go przetestować dokładniej.
-
Pytań 5 z 15Podstawy testowania5
Które z poniższych czynności stanowią część planowania testów w ramach podstawowego procesu testowego?
A. Tworzenie przypadków testowych.
B. Określanie ogólnego podejścia do testowania.
C. Przydzielanie zasobów.
D. Budowanie środowiska testowego.
E. Pisanie warunków testowych.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 (zob. rozdział 1.4 Podstawowy proces testowy), 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.
Podczas planowania testów należy określić ogólne podejście do testowania, w tym określić poziomy testów oraz kryteria wejścia i zakończenia, a także przydzielić zasoby do różnych czynności testowych. Tworzenie przypadków testowych, budowanie środowiska testowego oraz pisanie warunków testowych to zadania wykonywane podczas analizy i projektowania testów (zob. w sylabusie podrozdział 1.4.2 Analiza i projektowanie testów). Zgodnie z powyższym prawdziwe są odpowiedzi B i C, natomiast A, D i E są fałszywe.
Etap planowania i kontroli testów, o którym mowa w pytaniu, został opisany w sylabusie w podrozdziale 1.4.1 Planowanie i nadzór oraz w kilku rozdziałach działu 5. Zgodnie z podrozdziałem 1.4.1 sylabusa, planowanie testów polega na zdefiniowaniu celów testowania oraz określeniu czynności testowych potrzebnych do wypełnienia celów i misji testowania. Podrozdział 5.2.1 precyzuje, iż planowanie może zostać udokumentowane w głównym planie testów lub w oddzielnych planach testów dla każdego poziomu.
Zgodnie z podrozdziałem 5.2.2 Czynności związane z planowaniem testów sylabusa, w planowanie testów mogą wchodzić następujące czynności:
- ustalanie zakresu i ryzyka oraz zidentyfikowanie celów testowania,
- określanie ogólnego podejścia do testowania, włącznie z określeniem poziomów testów oraz kryteriów wejścia i zakończenia,
- integrowanie i koordynowanie czynności testowych z innymi czynnościami w cyklu życia oprogramowania (zakupami, dostawami, rozwojem, działaniem produkcyjnym oraz pielęgnacją),
- podejmowanie decyzji o tym, co testować, którym rolom przypisać jakie czynności testowe, jak czynności testowe powinny być wykonane oraz jak powinno się oceniać wyniki testów,
- harmonogramowanie analizy i projektowania testów,
- harmonogramowanie implementacji, wykonania i oceny testów,
- przydzielanie zasobów do różnych czynności testowych,
- określanie dokumentacji testowej: ilości, poziomu szczegółowości, struktury oraz wzorców,
- wybieranie metryk do monitorowania i kontrolowania przygotowania i wykonania testów, naprawy defektów oraz ryzyka,
- ustalanie poziomu szczegółowości procedur testowych, tak aby dostarczyć wystarczającą ilość informacji dla wsparcia powtarzalnego przygotowania i wykonania testów.
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 (zob. rozdział 1.4 Podstawowy proces testowy), 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.
Podczas planowania testów należy określić ogólne podejście do testowania, w tym określić poziomy testów oraz kryteria wejścia i zakończenia, a także przydzielić zasoby do różnych czynności testowych. Tworzenie przypadków testowych, budowanie środowiska testowego oraz pisanie warunków testowych to zadania wykonywane podczas analizy i projektowania testów (zob. w sylabusie podrozdział 1.4.2 Analiza i projektowanie testów). Zgodnie z powyższym prawdziwe są odpowiedzi B i C, natomiast A, D i E są fałszywe.
Etap planowania i kontroli testów, o którym mowa w pytaniu, został opisany w sylabusie w podrozdziale 1.4.1 Planowanie i nadzór oraz w kilku rozdziałach działu 5. Zgodnie z podrozdziałem 1.4.1 sylabusa, planowanie testów polega na zdefiniowaniu celów testowania oraz określeniu czynności testowych potrzebnych do wypełnienia celów i misji testowania. Podrozdział 5.2.1 precyzuje, iż planowanie może zostać udokumentowane w głównym planie testów lub w oddzielnych planach testów dla każdego poziomu.
Zgodnie z podrozdziałem 5.2.2 Czynności związane z planowaniem testów sylabusa, w planowanie testów mogą wchodzić następujące czynności:
- ustalanie zakresu i ryzyka oraz zidentyfikowanie celów testowania,
- określanie ogólnego podejścia do testowania, włącznie z określeniem poziomów testów oraz kryteriów wejścia i zakończenia,
- integrowanie i koordynowanie czynności testowych z innymi czynnościami w cyklu życia oprogramowania (zakupami, dostawami, rozwojem, działaniem produkcyjnym oraz pielęgnacją),
- podejmowanie decyzji o tym, co testować, którym rolom przypisać jakie czynności testowe, jak czynności testowe powinny być wykonane oraz jak powinno się oceniać wyniki testów,
- harmonogramowanie analizy i projektowania testów,
- harmonogramowanie implementacji, wykonania i oceny testów,
- przydzielanie zasobów do różnych czynności testowych,
- określanie dokumentacji testowej: ilości, poziomu szczegółowości, struktury oraz wzorców,
- wybieranie metryk do monitorowania i kontrolowania przygotowania i wykonania testów, naprawy defektów oraz ryzyka,
- ustalanie poziomu szczegółowości procedur testowych, tak aby dostarczyć wystarczającą ilość informacji dla wsparcia powtarzalnego przygotowania i wykonania testów.
-
Pytań 6 z 15Testowanie w cyklu życia oprogramowania6
Grupa czynności testowych zorganizowanych i zarządzanych łącznie to:
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)
Grupa czynności testowych, które są razem zorganizowane i zarządzane to poziom testów. Przykładami poziomów testów są testy modułowe, testy integracyjne, testy systemowe i testy akceptacyjne.
Każdy z poziomów testów obejmuje testy zaprojektowane specjalnie, aby odkryć problemy specyficzne dla danego etapu wytwarzania oprogramowania. Poziomy testów mogą być również zastosowane w ramach iteracyjnego modelu wytwarzania oprogramowania. Zgodnie z rozdziałem 2.2 Poziomy testów sylabusa:
Dla każdego poziomu testowania można zdefiniować: ogólne cele, produkty, na podstawie których tworzy się przypadki testowe (podstawę testów), przedmiot testów (to co jest testowane), typowe defekty i awarie do wykrycia, wymagania na jarzmo testowe oraz wsparcie narzędziowe, środowisko testowe, specyficzne podejście, odpowiedzialność.
Pozostałe opcje odpowiedzi (specyfikacja procedury testowej, specyfikacja przypadku testowego, plan testów) to rodzaje dokumentów przygotowywanych w ramach procesu testowego.
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)
Grupa czynności testowych, które są razem zorganizowane i zarządzane to poziom testów. Przykładami poziomów testów są testy modułowe, testy integracyjne, testy systemowe i testy akceptacyjne.
Każdy z poziomów testów obejmuje testy zaprojektowane specjalnie, aby odkryć problemy specyficzne dla danego etapu wytwarzania oprogramowania. Poziomy testów mogą być również zastosowane w ramach iteracyjnego modelu wytwarzania oprogramowania. Zgodnie z rozdziałem 2.2 Poziomy testów sylabusa:
Dla każdego poziomu testowania można zdefiniować: ogólne cele, produkty, na podstawie których tworzy się przypadki testowe (podstawę testów), przedmiot testów (to co jest testowane), typowe defekty i awarie do wykrycia, wymagania na jarzmo testowe oraz wsparcie narzędziowe, środowisko testowe, specyficzne podejście, odpowiedzialność.
Pozostałe opcje odpowiedzi (specyfikacja procedury testowej, specyfikacja przypadku testowego, plan testów) to rodzaje dokumentów przygotowywanych w ramach procesu testowego.
-
Pytań 7 z 15Testowanie w cyklu życia oprogramowania7
Testowanie połączenia jest również nazywane:
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)
Zgodnie ze słownikiem, testowanie połączenia to inna nazwa na określenie testowania integracji modułów, zwanego także testowaniem integracyjnym małej skali, czyli testów wykonywanych w celu wykrycia usterek w interfejsach i interakcjach pomiędzy integrowanymi modułami. Dla porównania istnieje także testowanie integracji systemów, zwane testowaniem integracyjnym zewnętrznym, które z kolei dotyczy testowania integracji systemów i pakietów oraz interfejsów z organizacjami zewnętrznymi (np. Elektroniczna Wymiana Danych, Internet).
Zarówno testowanie integracji modułów (testowanie połączenia, testowanie integracyjne małej skali), jak i testowanie integracji systemów (testowanie integracyjne zewnętrzne) to podtypy testowania integracyjnego. Zgodnie z sylabusem (zob. podrozdział 2.2.2 Testy integracyjne), testowanie integracyjne może być bowiem wykonywane na więcej niż jednym poziomie i dla przedmiotów testów o różnej wielkości:
- testowanie integracji modułów sprawdza interakcje pomiędzy modułami oprogramowania i jest wykonywane po testach modułowych,
- testowanie integracji systemów sprawdza interakcje pomiędzy różnymi systemami lub pomiędzy sprzętem a oprogramowaniem i może być wykonywane po testowaniu systemowym.
Dodatkowo można wyróżnić testowanie integracji sprzęt-oprogramowanie czy testowanie interfejsu.
Wskazane wśród możliwych odpowiedzi testowanie pielęgnacyjne to testowanie zmian we wdrożonym systemie lub testowanie wpływu zmienionego środowiska na wdrożony system.
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)
Zgodnie ze słownikiem, testowanie połączenia to inna nazwa na określenie testowania integracji modułów, zwanego także testowaniem integracyjnym małej skali, czyli testów wykonywanych w celu wykrycia usterek w interfejsach i interakcjach pomiędzy integrowanymi modułami. Dla porównania istnieje także testowanie integracji systemów, zwane testowaniem integracyjnym zewnętrznym, które z kolei dotyczy testowania integracji systemów i pakietów oraz interfejsów z organizacjami zewnętrznymi (np. Elektroniczna Wymiana Danych, Internet).
Zarówno testowanie integracji modułów (testowanie połączenia, testowanie integracyjne małej skali), jak i testowanie integracji systemów (testowanie integracyjne zewnętrzne) to podtypy testowania integracyjnego. Zgodnie z sylabusem (zob. podrozdział 2.2.2 Testy integracyjne), testowanie integracyjne może być bowiem wykonywane na więcej niż jednym poziomie i dla przedmiotów testów o różnej wielkości:
- testowanie integracji modułów sprawdza interakcje pomiędzy modułami oprogramowania i jest wykonywane po testach modułowych,
- testowanie integracji systemów sprawdza interakcje pomiędzy różnymi systemami lub pomiędzy sprzętem a oprogramowaniem i może być wykonywane po testowaniu systemowym.
Dodatkowo można wyróżnić testowanie integracji sprzęt-oprogramowanie czy testowanie interfejsu.
Wskazane wśród możliwych odpowiedzi testowanie pielęgnacyjne to testowanie zmian we wdrożonym systemie lub testowanie wpływu zmienionego środowiska na wdrożony system.
-
Pytań 8 z 15Testowanie w cyklu życia oprogramowania8
Jaki rodzaj testów jest używany w celu sprawdzenia, czy system będzie zachować się poprawnie, kiedy zostaną przekroczone ograniczenia wewnętrzne oprogramowania lub limity systemowe?
PoprawnieCele nauczania:
- LO-2.3.3 Kandydat potrafi wymienić i opisać różne typy testów niefunkcjonalnych bazujących na wymaganiach niefunkcjonalnych. (K2)
Typ testów używany w celu sprawdzenia, czy system będzie zachować się poprawnie, kiedy zostaną przekroczone ograniczenia wewnętrzne oprogramowania lub limity systemowe to testy przeciążające. Zgodnie ze słownikiem testowanie przeciążające to typ testowania wydajnościowego wykonywany, by określić jak system lub jego moduł pracuje na przewidywanej lub wyspecyfikowanej granicy lub poza nią lub też przy ograniczonym dostępie do pamięci lub serwera.
Testowanie przeciążające jest zbliżone do testowania obciążeniowego, z tą drobną różnicą, że w przypadku testowania przeciążającego chodzi o sprawdzenie działania poza pewnymi granicami, natomiast w przypadku testowania obciążeniowego poruszamy się w ramach tych granic.
Wymienione w odpowiedzi testowanie zabezpieczeń ma celu określenie zabezpieczeń oprogramowania, natomiast testowanie niezawodności sprawdza zdolność oprogramowania do wykonywania wymaganych funkcji w określonych warunkach przez określony czas lub dla określonej liczby operacji.
NiepoprawnieCele nauczania:
- LO-2.3.3 Kandydat potrafi wymienić i opisać różne typy testów niefunkcjonalnych bazujących na wymaganiach niefunkcjonalnych. (K2)
Typ testów używany w celu sprawdzenia, czy system będzie zachować się poprawnie, kiedy zostaną przekroczone ograniczenia wewnętrzne oprogramowania lub limity systemowe to testy przeciążające. Zgodnie ze słownikiem testowanie przeciążające to typ testowania wydajnościowego wykonywany, by określić jak system lub jego moduł pracuje na przewidywanej lub wyspecyfikowanej granicy lub poza nią lub też przy ograniczonym dostępie do pamięci lub serwera.
Testowanie przeciążające jest zbliżone do testowania obciążeniowego, z tą drobną różnicą, że w przypadku testowania przeciążającego chodzi o sprawdzenie działania poza pewnymi granicami, natomiast w przypadku testowania obciążeniowego poruszamy się w ramach tych granic.
Wymienione w odpowiedzi testowanie zabezpieczeń ma celu określenie zabezpieczeń oprogramowania, natomiast testowanie niezawodności sprawdza zdolność oprogramowania do wykonywania wymaganych funkcji w określonych warunkach przez określony czas lub dla określonej liczby operacji.
-
Pytań 9 z 15Statyczne techniki testowania9
Jaki wspólny cel mają przeglądy, analiza statyczna oraz testy dynamiczne:
PoprawnieCele nauczania:
- LO-3.1.1 Kandydat potrafi rozpoznać produkty, które mogą zostać sprawdzone przez różne techniki testowania statycznego. (K1)
- LO-3.1.2 Kandydat potrafi opisać znaczenie i wartość statystycznych technik testowania w ocenie produktów procesu rozwoju oprogramowania. (K2)
- LO-3.1.3 Kandydat potrafi wyjaśnić różnice pomiędzy testami statycznymi i dynamicznymi. (K2)
Wspólnym celem przeglądów, analizy statycznej oraz testów dynamicznych jest znajdowanie defektów. Zgodnie z rozdziałem 3.1 Techniki statyczne a proces testowania sylabusa:
Przeglądy, analiza statyczna oraz testy dynamiczne mają ten sam cel – znajdowanie usterek. Te trzy techniki uzupełniają się wzajemnie, mogą skutecznie i efektywnie znajdować różne typy błędów. Techniki statyczne, w odróżnieniu od testów dynamicznych, znajdują raczej przyczyny awarii (usterki), a nie same awarie.
Do typowych usterek, które łatwiej wykryć w testach statycznych niż dynamicznych należą: odchylenia od standardów, usterki w wymaganiach, usterki w projekcie, niedostateczna pielęgnowalność oraz nieprawidłowe specyfikacje interfejsów.
Celem przeglądów, analizy statycznej oraz testów dynamicznych nie jest poprawianie defektów, ponieważ lokalizacja oraz poprawianie usterek jest czynnością programistyczną, a nie testową.
NiepoprawnieCele nauczania:
- LO-3.1.1 Kandydat potrafi rozpoznać produkty, które mogą zostać sprawdzone przez różne techniki testowania statycznego. (K1)
- LO-3.1.2 Kandydat potrafi opisać znaczenie i wartość statystycznych technik testowania w ocenie produktów procesu rozwoju oprogramowania. (K2)
- LO-3.1.3 Kandydat potrafi wyjaśnić różnice pomiędzy testami statycznymi i dynamicznymi. (K2)
Wspólnym celem przeglądów, analizy statycznej oraz testów dynamicznych jest znajdowanie defektów. Zgodnie z rozdziałem 3.1 Techniki statyczne a proces testowania sylabusa:
Przeglądy, analiza statyczna oraz testy dynamiczne mają ten sam cel – znajdowanie usterek. Te trzy techniki uzupełniają się wzajemnie, mogą skutecznie i efektywnie znajdować różne typy błędów. Techniki statyczne, w odróżnieniu od testów dynamicznych, znajdują raczej przyczyny awarii (usterki), a nie same awarie.
Do typowych usterek, które łatwiej wykryć w testach statycznych niż dynamicznych należą: odchylenia od standardów, usterki w wymaganiach, usterki w projekcie, niedostateczna pielęgnowalność oraz nieprawidłowe specyfikacje interfejsów.
Celem przeglądów, analizy statycznej oraz testów dynamicznych nie jest poprawianie defektów, ponieważ lokalizacja oraz poprawianie usterek jest czynnością programistyczną, a nie testową.
-
Pytań 10 z 15Statyczne techniki testowania10
Która w poniższych list zawiera główne etapy przeglądu formalnego?
PoprawnieCele nauczania:
- LO-3.2.1 Kandydat pamięta kroki, role i odpowiedzialności związane z typowym przeglądem formalnym. (K2)
Zgodnie z podrozdziałem 3.2.1 Kroki przeglądu formalnego sylabusa, przegląd formalny zwykle składa się z następujących sześciu faz:
1. Planowanie:
- definiowanie kryteriów przeglądu,
- wybór uczestników przeglądu,
- przydział ról,
- wybór fragmentów dokumentów do przeglądu,
- dla bardziej formalnych typów przeglądów (np. inspekcji) – zdefiniowanie kryteriów wejścia i kryteriów zakończenia.
2. Rozpoczęcie
- rozdanie (rozesłanie) dokumentów,
- wyjaśnienie uczestnikom przeglądu celów przeglądu, procesu przeglądu oraz dokumentów,
- dla bardziej formalnych typów przeglądów (np. inspekcji) – sprawdzenie kryteriów wejścia.
3. Przygotowanie indywidualne
- przygotowanie przed spotkaniem przeglądowym poprzez przejrzenie dokumentów,
- zapisywanie potencjalnych defektów, pytań i komentarzy.
4. Kontrola / ocena / zapisanie wyników (spotkanie przeglądowe)
- dyskusja lub spisywanie, z udokumentowaniem wyników i sporządzeniem protokołu (dla bardziej formalnych typów przeglądów),
- zapisywanie defektów i rekomendacji dotyczących ich poprawiania, podejmowanie decyzji w sprawie defektów.
5. Poprawki
- naprawianie znalezionych defektów (zwykle wykonywane przez autora),
- zapisywanie zaktualizowanych statusów defektów (w przeglądach formalnych).
6. Zakończenie
- sprawdzenie, że usterki zostały obsłużone,
- zbieranie metryk,
- dla bardziej formalnych typów przeglądów (np. inspekcji) – sprawdzenie kryteriów zakończenia.
Więcej na temat faz przeglądu formalnego w filmie „Phases of Review” (otwórz w nowym oknie).
NiepoprawnieCele nauczania:
- LO-3.2.1 Kandydat pamięta kroki, role i odpowiedzialności związane z typowym przeglądem formalnym. (K2)
Zgodnie z podrozdziałem 3.2.1 Kroki przeglądu formalnego sylabusa, przegląd formalny zwykle składa się z następujących sześciu faz:
1. Planowanie:
- definiowanie kryteriów przeglądu,
- wybór uczestników przeglądu,
- przydział ról,
- wybór fragmentów dokumentów do przeglądu,
- dla bardziej formalnych typów przeglądów (np. inspekcji) – zdefiniowanie kryteriów wejścia i kryteriów zakończenia.
2. Rozpoczęcie
- rozdanie (rozesłanie) dokumentów,
- wyjaśnienie uczestnikom przeglądu celów przeglądu, procesu przeglądu oraz dokumentów,
- dla bardziej formalnych typów przeglądów (np. inspekcji) – sprawdzenie kryteriów wejścia.
3. Przygotowanie indywidualne
- przygotowanie przed spotkaniem przeglądowym poprzez przejrzenie dokumentów,
- zapisywanie potencjalnych defektów, pytań i komentarzy.
4. Kontrola / ocena / zapisanie wyników (spotkanie przeglądowe)
- dyskusja lub spisywanie, z udokumentowaniem wyników i sporządzeniem protokołu (dla bardziej formalnych typów przeglądów),
- zapisywanie defektów i rekomendacji dotyczących ich poprawiania, podejmowanie decyzji w sprawie defektów.
5. Poprawki
- naprawianie znalezionych defektów (zwykle wykonywane przez autora),
- zapisywanie zaktualizowanych statusów defektów (w przeglądach formalnych).
6. Zakończenie
- sprawdzenie, że usterki zostały obsłużone,
- zbieranie metryk,
- dla bardziej formalnych typów przeglądów (np. inspekcji) – sprawdzenie kryteriów zakończenia.
Więcej na temat faz przeglądu formalnego w filmie „Phases of Review” (otwórz w nowym oknie).
-
Pytań 11 z 15Techniki projektowania testów11
Jaki dokument określa sekwencję działań umożliwiających wykonanie testu?
PoprawnieCele nauczania:
- LO-4.1.1 Kandydat odróżnia projekt testów od specyfikacji przypadków testowych oraz od procedury testowej. (K2)
Sekwencję działań umożliwiających wykonanie testu określa specyfikacja procedury testowej (określana także jako procedura testowa lub scenariusz testowy). Informacji na ten temat szukaj w rozdziale 4.1 Proces rozwoju testów sylabusa oraz w słowniku. Warto także zajrzeć do standardu IEEE Std 829, pamiętając jednak, że istnieje kilka wersji normy IEEE Std 829, z czego dwie najnowsze to:
- IEEE Std 829-1998 (IEEE Standard for Software Test Documentation) zaakceptowana 16 września 1998 r.
- oraz jej rewizja oznaczona IEEE Std 829-2008 (IEEE Standard for Software and System Test Documentation) zaakceptowana 27 marca 2008 r.
Najnowszy sylabus ISTQB CTFL (wersja 2011) odwołuje się głównie (niemal w całości) do wersji IEEE Std 829-1998, a nie do nowszej IEEE Std 829-2008 (zob. rozdział „12. Załącznik E – Uwagi do wydania”, punkt 10).
Zgodnie z sylabusem, specyfikacja procedury testowej jest tworzona na etapie implementacji testów (zob. podrozdział 1.4.3 Implementacja i wykonanie testów) poprzez rozwijanie, implementowanie, priorytetyzowanie oraz organizowanie przypadków testowych.
W standardzie IEEE Std 829-1998 cel specyfikacji procedury testowej zdefiniowano jako „to specify the steps for executing a set of test cases or, more generally, the steps used to analyze a software item in order to evaluate a set of features”. Bardzo podobnie cel ten zdefiniowano w rewizji IEEE Std 829-2008: „to specify the steps for executing a set of test cases or, more generally, the steps used to exercise a software product or software-based system item in order to evaluate a set of features”.
Zgodnie ze standardem IEEE Std 829-1998 specyfikacja procedury testowej powinna obejmować następujące elementy:
1. Test procedure specification identifier
2. Purpose
3. Special requirements
4. Procedure stepsW rewizji IEEE Std 829-2008 zarys specyfikacji procedury testowej określono następująco:
1. INTRODUCTION
1.1. Document identifier
1.2. Scope
1.3. References
1.4. Relationship to other procedures
2. DETAILS
2.1. Inputs, outputs, and special requirements
2.2. Ordered description of the steps to be taken to execute the test cases
3. GENERAL
3.1. Glossary
3.2. Document change procedures and historyNiepoprawnieCele nauczania:
- LO-4.1.1 Kandydat odróżnia projekt testów od specyfikacji przypadków testowych oraz od procedury testowej. (K2)
Sekwencję działań umożliwiających wykonanie testu określa specyfikacja procedury testowej (określana także jako procedura testowa lub scenariusz testowy). Informacji na ten temat szukaj w rozdziale 4.1 Proces rozwoju testów sylabusa oraz w słowniku. Warto także zajrzeć do standardu IEEE Std 829, pamiętając jednak, że istnieje kilka wersji normy IEEE Std 829, z czego dwie najnowsze to:
- IEEE Std 829-1998 (IEEE Standard for Software Test Documentation) zaakceptowana 16 września 1998 r.
- oraz jej rewizja oznaczona IEEE Std 829-2008 (IEEE Standard for Software and System Test Documentation) zaakceptowana 27 marca 2008 r.
Najnowszy sylabus ISTQB CTFL (wersja 2011) odwołuje się głównie (niemal w całości) do wersji IEEE Std 829-1998, a nie do nowszej IEEE Std 829-2008 (zob. rozdział „12. Załącznik E – Uwagi do wydania”, punkt 10).
Zgodnie z sylabusem, specyfikacja procedury testowej jest tworzona na etapie implementacji testów (zob. podrozdział 1.4.3 Implementacja i wykonanie testów) poprzez rozwijanie, implementowanie, priorytetyzowanie oraz organizowanie przypadków testowych.
W standardzie IEEE Std 829-1998 cel specyfikacji procedury testowej zdefiniowano jako „to specify the steps for executing a set of test cases or, more generally, the steps used to analyze a software item in order to evaluate a set of features”. Bardzo podobnie cel ten zdefiniowano w rewizji IEEE Std 829-2008: „to specify the steps for executing a set of test cases or, more generally, the steps used to exercise a software product or software-based system item in order to evaluate a set of features”.
Zgodnie ze standardem IEEE Std 829-1998 specyfikacja procedury testowej powinna obejmować następujące elementy:
1. Test procedure specification identifier
2. Purpose
3. Special requirements
4. Procedure stepsW rewizji IEEE Std 829-2008 zarys specyfikacji procedury testowej określono następująco:
1. INTRODUCTION
1.1. Document identifier
1.2. Scope
1.3. References
1.4. Relationship to other procedures
2. DETAILS
2.1. Inputs, outputs, and special requirements
2.2. Ordered description of the steps to be taken to execute the test cases
3. GENERAL
3.1. Glossary
3.2. Document change procedures and history -
Pytań 12 z 15Techniki projektowania testów12
Jedno z pól na formularzu przyjmuje jako wartości znaki literowe. Która z poniższych odpowiedzi zawiera element niepoprawnej 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)
Prawidłowa jest odpowiedź „Boo01k”, bowiem w oparciu o treść pytania można wydzielić następujące klasy równoważności:
- poprawną: wartości tylko ze znakami literowymi,
- niepoprawną: wartości zawierające także znaki inne niż znaki literowe.
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)
Prawidłowa jest odpowiedź „Boo01k”, bowiem w oparciu o treść pytania można wydzielić następujące klasy równoważności:
- poprawną: wartości tylko ze znakami literowymi,
- niepoprawną: wartości zawierające także znaki inne niż znaki literowe.
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ń 13 z 15Techniki projektowania testów13
Która z poniższych technik projektowania przypadków testowych nie jest techniką białoskrzynkową?
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.
Białoskrzynkową techniką projektowania przypadków testów nie jest analiza wartości brzegowych. Analiza wartości brzegowych jest techniką czarnoskrzynkową (zob. w sylabusie podrozdział 4.3.2 Analiza wartości brzegowych).
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 (warto przy tym pamiętać, że oprócz powyższych technik sylabus wyróżnia także techniki oparte na doświadczeniu).
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 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 (ba, mogą nawet nie być w nim wymienione), natomiast wzmianka o nich pojawia się w słowniku.
Tabela 1: Techniki umówione w sylabusie
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 (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.
Białoskrzynkową techniką projektowania przypadków testów nie jest analiza wartości brzegowych. Analiza wartości brzegowych jest techniką czarnoskrzynkową (zob. w sylabusie podrozdział 4.3.2 Analiza wartości brzegowych).
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 (warto przy tym pamiętać, że oprócz powyższych technik sylabus wyróżnia także techniki oparte na doświadczeniu).
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 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 (ba, mogą nawet nie być w nim wymienione), natomiast wzmianka o nich pojawia się w słowniku.
Tabela 1: Techniki umówione w sylabusie
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 (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ń 14 z 15Zarządzanie testowaniem14
Które z poniższych jest NAJWAŻNIEJSZE podczas wybierania podejścia do testów?
PoprawnieCele nauczania:
- LO-5.2.6 Kandydat potrafi wymienić czynności przygotowania i wykonania testów, które należy wziąć pod uwagę przy planowaniu. (K1)
Spośród wymienionych opcji odpowiedzi, najważniejsze podczas wyboru podejścia do testów są dostępne umiejętności oraz doświadczenie w użyciu wybranych technik.
Zgodnie z podrozdziałem 5.2.6 Podejście do testowania, strategia testowania sylabusa, 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 na telefon komórkowy wymagane jest inne podejście niż testowanie aplikacji do bankowości internetowej
- 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).
NiepoprawnieCele nauczania:
- LO-5.2.6 Kandydat potrafi wymienić czynności przygotowania i wykonania testów, które należy wziąć pod uwagę przy planowaniu. (K1)
Spośród wymienionych opcji odpowiedzi, najważniejsze podczas wyboru podejścia do testów są dostępne umiejętności oraz doświadczenie w użyciu wybranych technik.
Zgodnie z podrozdziałem 5.2.6 Podejście do testowania, strategia testowania sylabusa, 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 na telefon komórkowy wymagane jest inne podejście niż testowanie aplikacji do bankowości internetowej
- 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).
-
Pytań 15 z 15Testowanie wspierane narzędziami15
Jak nazywa się technika skryptowa używająca plików zawierających nie tylko dane testowe i oczekiwane rezultaty, ale także słowa kluczowe odnoszące się do testowanej aplikacji?
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)
Technika skryptowa używająca plików zawierających nie tylko dane testowe i oczekiwane rezultaty, ale także słowa kluczowe odnoszące się do testowanej aplikacji to testowanie oparte o słowa kluczowe.
Testowanie oparte o słowa kluczowe, określane także jako testowanie oparte o słowa akcji, jest jedną z technik skryptowych (zob. w sylabusie podrozdział 6.2.2 Specjalne uwagi dla niektórych typów narzędzi w rozdziale 6.2 Skuteczne użycie narzędzi, potencjalne korzyści i ryzyko). Zgodnie z sylabusem:
W podejściu sterowanym słowami kluczowymi arkusz kalkulacyjny zawiera słowa kluczowe opisujące akcje do wykonania (nazywane również słowami akcji) oraz dane testowe. Testerzy (nawet jeżeli nie znają języków skryptowych) mogą w takim przypadku definiować testy przy użyciu słów kluczowych, które zostają dostosowane do testowanej aplikacji.
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)
Technika skryptowa używająca plików zawierających nie tylko dane testowe i oczekiwane rezultaty, ale także słowa kluczowe odnoszące się do testowanej aplikacji to testowanie oparte o słowa kluczowe.
Testowanie oparte o słowa kluczowe, określane także jako testowanie oparte o słowa akcji, jest jedną z technik skryptowych (zob. w sylabusie podrozdział 6.2.2 Specjalne uwagi dla niektórych typów narzędzi w rozdziale 6.2 Skuteczne użycie narzędzi, potencjalne korzyści i ryzyko). Zgodnie z sylabusem:
W podejściu sterowanym słowami kluczowymi arkusz kalkulacyjny zawiera słowa kluczowe opisujące akcje do wykonania (nazywane również słowami akcji) oraz dane testowe. Testerzy (nawet jeżeli nie znają języków skryptowych) mogą w takim przypadku definiować testy przy użyciu słów kluczowych, które zostają dostosowane do testowanej aplikacji.