Testowanie Agile: metodologia i cykl życia

Co to jest testowanie zwinne?

Testowanie zwinne to praktyka testowania zgodna z zasadami i zasadami zwinnego wytwarzania oprogramowania. W przeciwieństwie do metody Waterfall, testowanie zwinne rozpoczyna się na początku projektu i jest realizowane nieprzerwanie wraz z rozwojem oprogramowania. Nie jest ono sekwencyjne – wykonywane dopiero po fazie kodowania – lecz wplecione w każdą iterację, dzięki czemu informacje zwrotne docierają do zespołu w momencie pojawienia się defektów.

Zasady zwinnego testowania

Podstawowe zasady zwinnego testowania to:

• Działające oprogramowanie jest podstawową miarą postępu.
• Najlepsze wyniki osiągają zespoły samoorganizujące się.
• Wczesne i ciągłe dostarczanie wartościowego oprogramowania jest najwyższym priorytetem.
• Programiści i testerzy współpracują codziennie w ramach projektu.
• Zwinność można zwiększyć poprzez ciągłe udoskonalanie techniczne i dobre projektowanie.
• Ciągła informacja zwrotna gwarantuje, że produkt końcowy spełni oczekiwania biznesowe.
• Wdrażanie jest testowane w trakcie wdrażania, co skraca całkowity czas rozwoju.
• Proces testowania odbywa się w stałym, zrównoważonym tempie.
• Zespoły robią przerwy na refleksję i regularnie dokonują zmian, aby stać się bardziej efektywnymi.
• Najlepsze architektury, wymagania i projekty powstają w wyniku pracy samodzielnie organizujących się zespołów.
• Rozmowa twarzą w twarz jest najbardziej efektywną i skuteczną formą komunikacji w zespole.

Stosowane łącznie zasady te zwiększają wydajność oprogramowania i skracają drogę od pomysłu do działającej funkcji.

Cykl życia testowania zwinnego

Cykl testowania zwinnego składa się z pięciu faz, jak pokazano poniżej.

Fazy ​​są następujące:

• Faza 1: Ocena wpływu. Zbierz informacje od interesariuszy i użytkowników. Nazywa się to również fazą informacji zwrotnej, ponieważ pomaga inżynierom testującym wyznaczać cele na kolejny cykl życia.
• Faza 2: Planowanie testów Agile. Wszystkie strony zainteresowane spotykają się, aby zaplanować harmonogram testów, zakres i produkty końcowe.
• Faza 3: Gotowość do wydania. Revprzejrzyj zaimplementowane funkcje i zdecyduj, które z nich są gotowe do wdrożenia, a które należy wycofać z fazy rozwoju.
• Faza 4: Codzienne Scrumy. Poranne spotkanie, na którym zespół omawia stan testów i wyznacza cele na dany dzień.
• Faza 5: Sprawdź zwinność Revtj. Tygodniowe spotkania z interesariuszami w celu oceny postępów w realizacji celów i dostosowania strategii.

Zwinny plan testów

An zwinny plan testów opisuje rodzaje testów przeprowadzanych w iteracji, potrzebne dane i infrastrukturę, środowiska testoweoraz wyniki testów. W przeciwieństwie do modelu kaskadowego, zwinny plan testów jest tworzony i aktualizowany dla każdego wydania. Typowy plan obejmuje:

• Zakres testowania.
• Testowana jest nowa funkcjonalność.
• Poziom lub rodzaj testowania oparty na złożoności funkcji.
• Testowanie obciążenia i wydajności.
• Rozważania dotyczące infrastruktury.
• Plan ryzyka i jego łagodzenia.
• Zasoby.
• Rezultaty i kamienie milowe.

Zwinne strategie testowania

Cykl testowania zwinnego obejmuje cztery strategiczne etapy.

iteracja 0

W pierwszym etapie wykonujesz wstępne zadania konfiguracyjne. Obejmują one identyfikację osób do testów, instalację narzędzi testowych oraz planowanie zasobów, takich jak laboratorium do testów użyteczności. Cele iteracji 0 to:

• Stwórz biznesplan dla projektu.
• Określ warunki brzegowe i zakres projektu.
• Naszkicuj najważniejsze wymagania i przypadki użycia, które będą decydować o kompromisach w projektowaniu.
• Naszkicuj jedną lub więcej proponowanych architektur.
• Identyfikuj zagrożenia.
• Oszacowanie kosztów i przygotowanie wstępnego planu projektu.

Iteracje konstrukcyjne

