Testowanie w Agile Część II

Tagi: 0

Cztery metody testowania w Agile

 

Dwa tygodnie temu przedstawiliśmy wam metodykę Agile. Omówiliśmy jej zalety, wskazaliśmy potencjalne trudności i opisaliśmy dwie najbardziej popularne metody wykorzystujące zwinne podejście: Scrum i Kanban.




W tym poście zapraszamy do zapoznania się z czterema najbardziej popularnymi metodami testowania oprogramowania w zwinnych zespołach. Zaczynamy!

Behavior Driven Development (BDD)

Wiele z nas słyszało lub używało Test Driven Development (TDD). Sporo programistów wykorzystuje je do pisania testów jednostkowych. Behavior Driven Development oparte jest na tych samych zasadach, co TDD, ale w miejsce testów jednostkowych, wymaga analizy na wyższym poziomie biznesowym. Zamiast zaczynać pracę od jednostkowych testów technicznych, BDD skupia się na wymaganiach opartych na zachowaniu odbiorcy końcowego. Przeprowadzone testy w niektórych przypadkach mogą nawet zastąpić część wymaganej dokumentacji. Wymagania oparte na zachowaniach, które produkt powinien wykazywać, tworzą hermetyczny przewodnik dla inżynierów do wykorzystania w trakcie opracowywania testów.

BDD zaczyna się od specyfikacji funkcjonalnej wykorzystującej składnię Gherkin Given/When/Then. Prowadzi ona programistów, testerów oraz właścicieli produktów, w dalszej pracy nad projektem. BDD używa zautomatyzowanych funkcji testowych do określenia kompletności kodu, dopóki nie przejdzie on testów, tak jak w TDD. By mieć pewność, że test przejdzie (co zwykle wymaga wielu prób), programista powinien tylko korygować kod, a nie dodawać do niego nowe funkcje.

BDD wymaga mądrej strategii automatyzacji, która zagwarantuje wysoki poziom wydajności. To podejście wyróżnia BDD od innych technik stosowanych w Agile. BDD zobowiązuje do wcześniejszego przygotowania przypadków testowych i przeprowadzenia ich w końcowej fazie. Używając tej techniki w zwinnym środowisku, testy nie są oparte na wymaganiach, a sam proces testowy odbywa się wraz z rozwojem funkcji.

Nierzadko zdarza się, że właściciele biznesowi projektu piszą testy, co redukuje komunikację (i ryzyko wystąpienia nieporozumień) między analitykami biznesowymi, programistami a testerami.

Najlepsze praktyki:

  • Usprawnienie dokumentacji w celu utrzymania całego procesu w dobrej formie
  • Utrzymanie modelu „three amigos”, gdzie właściciel produktu, programista i tester tworzą spójny zespół
  • Budowanie zautomatyzowanych testów w taki sposób, by później móc jak najcześciej z nich korzystać

laptop klawiatura czarny

Acceptance Test Driven Development (ATDD)

Zarówno Acceptance Test Driven Development, jak i BDD wymagają napisania testów jeszcze przed rozpoczęciem pracy, a kody, które powstaną, muszą przez nie przejść. Jednak w odróżnieniu od TDD, gdzie testerzy zwykle operują technicznymi testami jednostkowymi, ATDD to zwykle testy akceptacyjne, skierowane do klienta.

Głównym założeniem ATDD jest uznanie postrzegania produktu przez klienta za równie ważne, co jego funkcjonalność. ATDD zbiera dane wejściowe od użytkowników, wykorzystuje je do opracowania kryteriów akceptacji, przetłumaczenia ich na testy akceptacyjne manualne lub automatyczne, a następnie opracowuje kod na podstawie tych testów. Tak jak TDD i BDD, ATDD jest metodą test-first, a nie procesem opartym na wymaganiach.

Podobnie jak BDD, ATDD pomaga eliminować obszary potencjalnego nieporozumienia poprzez usunięcie konieczności interpretacji przez programistów sposobu, w jaki produkt będzie używany. ATDD idzie nawet o krok dalej; kieruje się prosto do źródła (czyli użytkownika końcowego), by zrozumieć jak produkt będzie użytkowany.

Najlepsze praktyki:

  • Ścisła współpraca z klientami, na przykład poprzez grupy focusowe, by precyzyjniej ustalić kryteria produktu
  • Opracowanie kryteriów akceptacji w oparciu o oczekiwania klienta
  • Priorytetowe traktowanie dwóch pytań: Czy klienci będą korzystać z systemu, jeśli będzie X? Jak możemy ocenić czy system wykonuje X?

