Behavioral Driven Development in Practice

Remigiusz Dudek – Luxoft

Behavior Driven Development has already been around for a while. In my project we have been using BDD/JBehave for two years. We’ve started with a great enthusiasm, we were convinced that BDD is the right paradigm to develop our tests. Nevertheless after short period of time (aprox. 6 months) we’ve noticed that adding new scenario becomes harder and harder. At the same time, JBehave that was supposed to be our new documentation became unreadable hence unmaintenable. In order to fix the situation we were in, we had to revise our approach to JBehave and BDD in general. During this workshop I will not only cover concepts of JBehave but also I will present you the dark side of BDD, the side that as for now can very rarely be found on blogs.

Whole workshop is divided into two parts.

During first part you will gain general knowledge about Behavior Driven Development concepts, why it is worth to follow this notion in the first place.

For this part there is a very simple application created that will allow you to explore basics of JBehave:

• story file + steps = test scenario
• Given / When / Then notation
• passing/parsing variable
• examples table .vs. Tabular parameters
• Jbehave configuration

You will also learn two ways of how to embed JBehave tests into an existing test environment:

• using command line to run jBehave tests
• using Junit framework

Having basics covered I will also describe what are the mistakes that may make your automation suite un-maintainable and un-understandable in a very short period of time.

Second part of the workshop is devoted to Spring based application and how JBehave can be integrated into such environment. We will use another sample application that will allow us to explore the world of Spring-jms and you will have a chance to gain a hands-on experience in writing real system tests in such environment.

In order to efficiently participate in the workshop you need to fulfill either of the requirements:

1. Install VirtualBox (the image you will find on TestWarez website contains all necessary configuration + IntelliJ 12 with appropriate projects already imported)
2. Create you own configuration on your laptop (on TestWarez website you will find maven repository containing all needed libraries and sourcecode of two sample applications in a form of a maven project – ready to be imported into any IDE):
   • Active-mq (preferably 5.8)
   • Maven 3
   • IDE

Zwinny zespół testujący. Do połowy zależny czy do połowy niezależny?

Artur Górski – Motorola Soultions

Czy sposób zarządzania zespołem testującym w zwinnych projektach ma wpływ na skuteczność testowania, dystrybucję defektów oraz osiągnięcie potencjalnego sukcesu projektu ? Po przeanalizowaniu wyników trzech projektów o podobnym czasie trwania, procesie, złożoności i liczbie zasobów, w których zastosowano różne modele zarządzania, zauważono znaczne różnice w efektywności testowania.

Do najczęściej spotykanych modeli należy dołączenie dedykowanych osób (lub osoby) testujących do zespołu lub rozłożenie obowiązków testerskich pomiędzy wszystkich członków. Niestety zastosowanie jednego z ww. rozwiązań niesie za sobą kilka wad tj. zanikającej asertywności, nie logowania defektów, obniżania priorytetu testowania itd. a także powoduje nie spełnianie oczekiwań większości kluczowych interesariuszy. Co jest głównie spowodowane brakiem wiedzy na temat ich oczekiwań.

Na podstawie wniosków wysuniętych z dwóch poprzednich projektów, w których zastosowano testowanie wykonywane przez dedykowane zasoby (I projekt) oraz rozłożenie testowania wewnątrz zespołu (II projekt), a także po przeanalizowaniu oczekiwań wszystkich kluczowych interesariuszy został stworzony model zarządzania testowaniem, którego głównym celem zostało zwiększenie prewencji oraz wykrywalności defektów we wczesnych fazach wytwarzania oprogramowania.

Podczas prezentacji zostanie pokazana:
– skuteczność wykrywania defektów dla każdej z metod do zakończenia: fazy implementacji produktu i fazy stabilizacji;
– dystrybucja oraz skumulowana krzywa przychodzenia usterek;
– przykładowa analiza interesariuszy z punktu widzenia kierownika zespołu testującego;
– komunikacja oraz proces;

Dodatkowo jedna z sekcji dotyczy sposobu realizacji planu zarządzania ryzykiem produktowym, który w efekcie pozwolił na: wykrycie najważniejszych błędów na samym początku testowania, efektywne zarządzanie regresją, koncentrowanie wysiłku przeznaczonego na prewencję oraz testowanie reakcyjne na najbardziej ryzykowne obszary i wiele innych.

