Testowanie w Scrumie: Kompleksowy przegląd testowania w zwinnym zespole

Testowanie w Scrumie to wbudowanie testów w każdy Sprint, tak żeby każdy element Product Backlogu, który spełnia Definition of Done, był sprawdzonym i użytecznym Incrementem, a nie kodem czekającym na „fazę testów”. Scrum Guide 2020 nie zna stanowiska testera. Zna Developerów, Definition of Done i pięć wydarzeń. Poniżej pokazujemy, jak w tych ramach testować tak, żeby jakość nie była ostatnim punktem sprintu, tylko jego wynikiem.

Wiele tekstów o testowaniu w Scrumie wciąż opisuje „Zespół Deweloperski”, „ceremonie” i „metodologię”, czyli język sprzed listopada 2020 roku. To nie jest czepianie się słówek: zmiana nazw w Scrum Guide 2020 zmieniła też to, kto odpowiada za jakość. Jeśli w Waszym zespole tester czeka na „przekazanie do testów” pod koniec Sprintu, ten artykuł jest dla Was.

Czym jest testowanie w Scrumie według Scrum Guide 2020?

Według Scrum Guide 2020 Scrum to lekki framework (w polskim tłumaczeniu „uproszczone ramy postępowania”), który pomaga ludziom, zespołom i organizacjom tworzyć wartość przez adaptacyjne rozwiązania złożonych problemów. Nie jest metodologią ani procesem testowym. Nie mówi, jakimi technikami testować, kiedy uruchamiać regresję ani ile ma być testów automatycznych. Mówi za to bardzo konkretnie, kiedy praca jest skończona: gdy spełnia Definition of Done.

Dlatego testowanie w Scrumie zaczyna się od słownika. Poniżej zestawienie pojęć, które najczęściej pojawiają się w starszych opisach, z tym, co faktycznie stoi w aktualnym przewodniku.

O tym, czym Scrum różni się od Agile jako całości i kiedy lepiej sprawdza się Kanban, piszemy osobno w artykule Agile a Scrum: czym się różnią i jak pracować zwinnie. Tutaj zakładamy, że Scrum już macie, i skupiamy się na testach.

Gdzie jest tester, skoro Scrum zna tylko trzy odpowiedzialności?

Tester jest jednym z Developerów. Scrum Guide 2020 opisuje Developerów jako osoby w Scrum Teamie zaangażowane w tworzenie każdego aspektu użytecznego Incrementu w każdym Sprincie, a ich umiejętności są „często szerokie i zależne od dziedziny pracy”. Testowanie mieści się w tym bez żadnej gimnastyki.

Scrum Guide 2020 podaje, że Scrum Team liczy zwykle 10 osób lub mniej. W takim zespole jedna osoba z mocnymi kompetencjami testerskimi często wystarcza, pod warunkiem że nie jest jedyną osobą, która testuje. Sylabus ISTQB Certyfikowany Tester Poziom Podstawowy w wersji 4.0.1 z 2024 roku opisuje to jako podejście całego zespołu (whole team approach, podrozdział 1.5.2): każdy członek zespołu z odpowiednią wiedzą może wykonać każde zadanie, a za jakość odpowiadają wszyscy. Ten sam sylabus dodaje uczciwe zastrzeżenie: w systemach krytycznych dla bezpieczeństwa potrzebny bywa wysoki poziom niezależności testów, więc samo podejście całego zespołu nie wystarcza.

Z naszego doświadczenia najlepiej działa model, w którym tester jest „właścicielem pytań o jakość”, a nie „właścicielem testowania”. Pilnuje, żeby kryteria akceptacji były testowalne, podpowiada techniki, pisze testy w krytycznych miejscach i uczy programistów, jak testować resztę. Jeśli przygotowujecie się do pracy w takim modelu, podstawy technik testowych i podejścia zwinnego obejmuje szkolenie Foundation Level 4.0.

Jak testować w każdym z pięciu wydarzeń Scruma?

Scrum Guide 2020 wymienia pięć wydarzeń: Sprint, Sprint Planning, Daily Scrum, Sprint Review i Sprint Retrospective. Sprint jest kontenerem dla pozostałych czterech i trwa miesiąc lub krócej. Każde z wydarzeń to inna okazja do zadbania o jakość, a limity czasu poniżej podaje przewodnik dla Sprintu miesięcznego.

