SygnITy Expert
Shift-left testing – wejście QA od samego początku
Czy zdarzyło Ci się widzieć ryzyko dużo wcześniej niż reszta zespołu – już po kilku pierwszych testach, gdy wszyscy byli skupieni głównie na dowiezieniu terminu? Albo dostajesz „gotowy produkt”, który formalnie spełnia wymagania, ale czujesz, że korzystanie z niego w praktyce będzie po prostu niewygodne i nieintuicyjne.
Jeśli tak, to bardzo możliwe, że jako QA wchodzisz do projektu za późno. A to często prowadzi do chaosu: nagłych poprawek, napięć w zespole i błędów, którym można było zapobiec wcześniej.
W tym artykule pokażę, co się zmienia, kiedy QA jest zaangażowany od samego początku – już na etapie analizy wymagań. Jak może wyglądać taka współpraca w praktyce i co realnie daje to zespołowi oraz końcowemu produktowi.
1.W czym leży źródło ryzyka?
Jak już wspomniałem, ryzyko najczęściej nie leży w samym testowaniu, ale w momencie, w którym QA wchodzi do projektu. W tradycyjnym podejściu testy (poza jednostkowymi wykonywanymi przez developerów) pojawiają się dopiero po implementacji – czyli de facto w modelu shift-right.
Na tym etapie czasu zazwyczaj zaczyna brakować. Terminy gonią, a zakres testów często musi zostać ograniczony. W efekcie trudno dokładnie zweryfikować całe oprogramowanie – zarówno pod kątem spełnienia wymagań, jak i tego, czy produkt faktycznie będzie wygodny w użyciu dla użytkownika końcowego. Niestety może to prowadzić do wydania niedopracowanego produktu, co w konsekwencji przekłada się na straty finansowe, potencjalne ryzyko utraty wizerunku firmy oraz inne negatywne skutki.
Dodatkowo wszelkie zmiany na tym etapie – poprawa błędów, modyfikacja funkcjonalności czy nawet korekta samego projektu – są znacznie bardziej kosztowne niż wtedy, gdy zostałyby wychwycone wcześniej, na etapie analizy wymagań.
Bardzo często błędy pojawiają się już na etapie zbierania wymagań, co działa jak efekt kuli śnieżnej – ryzyka nakładają się na siebie i narastają w kolejnych fazach projektu. Jednym z rozwiązań tej sytuacji jest włączenie QA już na tym etapie.
2. Shift-left – z czym to się je?
Kiedy spojrzymy na wszystkie opisane wcześniej sytuacje razem, widać jeden wspólny mianownik – QA reaguje za późno. A skoro źródłem problemu jest moment wejścia do projektu, to rozwiązaniem nie jest „lepsze testowanie”, tylko przesunięcie tego momentu.
I właśnie tutaj pojawia się model shift-left testing.
W dużym uproszczeniu, shift-left to podejście polegające na przesunięciu działań związanych z testowaniem na wcześniejsze etapy cyklu życia oprogramowania. W praktyce oznacza to, że QA przestaje być wyłącznie etapem końcowej weryfikacji, a zaczyna uczestniczyć w procesie już od samego początku – na przykład podczas analizy wymagań.
Naturalną konsekwencją takiego podejścia jest szersza rola testera, który razem z zespołem bierze udział w doprecyzowywaniu wymagań. Dzięki temu może wcześniej wychwycić niejasności, niespójności czy sprzeczne założenia.
W tym podejściu nie chodzi więc o wykonywanie większej liczby testów, ale o przesunięcie myślenia o jakości na wcześniejszy etap. W efekcie wiele potencjalnych błędów zostaje wyeliminowanych jeszcze zanim powstanie pierwsza linia kodu. Przekłada się to na mniejszą liczbę błędów na późniejszych etapach oraz bardziej dopracowany i przyjazny dla użytkownika produkt.
3. Jak wygląda shift-left w praktyce?
Z definicji cykl życia oprogramowania (SDLC – Software Development Life Cycle) jest usystematyzowanym procesem tworzenia, wdrażania i utrzymania oprogramowania.
Patrząc na SDLC łatwo zauważyć, że testowanie tradycyjnie pojawia się dopiero na końcu procesu tworzenia. Shift-left zmienia ten schemat – QA zaczyna być obecny już na wcześniejszych etapach i nie czeka, aż produkt zostanie w pełni zbudowany.
A) Analiza wymagań
Na tym etapie rola testera często jest niedoceniana, a w praktyce może mieć największy wpływ na jakość całego produktu. Już podczas spotkań zespołowych QA nie tylko analizuje wymagania, ale aktywnie pomaga je doprecyzować.
Właśnie tutaj pojawia się jedna z największych wartości podejścia shift-left – wiele niespójności można wyłapać zanim powstanie kod.
Na tym etapie QA może zauważyć m.in.:
- braki w doprecyzowaniu wymagań
- sprzeczności pomiędzy wymaganiami
- niejasności w logice biznesowej
- brakujące scenariusze (edge case’y)
Przykładowo, przy funkcji filtrowania danych, pozornie proste wymaganie „filtrowanie po dacie” może rodzić wiele pytań: co jeśli użytkownik poda tylko jedną stronę zakresu, jak obsługiwane są strefy czasowe lub różne formaty dat.
Takie kwestie, wyłapane na etapie wymagań, pozwalają uniknąć późniejszych poprawek w kodzie i nieporozumień w implementacji.
B) Projektowanie
Pierwsze efekty zaangażowania testera już na etapie analizy wymagań widać właśnie tutaj – wymagania są bardziej doprecyzowane, spójne, a ryzyko błędów na etapie projektowania znacząco maleje.
Ten etap jest kluczowy w definiowaniu tego, „jak system ma działać”. Dzięki user stories oraz kryteriom akceptacji QA ma możliwość weryfikacji zaprojektowanych rozwiązań jeszcze przed ich implementacją.
Przykładowo: w jednym z rozwiązań założono, że po wybraniu kategorii w sklepie użytkownik zostaje przeniesiony bezpośrednio na listę wyników. Tymczasem w wymaganiach pierwotnie wskazano, że powinien trafić na stronę filtrowania. Takie rozbieżności można wychwycić już na etapie projektowania i doprecyzować je zanim powstanie kod.
Na podstawie projektu można również rozpocząć przygotowanie scenariuszy testowych oraz identyfikację potencjalnych ryzyk, co dodatkowo skraca późniejszy etap testowania.
C) Implementacja
Na tym etapie shift-left zaczyna być najbardziej widoczny w codziennej pracy zespołu. QA nie czeka już na gotową funkcjonalność, ale pozostaje w stałym kontakcie z developerami i na bieżąco wspiera proces wytwarzania oprogramowania.
Dzięki temu możliwy jest szybki feedback – zarówno w kwestii działania funkcji, jak i interpretacji wymagań. Zamiast sytuacji, w której błędy wychodzą dopiero na etapie testów, wiele nieprawidłowości można wyjaśnić i skorygować w trakcie implementacji.
W praktyce może to oznaczać np. weryfikację API jeszcze przed ukończeniem frontendu (np. z użyciem Postman), doprecyzowanie logiki biznesowej na bieżąco czy szybkie wychwytywanie niezgodności między implementacją a wymaganiami.
Efektem takiego podejścia jest krótsza pętla feedbacku, mniej „niespodzianek” na końcu sprintu oraz bardziej przewidywalny proces dostarczania oprogramowania.
Podsumowanie
Podejście shift-left niesie ze sobą wiele korzyści, ale nie jest też pozbawione wyzwań. Wymaga większego zaangażowania całego zespołu, lepszej komunikacji oraz świadomego planowania procesu. Z tego względu jego wdrożenie powinno być dobrze przemyślane, a nie wprowadzane „na siłę”.
Nie zmienia to jednak faktu, że korzyści z tego podejścia są bardzo wyraźne – pozwalają wcześniej eliminować ryzyka, skracają czas dostarczania oprogramowania i przede wszystkim znacząco podnoszą jego jakość.
Z perspektywy QA zmienia się najważniejsza rzecz: nie jesteś już tylko etapem na końcu procesu, ale aktywną częścią jego budowania od samego początku.