Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Automated Tests in Agile based on Serenity BDD - Michał Szybalski
Similar to Automated Tests in Agile based on Serenity BDD - Michał Szybalski (20)
Automated Tests in Agile based on Serenity BDD - Michał Szybalski
- 2. Automated Tests in Agile based on Serenity BDD Michał Szybalski
- 3. 3 Agenda 1. Fundamenty BDD 2. Selenium WebDriver 3. Serenity BDD - Automated Acceptance Testing with Style 4. Demo Test Example 5. Q&A
- 5. 5 Behavior-Driven Development (BDD ) jest zwinna techniką wytwarzania oprogramowania w oparciu o konkretną strukturę formułowania wymagań. Polega na tworzeniu oprogramowania przez opisywanie jego zachowania, z perspektywy jego udziałowców.
- 6. 6
- 7. 7 Założenia 1. ustalenie celów wszystkich zainteresowanych stron potrzebnych do realizacji wizji 2. zaangażowanie stackholderów w proces tworzenia oprogramowania 3. stworzenie przykładów opisujących sposób działania aplikacji 4. automatyzacja wyżej wymienionych przykładów i możliwość jej późniejszego wykorzystania w regresji 5. wykorzystanie mocków w celu umożliwienia symulacji oprogramowania z modułami, które nie zostały jeszcze stworzone
- 8. 8 3 Zasady BDD 1. Enough is enough 2. Deliver stakeholder value 3. It`s all about behaviour
- 11. 11 BDD vs TDD TDD means writing a test that fails because the specified functionality doesn't exist, then writing the simplest code that can make the test pass – development practise BDD means creating an executable specification that fails because the feature doesn't exist, then writing the simplest code that can make the spec pass – team methology
- 13. 13 Selenium - zestaw narzędzi do automatyzacji przeglądarek internetowych na wielu platformach WebDriver – koncepcja sterowników, która umożliwia bezpośrednią komunikację i kontrolę przeglądarek internetowych
- 14. 14 Selenium WebDriver Selenium 1.0 WebDriver MERGE SELENIUM WEBDRIVER Selenium IDE Selenium RC Selenium Grid
- 15. 15 Page Object Pattern Page Object Pattern – technika strukturyzaji kodu testu, która: • Promuje re-użycie i redykcje duplikatów w kodzie • Czyni testy bardziej czytelnymi • Usprawnia zarządzanie testami
- 19. 19
- 20. 20 Serenity BDD Serenity BDD – biblioteka open source, pomagająca tworzyć automatyczne testy akceptacyjne i regresji Serenity informuje nie tylko jakie testy zostały wykonane, ale co ważniejsze, jakie wymagania zostały przetestowane.
- 21. 21 Główne cechy o elastyczniejsze testy o łatwiejsze zarządzanie testami o przejrzyste raporty z testów o mapowanie testów na wymagania o mierzy jak wiele cech aplikacji jest faktycznie testowana
- 22. 22 Cykl życia Serenity BDD
- 23. 23 Definiowanie wymagań Wyrażane jako User Stories z kryteriami akceptacji, które pomagają opisać wymagania – to właśnie je automatyzujemy!
- 24. 24 Mapowanie wymagań Mapowanie wymagań na kryteria akceptacji za pomocą narzędzi BDD – jBehave, cucumber.
- 25. 25 Implementacja testu Implementacja testów automatycznych w oparciu o Selenium WebDriver
- 27. 27 Raport z pokrycia testów
- 28. 28 Demo Example
- 29. 29 1.Introducing BDD - Dan North https://dannorth.net/introducing-bdd/ 2.BDD in Action – John Ferguson Smart, 2015 3.http://behaviour-driven.org 4.http://www.thucydides.info/
Editor's Notes
- BDD was originally invented by Dan North in the early to mid-2000s as an easier wayto teach and practice Test-Driven Development (TDD). TDD, invented by Kent Beck inthe early days of Agile,10 is a remarkably effective technique that uses unit tests to specify,design, and verify application code. Cała aplikacja budowana jest z komponentów, małymi historyjkami które opowiadają o tym jak powinien zachować się program gdy zajdą pewne okoliczności – z ang. stories. Każde story budowany jest na schemacie given,when,then : given – określa warunki początkowe, przedstawia aktora, zapoznaje odbiorcę z kontekstem historyjki, when – opisuje akcje, występujące zdarzenie, then – informuje o oczekiwanych rezultatach.
- USING EXAMPLES A SHARED UNDERSTANDING SOFTWARE THAT MATTERS Wykorzystanie przykładów na wielu poziomach w celu utworzenia wspólnego zrozumienia i powierzchniowej niepewności Tak by dostarczyć oprogramowanie, które ma znaczenie jest zwinną techniką tworzenia oprogramowania mającą na celu lepszą integrację między programistami, testerami, ale także co bardzo ważne ludźmi biznesu czyli osobami nietechnicznymi ZAŁOŻENIA: ustalenie celów wszystkich zainteresowanych stron potrzebnych do realizacji wizji zdefiniowanie potencjalnych możliwości, które zostaną osiągnięte za pomocą napisanego kodu zaangażowanie stakholderów w proces tworzenia oprogramowania stworzenie przykładów opisujących sposób działania aplikacji automatyzacja wyżej wymienionych przykładów i możliwość jej późniejszego wykorzystania w regresji wykorzystanie mocków w celu umożliwienia symulacji oprogramowania z modułami, które nie zostały jeszcze stworzone
- analizujemy, planujemy i projektujemy tyle, ile naprawdę trzeba • nie tracimy czasu na na wyspecyfikowanie od razu całego zakresu projektu – wymagania i tak będą się pewnie zmieniać • robimy tylko tyle, ile trzeba wszystko, co robimy ma nieść ze sobą realną wartość biznesową • jeśli robimy coś, co tej wartości nie przynosi, warto zająć się czymś innym • jeżeli funkcjonalność pojawia się w projekcie, to znaczy, że jest wartościowa wszyscy uczestnicy projektu powinni odwoływać i myśleć o systemie w ten sam sposób – opisując jego zachowanie tym samym słownictwem dzięki temu zmniejszana jest bariera komunikacyjna między „nietechnicznym” klientem, a „technicznymi” programistami wymagania definiujemy w formie historyjek użytkownika
- Let’s say Chris’s company needs a new module for its accounting software. When Chris wants to add a new feature, the process goes something like this (see figure 1.1): 1 Chris tells a business analyst how he would like the feature to work. 2 The business analyst translates Chris’s requests into a set of requirements forthe developers, describing what the software should do. These requirementsare written in English and stored in a Microsoft Word document. 3 The developer translates the requirements into code and unit tests—written inJava, C#, or some other programming language—in order to implement thenew feature. 4 The tester translates the requirements in the Word document into test cases,and uses them to verify that the new feature meets the requirements. 5 Documentation engineers then translate the working software and code backinto plain English technical and functional documentation. There are many opportunities for information to get lost in translation, be misunderstood,or just be ignored. Chances are that the new module itself may not do exactlywhat was required and that the documentation won’t reflect the initial requirementsthat Chris gave the analyst.
- Chris’s friend Sarah runs another company that just introduced BDD. In a team practicingBDD, the business analysts, developers, and testers collaborate to understandand define the requirements together. They use a common languagethat allows for an easy, less ambiguous path from end-user requirements to usable, automatable tests. Like Chris, Sarah talks to a business analyst about what she wants. To reduce therisk of misunderstandings and hidden assumptions, they talk through concrete examples of what the feature should do. Before work starts on the feature, the business analyst gets together with the developer and tester who will be working on it, and they have a conversation about the feature. In this conversation, they discuss and translate key examples of how the feature should work into a set of requirements written in a structured, English-language format often referred to as Gherkin The developer uses a BDD tool to turn these requirements into a set of automatedtests that run against the application code and help objectively determinewhen a feature is finished. The tester uses the results of these tests as the starting point for manual andexploratory tests. The automated tests act as low-level technical documentation, and provideup-to-date examples of how the system works. Sarah can review the test reports tosee what features have been delivered, and whether they work the way she expected.
- Selenium - a suite of tools to automate web browsers across many platforms. Z jednej strony to bardzo wygodne dla programisty API pozwalające na interakcję z przeglądarką, z drugiej zaś to koncepcja sterowników (ang. driver), które tę bezpośrednią komunikację umożliwiają Doesn’t need a real browser No javascript limitations No need for a server.
- Selenium - a suite of tools to automate web browsers across many platforms. Z jednej strony to bardzo wygodne dla programisty API pozwalające na interakcję z przeglądarką, z drugiej zaś to koncepcja sterowników (ang. driver), które tę bezpośrednią komunikację umożliwiają
- Pozwala na odwzorowanie stron internetowych w klasy, w których metody reprezentują możliwe do wykonania akcje, natomiast pola - elementy na stronie.