Drugą fazą testowania zwinnego są iteracje konstrukcyjne, podczas których przeprowadzana jest większość testów. Ta faza to zestaw iteracji, podczas których rozwiązanie jest stopniowo budowane. W każdej iteracji zespół stosuje hybrydę praktyk z XP, Scrum, modelowania zwinnego i danych zwinnych.

Zespoły stosują praktykę priorytetyzacji wymagań: w każdej iteracji wybierają najważniejsze elementy z backlogu i je wdrażają. Iteracje konstrukcyjne dzielą się na dwa uzupełniające się rodzaje testów:

• Badania potwierdzające Weryfikuje, czy system spełnia oczekiwania interesariuszy. Jest to wykonywane przez sam zespół.
• Badania śledcze Wyszukuje problemy, które mogły zostać pominięte podczas testów potwierdzających. Testerzy zgłaszają potencjalne problemy jako historie defektów. Testowanie śledcze obejmuje testy integracyjne, obciążeniowe i bezpieczeństwa.

Badania potwierdzające mają dwa kolejne aspekty — testowanie deweloperów oraz zwinne testy akceptacyjne — i oba są zautomatyzowane, aby umożliwić ciągłe testowanie regresji przez cały cykl życia. Testowanie potwierdzające to zwinny odpowiednik testowania zgodnie ze specyfikacją.

Zwinne testowanie akceptacyjne łączy tradycyjne testy funkcjonalne i akceptacyjne, ponieważ zespół programistów i interesariusze wykonują je wspólnie. Testowanie programistyczne łączy tradycyjne testy jednostkowe z testowaniem integracji usług i weryfikuje zarówno kod aplikacji, jak i schemat bazy danych.

Wydanie, gra końcowa lub faza przejściowa

Celem fazy wydania jest pomyślne wdrożenie systemu do produkcji. Działania obejmują szkolenie użytkowników końcowych, personelu pomocniczego i zespołów operacyjnych; marketing wydania produktu; ćwiczenia z tworzenia i przywracania kopii zapasowych; oraz finalizację dokumentacji systemu i użytkownika.

Ostatni etap testowania zwinnego obejmuje pełne testy systemowe i testy akceptacyjne. Aby ukończyć projekt bez przeszkód, produkt musi zostać rygorystycznie przetestowany podczas iteracji konstrukcyjnych. W fazie końcowej testerzy koncentrują się na rozwiązywaniu defektów zgłoszonych wcześniej w cyklu.

Produkcja

Po etapie wprowadzenia na rynek produkt trafia do produkcji, gdzie jest monitorowany pod kątem zachowania na żywo, a wszelkie wykryte problemy są uwzględniane w kolejnym cyklu planowania.

Kwadranty zwinnego testowania

Kwadranty testowania zwinnego dzielą cały proces na cztery obszary i pomagają zespołom zrozumieć, jak przeprowadzane jest testowanie zwinne.

Kwadrant Agile I

Kwadrant I koncentruje się na wewnętrznej jakości kodu, wykorzystując testy oparte na technologii, które wspierają zespół:

• Testy jednostkowe.
• Testy komponentów.

Zwinny Kwadrant II

Kwadrant II zawiera testy zorientowane na biznes, które wspierają zespół i koncentrują się na wymaganiach. Typowe zadania w tym kwadrancie obejmują:

• Testowanie przykładów możliwych scenariuszy i przepływów pracy.
• Testowanie artefaktów doświadczenia użytkownika, takich jak prototypy.
• Testowanie parowe.

Zwinna ćwiartka III

Kwadrant III zapewnia informacje zwrotne dla Kwadrantów I i II. Przypadki testowe stanowią tu często podstawę automatyzacji, a wielokrotne przeglądy iteracyjne budują zaufanie do produktu. Typowe prace obejmują:

• Test użyteczności.
• Testowanie eksploracyjne.
• Testowanie par z klientami.
• Wspólne testowanie.
• Testowanie akceptacji użytkownika.

Zwinny kwadrant IV

Kwadrant IV koncentruje się na wymaganiach niefunkcjonalnych, takich jak wydajność, bezpieczeństwo i stabilność. Ten kwadrant zapewnia, że ​​aplikacja spełnia oczekiwane parametry niefunkcjonalne. Typowe zadania obejmują:

• Testy niefunkcjonalne, takie jak testy obciążeniowe i wydajnościowe.
• Testy bezpieczeństwa obejmujące uwierzytelnianie i próby włamań.
• Testowanie infrastruktury.
• Testowanie migracji danych.
• Testowanie skalowalności.
• Testowanie obciążeniowe.

Wyzwania związane z zapewnianiem jakości w kontekście zwinnego rozwoju oprogramowania

