W poprzednich lekcjach omówiliśmy techniki testowania skupiające się głównie na wykrywaniu defektów – czarnoskrzynkowe, białoskrzynkowe i oparte na doświadczeniu.

Jednak nowoczesne podejścia do tworzenia oprogramowania, zwłaszcza zwinne (Agile), kładą ogromny nacisk na współpracę i komunikację w zespole.

Sylabus ISTQB Foundation Level v4.0 w sekcji 4.5 (FL-4.5.1 K2, FL-4.5.2 K2, FL-4.5.3 K2) wprowadza podejścia do testowania oparte na współpracy (Collaborative Test Approaches).

Mają one na celu nie tylko wykrywanie, ale przede wszystkim zapobieganie defektom poprzez lepsze zrozumienie wymagań i wspólne budowanie jakości.

Kluczem jest tutaj zaangażowanie całego zespołu – programistów, testerów, analityków biznesowych, właścicieli produktu – we wczesne etapy definiowania i weryfikowania wymagań oraz projektowania testów.

Podejścia te promują wspólną odpowiedzialność za jakość i pomagają budować oprogramowanie, które faktycznie spełnia oczekiwania użytkowników.

W ramach tej lekcji przyjrzymy się trzem kluczowym elementom podejść opartych na współpracy, które są ze sobą ściśle powiązane:

1. Wspólne pisanie historyjek użytkownika (Collaborative User Story Writing)
2. Kryteria akceptacji (Acceptance Criteria)
3. Wytwarzanie sterowane testami akceptacyjnymi (Acceptance Test-Driven Development - ATDD)

Zrozumienie tych koncepcji jest fundamentalne dla efektywnej pracy w zwinnych zespołach i budowania wysokiej jakości oprogramowania od samego początku.

1. Wspólne Pisanie Historyjek Użytkownika (Collaborative User Story Writing)

Czym jest historyjka użytkownika? Historyjka użytkownika (User Story) to krótkie, proste opisanie funkcjonalności systemu z perspektywy użytkownika końcowego lub klienta.

Reprezentuje ona pewną wartość, którą użytkownik chce uzyskać dzięki systemowi. Jest to podstawowy element backlogu produktu w wielu metodykach zwinnych, takich jak Scrum.

Standardowy format: Najczęściej stosowany format historyjki to:

Jako [rola użytkownika],
chcę [wykonać jakąś akcję / osiągnąć cel],
abym mógł/mogła [uzyskać określoną wartość / korzyść biznesową].

Przykład: "Jako zarejestrowany klient, chcę dodać produkt do koszyka, abym mógł go później kupić."

Kluczowe aspekty historyjki użytkownika – „3 C” (Card, Conversation, Confirmation):

• Karta (Card): Fizyczny lub cyfrowy nośnik (np. karteczka samoprzylepna, wpis w Jirze), na którym zapisany jest krótki opis historyjki. Służy jako "token" reprezentujący wymaganie.
• Rozmowa (Conversation): Najważniejszy element! Historyjka to zaproszenie do dyskusji między członkami zespołu (programistami, testerami, analitykami, właścicielem produktu). Celem rozmowy jest dogłębne zrozumienie potrzeby użytkownika, kontekstu, potencjalnych scenariuszy użycia i ograniczeń. To właśnie podczas rozmowy wyjaśniane są szczegóły, które nie mieszczą się na karcie.
• Potwierdzenie (Confirmation): Kryteria akceptacji (omówione dalej), które definiują, kiedy historyjka zostanie uznana za zrealizowaną ("Done"). Stanowią one podstawę do testowania.

Dlaczego wspólne pisanie jest ważne?

Tradycyjnie wymagania były spisywane przez analityków i przekazywane dalej.

Podejście oparte na współpracy zakłada, że historyjki są tworzone i doprecyzowywane przez cały zespół. Dlaczego?

• Wspólne zrozumienie: Angażując różne role (biznes, development, testy) od początku, budujemy wspólne, głębsze zrozumienie wymagań i unikamy nieporozumień na późniejszych etapach.
• Perspektywa testowa od początku: Testerzy uczestniczący w tworzeniu historyjek mogą od razu zadawać pytania dotyczące testowalności, przypadków brzegowych, scenariuszy negatywnych i kryteriów akceptacji. Pomaga to tworzyć bardziej kompletne i testowalne historyjki.
• Identyfikacja ryzyk i zależności: Wspólna dyskusja pozwala wcześniej zidentyfikować potencjalne ryzyka techniczne, zależności między historyjkami czy niejasności w wymaganiach.
• Lepsza jakość wymagań: Historyjki stają się bardziej precyzyjne, kompletne i jednoznaczne, co bezpośrednio przekłada się na jakość implementacji.

Techniki wspierające wspólne pisanie:

• Burza mózgów (Brainstorming): Generowanie pomysłów na funkcjonalności i historyjki.
• Mapy myśli (Mind Mapping): Wizualne organizowanie pomysłów i zależności.
• Warsztaty Story Mapping: Ustrukturyzowane sesje, podczas których zespół wizualizuje przepływ użytkownika i dekomponuje go na historyjki.
• Spotkania refinementu backlogu (Backlog Refinement/Grooming): Regularne sesje, podczas których zespół omawia, doprecyzowuje i szacuje historyjki z backlogu.

Cechy dobrej historyjki – INVEST: Akronym INVEST pomaga ocenić jakość historyjek:

• Independent (Niezależna): Powinna być możliwa do zaimplementowania i przetestowania niezależnie od innych historyjek (choć zależności zawsze istnieją, dążymy do ich minimalizacji).
• Negotiable (Negocjowalna): Historyjka to punkt wyjścia do dyskusji, a nie sztywny kontrakt. Szczegóły powinny być doprecyzowane w rozmowie.
• Valuable (Wartościowa): Musi dostarczać konkretną wartość dla użytkownika lub klienta.
• Estimable (Szacowalna): Zespół powinien być w stanie oszacować wysiłek potrzebny do jej realizacji.
• Small (Mała): Powinna być na tyle mała, aby można ją było zrealizować w ramach jednej iteracji (sprintu).
• Testable (Testowalna): Musi być możliwe zweryfikowanie, czy została poprawnie zaimplementowana (tu kluczowe są kryteria akceptacji).

2. Kryteria Akceptacji (Acceptance Criteria)

Czym są kryteria akceptacji? Kryteria akceptacji to zestaw predefiniowanych warunków, które muszą zostać spełnione, aby historyjka użytkownika mogła zostać uznana za zakończoną ("Done").

Stanowią one konkretne, testowalne wymagania, które doprecyzowują ogólny opis zawarty w historyjce.

Są one kluczowym elementem "Potwierdzenia" (Confirmation) w modelu 3C.

Cel kryteriów akceptacji:

• Definiowanie zakresu: Wyjaśniają, co dokładnie obejmuje dana historyjka, a co nie.
• Usuwanie niejednoznaczności: Doprecyzowują wymagania, eliminując potencjalne nieporozumienia.
• Podstawa do testowania: Stanowią bezpośrednią podstawę do tworzenia testów akceptacyjnych (manualnych lub automatycznych).
• Komunikacja: Zapewniają wspólne zrozumienie między biznesem a zespołem deweloperskim co do oczekiwanego rezultatu.
• Definicja "Done": Pomagają określić, kiedy praca nad historyjką jest faktycznie zakończona.

Kto definiuje kryteria akceptacji? Podobnie jak historyjki, kryteria akceptacji powinny być definiowane we współpracy całego zespołu (właściciel produktu, analitycy, programiści, testerzy) podczas rozmów (Conversation) na temat historyjki.

Testerzy odgrywają tu kluczową rolę, dbając o to, aby kryteria były testowalne, jednoznaczne i pokrywały różne scenariusze (pozytywne, negatywne, brzegowe).

Formaty kryteriów akceptacji:

• Lista kontrolna (Checklist): Prosta lista warunków do spełnienia (np. "Pole X jest widoczne", "Przycisk Y jest aktywny").
• Reguły (Rules): Zestaw reguł biznesowych, które muszą być przestrzegane.
• Format scenariuszowy (Scenario-oriented): Najpopularniejszy format, często wykorzystujący składnię Gherkin (Given/When/Then).

Przykład (format scenariuszowy - Gherkin):

Dla historyjki: "Jako zarejestrowany klient, chcę dodać produkt do koszyka, abym mógł go później kupić."

Kryteria akceptacji:

Scenariusz: Dodanie produktu do pustego koszyka
  Biorąc pod uwagę (Given), że jestem zalogowanym klientem na stronie produktu
  I (And) mój koszyk jest pusty
  Kiedy (When) kliknę przycisk "Dodaj do koszyka"
  Wtedy (Then) produkt powinien zostać dodany do koszyka
  I (And) wskaźnik ilości produktów w koszyku powinien pokazywać "1".

Scenariusz: Dodanie tego samego produktu ponownie
  Biorąc pod uwagę (Given), że jestem zalogowanym klientem na stronie produktu
  I (And) dodałem już ten produkt do koszyka
  Kiedy (When) ponownie kliknę przycisk "Dodaj do koszyka"
  Wtedy (Then) ilość tego produktu w koszyku powinna wzrosnąć o 1
  I (And) wskaźnik ilości produktów w koszyku powinien zostać zaktualizowany.

Cechy dobrych kryteriów akceptacji:

• Testowalne: Musi być możliwe jednoznaczne sprawdzenie, czy warunek jest spełniony, czy nie.
• Jasne i zwięzłe: Powinny być łatwe do zrozumienia dla wszystkich członków zespołu.
• Kompletne: Powinny pokrywać kluczowe aspekty funkcjonalności opisanej w historyjce.
• Skoncentrowane na użytkowniku/biznesie: Powinny opisywać oczekiwane zachowanie z perspektywy wartości dla użytkownika.

3. Wytwarzanie Sterowane Testami Akceptacyjnymi (Acceptance Test-Driven Development - ATDD)

Czym jest ATDD? ATDD to podejście do wytwarzania oprogramowania oparte na współpracy, w którym testy akceptacyjne są tworzone przed rozpoczęciem kodowania.

Te testy, wynikające bezpośrednio z kryteriów akceptacji, służą jako specyfikacja oczekiwanego zachowania systemu i kierują procesem implementacji.

Cykl ATDD (często nazywany cyklem "Red-Green-Refactor" na poziomie akceptacyjnym):

1. Dyskusja (Discuss): Zespół (biznes, deweloperzy, testerzy) wspólnie omawia historyjkę użytkownika i definiuje kryteria akceptacji, często w formie testów akceptacyjnych (np. w Gherkin).
2. Formułowanie (Distill): Testy akceptacyjne są formalizowane w sposób zrozumiały zarówno dla ludzi, jak i potencjalnie dla narzędzi automatyzujących (jeśli stosowana jest automatyzacja).
3. Rozwój (Develop): Programiści implementują funkcjonalność, mając na celu sprawienie, aby zdefiniowane wcześniej testy akceptacyjne przeszły pomyślnie. Zazwyczaj zaczynają od napisania kodu, który powoduje, że testy (jeśli są zautomatyzowane) kończą się niepowodzeniem (stan "Red").
4. Demonstracja (Demo) / Wykonanie (Execute): Po zaimplementowaniu funkcjonalności, testy akceptacyjne są wykonywane (manualnie lub automatycznie). Jeśli przechodzą pomyślnie (stan "Green"), funkcjonalność jest uznawana za zgodną z oczekiwaniami. Jeśli nie, wraca się do kroku Rozwój. Opcjonalnie, można przeprowadzić demonstrację dla interesariuszy.
5. Refaktoryzacja (Refactor - opcjonalnie): Po uzyskaniu działającej funkcjonalności i przechodzących testów, kod może być refaktoryzowany (ulepszany wewnętrznie bez zmiany zewnętrznego zachowania), upewniając się, że testy nadal przechodzą.

Kluczowe korzyści ATDD:

• Wspólne zrozumienie wymagań: Proces tworzenia testów akceptacyjnych przed kodowaniem wymusza dogłębne zrozumienie wymagań przez cały zespół.
• Precyzyjna specyfikacja: Testy akceptacyjne stają się żywą, wykonywalną specyfikacją systemu.
• Zapobieganie defektom: Skupienie na testowalności i kryteriach akceptacji od początku pomaga unikać błędów wynikających z nieporozumień lub niejasnych wymagań.
• Wsparcie dla automatyzacji: Testy akceptacyjne, zwłaszcza te w formacie Gherkin, mogą być łatwo zautomatyzowane przy użyciu narzędzi takich jak Cucumber czy SpecFlow.
• Szybsza informacja zwrotna: Zautomatyzowane testy akceptacyjne dostarczają szybkiej informacji zwrotnej o stanie implementacji.
• Lepsza współpraca: ATDD naturalnie promuje bliską współpracę między różnymi rolami w zespole.

ATDD a TDD (Test-Driven Development): ATDD jest często mylone z TDD.

TDD (wytwarzanie sterowane testami jednostkowymi) to praktyka programistyczna, gdzie programista pisze mały test jednostkowy przed napisaniem kodu produkcyjnego, który ma ten test zaliczyć.

ATDD działa na wyższym poziomie – testów akceptacyjnych, które weryfikują zachowanie systemu z perspektywy biznesowej/użytkownika.

Oba podejścia mogą (i często są) stosowane razem.

Podsumowanie

Podejścia oparte na współpracy, takie jak wspólne tworzenie historyjek użytkownika, definiowanie kryteriów akceptacji i stosowanie ATDD, rewolucjonizują sposób myślenia o jakości oprogramowania.

Przenoszą one punkt ciężkości z późnego wykrywania defektów na wczesne zapobieganie im poprzez budowanie wspólnego zrozumienia i precyzyjne definiowanie oczekiwań.

Współpraca między biznesem, programistami i testerami od samego początku cyklu życia historyjki użytkownika jest kluczem do tworzenia oprogramowania, które nie tylko działa, ale przede wszystkim dostarcza realną wartość i spełnia potrzeby użytkowników.