Zwinne testowanie, czyli agile testing

Co to znaczy zwinne podejście do testów? Zacznijmy od zrozumienia, że w środowisku Agile, zwinne testowanie nie jest tylko etapem - to proces ciągły. Testowanie zwinne (Agile testing) integruje testowanie, jako podstawową część cyklu życia projektu, nie tylko jako ostatni krok przed wdrożeniem.

Podejście zwinne i kaskadowe, czyli Agile i Waterfall

Agile testing i testowanie w modelu Waterfall różnią się znacząco. W podejściu Agile testy są integralną częścią procesu deweloperskiego, przeprowadzane są równolegle do pisania kodu. Dzięki temu, możliwe jest szybkie reagowanie na zmiany. Agile jest w cyklach, co oznacza ciągłe doskonalenie produktu wg. kalibrowanych na bieżąco wymagań. Z kolei w Waterfall, testowanie jest oddzielnym, końcowym etapem projektu. Ta sekwencyjność może prowadzić do opóźnień, gdyż błędy wykryte na tym etapie wymagają powrotu do wcześniejszych faz projektu.

Co oznacza i gdzie się stosuje testowanie zwinne?

Testowanie zwinne, jak sama nazwa wskazuje, stosuje się w projektach, które korzystają metodyki Agile (takie jak Scrum czy Lean). Jest to metoda testowania idealna tam, gdzie potrzebna jest szybka reakcja na zmieniające się wymagania klienta oraz dość dynamiczne środowisko projektowe. W praktyce Agile testy są przeprowadzane w trakcie rozwoju produktu. Sprawdzanie jakości niezbędnym elementem każdego etapu, co umożliwia bieżące wyłapywanie problemów, dostosowywanie produktu i natychmiastowe rozwiązywanie napotkanych trudności.

Kim jest tester zwinny?

Tester zwinny to ktoś więcej niż tylko osoba sprawdzająca błędy. To integralny członek zespołu projektowego, który pracuje ramię w ramię z programistami, projektantami i menedżerami produktu. Wszyscy oni są deweloperami projektu. Dzięki bliskiej współpracy i ciągłej wymianie informacji, tester zwinny pomaga zespołowi utrzymać wysoką jakość kodu i dostosować produkt do rzeczywistych potrzeb użytkowników.

Rodzaje podejść do testowania oprogramowania wg. nomenklatury ISTQB

Międzynarodowa Rada Kwalifikacji Testowania Oprogramowania (ISTQB) definiuje różne podejścia do testowania. Wśród nich znajdują się:
- testy statyczne, które analizują kod bez jego wykonania;
- testy dynamiczne, które wymagają uruchomienia programu;
- testy manualne i automatyczne

Strategia

Strategia testowania Agile różni się od tradycyjnych planów testów. Przy zwinnych projektach, bardzo często szczegółowy plan często ustępuje miejsca gotowości na zmiany. Bądźmy szczerzy, dobrze udokumentowany plan testów nie jest częsty, a zmieniające się wymagania nie sprzyjają szczegółowej dokumentacji. Jak więc możesz skutecznie opracować strategię testowania w swoim projekcie Agile?

Istnieje wiele sposobów na opracowanie takiej strategii testowania. Możesz po prostu nakreślić ją w dokumencie najlepiej zbierającym aktualny stan wiedzy. Możesz też stworzyć macierz testów. Lub możesz użyć tablicy Kanban.

Bez względu na to, którą metodę zastosujesz, twoja strategia powinna zawierać:

- Cel nadrzędny(zdefiniowany przez historię użytkownika)
- Cele podrzędne (przypadki testowe)
- Zakres (co musi być testowane)
- Metody (jak będą przeprowadzane testy)

Pierwszym krokiem jest określenie celu. Co dokładnie chcesz przetestować? Zaczynając od celu, możesz jasno zdefiniować, co będzie przedmiotem testów. Następnie napisz historię użytkownika, w której zawarte będą kryteria akceptacji (często oznaczane skrótem AC). To Twoja definicja zakończenia zadania. Na podstawie tej historii stwórz przypadek testowy.

Twoja strategia powinna również określać zakres - czyli to, co musi zostać przetestowane, oraz metody - jak planujesz przeprowadzać te testy. Czy wolisz tradycyjne dokumenty, a może dynamiczną tablicę Kanban? Niezależnie od wybranej metody, ważne jest, aby strategia była jasna i przystępna dla całego zespołu.

Tworzenie strategii testowania Agile może być wyzwaniem, w każdym zespole będzie wyglądać też trochę inaczej, ale tym bardziej warto próbować ją tworzyć, wdrażać i dokumentować.

Załóżmy, że prowadzisz projekt rozwijający aplikację e-commerce, która ma umożliwić użytkownikom łatwiejsze zarządzanie ich subskrypcjami produktowymi. Poniżej przedstawiam, jak mógłby wyglądać praktyczny przykład strategii testowania dla takiego projektu:

Cel nadrzędny (zdefiniowany przez historię użytkownika)

User story: Jako użytkownik chcę mieć możliwość przeglądania moich aktywnych subskrypcji w aplikacji, aby móc łatwo zarządzać moimi zamówieniami.

Cele podrzędne (przypadki testowe)

Przypadek testowy 1: Sprawdzenie, czy użytkownik może zobaczyć listę swoich aktualnych subskrypcji po zalogowaniu.
Przypadek testowy 2: Testowanie funkcji anulowania subskrypcji, w tym potwierdzenie, że użytkownik otrzymuje odpowiednie powiadomienia.
Przypadek testowy 3: Weryfikacja, czy aktualizacje subskrypcji są odzwierciedlane w czasie rzeczywistym.

Zakres

Zakres testów obejmowałby wszystkie funkcje związane z zarządzaniem subskrypcjami, w tym wyświetlanie, aktualizowanie i anulowanie subskrypcji przez użytkownika.

Metody

Metoda testów manualnych: Testerzy przeprowadziliby ręczne testy korzystając z różnych scenariuszy użytkowania w celu sprawdzenia, czy wszystkie funkcje działają zgodnie z oczekiwaniami.
Metoda testów automatycznych: Użycie narzędzi automatyzacji, takich jak Selenium, do tworzenia skryptów testowych, które regularnie sprawdziłyby podstawowe funkcjonalności subskrypcji, zapewniając szybkie wykrywanie błędów po każdej aktualizacji kodu.

Wdrażanie

Do zarządzania testami i śledzenia postępów użylibyśmy tablicy Kanban, co umożliwiłoby zespołowi testującemu dostosowywanie się do zmieniających się priorytetów i szybkie komunikowanie statusu testów. Każdy przypadek testowy miałby swoją kartę na Kanbanie, co pozwoliłoby śledzić jego postępy od momentu planowania (backlog) po zakończenie (akceptację lub odrzucenie przez zgłoszenie błędu).