Szczególnie warto zatrzymać się przy Daily Scrum. Według Scrum Guide 2020 to 15 minut dla Developerów na sprawdzenie postępu w stronę Sprint Goal i dostosowanie Sprint Backlogu. To nie jest spotkanie statusowe dla kierownika ani raport „co zrobiłem wczoraj”. Przewodnik pozwala Developerom wybrać dowolną strukturę, byle skupiała się na postępie w stronę celu i dawała plan na kolejny dzień pracy. Daily, na którym każdy po kolei melduje, co robił wczoraj, nie jest Daily Scrumem, tylko porannym apelem z kawą w ręku.

Dla testera dobre Daily to miejsce, gdzie mówi: „historia 214 czeka na dane testowe, bez nich nie zamkniemy jej w tym Sprincie, kto mi pomoże”. To zdanie o Sprint Goal i o przeszkodzie, a nie raport z liczby wykonanych przypadków testowych. Przy Sprint Review z kolei zasada z przewodnika jest bezlitosna: element, który nie spełnia Definition of Done, nie może być nawet zaprezentowany na Review i wraca do Product Backlogu.

Czy refinement jest wydarzeniem Scruma i co robi w nim tester?

Nie jest. Scrum Guide 2020 opisuje doskonalenie Product Backlogu (Product Backlog refinement) jako ciągłe działanie: dzielenie elementów na mniejsze, bardziej precyzyjne i dodawanie szczegółów, takich jak opis, kolejność i rozmiar. Wiele zespołów organizuje na to stałe spotkanie w kalendarzu i to jest w porządku, tylko nie nazywajcie go szóstym wydarzeniem Scruma, bo przewodnik ma ich pięć.

Dla testera refinement to najtańsze miejsce na znalezienie defektu, bo defekt w wymaganiu nie ma jeszcze ani linijki kodu. Według raportu NIST z 2002 roku, w przykładowym zestawieniu względnych kosztów, naprawa defektu wykrytego na etapie wymagań kosztuje 1 jednostkę, na etapie kodowania 5, w testach integracyjnych i systemowych 10, a po wydaniu 30. W Scrumie te etapy dzieją się w ciągu kilku dni, ale proporcja zostaje: pytanie zadane na refinemencie jest tańsze niż defekt zgłoszony w środę przed Review.

Najlepszym narzędziem testera na refinemencie są przykłady. Zamiast kryterium „system obsługuje zwroty” zapiszcie zachowanie na konkretnych danych, z wartościami granicznymi. Poniżej przykład w składni Gherkin, z którym zespół wychodzi z refinementu:

Feature: Zwrot zamówienia w aplikacji sklepu

  # Kryteria akceptacji uzgodnione na refinemencie, zanim powstał kod
  Scenario: Zwrot w ustawowym terminie
    Given klient ma zamówienie dostarczone 13 dni temu
    When zgłasza zwrot jednego produktu
    Then system tworzy zgłoszenie zwrotu ze statusem "Oczekuje na paczkę"
    And klient dostaje etykietę nadania w mailu

  Scenario: Zwrot po terminie
    Given klient ma zamówienie dostarczone 15 dni temu
    When próbuje zgłosić zwrot
    Then system odrzuca zgłoszenie z komunikatem o upływie terminu
    And nie wysyła etykiety nadania

  Scenario Outline: Granica terminu zwrotu
    Given klient ma zamówienie dostarczone <dni> dni temu
    When zgłasza zwrot
    Then wynik zgłoszenia to "<wynik>"

    Examples:
      | dni | wynik      |
      | 14  | przyjęte   |
      | 15  | odrzucone  |

Taki zapis od razu ujawnia pytanie, którego nikt nie zadał: czy 14 dni liczymy od dostarczenia, czy od dnia po dostarczeniu? Lepiej usłyszeć je od testera na refinemencie niż od klienta w reklamacji. Więcej o samej składni piszemy w artykule język Gherkin: co to jest i jak go używać, a o tym, jak z takich scenariuszy zrobić testy akceptacyjne, w tekście testy akceptacyjne (UAT) i kryteria akceptacji.

Jak wygląda Definition of Done, która naprawdę chroni jakość?

Według Scrum Guide 2020 Definition of Done to formalny opis stanu Incrementu, który spełnia miary jakości wymagane dla produktu. W chwili, gdy element Product Backlogu spełnia DoD, powstaje Increment. Jeśli organizacja ma standard DoD, wszystkie zespoły muszą go stosować jako minimum, a jeśli go nie ma, Scrum Team tworzy własną.

Dobra DoD jest krótka, sprawdzalna i zapisana tak, żeby każdy mógł odpowiedzieć „tak” albo „nie”. Poniżej przykład dla zespołu webowego, który w naszych projektach często służy jako punkt startu do dyskusji:

Zwróćcie uwagę, czego w tej DoD nie ma: „tester zatwierdził”. Akceptacja nie zależy od podpisu jednej osoby, tylko od spełnienia kryteriów. Scrum Guide 2020 wymienia też Definition of Done wśród rzeczy, które Scrum Team sprawdza na Retrospektywie, więc DoD ma się zmieniać razem z dojrzałością zespołu. Dostępność cyfrowa jako część DoD to osobny, coraz ważniejszy temat, który rozwija Strefa QA w tekście o WCAG jako części Definition of Done.

Jak zmieścić regresję i automatyzację testów w Sprincie?

Bez automatyzacji testowanie w Scrumie zderza się ze ścianą po kilku Sprintach: każdy Sprint dokłada funkcji, a regresja ręczna rośnie, aż przestaje się mieścić w czasie. Sylabus ISTQB 4.0.1 łączy to z podejściem shift left (podrozdział 2.1.5) i z ciągłą integracją, która zachęca do częstego dostarczania kodu razem z testami.

W projekcie dla Argos, gdzie zajmowaliśmy się automatyzacją testów i uporządkowaniem procesów QA, regresja przed releasem skróciła się z 5 dni do 10 godzin, według danych potwierdzonych przez klienta. W kategoriach Scruma oznacza to różnicę między regresją, która zjada czwartą część dwutygodniowego Sprintu, a regresją, która mieści się w jednej nocy na pipeline. Jak to zrobić krok po kroku, opisujemy w case study jak skrócić testy regresyjne z 5 dni do 10 godzin.

Praktyczna kolejność w zespole scrumowym wygląda tak:

1. testy jednostkowe i API piszą się w tym samym Sprincie co funkcja, bo są najtańsze i najszybsze, zgodnie z piramidą testów,
2. testy interfejsu automatyzujecie tylko dla ścieżek krytycznych biznesowo, resztę sprawdzacie testami eksploracyjnymi,
3. zestaw regresji uruchamia się w pipeline przy każdej zmianie, a jego czas jest metryką omawianą na Retrospektywie,
4. dług testowy trafia do Product Backlogu jako widoczne elementy, a nie do szuflady testera.

Jeśli zespół nie ma kompetencji, żeby zbudować taki zestaw, warto zacząć od wsparcia przy automatyzacji testów albo od przejęcia testów regresyjnych na czas budowy własnych testów.

Jakie błędy w testowaniu w Scrumie widzimy najczęściej?

U naszych klientów te same pięć wzorców wraca niezależnie od branży. Każdy z nich formalnie „mieści się w Scrumie”, a w praktyce odtwarza kaskadę wewnątrz Sprintu.

Konflikty między programistami a testerami w jednym Sprincie dobrze opisuje Strefa QA w tekście o DEV i QA w jednym Sprincie. Jeśli chcecie przećwiczyć Scrum z całym zespołem na przykładach z Waszego projektu, służy do tego szkolenie metodyki zwinne Scrum i Agile, a liderom testów, którzy układają strategię testów dla kilku zespołów, szkolenia z zarządzania testami.

Powiązane na blogu Quality Island

• Agile a Scrum: czym się różnią i jak pracować zwinnie w praktyce
• Testy akceptacyjne (UAT): co to jest, rodzaje i kryteria akceptacji
• Shift left testing: co to jest, zalety, wady i jak wdrożyć
• Język Gherkin: co to jest i jak go używać
• Jak skrócić testy regresyjne z 5 dni do 10 godzin: case Argos

Pełna lista źródeł

• K. Schwaber, J. Sutherland, The Scrum Guide, wersja z listopada 2020, 2020. Stąd trzy odpowiedzialności, pięć wydarzeń, limity czasu, opis refinementu, Daily Scrum i Definition of Done.
• K. Schwaber, J. Sutherland, tłumaczenie polskie, Scrum Guide 2020, wersja polska (PDF), 2020. Stąd polskie nazwy: Developerzy, doskonalenie Product Backlogu, uproszczone ramy postępowania.
• ISTQB, Certified Tester Foundation Level, sylabus v4.0.1, 2024. Podrozdziały 1.5.2 Whole Team Approach, 1.5.3 Independence of Testing i 2.1.5 Shift Left.
• NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002. Tabela 5-1, względny koszt naprawy defektu według etapu wykrycia (przykład).
• Quality Island, case study Argos, dane własne 2026, liczby potwierdzone przez klienta.