Co to jest testowanie zwinne? Proces i cykl życia
Co to jest testowanie zwinne?
Testowanie zwinne to praktyka testowania, która kieruje się zasadami i zasadami zwinnego tworzenia oprogramowania. W przeciwieństwie do metody Waterfall, testowanie zwinne można rozpocząć na początku projektu z ciągłą integracją pomiędzy rozwojem i testowaniem. Metodologia testowania Agile nie jest sekwencyjna (w tym sensie, że jest wykonywana dopiero po fazie kodowania), ale ciągła.
Zasady zwinnego testowania
Oto podstawowe zasady zwinnego testowania:
- W tym modelu testowania Agile działające oprogramowanie jest główną miarą postępu.
- Najlepszy efekt mogą osiągnąć samoorganizujące się zespoły.
- Naszym najwyższym priorytetem jest wczesne i ciągłe dostarczanie wartościowego oprogramowania.
- Twórcy oprogramowania muszą działać, aby gromadzić się codziennie przez cały czas trwania projektu.
- Zwiększanie zwinności poprzez ciągłe doskonalenie techniczne i dobry projekt.
- Zwinne testowanie zapewnia, że produkt końcowy spełnia oczekiwania firmy, zapewniając ciągłą informację zwrotną.
- W procesie Agile Test musimy przeprowadzić proces testowania w trakcie wdrożenia, co skraca czas rozwoju.
- Proces testowania w Agile powinien pracować w stałym tempie rozwoju
- Regularnie zastanawiaj się, jak stać się bardziej skutecznym.
- Najlepsze architektury, wymagania i projekty powstają w wyniku pracy samoorganizujących się zespołów.
- Za każdym razem, gdy zespół się spotyka, dokonuje przeglądu i dostosowuje swoje zachowanie, aby stać się bardziej skutecznym.
- Rozmowa twarzą w twarz z zespołem programistów jest najskuteczniejszą i wydajniejszą metodą przekazywania informacji w zespole.
Testowanie zwinne obejmuje różne zasady, które pomagają nam zwiększać produktywność Oprogramowania.
Cykl życia testowania zwinnego
Cykl życia testów zwinnych składa się z pięciu różnych faz, jak widać na poniższym obrazku:
Oto kroki testowania procesu Agile:
Faza 1: Ocena wpływu: W tej początkowej fazie zbieramy informacje od interesariuszy i użytkowników. Faza ta nazywana jest także fazą sprzężenia zwrotnego, ponieważ pomaga inżynierom testującym w ustaleniu celów na następny cykl życia.
Faza 2: Planowanie testów zwinnych: Jest to druga faza cyklu życia testów Agile, podczas której wszyscy interesariusze spotykają się, aby zaplanować harmonogram procesu testowania i produkty dostarczane.
Faza 3: Gotowość do wydania: Na tym etapie sprawdzamy, czy funkcje, które zostały opracowane/wdrożone, są gotowe do wdrożenia lub nie. Na tym etapie decyduje się również, który z nich powinien wrócić do poprzedniej fazy rozwoju.
Faza 4: Codzienne Scrumy: Ten etap obejmuje każde poranne spotkanie na stojąco, podczas którego można nadrobić zaległości w testowaniu i ustalić cel na cały dzień.
Faza 5: Sprawdź zwinność Revwidok: Ostatnią fazą cyklu życia Agile jest Agility Revie Spotkanie. Obejmuje cotygodniowe spotkania z interesariuszami w celu regularnej oceny i oceny postępów w realizacji celów.
Zwinny plan testów
Zwinny plan testów obejmuje typy testów przeprowadzanych w tej iteracji, takie jak wymagania dotyczące danych testowych, infrastruktura, środowiska testowei wyniki testów. W przeciwieństwie do modelu kaskadowego, w modelu zwinnym plan testów jest pisany i aktualizowany dla każdego wydania. Typowe plany testów w Agile obejmują
- Zakres testowania
- Nowe funkcjonalności, które są w fazie testowania
- Poziom lub rodzaje testów w oparciu o złożoność funkcji
- Testowanie obciążenia i wydajności
- Uwzględnienie infrastruktury
- Plan łagodzenia lub ryzyka
- Zasoby
- Produkty dostarczane i kamienie milowe
Zwinne strategie testowania
Cykl życia testów zwinnych obejmuje cztery etapy
iteracja 0
Podczas pierwszego etapu lub iteracji 0 wykonujesz zadania konfiguracji początkowej. Obejmuje to identyfikację osób do testowania, instalowanie narzędzi testowych, planowanie zasobów (laboratorium testowania użyteczności) itp. Następujące kroki są ustawione do osiągnięcia w iteracji 0
- Stworzenie uzasadnienia biznesowego projektu
- Ustalenie warunków brzegowych i zakresu projektu
- Nakreśl kluczowe wymagania i przypadki użycia, które będą stanowić podstawę kompromisów projektowych
- Opisz jedną lub więcej kandydackich architektur
- Identyfikacja ryzyka
- Wycena kosztów i przygotowanie projektu wstępnego
Iteracje konstrukcyjne
Drugą fazą zwinnej metodologii testowania są iteracje konstrukcyjne. Większość testów odbywa się w tej fazie. Fazę tę obserwuje się jako zbiór iteracji prowadzących do zbudowania przyrostu rozwiązania. W tym celu w każdej iteracji zespół realizuje hybryda praktyk z XP, Scrum, modelowania Agile i zwinnych danych i tak dalej.
Podczas iteracji konstruowania zwinny zespół postępuje zgodnie z praktyką dotyczącą wymagań priorytetowych: przy każdej iteracji pobierają najbardziej istotne wymagania pozostałe ze stosu elementów pracy i wdrażają je.
Iterację konstrukcji można podzielić na dwie części: testy potwierdzające i testy badawcze. Koncentraty do testów potwierdzających na sprawdzeniu, czy system spełnia zamierzenia interesariuszy opisane dotychczas zespołowi i jest realizowany przez zespół. Podczas gdy testy dochodzeniowe wykrywają problem, który zespół potwierdzający pominął lub zignorował. W testach śledczych tester określa potencjalne problemy w formie historii defektów. Testowanie śledcze zajmuje się typowymi zagadnieniami, takimi jak testowanie integracyjne, testowanie obciążenia/stresu i testowanie bezpieczeństwa.
Powtórzę: testy potwierdzające mają dwa aspekty testowanie deweloperów oraz zwinne testy akceptacyjne. Oboje są zautomatyzowane, aby umożliwić ciągłe testowanie regresji w całym cyklu życia. Testowanie potwierdzające jest zwinnym odpowiednikiem testowania zgodnie ze specyfikacją.
Zwinne testy akceptacyjne to połączenie tradycyjnych testów funkcjonalnych i tradycyjnych testów akceptacyjnych, w których uczestniczy zespół programistów i interesariusze. Testowanie programistyczne jest połączeniem tradycyjnych testów jednostkowych i tradycyjnych testów integracji usług. Testowanie programistyczne weryfikuje zarówno kod aplikacji, jak i schemat bazy danych.
Wydaj grę końcową lub fazę przejściową
Celem „Release, End Game” jest pomyślne wdrożenie systemu do produkcji. Działania w tej fazie obejmują szkolenie użytkowników końcowych, osób wspierających i operacyjnych. Obejmuje ona również marketing wydania produktu, tworzenie kopii zapasowych i przywracanie, finalizowanie dokumentacji systemu i użytkownika.
Ostatni etap testowania metodologii zwinnej obejmuje pełne testowanie systemu i testy akceptacyjne. Aby zakończyć końcowy etap testów bez żadnych przeszkód, należy przetestować produkt bardziej rygorystycznie, gdy znajduje się on w iteracjach konstrukcyjnych. Podczas gry końcowej testerzy będą pracować nad historiami defektów.
Produkcja
Po etapie wypuszczenia produkt przejdzie do etapu produkcji.
Kwadranty zwinnego testowania
Kwadranty testowania zwinnego dzielą cały proces na cztery kwadranty i pomagają zrozumieć, w jaki sposób przeprowadzane jest testowanie zwinne.
Kwadrant Agile I
W tej ćwiartce główny nacisk położony jest na jakość kodu wewnętrznego, która składa się z przypadków testowych opartych na technologii i wdrożonych w celu wsparcia zespołu, obejmuje
- Testy jednostkowe
- Testy komponentów
Zwinny Kwadrant II
Zawiera przypadki testowe o charakterze biznesowym i wdrażane w celu wsparcia zespołu. Ten kwadrant skupia się na wymaganiach. Rodzaj testu przeprowadzanego w tej fazie to
- Testowanie przykładów możliwych scenariuszy i przepływów pracy
- Testowanie doświadczeń użytkowników, takich jak prototypy
- Testowanie par
Zwinna ćwiartka III
Kwadrant ten dostarcza informacji zwrotnej do ćwiartek pierwszej i drugiej. Przypadki testowe mogą być podstawą do przeprowadzenia testów automatycznych. W tym kwadrancie przeprowadza się wiele rund przeglądów iteracyjnych, co buduje zaufanie do produktu. Rodzaj testów przeprowadzanych w tym kwadrancie to:
- Test użyteczności
- Testowanie eksploracyjne
- Testowanie w parach z klientami
- Wspólne testowanie
- Testy akceptacji użytkownika
Zwinny kwadrant IV
Kwadrant ten koncentruje się na wymaganiach niefunkcjonalnych, takich jak wydajność, bezpieczeństwo, stabilność itp. Za pomocą tego kwadrantu aplikacja jest tworzona w celu dostarczenia niefunkcjonalnych cech i oczekiwanej wartości.
- Testy niefunkcjonalne, takie jak testy obciążeniowe i wydajnościowe
- Testowanie bezpieczeństwa w odniesieniu do Uwierzytelnianie i hakowanie
- Testowanie infrastruktury
- Testowanie migracji danych
- Testowanie skalowalności
- Testowanie obciążenia
Wyzwania kontroli jakości związane ze zwinnym tworzeniem oprogramowania
- Szanse na błąd są większe w przypadku zwinności, ponieważ dokumentacja ma mniejszy priorytet, co ostatecznie wywiera większą presję na zespół ds. kontroli jakości
- Nowe funkcje są wprowadzane szybko, co skraca czas dostępny zespołom testowym na określenie, czy najnowsze funkcje są zgodne z wymaganiami i czy rzeczywiście odpowiadają potrzebom biznesowym
- Od testerów często wymaga się pełnienia roli półprogramisty
- Cykle wykonywania testów są bardzo skompresowane
- Bardzo mniej czasu na przygotowanie planu testów
- W przypadku testów regresyjnych będą miały minimalny czas
- Zmiana roli ze strażnika jakości na partnera w zakresie jakości
- Zmiany i aktualizacje wymagań są nieodłącznym elementem metody zwinnej i stają się największym wyzwaniem dla kontroli jakości
Ryzyko automatyzacji w procesie zwinnym
- Zautomatyzowany interfejs użytkownika zapewnia wysoki poziom pewności, ale jest powolny w wykonaniu, delikatny w utrzymaniu i kosztowny w budowie. Automatyzacja może nie poprawić znacząco produktywności testów, jeśli testerzy nie wiedzą, jak testować
- Niewiarygodne testy są głównym problemem w testach automatycznych. Naprawianie nieudanych testów i rozwiązywanie problemów związanych z testami kruchymi powinno być najwyższym priorytetem, aby uniknąć fałszywych alarmów
- Jeśli automatyczne testy są inicjowane ręcznie, a nie poprzez CI (ciągłą integrację), istnieje ryzyko, że nie będą one regularnie uruchamiane, co może spowodować niepowodzenie testów
- Testy automatyczne nie zastępują eksploracyjnych testów ręcznych. Aby uzyskać oczekiwaną jakość produktu, wymagana jest mieszanka rodzajów i poziomów testów
- Wiele dostępnych komercyjnie narzędzi automatyzacyjnych oferuje proste funkcje, takie jak automatyzacja przechwytywania i odtwarzania ręcznych przypadków testowych. Takie narzędzie zachęca do testowania za pośrednictwem interfejsu użytkownika i prowadzi do z natury kruchych i trudnych do utrzymania testów. Ponadto przechowywanie przypadków testowych poza systemem kontroli wersji tworzy niepotrzebną złożoność
- Aby zaoszczędzić czas, często plan testów automatycznych jest źle zaplanowany lub niezaplanowany, co skutkuje niepowodzeniem testu
- Procedury konfigurowania i usuwania testów są zwykle pomijane podczas automatyzacji testów, podczas gdy przeprowadzanie testów ręcznych, procedur konfigurowania i usuwania testów wydaje się płynne
- Wskaźniki produktywności, takie jak liczba przypadków testowych utworzonych lub wykonanych dziennie, mogą być bardzo mylące i prowadzić do dużych inwestycji w przeprowadzanie bezużytecznych testów
- Członkowie zespołu ds. zwinnej automatyzacji muszą być skutecznymi konsultantami: przystępnymi, współpracującymi i pomysłowymi, w przeciwnym razie system ten szybko zawiedzie
- Automatyzacja może proponować i dostarczać rozwiązania testowe, które wymagają zbyt dużo bieżącej konserwacji w stosunku do dostarczanej wartości
- Zautomatyzowanym testom może brakować wiedzy specjalistycznej potrzebnej do opracowania i dostarczenia skutecznych rozwiązań
- Zautomatyzowane testowanie może być tak skuteczne, że zabraknie ważnych problemów do rozwiązania i w ten sposób zamienią się w nieistotne problemy.
Podsumowanie
Zwinna metodologia testowania oprogramowania polega na testowaniu tak wcześnie, jak to możliwe cykl życia oprogramowania. Wymaga dużego zaangażowania klienta i testowania kodu, gdy tylko stanie się on dostępny. Kod powinien być na tyle stabilny, aby można go było poddać testom systemowym. Można przeprowadzić szeroko zakrojone testy regresyjne, aby upewnić się, że błędy zostały naprawione i przetestowane. Przede wszystkim komunikacja między zespołami zapewnia sukces w testowaniu modelu zwinnego!!!