2.1 Testowanie w cyklu wytwarzania oprogramowania Flashcards
W jaki sposób wybór modelu cyklu życia oprogramowania (SDLC) wpływa na testowanie?
- Determinuje zakres i kolejność czynności testowych.
- Określa poziom szczegółowości dokumentacji testowej.
- Wpływa na dobór technik i podejścia do testowania.
- Może decydować o zakresie automatyzacji testów.
- Definiuje rolę i odpowiedzialności testera w zespole.
Jak modele sekwencyjne (np. Waterfall) wpływają na testowanie?
- We wczesnych fazach testerzy uczestniczą w przeglądach wymagań, analizie testowej i projektowaniu testów.
- Testy dynamiczne (z uruchamianiem kodu) mogą rozpocząć się dopiero później w cyklu, gdy dostępny jest już działający kod.
Jak modele iteracyjne (np. Agile) wpływają na testowanie?
- Każda iteracja dostarcza działający prototyp lub przyrost produktu, więc testowanie statyczne i dynamiczne może być przeprowadzane na wszystkich poziomach testów w każdej iteracji.
- Częste wydania oznaczają konieczność szybkiej informacji zwrotnej oraz intensywnych testów regresji.
Jak model Agile w SDLC wpływa na testowanie?
Zakładamy, że zmiany mogą następować przez cały projekt, stąd preferuje się:
- lekką dokumentację,
- szeroką automatyzację testów regresji,
- testy manualne oparte na technikach opartych na doświadczeniu.
Jakie dobre praktyki testowe są zalecane niezależnie od wybranego modelu SDLC?
- Dla każdej aktywności deweloperskiej powinna istnieć odpowiadająca jej aktywność testowa.
- Różne poziomy testów mają odrębne cele i powinny się uzupełniać (a nie dublować).
- Analiza i projektowanie testów na danym poziomie powinny zaczynać się już w fazie deweloperskiej odpowiadającej temu poziomowi.
- Testerzy biorą udział w przeglądach produktów pracy (shift-left) tak wcześnie, jak to możliwe (np. gdy dostępne są wstępne wersje specyfikacji).
Na czym polega podejście Test-Driven Development (TDD)?
- Kodowanie jest kierowane przez przypadki testowe (zamiast rozległego projektowania z góry).
- Najpierw pisze się testy, a dopiero potem implementuje się kod, by te testy przechodziły. Oba elementy są następnie refaktoryzowane w miarę potrzeb.
Opisz podejście Acceptance-Test Driven Development (ATDD).
- Tworzy się testy w oparciu o kryteria akceptacji, jako część procesu projektowania systemu.
- Poza tym jest bardzo zbliżone do TDD (najpierw testy, potem implementacja).
Opisz podejście Behavior-Driven Development (BDD).
- Określa pożądane zachowanie aplikacji w postaci przypadków testowych pisanych w prostej, zrozumiałej dla interesariuszy formie (najczęściej w formacie Given / When / Then).
- Testy te są następnie (zwykle automatycznie) tłumaczone na testy wykonywalne.
Czym jest DevOps?
- To podejście organizacyjne, które tworzy synergię pomiędzy zespołami deweloperskimi i operacyjnymi w celu osiągania wspólnych celów.
- Testowanie jest w tym ujęciu częścią strony deweloperskiej, choć często współpracuje z operacjami.
Jakie korzyści z DevOps można wymienić z perspektywy testowania?
- Szybka informacja zwrotna dotycząca jakości kodu.
- Zachęcanie deweloperów do tworzenia wysokiej jakości kodu, wraz z testami komponentów (jednostkowych) i analizą statyczną.
- Promowanie zautomatyzowanych procesów (np. CI/CD).
- Lepszy wgląd w aspekty niefunkcjonalne, takie jak wydajność czy niezawodność.
- Zmniejszenie potrzeby powtarzania testów manualnych dzięki automatyzacji w pipeline’ie ciągłego dostarczania.
- Mniejsze ryzyko regresji dzięki szerokiemu zakresowi zautomatyzowanych testów regresyjnych.
Jakie trzy ryzyka lub wyzwania wiążą się z DevOps?
- Trzeba zdefiniować i utrzymać pipeline DevOps (proces ciągłego dostarczania).
- Narzędzia CI/CD muszą zostać wprowadzone i stale aktualizowane.
- Automatyzacja testów wymaga dodatkowych zasobów i bywa trudna do utrzymania, zwłaszcza na dłuższą metę.
Co oznacza podejście shift-left?
Testowanie należy rozpocząć wcześniej w cyklu wytwarzania oprogramowania (SDLC), zamiast czekać, aż kod zostanie w pełni zaimplementowany lub zintegrowany.
Opisz dobre praktyki przy podejściu shift-left.
- Przeglądanie specyfikacji z perspektywy testów (wcześnie wykryte nieścisłości).
- Pisanie przypadków testowych zanim powstanie kod i testowanie na bieżąco wraz z implementacją.
- Wykorzystywanie ciągłej integracji (CI) i ciągłego dostarczania (CD) do szybkiej informacji zwrotnej.
- Wykonywanie analizy statycznej przed testami dynamicznymi (często z użyciem narzędzi automatycznych).
- Rozpoczynanie testów niefunkcjonalnych już na poziomie komponentów, a nie odkładanie ich na później.
Jak podejście shift-left wpływa na wysiłek i koszty?
Wymaga dodatkowego wysiłku i kosztów na początku projektu, ale pozwala zaoszczędzić czas i pieniądze w dalszej perspektywie (mniej poprawek w późnych fazach).
O czym rozmawia się podczas Retrospektywy?
- Co się udało i warto to zachować?
- Co poszło źle lub mogłoby być lepsze?
- Co robić inaczej w przyszłych iteracjach czy projektach?
W jakim raporcie są zapisywane wyniki Retrospektywy?
Zwykle w raporcie z retrospektywy (Retrospective Report) lub w innym dokumencie podsumowującym ustalenia dla zespołu (np. w backlogu usprawnień, notatkach z retrospektywy itp.).
Jakie są korzyści z Retrospektyw?
- Zwiększenie efektywności i wydajności testów.
- Wyższa jakość relacji w zespole (lepsza komunikacja).
- Uczenie się na błędach (lepsze podejście w kolejnych iteracjach).
- Poprawa jakości samego procesu testowego.
- Wzmocnienie współpracy między deweloperami a testerami.