“O co im w ogóle chodzi?”

  • Product Owner

“O co mu w ogóle chodzi?”

  • Programiści

Chociaż powyższe zdania mogą powodować lekki uśmiech, to jednak powszechność występowania tego zjawiska w świecie IT nie jest już tak zabawna. Tak często potrzeby szeroko rozumianego „biznesu” są źle przekładane na język zrozumiały dla developerów, że istnieje cały szereg kursów, szkoleń, metodyk pracy itd. mających na celu jedno: usprawnienie komunikacji pomiędzy interesariuszami projektu. Według różnych badań *(link) najczęściej wymieniane 5 przyczyn porażek projektu wiążą się ze złym zarządzaniem, a konkretniej z brakiem:

  • Potrzeb rynkowych
  • Wsparcia kierownictwa
  • Jasno określonych wymagań
  • Właściwego planowania
  • Realistycznych oczekiwań

Pomijając pierwszy czynnik z powyższej listy, na który nie mamy realnego wpływu w trakcie realizacji projektu, to pozostałe jej elementy zwyczajowo sprowadzają się do braku bądź niewłaściwej komunikacji.

Jak to się ma do kodowania i programowania? W każdym projekcie zleceniodawca przekazuje listę wymagań, jakie ma spełniać jego wymarzony, długo oczekiwany produkt. Jeżeli nie dojdzie do wzajemnego zrozumienia, czym konkretnie będzie klucz, według którego produkt zostanie odebrany? Może dojść do nieporozumień: klient nie będzie chciał zapłacić za produkt, którego nie zamawiał, wykonawca zaś będzie się czuł poszkodowany, bo początkowe założenia projektu mogły być źle sprecyzowane bądź błędne. Więc dlaczego tym kluczem nie miałby być scenariusz testowy? Np. taki jak poniżej:
(Jeszcze w ramach krótkiego wyjaśnienia: w projektach IT właściwym językiem jest angielski i w tym języku powinny być pisane scenariusze testowe. Jest to istotne chociażby ze względu na fakt, że realizacja poszczególnych podzadań może zostać zlecona do zagranicznego podwykonawcy.)

Feature: Login functionality

 Scenario: As a guest I want to log in to the system  
  When I’m on the homepage  
    And I fill “username” field with “adam”  
    And I fill “password” field with “AbbCC00”  
    And I click “Log in” button  
  Then I want to see “Welcome back, adam!”  
    And I want to see “Log out” button  
         And I don’t want to see “Log in” button  

 Scenario: … (scenario 2) …  

Proste, prawda? Sam scenariusz jest doskonale zrozumiały: wchodzę tutaj, wpisuję to, wpisuję tamto, klikam przycisk i widzę to i tamto. Jednak rozpisanie tak kluczowych funkcjonalności powoduje, że strona zlecająca zaczyna rozumieć stopień skomplikowania i złożoność zamawianego systemu; wymagania są jasne dla wykonawcy, który może precyzyjnie zaplanować swoją pracę oraz cały projekt.

Wszystko pięknie, tylko trzeba odpowiedzieć na pytanie: gdzie i jak to stosować? Pisać na kartce, drukować, nauczyć się na pamięć? Otóż… cała idea tego pomysłu polega na tym, że jest to test automatyczny. Powyższy listing to zawartość pliku uruchamianego przez środowisko testowe z wykorzystaniem przeglądarki WWW, które automatycznie sprawdzi poprawność wykonywanych kroków i zgłosi wszelkie nieprawidłowości. System też doczekał się pełnego wsparcia w niektórych IDE (np. PHPStorm), przez co tworzenie scenariuszy sprowadza się do wybierania kolejnych, już zdefiniowanych kroków, a w przypadku braku implementacji danego kroku, napisanie jej jest bardzo proste. Poniższy fragment kodu interpretuje sprawdzenie, czy użytkownik może przejść jak i samo przechodzenie do podanego katalogu:

class FeatureContext extends MinkContext  
{  
   …  

   /**   
    * @Given /^I am in a directory "([^"]*)"$/  
    */  
   public function newStepToImplement($dir) {  
      if (!file_exists($dir)) {  
             throw new Exception(“Cannot find given dir!”);  
           }  
           chdir($dir);  
   }  
 …   
}  

Jak widać na powyższych przykładach, tworzenie scenariuszy oraz ich implementacji jest bardzo proste.

Mając już tak przygotowane narzędzie dość łatwo można wyobrazić sobie następujący przebieg zlecenia:

  • Zleceniodawca (PO) chce wdrożyć potrzebną mu funkcjonalność do systemu
  • Rozpisuje scenariusze pokazujące zespołowi developerów, jak dana funkcjonalność MUSI się zachowywać, żeby spełnić kryteria akceptacji
  • Developerzy realizują zadanie – w którego trakcie PO może sprawdzić przebieg zadania, prosząc o podesłanie bieżącego wyniku testu
  • Po ukończeniu pracy developerzy pokazują rezultat testu jako potwierdzenie spełnienia kryteriów odbioru.

Jak widać na powyższej uproszczonej liście schemat postępowania jest nie tylko bardzo przejrzysty, ale niesie ze sobą olbrzymią korzyść, która na pierwszy rzut oka jest niewidoczna: zarówno zleceniodawca jak i zleceniobiorca doskonale rozumieją, co jest do zrobienia. Dzięki wdrożeniu testów BDD obydwie strony oszczędzają mnóstwo czasu na ustalaniu, co druga strona miała na myśli, pisząc/realizując zlecenie. Dodatkową korzyścią jest też sam fakt istnienia i spisania scenariuszy testowych, które przy testach regresyjnych doskonale ukazują stabilność aplikacji przy wdrażaniu nowych funkcjonalności.

W ostatnim czasie testy BDD zyskują kolejnych zwolenników, pomimo iż jest to względnie nowe podejście. Niesie jednak ze sobą tak wiele korzyści, że warto mu się bliżej przyjrzeć. Nigdzie nie jest przecież zabronione wybieranie i dostosowywanie do swoich potrzeb fragmentów danego rozwiązania: a tych do wyboru jest tutaj multum.