Zwinne dostarczanie usług przynosi realne korzyści, ale stwarza również nowe wyzwania dla zespołów ds. zapewnienia jakości:

• Dokumentacja ma niższy priorytet, więc ryzyko wystąpienia błędu rośnie, a presja przenosi się na zespół ds. zapewnienia jakości.
• Nowe funkcje pojawiają się szybko, pozostawiając testerom mniej czasu na sprawdzenie, czy najnowsze funkcje odpowiadają wymaganiom i zamierzeniom biznesowym.
• Testerzy często pełnią rolę półprogramistów.
• Cykle wykonywania testów są mocno skompresowane.
• Czasu na przygotowanie planu testów jest niewiele.
• Budżety na testy regresyjne stają się napięte.
• Testerzy przestają być strażnikami jakości i stają się partnerami w zapewnianiu jakości.
• Częste zmiany wymagań są nieodłączną cechą metodyki Agile, co stanowi jedno z największych wyzwań w zapewnianiu jakości.

Ryzyko automatyzacji w procesie Agile

Automatyzacja jest niezbędna w metodykach Agile, ale niesie ze sobą ryzyko, którym zespoły muszą aktywnie zarządzać:

• Zautomatyzowane testy interfejsu użytkownika oferują wysoką pewność, ale są powolne, niestabilne i kosztowne w utrzymaniu. Wzrost produktywności pojawia się tylko wtedy, gdy testerzy wiedzą, jak projektować dobre testy.
• Niewiarygodne testy stanowią poważny problem. Naprawa niestabilnych testów i eliminacja fałszywie dodatnich wyników musi pozostać priorytetem.
• Testy automatyczne uruchamiane ręcznie, a nie za pośrednictwem CI, stwarzają ryzyko niezauważalnego działania i generowania nieaktualnych wyników.
• Automatyzacja nie zastępuje eksploracyjnych testów manualnych. Aby osiągnąć oczekiwaną jakość, konieczne jest połączenie różnych typów i poziomów testów.
• Narzędzia do przechwytywania i odtwarzania sprzyjają tworzeniu skryptów opartych na interfejsie użytkownika, które są kruche i trudne w utrzymaniu. Testy przechowywane poza kontrolą wersji wprowadzają niepotrzebną złożoność.
• Źle zaplanowana automatyzacja, podejmowana w celu „oszczędzania czasu”, często kończy się całkowitą porażką.
• Procedury konfiguracji i demontażu testów łatwo przeoczyć podczas automatyzacji, podczas gdy testowanie ręczne radzi sobie z nimi naturalnie.
• Wskaźniki produktywności, takie jak „liczba przypadków testowych na dzień”, mogą wprowadzać zespoły w błąd i powodować wykonywanie bezużytecznych testów.
• Zespół zajmujący się automatyzacją musi składać się z efektywnych konsultantów — przystępnych, chętnych do współpracy i pomysłowych — w przeciwnym razie przedsięwzięcie zakończy się niepowodzeniem.
• Rozwiązania wymagające intensywnej, ciągłej konserwacji mogą okazać się nieopłacalne w stosunku do wartości, jaką oferują.
• Testy automatyczne mogą nie zapewniać wystarczającej wiedzy specjalistycznej, aby dostarczać skuteczne rozwiązania.
• Skuteczna automatyzacja może sprawić, że zabraknie ważnych problemów do rozwiązania i pracownicy skupią się na mniej wartościowych zadaniach.

Najlepsze praktyki efektywnego testowania Agile

Poniższe praktyki sprawiają, że testowanie zwinne jest szybkie, niezawodne i wartościowe dla zespołu:

• Shift lewy: Rozpocznij testowanie w momencie spełnienia wymagań, a nie na końcu iteracji.
• Współpracuj z programistami: wspólnie przejrzyj kryteria akceptacji, aby wady były projektowane, a nie kodowane.
• Automatyzacja warstw: zbuduj zdrową piramidę testów jednostkowych, usługowych i interfejsu użytkownika.
• Zachowaj niezależność testów: wyizoluj każdy test, tak aby ewentualne niepowodzenia wskazywały na jedną przyczynę.
• Track testów łamliwych: poddawaj kwarantannie i szybko naprawiaj niestabilne testy, aby zapobiec utracie zaufania do pakietu.
• Wykorzystaj analizę wspomaganą sztuczną inteligencją: pozwól narzędziom oznaczać testy, które uległy uszkodzeniu, grupować błędy i sugerować stabilne lokalizatory po każdym scaleniu.

FAQ