Prezetacja: Artur Gorski – Zwinny zespol testujacy. Do polowy zalezny czy do polowy niezalezny

Automatyzacja bez nadmiernego bólu

Piotr Januszek – hybris

Techniką, która sprawia wiele trudności w procesie testowania jest automatyzacja testów. Każdy, kto podejmuje się jej implementacji, liczy na to, że zwiększy jakość produktu oraz zagwarantuje krótszy czas spędzony na testach regresywnych. Niestety w wielu przypadkach funkcjonalne testy automatyczne stają się koniem trojańskim. Automatyzacja zamiast rozwiązać nasze problemy, sama staje się problemem.

Głównym tematem prezentacji będzie pokazanie metodologii użytej przy automatyzacji, bazującej na testowaniu przy użyciu słów kluczowych oraz omówienie problemów napotkanych podczas jej implementacji wraz z ich rozwiązaniami. Pokazane zostanie jak doprowadzić do tego, aby automatyzacja stała się silnym punktem procesu testowego, mimo ciągle zmieniających się wymagań.

Prezentacja bazować będzie na skutecznej automatyzacji, którą wprowadzano w firmie tworzącej kompleksową platformę e-commerce’ową. Omówione zostanie pierwsze, nieudane podejście do automatyzacji, oraz co doprowadziło do jej porażki. Następnie pokazane zostanie z jakimi problemami (nie tylko technicznymi) się spotkano i w jaki sposób zostały one rozwiązane. Przedstawiony zostanie również proces i struktura testów jako przykład uniknięcia błędów.

Prezentacja: Piotr Januszek – Automatyzacja bez nadmiernego bolu

Continuous delivery – is it possible?

Robert Kornaś – ATSI

Referat koncentruje się na prezentacji i analizie tzw. zwinnego sposobu wytwarzania, testowania oraz wdrażania oprogramowania (agile software development) przy pełnej współpracy zespołu deweloperskiego oraz klientów. Zaproponowane zostało podejście wspólnej odpowiedzialności (everyone contributes to the outcome), w którym poszczególne jednostki partycypujące w procesie tworzenia produktu osiągają efekt końcowy z uwzględnieniem potrzeb i obowiązków pozostałych członków grupy. Ten styl został osiągnięty dzięki ciągłemu i nieprzerwanemu rozwojowi w trakcie kilkuletniej pracy zespołu
deweloperskiego. Jasny i przejrzysty zakres zobowiązań pozwolił na zwiększenie wydajności testów, wyeliminowanie powtarzalności tych samych błędów oraz nieprzerwany rozwój.

W opisywanej metodologii zespół definiowany jest jako grupa specjalistów posiadających pełną wiedzę niezbędną do wykonania produktu. Programista, tester i klient wspólnie biorą udział w procesie testowania, chociaż odbywa się to na różnych płaszczyznach. Wprawdzie zespół specjalizuje się w webowych systemach biznesowych, ale ponieważ schemat działań jest dopracowany i sprawdzony, może on zostać wdrożony i zastosowany również do projektów innego rodzaju.

Wydajny proces testowania powinien opierać się na mocnych filarach. Zostały one opisane w formie: testów automatycznych (automatic tests), ciągłej integracji (continuous integration), ciągłego wdrażania (continuous deployment) oraz pełnej automatyzacji procesu testowego. W referacie zostanie zaprezentowana analiza poszczególnych narzędzi oraz procedur jako konkretnych przykładów uniwersalnych rozwiązań.
Ponieważ wysoka jakość produktu traktowana jest jako główne kryterium w całym procesie wytwarzania oprogramowania, testowanie staje się najważniejszym z zagadnień, poddawanym nieustannej weryfikacji i poprawie. Analizowany tutaj styl zwinnego wytwarzania oprogramowania przybliży również różnorodne problemy związane ze zwinnym testowaniem, a szczególnie współpracą programistów, testerów i odbiorców produktu.

Zostaną przedstawione bardzo zdecydowane i konsekwentne działania zespołu, które zaowocowały przejrzystością całego procesu testowego, podniesieniem jakości dostarczanych produktów oraz skróceniem czasu ich wdrożenia. Powyższa metodologia wraz z osiągniętymi rezultatami, jak również innowacyjnymi procedurami, powinna posłużyć jako “mapa drogowa” dla mniej doświadczonych grup, które nadal pracują nad stworzeniem optymalnego podejścia do testowania swoich produktów. Dostarczy ona również materiału porównawczego dla bardziej doświadczonych zespołów projektowych.

