Acceptance Test-Driven Development (ATDD)

Największe nieporozumienie wokół ATDD polega na tym, że ludzie traktują je jak narzędzie do automatyzacji testów. Tymczasem testy to efekt uboczny tej rozmowy — artefakt, który zostaje po dobrze przeprowadzonej dyskusji o wymaganiach.

Acceptance Test-Driven Development (ATDD) to podejście, które silnie wspiera współpracę między interesariuszami biznesowymi, programistami i testerami, koncentrując się na wspólnym zrozumieniu wymagań jeszcze przed rozpoczęciem implementacji funkcjonalności. Dla testera, ATDD to nie tylko sposób pisania testów – to zmiana roli: z „kontrolera jakości” na współtwórcę jakości już od samego początku cyklu życia funkcjonalności.

Najważniejsze założenia ATDD

1. Wspólne definiowanie akceptowalnych kryteriów

   • Akceptowalne kryteria (acceptance criteria) są tworzone razem: biznes + tester + deweloperzy.
   • Celem jest zbudowanie wspólnego zrozumienia potrzeby biznesowej, zanim kod zostanie napisany.
   • Przykładem są scenariusze w stylu Gherkin: Given–When–Then.

2. Testy akceptacyjne jako specyfikacja

   • Testy stają się żywą dokumentacją wymagań – są czytelne zarówno dla biznesu, jak i technicznych członków zespołu.
   • Specyfikacja testowa = definicja „co to znaczy, że funkcjonalność działa”.

3. Automatyzacja testów

   • Scenariusze ATDD są podstawą do testów automatycznych – np. w narzędziach takich jak Cucumber, SpecFlow, Behave, Robot Framework.
   • Testerzy współtworzą warstwę testów oraz często odpowiadają za ich automatyzację.

4. Testy pisane przed implementacją

   • W przeciwieństwie do tradycyjnego testowania, testy ATDD są pisane zanim powstanie kod.
   • Pomaga to projektować „pod testy” – czyli funkcjonalność, którą łatwo przetestować (czyli też często lepiej zaprojektowaną).

5. Nacisk na zachowanie systemu (behavior-driven)

   • Koncentracja nie na implementacji, ale na zachowaniu z punktu widzenia użytkownika końcowego.

Rola testera w ATDD

Tester w ATDD to aktywny uczestnik procesu tworzenia wartości, a nie tylko osoba testująca gotowy produkt.

1. Współpraca i facylitacja

   • Tester bierze udział w spotkaniach typu refinement, planning, Three Amigos.
   • Pomaga w budowaniu wspólnego zrozumienia wymagań.
   • Upewnia się, że kryteria są testowalne, mierzalne i kompletne.

2. Prowadzenie dyskusji o kryteriach akceptacyjnych

   • Zadaje pytania typu: „A co jeśli...?”, „Czy to też powinno być uwzględnione?”.
   • Dba o kompletność i zrozumiałość przypadków testowych.

3. Automatyzacja scenariuszy testowych

   • Współtworzy lub implementuje automatyczne testy akceptacyjne.
   • Pisze czytelne, stabilne i reużywalne testy.

4. Dbanie o jakość testów (test hygiene)

   • Unika duplikatów i zbędnej złożoności.
   • Utrzymuje testy w duchu clean code dla testów.
   • Pilnuje, by testy były odporne na zmiany i łatwe do utrzymania.

5. Mentor i edukator

   • Wspiera zespół w nauce ATDD i dobrych praktyk testowych.
   • Przenosi podejście ATDD na inne poziomy testowania – regresje, exploratory, systemowe.

Wartości ATDD z perspektywy testera

• Lepsza jakość od samego początku – mniej błędów i nieporozumień.
• Większe zaangażowanie testera w cykl życia funkcjonalności.
• Testy jako dokumentacja – zrozumiała i aktualna.
• Praca zespołowa – tester jako partner, nie kontroler.

Antywzorce w testach ATDD – przestrogi dla testera

• Scenariusze zbyt techniczne – niezrozumiałe dla biznesu.
• Scenariusze długie i złożone – trudne do zrozumienia i utrzymania.
• Brak przypadków brzegowych.
• Zależne testy – np. testy działające tylko po innych (chaining).
• Flaky tests – testy niestabilne, podważające zaufanie do wyników.

Checklist dla testera w ATDD

Uczestniczę w definiowaniu kryteriów akceptacyjnych.

Biorę udział w spotkaniach (np. refinement, Three Amigos), gdzie wspólnie z zespołem i interesariuszami doprecyzowujemy wymagania oraz ustalamy kryteria akceptacyjne.

Wspieram zespół w pisaniu scenariuszy Gherkin.

Pomagam przekładać wymagania biznesowe na scenariusze w formacie Given–When–Then, zrozumiałe zarówno dla biznesu, jak i zespołu technicznego.

Upewniam się, że scenariusze są testowalne i zrozumiałe.

Weryfikuję, czy scenariusze mają jednoznaczne i mierzalne kryteria. Zgłaszam niejasności i wspólnie je doprecyzowujemy. Scenariusze ATDD pisane są zwykle w języku naturalnym (np. Gherkin), ale z czasem ten język staje się częścią wspólnego słownika domenowego zespołu.

Współtworzę lub automatyzuję testy akceptacyjne.

Tworzę lub utrzymuję automatyczne testy akceptacyjne na bazie scenariuszy, korzystając z narzędzi takich jak Cucumber, SpecFlow czy Robot Framework.

Dbam o jakość, odporność i klarowność testów.

Analizuję testy pod kątem przejrzystości, stabilności i pokrycia przypadków. Unikam nadmiarowości i podatności na błędy.

Pomagam zespołowi rozwijać kompetencje ATDD.

Dzielę się wiedzą, prowadzę warsztaty lub wspieram innych w nauce ATDD, promując podejście zorientowane na wspólne zrozumienie wymagań i jakość.

---

Cecha / podejście	TDD	ATDD	BDD
Skupienie	Kod	Zachowanie	Zachowanie
Autor testów	Developer	Zespół (PO, QA, Dev)	Zespół
Poziom testów	Unit	Akceptacyjne	Akceptacyjne/systemowe
Narzędzia	JUnit, NUnit	Cucumber, SpecFlow	Cucumber, JBehave

---

Reference:

• Renu Rajani, "Testowanie kodu w praktyce".
• Markus Gärtner, "ATDD by Example".