Jedną z fundamentalnych zasad testowania, którą poznaliśmy w pierwszym rozdziale, jest zasada wczesnego testowania.

Mówi ona, że im wcześniej w cyklu życia oprogramowania rozpoczniemy działania związane z testowaniem i zapewnianiem jakości, tym lepiej.

Wczesne wykrywanie defektów jest znacznie tańsze i łatwiejsze do naprawienia niż znajdowanie ich na późniejszych etapach, np. podczas testów systemowych czy, co gorsza, już po wdrożeniu na produkcję.

W ostatnich latach ta zasada zyskała popularną nazwę i stała się kluczowym elementem nowoczesnych metodyk wytwarzania oprogramowania – mowa o podejściu „Shift Left”, czyli „przesunięciu w lewo”.

W tej lekcji zgłębimy, co dokładnie oznacza to pojęcie, dlaczego jest tak ważne i jakie konkretne praktyki, wymienione w sylabusie ISTQB, pomagają w jego realizacji.

Co Oznacza "Shift Left"?

Wyobraźmy sobie oś czasu reprezentującą cykl życia oprogramowania, zaczynając od lewej strony (wczesne etapy, jak analiza wymagań, projektowanie) i przesuwając się w prawo (implementacja, testowanie, wdrożenie, utrzymanie).

Tradycyjnie, większość intensywnych działań testowych koncentrowała się po prawej stronie tej osi, głównie po zakończeniu implementacji.

Podejście „Shift Left” polega na świadomym przesuwaniu działań związanych z testowaniem i zapewnianiem jakości jak najdalej w lewo na tej osi czasu, czyli na jak najwcześniejsze etapy projektu.

Jak słusznie zauważa sylabus ISTQB, „zasada wczesnego testowania jest niekiedy nazywana „przesunięciem w lewo”, ponieważ w myśl tej zasady testowanie odbywa się na wcześniejszym etapie cyklu wytwarzania oprogramowania”.

Nie chodzi tu o całkowite zaniechanie testowania na późniejszych etapach – testy systemowe czy akceptacyjne nadal są niezbędne.

Chodzi raczej o zmianę punktu ciężkości i proaktywne angażowanie się w działania jakościowe od samego początku projektu, a nie tylko reagowanie na problemy wykryte pod koniec.

„Shift Left” to nie tylko technika, ale przede wszystkim sposób myślenia i kultura pracy, która promuje wbudowywanie jakości w proces, a nie tylko jej sprawdzanie.

Wymaga to ścisłej współpracy między wszystkimi członkami zespołu – analitykami, projektantami, programistami i testerami – oraz traktowania jakości jako wspólnej odpowiedzialności.

Dlaczego "Shift Left" Jest Ważne?

Główną motywacją stojącą za podejściem „Shift Left” jest redukcja kosztów i ryzyka związanego z defektami.

Badania i praktyka pokazują, że koszt naprawy defektu rośnie wykładniczo wraz z postępem projektu.

Defekt wykryty i naprawiony na etapie wymagań może kosztować symboliczną kwotę (np. czas potrzebny na poprawienie dokumentu).

Ten sam defekt, jeśli zostanie zaimplementowany i wykryty dopiero podczas testów systemowych, może wymagać zmian w kodzie, ponownych testów, aktualizacji dokumentacji, co generuje znacznie większe koszty.

Jeśli zaś defekt trafi na produkcję, koszty mogą być ogromne – obejmują nie tylko naprawę, ale także utratę reputacji, niezadowolenie klientów, a w skrajnych przypadkach nawet straty finansowe lub prawne.

„Shift Left” pomaga minimalizować te koszty poprzez:

• Wczesne wykrywanie defektów: Angażując się w jakość od początku, mamy szansę znaleźć problemy w wymaganiach, projektach czy wczesnych wersjach kodu, zanim zdążą one spowodować większe szkody.
• Zapobieganie defektom: Wczesna analiza i dyskusje na temat jakości i testowalności mogą pomóc w uniknięciu wprowadzenia pewnych typów defektów w ogóle.
• Skrócenie pętli informacji zwrotnej: Im szybciej programista dowie się o problemie w napisanym przez siebie kodzie (np. dzięki testom jednostkowym uruchamianym lokalnie lub w CI), tym łatwiej i szybciej może go naprawić.
• Budowanie jakości, a nie tylko jej testowanie: „Shift Left” promuje kulturę, w której cały zespół czuje się odpowiedzialny za jakość i aktywnie uczestniczy w jej zapewnianiu na każdym etapie.
• Zmniejszenie ryzyka projektowego: Wczesne wykrywanie i naprawianie problemów zmniejsza ryzyko opóźnień, przekroczenia budżetu i dostarczenia produktu niespełniającego oczekiwań.