Interesującym aspektem będzie prezentacja sposobu pracy mocno zdyscyplinowanego zespołu deweloperskiego, który instaluje rozwijane oprogramowanie na serwerach produkcyjnym kilka razy dziennie! Ten dojrzały model został osiągnięty przy użyciu wielu stopni weryfikacji rozwijanego oprogramowania oraz mechanizmu „bezpiecznego” włączania/wyłączania wprowadzonych funkcjonalności.

Stosowana praktyka ciągłej integracji oraz instalacji zapewnia niemalże natychmiastowe wdrożenie bez potrzeby oczekiwana na tak zwany dzień wdrożenia. Istnieje możliwość szybkiej reakcji na pojawiające się problemy oraz szanse. Klienci biznesowi i właściciele produktów nie muszą czekać tygodniami lub miesiącami na poszczególne wydania. W zależności od wielkości kwestii, jest ona dostarczana w ciągu kilku dni. Dzięki mechanizmowi „bezpiecznego” włączania/wyłączania danej funkcjonalności dla poszczególnych użytkowników, testy akceptacyjne lub wydajnościowe mogą być wykonywane na serwerze produkcyjnym przez wybrane osoby. Nie ma również przeciwwskazań aby realizować konkretne wymaganie na kilka
różnych sposobów, udostępniać je poszczególnym grupom użytkowników, przeprowadzać analizy i zbierać statystyki w celu wyboru najlepszego z nich.

Prezentacja ma na celu skłonić do refleksji nad tym jak długi jest czas od przekazania idei do wdrożenia działającego oprogramowania. Dzięki dużej popularności SCRUM’a oraz innych metod iteracyjnych, dwutygodniowe lub tygodniowe wdrożenia nie są niczym niezwykłym; dlaczego więc nie możemy wdrażać naszego oprogramowania codziennie lub kilka razy dziennie?

Sądzę, że zatraciliśmy się w swoich „obozach” programistycznych, testerskich, wdrożeniowych czy utrzymaniowych, w których oprogramowanie przerzucane jest niczym piłeczka od jednych do drugich. Pomimo wielu starań, w poszczególnych grupach nadal nie myślimy rynkowo o rozwijanym oprogramowaniu. Dla ludzi biznesu jedyną wartością w całym procesie jest działające oprogramowanie. To ono powinno być zwrotem z inwestycji, dlatego powinniśmy dążyć do maksymalnego skrócenia czasu wdrożenia zgodnie z zasadą Lean software development „Deliver as fast as possible”.

Prezentacja: Robert Kornas – Continuous delivery – is it possible

Testy z wykorzystaniem SoapUI

Jacek Okrojek

SoapUI to zyskujące sobie coraz większą popularność narzędzie wspomagające testy funkcjonalne, obciążeniowe oraz bezpieczeństwa. Zyskuje sobie zwolenników przede wszystkim ze względu na łatwość obsługi i dużą funkcjonalność. Atutem aplikacji jest możliwość wykorzystnia skryptów Groovy jako elementów testów oraz procesu ich uruchamiania.
W trakcie warsztatu uczestnicy poznają podstawy języka Groovy. Przedstawiony zostanie sposób pracy z podstawowymi typami danych, a także operowanie na plikach i wykorzystanie wyrażeń regularnych. Poznając model obiektów soapUI uczestnicy nauczą się wykorzystywać zdobyte wiadomości do rozszerzania możliwości aplikacji. Zadania i ćwiczenia będą dotyczyć testowania z wykorzystaniem losowych danych, Data Driven Testing oraz tworzenia własnych raporów. Uzupełnieniem będzie prezentacja ciekawej chociaż mniej znanej funkcji jaką jest symulowanie usług.

Od uczestników wymagana jest podstawowa wiedza na temat aplikacji soapUI. Osoby, które nie miały okazji pracować z aplikacją proszę o zapoznanie się z informacjami na stronie http://www.soapui.org/Functional-Testing/functional-testing.html

Zastosowanie sztucznej inteligencji w testowaniu oprogramowania

Tomasz Osojca – CORRSE

