W technice BDD tak na prawdę nie istnieje takie pojęcie jak testy akceptacyjne. Ściślej mówiąc nie istnieje nawet coś takiego jak test. Podstawą do kontroli poprawności działania aplikacji lub funkcjonalności są specyfikacja i scenariusze działania. BDD (Behaviour Driven Development), jak sama nazwa wskazuje opiera się na pewnych zachowaniach, które wynikają ze specyfikacji lub scenariuszy. W przeciwieństwie do TDD czy innych metod testowania aplikacji nie sprawdzasz w jaki sposób i z wykorzystaniem jakich metod działają funkcjonalności, ale jesteś zorientowany na cel. Idealny do zobrazowania tej metody jest przykład dwóch absolwentów: Pierwszy studiuje informatykę, ale nie lubi swoich studiów, uczy się bo musi i nie jest dobrym informatykiem, choć jego przyszly zawód to Informatyk. Drugi to student prawa, którego pasją są komputery, zna się bardzo dobrze na tym temacie i choć jest z zawodu Prawnikiem, to zachowuje się jak Informatyk. Teraz mając do wykonania pewne zadanie informatyczne nie sprawdzamy czy wykonał je Informatyk tylko czy wykonała je osoba zachowująca się jak Informatyk. To podejście, zupełnie odmienne w stosunku do testów jednostkowych, sprawia że testowanie aplikacji znacznie się skraca i dotyczy tylko funkcjonalności, które faktycznie wymagają takich testów.
A teraz do dzieła. Jak powinna wyglądać poprawnie przygotowana specyfikacja? Przede wszystkim powinna zawierać pełną listę funkcjonalności wymaganych przez klienta. Specyfikacja to nie zbiór pytań czy warunków typu:
- Czy użytkownik może się zarejestrować przy użyciu loginu i hasła?
- Użytkownik powinien mieć możliwość zalogowania się przy użyciu loginu i hasła.
- etc.
Przykłady
Poprawna specyfikacja opisuje konkrentą część aplikacji, opcjonalnie w jakimś kontekście, mówiąc jakie ma możliwości. Trochę to skomplikowane, ale poniższy przykład wszystko wyjaśni:- Użytkownik
- podczas rejestracji
- loguje się przy użyciu loginu, hasła i adresu mailowego
- otrzymuje potwierdzenie rejestracji z linkiem aktywacyjnym na podany adres email
- dokonuje aktywacji poprzez wejscie na otrzymany adres
- zostaje automatycznie zalogowany do panelu klienta
Tak przygotowana specyfikacja daje się wykorzystać w dwóch sytuacjach. Przede wszystkim programista wykorzystując w swoim języku którąś z bibliotek *spec (rspec, phpspec, jspec, pyspec etc) nie musi w żaden sposób jej modyfikować, wystarczy że odpowiednio obstawi opis, kontekst i funkcjonalność metodami z w/w biblioteki i dopisze do tego odpowiednie testy. Z kolei wyniki tych testów możesz przedstawic partnerowi/klientowi w postaci bardzo zrozumiałego i czytelnego raportu.
Z podobną sytuacją masz do czynienia w przypadku scenariuszy. Scenariusze różnią się od specyfikacji tym, że określają pewne działania a nie funkcjonalności. Co to onacza? Oznacza to, że w scenariuszu klient opisuje jak mają działać poszczególne funkcjonalności, nie od strony kodowej a od strony użytkownika. Najczęściej scenariusze opisują zachowania interfejsu użytkownika, komunikacji, wymiany danych, etc. A tak powinny wyglądać scenariusze:
- Rejestracja użytkownika
- Klient wchodzi na stronę rejestracji
- i widzi pola do wpisania loginu, hasła, potwierdzenia hasła oraz adresu email, i checkbox z akceptacją regulaminu
- i widzi przycisk "Zarejestruj się"
- Kiedy wypełni wszystkie dane i zaakceptuje regulamin i kliknie przycisk "Zarejestruj się"
- to zostaje przekierowany na stronę główną
- i zostaje poinformowany, że na podany przez niego adres mailowy zostało wysłane potwierdzenie
- Aktywacja konta
- Dany użytkownik po odebraniu maila aktywacyjnego wchodzi na zamieszczony w nim link
- i zostaje poinformowany na stronie, że jego konto zostało aktywowane
- widzi link "Teraz możesz się zalogować" prowadzący do strony logowania
- kliknie link "Teraz możesz się zalogować"
- zostaje przeniesiony do strony logowania
- Poprawne logowanie
- Dany użytkownik będąc na stonie logowania
- widzi pola do wpisania loginu i hasła
- oraz przycisk "Zaloguj się"
- Kiedy poda dobry login i hasło, i kliknie przycisk "Zaloguj się"
- to zostaje przekierowany do swojego panelu klienta
- Nieprawidłowe logowanie
- Dany użytkownik będąc na stonie logowania
- widzi pola do wpisania loginu i hasła
- oraz przycisk "Zaloguj się"
- poda nieprawidłowy login lub hasło, i kliknie przycisk "Zaloguj się"
- otrzymuje informację, że podane przez niego dane są nieprawidłowe
Podsumowanie
Trochę się rozpisałem z tymi scenariuszami. Zależało mi na pokazaniu Ci, że ta sama funkcjonalność w momencie gdy może zachowywać się na dwa sposoby, wymaga napisania dwóch osobnych scenariuszy. Teraz tak samo jak w przypadku specyfikacji, programista może przygotować odpowiednie testy za pomocą narzędzi takich jak Cucumber, a wynik scenariuszy możesz przedstawić klientowi w postaci raportu. Przy pomocy bardziej zaawansowanych narzędzi (np. Selenium) programiści mogą również przygotować symulacje działania takich scenariuszy, w których klient na żywo będzie mógł prześledzić ich działanie.
Przygotowanie scenariuszy oraz specyfikacji ma jeszcze jedną ogromną zaletę. Znacznie obniża mozliwość wystąpienia nieporozumień na płaszczyźnie klient - wykonawca (PM), oraz już wewnątrz firmy, tzn. pomiedzy PMem a programistami. Dzieje się tak, ponieważ specyfikacja przygotowana przez PM-a wspólnie z klientem jest zrozumiała zarówno dla klienta jak i dla programisty. Mało tego - jest zrozumiała również dla samych narzędzi wykonujących testy. Drugą ogromną zaletą jest częściowe przeniesienie odpowiedzialności. Co to oznacza? Jest to nic innego jak zabezpieczenie się przed roszczeniami ze strony klienta, w przypadku kiedy coś działa nie "tak jak on sobie to wyobrażał". Skoro masz przygotowane wspólnie z klientem specyfikacje i scenariusze, które klient w 100% zatwierdził, to fakt, że testy na ich podstawie przechodzą jest Twoim głównym argumentem w sytuacjach spornych. Krótko mówiąc: jest specyfikacja i aplikacja działa zgodnie z nią, więc możesz być spokojny. Oczywiście takie podejście należy stosować w ostateczności, a najlepiej unikać go poprzez jak najdokładniejsze przygotowanie specyfikacji i scenariuszy, bo to pomoże oraz ułatwi pracę i komunikację wszystkim: klientom, wykonawcy i programistom.
Krzysztof Kowalik, grudzień 2009