Dobre Praktyki Wspierające "Shift Left"

Sylabus ISTQB Foundation Level v4.0 wymienia kilka konkretnych dobrych praktyk, które ilustrują, jak można wdrożyć podejście „Shift Left” w testowaniu.

Są one rozwinięciem i uszczegółowieniem zasad, które poznaliśmy w poprzednich lekcjach:

1. Dokonywanie Przeglądu Specyfikacji z Punktu Widzenia Testowania:

Jest to kluczowy przykład testowania statycznego (które omówimy szerzej w Rozdziale 3).

Angażowanie testerów (ale także programistów i innych interesariuszy) w przeglądy dokumentów takich jak specyfikacje wymagań, historyjki użytkownika, kryteria akceptacji czy projekty architektury, pozwala na wczesne wykrycie potencjalnych defektów.

Testerzy, dzięki swojej perspektywie, mogą identyfikować niejasności, braki, niespójności, sprzeczności czy problemy z testowalnością w tych dokumentach.

Naprawienie tych problemów na etapie specyfikacji jest wielokrotnie tańsze niż naprawianie błędów w kodzie wynikających z tych problemów.

2. Pisanie Przypadków Testowych Przed Rozpoczęciem Pisania Kodu:

Ta praktyka jest fundamentem podejść takich jak TDD, ATDD i BDD, które omówiliśmy w poprzedniej lekcji.

Definiowanie oczekiwanego zachowania w postaci testów (jednostkowych, akceptacyjnych, scenariuszy BDD) przed implementacją kodu ma kilka zalet.

Po pierwsze, zmusza do precyzyjnego przemyślenia wymagań i projektu.

Po drugie, zapewnia natychmiastową informację zwrotną podczas kodowania – programista wie, kiedy osiągnął cel.

Po trzecie, gwarantuje, że kod jest pokryty testami od samego początku.

Uruchamianie kodu w tzw. „jarzmie testowym” (test harness) podczas implementacji pozwala na szybką weryfikację poprawności działania w izolowanym środowisku.

3. Korzystanie z Mechanizmu Ciągłej Integracji (CI) / Ciągłego Dostarczania (CD):

Jak wspomnieliśmy w lekcji o DevOps, potoki CI/CD są potężnym narzędziem wspierającym „Shift Left”.

Automatyczne budowanie i uruchamianie testów (zwłaszcza jednostkowych i integracyjnych) po każdej zmianie kodu przekazanej do repozytorium zapewnia bardzo szybką informację zwrotną programistom.

Pozwala to na natychmiastowe wykrycie problemów z integracją lub regresji, zanim zostaną one wprowadzone do głównej gałęzi kodu i wpłyną na pracę innych członków zespołu.

4. Przeprowadzanie Analizy Statycznej Kodu Źródłowego:

Analiza statyczna polega na automatycznym sprawdzaniu kodu źródłowego bez jego uruchamiania, w poszukiwaniu potencjalnych problemów, takich jak błędy składniowe, naruszenia standardów kodowania, potencjalne luki bezpieczeństwa czy skomplikowane fragmenty kodu (tzw. „code smells”).

Narzędzia do analizy statycznej (np. SonarQube, Checkstyle, ESLint) mogą być zintegrowane z procesem CI lub używane przez programistów lokalnie.

Wykonywanie analizy statycznej przed rozpoczęciem testowania dynamicznego (czyli uruchamianiem kodu) pozwala na wczesne wykrycie i usunięcie wielu prostych błędów i problemów ze stylem kodu, co poprawia jego jakość i utrzymywalność.

Podsumowanie

Podejście „Shift Left” to realizacja zasady wczesnego testowania, polegająca na przesuwaniu działań związanych z zapewnianiem jakości na jak najwcześniejsze etapy cyklu życia oprogramowania.

Jego głównym celem jest redukcja kosztów i ryzyka poprzez wczesne wykrywanie i zapobieganie defektom.

Kluczowe praktyki wspierające „Shift Left” obejmują przeglądy specyfikacji, pisanie testów przed kodem (TDD/ATDD/BDD), wykorzystanie CI/CD oraz analizę statyczną kodu.

Wdrożenie „Shift Left” wymaga zmiany kultury organizacyjnej w kierunku wspólnej odpowiedzialności za jakość i ścisłej współpracy w zespole.