Celem prezentacji jest zainteresowanie słuchaczy możliwościami wykorzystania sztucznej inteligencji (AI) w testowaniu oprogramowania. Przedstawienie przeglądu istniejących oraz możliwych, zdaniem autora zastosowań, oraz zaproszenie do wspólnej pracy badawczo-rozwojowej w tym zakresie.
W ramach wprowadzenia w temat przedstawiona zostanie definicja testowania jako “problemu optymalizacji i wnioskowania”. Tak zdefiniowany “problem testowania” zostanie zestawiony z przykładowym problemem klasy NP (problem niederministyczny, wielomianowy) – problemem komiwojażera. Problemy klasy NP charakteryzują się tym, iż trywialne rozwiązanie (w przypadku problemu komiwojażera – obliczenie długości wszystkich możliwych ścieżek i wybór najkrótszej) jest nieakceptowalne ze względu na złożoność obliczeniową, która wynosi O(n-1)!. Fakt podobnego wzrostu złożoności (liczby wszystkich możliwych przypadków testowych) “problemu testowania” wraz ze wzrostem liczby parametrów wejściowych pozwala autorowi na robocze (nie jest to ścisła definicja) zakwalifikowanie “problemu testowania” do klasy problemów NP.
Problem komiwojażera (i inne problemy NP) posiada wiele rozwiązań sub-optymalnych (nie optymalnych globalnie ale wystarczająco dokładnych do zastosowań praktycznych oraz osiągalnych w akceptowalnym czasie) na gruncie technik sztucznej inteligencji. Dzięki zbudowanej analogii “problemu testowania” i problemu komiwojażera autor stawia teza o przydatności sztucznej inteligencji w testowaniu.

Podsumowaniem części wstępnej będzie wskazanie na potrzebę utworzenia “uniwersalnego modelu” testowania, jako podstawy dla automatycznego przetwarzania, wnioskownia i innych technik sztucznej inteligencji.

W dalszej części prezentacji słuchacze będą mieli okazję zapoznać się z przeglądem (niestety na tą chwilę niekompletnym) prac badawczych i zastosowań komercyjnych technik sztucznej inteligencji do realizacji zadań z zakresu testowania oprogramowania. Na bazie przeglądu zostanie przedstawione spojrzenie w przyszłość pokazujące możliwe kierunki rozwoju zstosowań AI w testach w szczególności w takich zadaniach jak:

• automatyczna generacja przypadków testowych w oparciu o specyfikację (formalną lub opisaną językiem naturalnym),
• automat testowy przejawiający “sztuczno inteligentne” zachowania,
• wnioskowanie na podstawie zgromadzonych danych (baz defektów, wyników testów).

Wystąpienie zakończy się zaproszeniem do dyskusji oraz współpracy w projekcie badawczo-rozwojowym mającym na celu zbadanie możliwości zastosowania sztucznej inteligencji do realizacji zadań testowych w rzeczywistych zastosowaniach komercyjnych.

Prezentacja: Tomasz Osojca – Zastosowanie sztucznej inteligencji w testowaniu oprogramowania

Jaka jest najlepsza metodyka testowania?

Jan Sabak – AmberTeam Testing

Jednak każda organizacja jest inna i każdy projekt jest inny. Podejście do testowania trzeba dostosować między innymi do metodyk zarządczej i wytwórczej stosowanych w projekcie. Inaczej testuje się w projektach wykonywanych metodykami tradycyjnymi, a inaczej – zwinnymi.
W prezentacji pokazuję metodyki działające w różnego rodzaju projektach oraz sposób opracowania strategii testowania dla dowolnego projektu.
Celem prezentacji jest pokazania, że nie ma jednej pasującej do wszystkich porjektów, najlepszej metodyki, ale w każdym projekcie konieczne (i możliwe) jest opracowanie optymalnej metodyki testowania.

Prezentacje: Jan Sabak – Jaka jest najlepsza metodyka testówania

Testy wydajnościowe LoaduI

Krzystof Słysz, Michał Ziółek – Corrse

Instrukcja dla uczestnika warsztatu:
1. Pobrać pliki instalacyjne aplikacji SoapUi oraz LoadUi. Ważne żeby mieć zainstalowane właśnie te wersje narzędzi.
2. Zainstalować oba narzędzia. Najpierw SoapUi a następnie LoadUi.
3. Sprawdzić poprawność instalacji uruchamiając oba narzędzia.
4. Pobrać dodatkowe materiały warszatatowe

