Shift-left testing to przesunięcie testowania na wcześniejsze etapy cyklu wytwórczego: tester przegląda wymagania, zanim powstanie kod, testy pisze się przed implementacją, a analiza statyczna i automatyczne testy komponentów działają przy każdej zmianie w repozytorium. Nie oznacza to rezygnacji z testów na późniejszych poziomach, tylko wcześniejsze wykrywanie defektów.
Na skróty
Czego dowiesz się z artykułu:
- Jak shift-left definiuje sylabus ISTQB i jakie praktyki do niego zalicza
- Jak TDD, ATDD i BDD realizują zasadę wczesnego testowania
- Co shift-left oznacza dla bezpieczeństwa według NIST SSDF i OWASP SAMM
- Kto w zespole odpowiada za jakość, gdy testy zaczynają się przed kodem
Dla kogo jest ten artykuł:
- Inżynierowie jakości i testerzy w zespołach zwinnych
- Programiści i liderzy techniczni budujący potok CI/CD
- Właściciele produktów, którzy piszą kryteria akceptacji
Czas czytania: 7 minut
Czym jest shift-left według ISTQB
Sylabus Certified Tester Foundation Level w wersji v4.0.1, udostępniony na stronie certyfikacji w istqb.org, opisuje shift-left w sekcji 2.1.5 jako inną nazwę zasady wczesnego testowania: testy wykonuje się wcześniej w cyklu życia oprogramowania, bez czekania na gotowy kod ani na zintegrowane komponenty. Sylabus od razu zastrzega, że nie wolno przy tym zaniedbywać testów na późniejszych etapach.
Jako dobre praktyki sylabus wymienia:
- przegląd specyfikacji z perspektywy testera — taki przegląd często wykrywa niejednoznaczności, braki i sprzeczności,
- pisanie przypadków testowych przed kodem i uruchamianie kodu w jarzmie testowym już podczas implementacji,
- ciągłą integrację, a najlepiej ciągłe dostarczanie z szybką informacją zwrotną i automatycznymi testami komponentów,
- analizę statyczną kodu źródłowego przed testami dynamicznymi albo jako część zautomatyzowanego procesu,
- testy niefunkcjonalne już na poziomie testów komponentów, tam gdzie to możliwe.
Tę samą zasadę realizują podejścia opisane w sekcji 2.1.3 sylabusa: TDD (testy pisane przed kodem, potem kod spełniający testy i refaktoryzacja), ATDD (testy wyprowadzane z kryteriów akceptacji) oraz BDD (oczekiwane zachowanie zapisane w formacie Given/When/Then).
Dlaczego wcześniej — i czego nie obiecywać
Zasada wczesnego testowania w sylabusie ISTQB z istqb.org ma jakościowe uzasadnienie: defekt usunięty wcześnie nie powoduje kolejnych defektów w produktach pracy wyprowadzonych z wadliwego dokumentu, a późnych awarii jest mniej. Sylabus jest przy tym uczciwy co do kosztów. Shift-left może oznaczać dodatkowe szkolenia, wysiłek i koszty na początku procesu, a oszczędność jest dopiero oczekiwana w jego dalszej części. Warunkiem jest przekonanie interesariuszy do samej koncepcji.
W praktyce warto więc mierzyć własne dane: w jakiej fazie wykryto defekt, ile czasu zajęła jego naprawa i czy po zmianie procesu przesuwa się to w lewo. To lepszy argument dla zarządu niż obiegowe mnożniki kosztu błędu, których nie da się odnieść do własnego projektu.
Shift-left w bezpieczeństwie: NIST SSDF i OWASP SAMM
To samo przesunięcie dotyczy bezpieczeństwa. NIST SP 800-218, czyli Secure Software Development Framework (SSDF) w wersji 1.1 z lutego 2022 r., opublikowany w csrc.nist.gov, opisuje praktyki, które łatwo przypiąć do wczesnych etapów. Praktyka PW.1 dotyczy projektowania oprogramowania pod wymagania bezpieczeństwa z użyciem modelowania ryzyka, np. modelowania zagrożeń. PW.7 obejmuje przegląd lub analizę kodu czytelnego dla człowieka, wykonywane przez ludzi albo narzędzia — w praktyce przegląd kodu i SAST. PW.8 to testowanie kodu wykonywalnego w celu znalezienia podatności, których nie wykryły wcześniejsze przeglądy.
Według strony projektu w csrc.nist.gov NIST opublikował 17 grudnia 2025 r. projekt rewizji (SP 800-218 Rev. 1, SSDF w wersji 1.2), a konsultacje zamknięto 30 stycznia 2026 r. Do czasu wydania wersji ostatecznej punktem odniesienia pozostaje wersja 1.1.
Do oceny, na ile zespół już stosuje takie praktyki, służy OWASP SAMM. Strona projektu w owasp.org opisuje go jako otwarty model dojrzałości, który obejmuje cały cykl życia oprogramowania, pozwala ocenić istniejące praktyki bezpieczeństwa i zaplanować ich rozwój w kolejnych iteracjach. Aktualna wersja to 2.2.0.
Role w zespole: jakość jest wspólna
Sylabus ISTQB opisuje podejście całego zespołu (whole team approach): każdy członek zespołu z odpowiednią wiedzą może wykonać dowolne zadanie, a za jakość odpowiadają wszyscy. W shift-left przekłada się to na konkretne role:
- Inżynier jakości przegląda wymagania, uzgadnia z programistami strategię testów i automatyzację, pomaga pisać testy akceptacyjne.
- Programista pisze testy komponentów, często w rytmie TDD, i reaguje na wyniki analizy statycznej w potoku.
- Właściciel produktu formułuje kryteria akceptacji tak, żeby dało się z nich wyprowadzić testy.
- Security champion — w zadaniu PW.1.1 (modelowanie ryzyka) NIST SSDF wskazuje security championów jako szczególnych adresatów szkolenia zespołu.
Czytaj także
- Strategia testowania w projekcie zwinnym — miejsce testów w sprincie
- Od testera do QA Engineer — kompetencje inżyniera jakości
- DevSecOps w praktyce — bezpieczeństwo w potoku
Rozwijaj kompetencje
Temat rozwijają szkolenia ISTQB Foundation Level — przygotowanie do certyfikacji oraz Test Driven Development — od teorii do praktyki. Pierwsze porządkuje pojęcia i techniki testowania, drugie uczy pisania testów przed kodem. Skontaktuj się z nami, żeby dobrać zakres do swojego zespołu.
Najczęściej zadawane pytania (FAQ)
Czym są testy kontraktowe i jak wspierają shift-left?
Testy kontraktowe sprawdzają, czy usługa udostępniająca API i usługa z niego korzystająca trzymają się uzgodnionego kontraktu. Pozwalają wykryć niezgodność interfejsów przy budowaniu pojedynczej usługi, zanim powstanie pełne środowisko integracyjne. Szerzej piszemy o nich w artykule Testy kontraktowe w architekturze mikroserwisów.
Jakie techniki testowania stosuje się w podejściu shift-left?
Najczęściej przegląd wymagań i specyfikacji, testy komponentów pisane w rytmie TDD, testy akceptacyjne wyprowadzane z kryteriów (ATDD, BDD), analizę statyczną kodu w potoku CI oraz wczesne testy niefunkcjonalne. Testy systemowe i akceptacyjne zostają, ale trafia do nich mniej defektów.
Czym zajmuje się QA engineer w zespole pracującym w modelu shift-left?
Mniej czasu spędza na wykonywaniu testów po zakończeniu implementacji, a więcej na przeglądzie wymagań, projektowaniu strategii testów, automatyzacji i wspieraniu programistów oraz właściciela produktu. Jego rolą jest dbanie o to, żeby jakość była wbudowana w proces od pierwszego dnia.
Czy sylabus ISTQB Foundation Level obejmuje shift-left?
Tak. Sylabus CTFL v4.0.1 z istqb.org poświęca shift-left sekcję 2.1.5 i wymienia praktyki, które go realizują. Pojęcie wiąże z zasadą wczesnego testowania oraz z podejściami TDD, ATDD i BDD, więc wiedza z tego zakresu jest częścią przygotowania do certyfikacji.