5.1 Planowanie testów Flashcards
Jakie są główne cele (cele) tworzenia planu testów?
- Dokumentuje sposób i harmonogram osiągnięcia celów testowych.
- Pomaga zapewnić, że wykonywane czynności testowe spełnią ustalone kryteria.
- Służy jako kanał komunikacji z członkami zespołu i interesariuszami.
- Pokazuje, że testowanie będzie zgodne z istniejącą polityką i strategią testową (lub wyjaśnia wszelkie odchylenia).
W jaki sposób planowanie testów wpływa korzystnie na proces i cykl życia testów?
- Planowanie testów wymusza przemyślenie wyzwań związanych z ryzykiem, harmonogramem, zasobami (ludzie, narzędzia, koszty), co pozwala lepiej przygotować się do realizacji celów testowych.
- Umożliwia zdefiniowanie zakresu i potrzeb testowych już na wczesnym etapie cyklu projektu, co pomaga w unikaniu późniejszych problemów.
Co zazwyczaj zawiera plan testów?
- Kontekst (zakres, cele testów, ograniczenia, podstawa testów),
- Założenia i ograniczenia (assumptions & constraints),
- Interesariusze (role, odpowiedzialność, znaczenie dla testów, potrzeby rekrutacji i szkolenia),
- Komunikacja (częstotliwość, formy raportów, wzory dokumentów),
- Rejestr ryzyka (ryzyka produktowe, ryzyka projektowe),
- Podejście testowe (poziomy, typy, techniki, produkty pracy, wymagania dot. danych, środowisko, odstępstwa od strategii, itp.),
- Budżet i harmonogram (zarys kosztów, harmonogram działań testowych).
Jakie dwa rodzaje planowania zazwyczaj występują w iteracyjnych modelach cyklu życia oprogramowania?
- Planowanie wydań (release planning),
- Planowanie iteracji (iteration planning).
Na czym polega planowanie wydań?
- Określa perspektywę (co i kiedy zostanie wydane), definiuje i aktualizuje backlog produktu.
- Może obejmować rozbijanie dużych user stories na mniejsze.
- Ma na celu ustalenie, w której iteracji zostaną zrealizowane poszczególne funkcje, aby dotrzymać terminu wydania.
Jak testerzy uczestniczą w planowaniu wydań?
- Piszą/oceniają historie użytkownika (user stories) i ich kryteria akceptacji pod kątem testowalności,
- Pomagają w analizie ryzyka (ryzyka projektowe i jakościowe),
- Szacują wysiłek potrzebny na testy,
- Ustalają podejście testowe i planują harmonogram testów w zakresie danego wydania.
Na czym polega planowanie iteracji?
Dotyczy końca pojedynczej iteracji i zadań zawartych w backlogu tej iteracji.
Testerzy uczestniczą m.in. w:
* Szczegółowej analizie ryzyka związanej z user stories,
* Sprawdzaniu testowalności user stories,
* Rozbijaniu user stories na zadania (w tym zadania testowe),
* Szacowaniu wysiłku testowego,
* Identyfikowaniu i doprecyzowaniu aspektów funkcjonalnych i niefunkcjonalnych.
Czym jest kryterium wejścia (entry criteria) i co najczęściej zawiera?
Kryteria wejścia określają warunki wstępne do podjęcia danej czynności (np. fazy testów).
Zwykle obejmują:
* Dostępność zasobów (ludzie, narzędzia, środowiska, dane, budżet, czas),
* Dostępność elementów testowych (podstawa testów, wymagania, user stories, przypadki testowe),
* Wstępny poziom jakości elementu testowego (np. przejście testów dymnych).
Często nazywane także Definition of Ready w metodykach zwinnych.
Czym jest kryterium wyjścia (exit criteria) i co zazwyczaj zawiera?
Kryteria wyjścia to cele, które muszą być spełnione, aby uznać daną czynność (np. testowanie) za zakończoną.
Typowo uwzględniają:
* Miary dokładności (coverage level, liczba niewyjaśnionych defektów, gęstość defektów, liczba niezdanych testów),
* Kryteria ukończenia (wszystkie planowane testy wykonano, zgłoszono defekty, przeprowadzono regresję).
Może uwzględniać też kwestie budżetu/czasu i świadomość ryzyka, jeśli interesariusze decydują o wydaniu produktu pomimo pewnych braków.
Często określane jako Definition of Done.
Wraz ze wzrostem wielkości zadania wzrasta ryzyko błędnych szacowań. Jak poprawić dokładność szacowania w dużym projekcie testowym?
- Rozbić zadanie testowe na mniejsze części, które da się precyzyjniej oszacować.
- Uświadomić interesariuszy, że szacowanie obarczone jest założeniami i niepewnością.
- Stosować przeglądy i aktualizować szacunki, gdy pojawią się nowe informacje.
Na czym polega szacowanie oparte na wskaźnikach (ratios)?
- Jest to metoda bazująca na metrykach z poprzednich projektów, pozwalająca określić standardowe wskaźniki (np. stosunek czasu developmentu do czasu testów).
- Wskaźniki organizacji są dobrym źródłem do estymacji (np. w poprzednim projekcie: 3:2 między dev a test).
- Przykład: jeśli obecny projekt zakłada 600 roboczodni developmentu, przy wskaźniku 3:2 szacujemy 400 roboczodni testów.
Jak działa metoda szacowania przez ekstrapolację (Extrapolation)?
- Kolejna metryczna technika, w której tak wcześnie, jak to możliwe, zbiera się pomiary wysiłku w bieżącym projekcie.
- Na podstawie tych obserwacji szacuje się pozostały wysiłek, ekstrapolując dane (często z modelem matematycznym).
- W iteracyjnym SDLC zespół deweloperski i testerski cyklicznie realizują pełen cykl – można ekstrapolować wysiłek testowy w kolejnych iteracjach na podstawie wyników poprzednich.
Na czym polega technika szacowania Wideband Delphi?
- Jest to iteracyjne, oparte na ekspertach podejście. Każdy ekspert dokonuje samodzielnego oszacowania, a następnie wyniki są zbierane.
- Eksperci dyskutują rozbieżności wykraczające poza ustalone granice i ponownie szacują, aż osiągną konsensus.
- Planning Poker (Poker Planistyczny) to popularna wariacja tej metody stosowana w Agile.
Jak działa metoda trzech punktów (Three-Point Estimation)?
- Eksperci przygotowują 3 estymacje:
1. optymistyczną (a),
2. najbardziej prawdopodobną (m),
3. pesymistyczną (b). - Końcowy szacunek (E) jest średnią ważoną tych wartości, np. wg wzoru (a + 4*m + b) / 6.
- Metoda ta umożliwia także obliczenie odchylenia, np. SD = (b – a) / 6.
Jakie trzy strategie priorytetyzacji przypadków testowych są najczęściej stosowane?
- Oparta na ryzyku (risk-based): najpierw testuje się przypadki pokrywające największe ryzyka,
-
Oparta na pokryciu (coverage-based): najpierw wykonuje się przypadki przynoszące najwyższe pokrycie,
* Wariant: dodatkowe pokrycie – każdy kolejn y przypadek wnosi najwięcej nowego pokrycia. - Oparta na wymaganiach (requirements-based): kolejność testów odpowiada priorytetom wymagań ustalonym przez interesariuszy.
Czemu testy nie zawsze są uruchamiane wg priorytetów?
Choć teoretycznie powinna decydować wyłącznie kolejność priorytetów, w praktyce inne czynniki mogą mieć znaczenie:
* Zależności między funkcjami lub przypadkami testowymi,
* Dostępność środowisk czy danych testowych,
* Dostępność kluczowych osób (np. testerów, ekspertów) lub okno czasowe na test danego obszaru.
Wyjaśnij znaczenie modelu piramidy testów.
Piramida testów to wizualizacja poziomów (lub warstw) testów i ich zasięgu:
* Wyższa część piramidy (testy systemowe, akceptacyjne) – zwykle mniejsza ilość testów, ale szerszy kontekst funkcjonalny.
* Niższa część piramidy (testy modułowe) – większa ilość testów, ale węższy zakres (np. sprawdzanie klasy, funkcji, instrukcji w kodzie).
Model sugeruje, że najwięcej testów powinno być na niższych poziomach (szybsze i tańsze), a mniej na wyższych (wolniejsze, droższe).
Jaka jest funkcja i cel modelu „kwadrantów testowych”?
- Model grupuje testy wg typów, celów i zakresu.
- Wspiera zarządzanie testami, pokazując, które testy i narzędzia są potrzebne w różnych fazach (od wczesnych testów automatycznych po testy eksploracyjne, UAT itd.).
- Ułatwia rozróżnienie i rozmieszczenie testów w czterech kategoriach (np. rozwój sterowany testami, testy użyteczności, testy niefunkcjonalne itp.).
Jak zdefiniowane są kwadranty w modelu kwadrantów testowania?
- W modelu testy mogą być skierowane do biznesu (business-facing) albo skierowane do technologii (technology-facing),
- Mogą też wspierać zespół rozwijający oprogramowanie bądź oceniać wytworzony produkt.
- Kombinacja tych osi daje cztery kwadranty, np. Q1 (techniczne, wspierające), Q2 (biznesowe, wspierające), Q3 (biznesowe, oceniające), Q4 (techniczne, oceniające).
Jakie są kwadranty testowe w modelu kwadrantów?
- Q1 (Zorientowany na rozwój, techniczny, wspierający): obejmuje testy modułowe, testy integracyjne na poziomie komponentów, testy automatyczne,
- Q2 (Zorientowany na rozwój, biznesowy, wspierający): obejmuje np. testy funkcjonalne na poziomie systemu, prototypowanie, warsztaty z użytkownikami, testy eksploracyjne w trakcie,
- Q3 (Biznesowy, oceniający): skupia się na doświadczeniu użytkownika, testach użyteczności, testach akceptacyjnych, ocenie jakości z punktu widzenia końcowego odbiorcy,
- Q4 (Techniczny, oceniający): obejmuje testy wydajności, bezpieczeństwa, niefunkcjonalne, często zaawansowane narzędzia i analizy.