Jak uratowaliśmy duży kontrakt dzięki regresyjnym testom obciążeniowym

Ireneusz Szmigiel – Parasoft

Przy stale rosnącej konkurencji i zamrożonych budżetach firmy stale szukają oszczędności.
W cyklu rozwoju oprogramowania testy zawsze stanowiły znaczącą pozycję kosztową. W szczególności testy obciążeniowe, które wymagają czasochłonnego przygotowania środowiska, scenariuszy testowych, profili obciążeniowych i wreszcie samego wykonania testów. Dlatego zazwyczaj wykonywane są tylko w przypadku absolutnej konieczności.
Tymczasem zastosowanie wirtualnych środowisk testowych wraz z automatyzacją pozwala na znaczące oszczędności, a co za tym idzie, wykonywanie testów obciążeniowych częściej i przy mniejszym nakładzie czasu, pracy i pieniędzy.
Niniejsza prezentacja opowiada prawdziwą historią o tym jak o mały włos nie straciliśmy klienta na skutek słabej wydajności stworzonego oprogramowania, oraz o wyciągniętych z tego zdarzenia wnioskach, które zaskutkowały stworzeniem zautomatyzowanych regresyjnych testów obciążeniowych.

Prezentacje: Ireneusz Szmigiel – Jak uratowalismy duzy kontrakt dzieki regresyjnym testom obciazeniowym

BUC testing – organizacja automatycznych testów funkcjonalnych, na przykładzie Sikuli

Grzegorz Świeć, Paweł Goławski – CGM

Doskonały przykładem narzędzia typu record-and-playback jest Sikuli IDE. Narzędzie to działa na zasadzie rozpoznawania graficznych elementów GUI, takich jak przycisk, pole tekstowe i wykonywania akcji na nich. Z jego użyciem, pokazuję jak łatwo można stworzyć test black-box, dla większości systemów. Narzędzie to staje się coraz powszechniejsze z uwagi na jego dostępność (open source) i coraz aktywniejsze community, rozwijające to oprogramowanie. Prezentacja łatwości wykonywania testów tym narzędziem jest jednak złudna. Złudna na tyle, że niezmiennie prowadzone są próby, szerszego stosowania takich testów, przez często niewykwalifikowaną bądź dopiero wchodzącą na ścieżkę kariery załogę. Wynika to z charakteru narzędzi typu nagraj-odtwórz. Łatwość imitacji działań użytkownika okupiona jest w tym przypadku, dużym kosztem utrzymania takich testów.
Scenariusz napisania setek testów w zaprezentowany sposób, jest łatwy do wyobrażenia. Realia życia projektów, przypominają nam o często zmieniającym się GUI testowanej aplikacji. Zmiana wyglądu jednej kontrolki przy oknie logowania, stawia widmo przerobienia setek napisanych testów. Co w tym momencie jest oczywiście kosztownym wyzwaniem.
Reasumując prezentację Sikuli IDE. Jest to narzędzie przydatne do szybkiej ewaluacji samej technologii. To znaczy mechanizmu prowadzenia testów za pomocą rozpoznawania graficznych elementów GUI. Innymi słowy możemy z jego pomocą sprawdzić czy technologia jest wystarczająco skuteczna do naszych zadań. Innym potencjalnym zastosowaniem mogą okazać się testów automatyczne, które jednak uruchamiamy rzadko. Soaking testy, testy zajętości pamięci na kliencie lub testy wycieków pamięci mogą być takim przykładem. Jeżeli jednak naszym celem jest stworzenie testów uruchamianych częściej (np. testów regresji), musimy postawić na rozwiązanie bardziej generyczne i zmniejszające koszt wprowadzanych zmian w systemie testującym.
Sikuli, podobnie jak większość narzędzi open source, pozwala na wykorzystanie jego modułów w pisanym kodzie. Podobnym przykładem może być Selenium. Innymi słowy wykorzystanie modułu Sikuli jako zależności w naszym projekcie nie jest przedsięwzięciem nader trudnym. Co prezentuję na żywo. Dodatkowo jest to dobry moment by nadmienić, że wydana niedawno nowa wersja Sikuli, zawiera moduł API, który dodatkowo ułatwia nam używania go jako zależności. Pisany kod to zazwyczaj trywialny algorytm wykonujący kolejne polecenia, pisane w sposób deklaratywny. Brak jest w nich zazwyczaj warunków czy pentli.
Samo przejście na pisanie testów w kodzie nie jest jeszcze poszukiwanym rozwiązaniem, które ułatwi nam utrzymanie testów.