góry odkrywca widok

Exploratory Testing (Testy eksploracyjne)

Testy eksploracyjne właściwie są typem testów funkcjonalnych, ale upowszechniły się w środowisku Agile. Zapewniają testerom swoiste „prawo własności” kodu, by ci mogli analizować go w chaotycznie uporządkowany sposób. W takim przypadku testerzy nie podążają utartą ścieżką, a raczej próbują wywołać błąd w oprogramowaniu. Dostarczają informacje o defektach, ale nie zawsze wraz ze szczegółową dokumentacją.

Tego typu testy nie są skryptowane. Chodzi raczej o opracowanie możliwie najlepszych testów opartych na każdym, unikalnym fragmencie oprogramowania. Z uwagi na nieskryptowe podejście, testy eksploracyjne często naśladują interakcje użytkowników z oprogramowaniem w prawdziwym życiu.

Testowanie eksploracyjne odbywa się zgodnie z czterema kluczowymi zasadami:

  • Równoległe planowanie testów, projektowanie testów i wykonywanie ich
  • Specyficzny, ale elastyczny
  • Dostosowany do badania potencjalnych szans
  • Dzielenie się wiedzą

Najlepsze praktyki:

  • Porządkowanie funkcji w aplikacji. Można do tego użyć Mindmap czy arkusza kalkulacyjnego
  • Koncentrowanie się na konkretnych obszarach lub konkretnych scenariuszach
  • Dokumentowanie wyników analiz korzystając z narzędzia takiego, jak qTest Explorer, które umożliwiają pewien wgląd do tego, co zostało zrobione.

Session Based Testing (Testy oparte na sesjach)

Ten rodzaj testowania oparty jest na testach eksploracyjnych, jednocześnie zapewniając lepszą strukturę. Ponieważ testowanie eksploracyjne jest nieskryptowane, utrudnia to wskazanie osób odpowiedzialnych i opiera się w głównej mierze na umiejętnościach oraz doświadczeniu zaangażowanych testerów. Analiza oparta na sesjach ma na celu złagodzenie tych wad, poprzez wprowadzenie struktury do badań eksploracyjnych, jednocześnie nie rezygnują z korzyści, jakie zapewnia testowanie eksploracyjne; możliwość lepszego naśladowania doświadczenia użytkowania czy kreatywności podczas analiz.

Testowanie oparte na sesjach zapewnia strukturę przez przeprowadzanie analizy w ściśle określonych przedziałach czasowych, w oparciu o wytyczne oraz wymagając od testerów raportowania analizy po każdej zakończonej sesji. Dodatkowo testy takie powinny zostać zakończone wymianą informacji między testerami a managerami projektu na podstawie zasady PROOF:

  • Co się wydarzyło/ What happened (Past)
  • Co zostało osiągnięte/ What was achieved (Results)
  • Co stanowiło przeszkodę/ What got in the way (Obstacles)
  • Co wciąż trzeba zrobić/ What still needs to be done (Outlook)
  • Jak tester czuje się z tym zadaniem/ How does the tester feel about it (Feelings)

Najlepsze praktyki:

  • Przedstawienie misji, by testerzy mieli pełen obraz tego, co poddają analizie
  • Opracowanie jasnych wytycznych dotyczących misji i obszarów programowania do przetestowania. Wskazanie, którzy testerzy będą przeprowadzali sesję, kiedy będzie miała miejsce i jak długo będzie trwała, jak testy zostaną zaprojektowane i przeprowadzone. Omówienie znalezione błędów i przedstawienie ogólnych uwag (podobnie, jak w przypadku testów eksploracyjnych, przydatne może okazać się narzędzie do dokumentacji procesów)
  • Przeprowadzanie sesji testowej bez żadnych przerw
  • Wyraźne dokumentowanie działań i prowadzenie notatek podczas sesji
  • Przeprowadzenie podsumowania dla testerów i managerów, by przejrzeć ustalenia z sesji i omówić kolejne kroki postępowania

Mamy nadzieję, że ten krótki przekrój przez cztery najbardziej popularne metody testowania oprogramowania w zwinnym środowisku, okazał się dla was przydatny i że dzięki niemu poczujecie się pewniej, gdy traficie do zwinnego zespołu w przyszłości lub wasz obecny zespół przejdzie na zwinne metodyki pracy.

Czy znacie inne metody testowania w środowisku Agile? Piszcie w komentarzach! 🙂

DYSKUSJA

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

wypróbuj

Zarejestruj się i zacznij działać!