Co to jest testowanie zwinne?
ZWINNE TESTOWANIE to praktyka testowa zgodna z regułami i zasadami zwinnego tworzenia oprogramowania. W przeciwieństwie do metody Waterfall, testowanie zwinne można rozpocząć na początku projektu z ciągłą integracją między programowaniem a testowaniem. Metodologia testów zwinnych nie jest sekwencyjna (w tym sensie, że jest wykonywana dopiero po fazie kodowania), ale ciągła.
W tym artykule omówimy
- Plan testów zwinnych.
- Strategie testowania zwinnego.
- Kwadrant testowania zwinnego.
- Wyzwania związane z zapewnianiem jakości przy zwinnym tworzeniu oprogramowania.
- Ryzyko automatyzacji w zwinnym procesie.
Plan testów zwinnych
Plan testów zwinnych obejmuje typy testów przeprowadzanych w ramach tej iteracji, takie jak wymagania dotyczące danych testowych, infrastruktura, środowiska testowe i wyniki testów. W przeciwieństwie do modelu kaskadowego, w modelu zwinnym plan testów jest zapisywany i aktualizowany dla każdej wersji. Typowe plany testów w Agile obejmują
- Zakres testowania
- Nowe funkcjonalności, które są w fazie testów
- Poziom lub typy testów w oparciu o złożoność funkcji
- Testowanie obciążenia i wydajności
- Uwzględnienie infrastruktury
- Plan łagodzenia lub ryzyka
- Zasoby
- Elementy dostarczane i kamienie milowe
Strategie testowania zwinnego
Cykl życia testów zwinnych obejmuje cztery etapy
(a) Iteracja 0
Podczas pierwszego etapu lub iteracji 0 wykonujesz zadania konfiguracji początkowej. Obejmuje identyfikację osób do testowania, instalowanie narzędzi testowych, planowanie zasobów (laboratorium testowania użyteczności) itp. Poniższe kroki są ustawione do osiągnięcia w Iteracji 0
a) Ustalenie uzasadnienia biznesowego projektu
b) Ustal warunki brzegowe i zakres projektu
c) Przedstaw kluczowe wymagania i przypadki użycia, które będą napędzać kompromisy projektowe
d) Przedstaw jedną lub więcej architektur kandydatów
e) Identyfikacja ryzyka
f) Oszacowanie kosztów i przygotowanie projektu wstępnego
(b) Iteracje konstrukcji
Druga faza metodologii testowania zwinnego to iteracje konstrukcji, większość testów odbywa się w tej fazie. Ta faza jest obserwowana jako zestaw iteracji w celu zbudowania przyrostu rozwiązania. Aby to zrobić, w każdej iteracji zespół wdraża hybrydę praktyk z XP, Scruma, modelowania Agile, danych zwinnych i tak dalej.
W iteracji konstrukcyjnej zespół zwinny postępuje zgodnie z priorytetową praktyką w zakresie wymagań: przy każdej iteracji pobiera najbardziej istotne wymagania pozostałe ze stosu elementów roboczych i wdraża je.
Iteracja konstrukcji jest podzielona na dwie części: testy potwierdzające i badania badawcze. Testowanie potwierdzające koncentruje się na sprawdzeniu, czy system spełnia zamierzenia interesariuszy, jak opisano zespołowi do tej pory, i jest wykonywane przez zespół. Podczas gdy badanie dochodzeniowe wykrywa problem, który zespół potwierdzający pominął lub zignorował. W testowaniu śledczym tester określa potencjalne problemy w postaci historii defektów. Testy śledcze dotyczą typowych problemów, takich jak testy integracyjne, testy obciążenia / obciążenia i testy bezpieczeństwa.
W przypadku testów potwierdzających istnieją dwa aspekty testowania deweloperskiego i zwinnego testowania akceptacyjnego . Oba są zautomatyzowane, aby umożliwić ciągłe testowanie regresji przez cały cykl życia. Testowanie potwierdzające jest zwinnym odpowiednikiem testowania zgodnie ze specyfikacją.
Zwinne testy akceptacyjne to połączenie tradycyjnego testowania funkcjonalnego i tradycyjnego testowania akceptacyjnego, w którym zespół programistów i interesariusze robią to razem. Podczas gdy testy deweloperskie to połączenie tradycyjnych testów jednostkowych i tradycyjnych testów integracji usług. Testowanie deweloperskie weryfikuje zarówno kod aplikacji, jak i schemat bazy danych.
(c) Wydanie gry końcowej lub faza przejścia
Celem „Release, End Game” jest pomyślne wdrożenie systemu do produkcji. Działania w tej fazie obejmują szkolenie użytkowników końcowych, osoby wspierające i osoby operacyjne. Obejmuje również marketing wydania produktu, tworzenie kopii zapasowych i przywracanie, finalizację systemu i dokumentacji użytkownika.
Ostatni etap testowania metodologii Agile obejmuje pełne testowanie systemu i testy akceptacyjne. Aby zakończyć końcowy etap testowania bez żadnych przeszkód, produkt powinien być poddawany bardziej rygorystycznemu testowaniu podczas wykonywania iteracji konstrukcyjnych. Podczas gry końcowej testerzy będą pracować nad historiami błędów.
(d) Produkcja
Po fazie wydania produkt przejdzie do etapu produkcji.
Kwadranty testowania zwinnego
Kwadranty testów zwinnych dzielą cały proces na cztery ćwiartki i pomagają zrozumieć, w jaki sposób przeprowadzane są testy zwinne.
a) Kwadrant Agile I - Jakość kodu wewnętrznego jest głównym celem w tym kwadrancie i składa się z przypadków testowych, które są oparte na technologii i są wdrażane w celu wsparcia zespołu, obejmuje
1. Testy jednostkowe
2 Testy komponentów
b) Agile Quadrant II - Zawiera przypadki testowe, które są napędzane biznesowo i są wdrażane w celu wsparcia zespołu. W tym kwadrancie skupiono się na wymaganiach. Rodzaj testu wykonywanego w tej fazie to
1. Testowanie przykładów możliwych scenariuszy i przepływów pracy
2. Testowanie doświadczeń użytkownika, takich jak prototypy
3. Testowanie par
c) Agile Quadrant III - ten kwadrant dostarcza informacji zwrotnej do ćwiartki pierwszej i drugiej. Przypadki testowe mogą służyć jako podstawa do przeprowadzania testów automatycznych. W tym kwadrancie przeprowadza się wiele rund przeglądów iteracyjnych, co buduje zaufanie do produktu. Rodzaj testów wykonywanych w tym kwadrancie to
1. Testowanie użyteczności
2. Testowanie eksploracyjne
3. Testowanie w parach z klientami
4. Testowanie zespołowe
5. Testy akceptacyjne użytkownika
d) Kwadrant Agile IV - ten kwadrant koncentruje się na niefunkcjonalnych wymaganiach, takich jak wydajność, bezpieczeństwo, stabilność itp. Za pomocą tego kwadrantu aplikacja ma dostarczać niefunkcjonalne cechy i oczekiwaną wartość.
1. Testy niefunkcjonalne, takie jak testy obciążeniowe i testy wydajności
2. Testy bezpieczeństwa pod kątem uwierzytelniania i hakowania
3. Testowanie infrastruktury
4. Testy migracji danych
5. Testowanie skalowalności
6. Testowanie obciążeniowe
Wyzwania związane z kontrolą jakości przy zwinnym tworzeniu oprogramowania
a) 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
b) 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 odpowiada to potrzebom biznesowym
c) Testerzy są często zobowiązani do odgrywania roli półprofesjonalnej
d) Cykle wykonywania testów są silnie skompresowane
e) Bardzo mniej czasu na przygotowanie planu testów
f) W przypadku testów regresji będą miały minimalny czas
g) Zmiana ich roli z bycia strażnikiem jakości na bycie partnerem w jakości
h) Zmiany i aktualizacje wymagań są nieodłącznym elementem metody zwinnej, stając się największym wyzwaniem dla zapewniania jakości
Ryzyko automatyzacji w zwinnym procesie
- Zautomatyzowany interfejs użytkownika zapewnia wysoki poziom pewności, ale ich wykonanie jest powolne, kruche w utrzymaniu i kosztowne w budowie. Automatyzacja może nie poprawić znacząco produktywności testów, chyba że testerzy wiedzą, jak testować
- Zawodne testy są głównym problemem w testowaniu automatycznym. Naprawianie zakończonych niepowodzeniem testów i rozwiązywanie problemów związanych z kruchymi testami powinno być najwyższym priorytetem, aby uniknąć fałszywych trafień
- Jeśli testy automatyczne są inicjowane ręcznie, a nie przez CI (Continuous Integration), istnieje ryzyko, że nie działają one regularnie i dlatego mogą powodować niepowodzenie testów
- Testy automatyczne nie zastępują ręcznego testowania eksploracyjnego. Aby uzyskać oczekiwaną jakość produktu, wymagana jest mieszanka typów i poziomów badań
- Wiele dostępnych na rynku narzędzi do automatyzacji zapewnia 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. Przechowywanie przypadków testowych poza systemem kontroli wersji powoduje również niepotrzebną złożoność
- Aby zaoszczędzić czas, często plan testów automatyzacji jest źle zaplanowany lub nieplanowany, co skutkuje niepowodzeniem testu
- Podczas automatyzacji testów zwykle pomijane są procedury konfiguracji i usuwania testów, podczas gdy wykonywanie testów ręcznych, konfiguracja testów i procedury eliminacji brzmią bezproblemowo
- Wskaźniki produktywności, takie jak liczba przypadków testowych tworzonych lub wykonywanych dziennie, mogą być bardzo mylące i mogą prowadzić do dużych inwestycji w przeprowadzanie bezużytecznych testów
- Członkowie zespołu zwinnej automatyzacji muszą być skutecznymi konsultantami: przystępnymi, współpracującymi i zaradnymi, w przeciwnym razie ten system szybko zawiedzie
- Automatyzacja może proponować i dostarczać rozwiązania testowe, które wymagają zbyt długiej bieżącej konserwacji w stosunku do zapewnianej wartości
- Testowanie automatyczne może nie mieć doświadczenia w opracowywaniu i dostarczaniu skutecznych rozwiązań
- Testy automatyczne mogą być tak skuteczne, że zabraknie im ważnych problemów do rozwiązania, a tym samym zwrócą się do nieistotnych problemów.
Wniosek
Metodyka zwinna w testowaniu oprogramowania obejmuje testowanie na jak najwcześniejszym etapie cyklu życia oprogramowania. Wymaga dużego zaangażowania klienta i testowania kodu, gdy tylko stanie się dostępny. Kod powinien być wystarczająco stabilny, aby zabrać go do testowania systemu. Można przeprowadzić obszerne testy regresji, aby upewnić się, że błędy zostały naprawione i przetestowane. Przede wszystkim komunikacja między zespołami sprawia, że testowanie modeli zwinnych jest sukcesem !!!