UI mapping
Pierwszym krokiem, który prezentuję, jest mapowanie elementów UI. Jest to sposób odwoływania się do elementów lokalizowanych na GUI, poprzez współdzielone referencje. Dzięki temu zmiany tych elementów, spowodują że utrzymanie testów wymagało będzie zmian tylko w jednym miejscu.
Rozwiązanie takie jest wystarczające przy drobnych zmianach GUI testowanej aplikacji. Niestety jeśli testowana aplikacja oprócz wyglądu zmieni swoje zachowanie, to stosując tylko to rozwiązanie, nadal musielibyśmy zmieniać dużą część kodu.
Z pomocą przychodzi nam kolejny wzorzec.

Page Object Pattern
Jest to sposób modelowania testów przy pomocy obiektów. Jeden obiekt jest reprezentacją jednej strony/jednego widoku aplikacji. Obiekt taki zawiera oprócz referencji do elementów GUI, również metody odpowiadające procesom biznesowym możliwych w danym miejscu aplikacji. Same testy wykorzystują Page Object’y do zmian stanów aplikacji, a na końcu wykonują assert’y, tzn metody weryfikujące czy dana funkcjonalność działa tak jak pożądano.

Module Object Pattern
Rozwinięciem rzadziej spotykanym jest, jest jeszcze większa granulacja logiki testów, do postaci modułów komponentów. Ma ona na celu odwzorowanie sposobu tworzenia testów, w taki sposób jak tworzy się aplikację, tzn za pomocą modułów. W takim rozwiązaniu poszczególne Page Objecty składane są z Module Object’ów, Samo przeprowadzanie testów wygląda tak samo jak we wzorcu pokazanym wyżej.

Z pomocą tych trzech wzorców projektowych, otrzymaliśmy łatwy w utrzymaniu układ testów automatycznych. Następnymi wyzwaniem z którym może przyjść nam się zmierzyć, jest ułatwienie konstrukcji scenariuszy testów w sposób zrozumiały dla biznesu, prowadzenie powiązań testów z wymaganiami (traceability), czy też czytelne raportowanie wyników testów.
Aby bardziej unaocznić problem popatrzmy na przypadek użycia. Firma prowadzi projekt IT w metodologii SCRUM. Backlog w postaci historyjek definiowanych przez anlityka, jest utrzymywany w repozytorium wiedzy. Każda historyjka zawiera opis działąnia oraz kryteria akceptacji. Po fazie deweloperskiej, historyjka, czasem w już „nieco” zmienionej formie trafia do testów. Tam ponownie jest analizowana i „nieco” zmieniana. Oprócz historyjki czasami dodatkowo tworzone jest również repozytorium testów, używane później do przeprowadzania testów regresji.

Domain Specific Language na przykładzie jBehave.
Z pomocą przychodzi nam DSL. Czyli zunifikowany język opisu historyjek, używany przez klienta, analityka, dewelopera i testera. W implementacji jBehave, opiera się on o słowa kluczowe.
Podobnie jak w wyżej przedstawionym przypadku użycia, język DSL również zawiera opis wymagania i kryteria akceptacji.

Opis funkcjonalności prezentowany jest przez słowa:
„As a” – przedstawienie aktora.
„I want to” – przedstawienie pożądanej funkcjonalności.
„In order to” – przedstawienie uzasadnienia biznesowego. Czyli korzyści jaką przyniesie dana funkcjonalność użytkownikowi/aktorowi.

Opis kryteriów akceptacji znajduje reprezentują słowa:
„Given” – opis stanu w jakim pożądane zachowanie będzie się znajdowało.
„When” – opis zachowania
„Then” – opis oczekiwanych rezultatów.

jBbehave wspiera adnotowanie metod poszczególnymi słowami kluczowymi kryteriów akceptacji. W trakcie uruchomienia testu dany scenariusz uruchamiany jest zgodnie poszczególnymi słowami kluczowymi zawartymi w opisie kryteriów akceptacji.

W przykładzie pokazuję, jak w prosty sposób możemy wykorzystać jBehave razem z Sikuli.

BUC Pattern
Doszliśmy do etapu w którym mamy BDD, mamy Page Object’y. Czyż nie fajnie byłoby te dwa podejścia scalić ze sobą? BUC pattern to pokazanie jak może wyglądac testowanie przypadków biznesowych (Business Use Case). BUC traktowany jest jako proces biznesowy, składający się z poszczególnych Page Objectów. Umożliwia nam to wykorzystanie już nie pojedynczych Page’ów, ale całych procesów w trakcie uruchamiania testu.
Prezentacja pokazuje jak czytelne staje się BDD, przy połączeniu z procesem biznesowym.

Wnioski:
Bez pisania kodu testującego, wprowadzanie automatyzacji jest drogie.
BDD można wykorzystywać również od strony testów funkcjonalnych na poziomie integracyjnym i systemowym, nie tylko jednostkowym.
Projektując testy automatyczne stawiaj na oddzielenie logiki testu i reużywalność.
Sikuli to silne narzędzie opensourc. Ma jednak swoje wady. I18n, zmiana czcionki, czy też rozdzielczości może stanowić kłopot.

Źródła:
Sikuli: http://www.sikuli.org/
UI Mapping: http://docs.seleniumhq.org/docs/06_test_design_considerations.jsp
Page Object Pattern: https://code.google.com/p/selenium/wiki/PageObjects
Page Object Pattern: http://selenium-python.readthedocs.org/en/latest/test-design.html
BDD: http://dannorth.net/introducing-bdd/
jBehave: http://jbehave.org/

Prezentacja: Grzegorz Swiec – BUC testing – organizacja automatycznych testow funkcjonalnych, na przykladzie Sikuli

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework

Edyta Tomalik, Grzegorz Ziemiecki – Nokia Siemens Networks

Acceptance Test Driven Development nie jedno ma imię. W obszarze testowania oprogramowania można zetknąć się z różnymi pojęciami zaczynając od samego ATDD, poprzez Behaviour Driven Development, Agile Acceptance Testing, Executable Specifications kończąc na Specification By Example. Mimo, iż metodyki te rozwijają się niezależnie od siebie, wszystkie współdzielą między sobą pewien wspólny zbiór idei oraz zasad. Zagadnienia te dotyczą całkowitej zmiany podejścia do tworzenia specyfikacji, implementacji kodu oraz samego testowania oprogramowania. Testowanie jako proces polegający na zapewnieniu jakości staje się jednocześnie sposobem na zdefiniowanie wymagań. Testy automatyczne stają się „wykonywalnymi specyfikacjami”.
Celem niniejszej prezentacji jest pokazanie jak poradzić sobie z problemem zdefiniowania kryteriów akceptacji (acceptance criteria) dla konkretnej historyjki użytkownika (user story). Co więcej skupimy się na pełnym i jednoznacznym zrozumieniu oczekiwanych rezultatów dla danej funkcjonalności, czyli jednym słowem sformułowaniem condition of satisfaction.
Zostaną zaprezentowane korzyści, jakie przynosi wdrożenie metodyki ATDD oraz ryzyka, jakie ze sobą niesie i które należy wziąć pod uwagę implementując ją w swoim zespole.
Pokażemy na rzeczywistym przykładzie jak może wyglądać ATDD w zespole scrumowym przy użyciu narzędzia ROBOT Framework. Doskonałym przykładem są tutaj testy graficznego interfejsu użytkownika (GUI). Mogłoby się wydawać, że GUI stanowi prosty etap testowania. Szacuje się jednak, że w nowoczesnych systemach komputerowych może obejmować nawet więcej niż połowę kodu. Z tego względu stopień skomplikowania testowania GUI drastycznie wzrasta. Dodatkową trudność stanowi fakt, że nie istnieje metodyka, która w znaczący sposób ułatwia testowanie tak dużej ilości kodu. Ponadto, w testach takich można wyróżnić dwie kategorie – testy użyteczności i testy funkcjonalne. Mimo że testy użyteczności są wyjątkowo istotne, skupimy się tylko na przykładach poruszających testy funkcjonalne GUI i na praktycznym podejściu do ich automatyzacji na przykładzie alarmów.

Prezentacja: Grzegorz Ziemiecki – Acceptance Test Driven Development wspierane przez narzedzie ROBOT Framework