Bdd and Agile Requirements Boiling Frogs 2016
Agile, Scrum, Lean Startup, Testy A/B, Zwinny Marketing, Lean Canvas, Agile Coaching, Test Driven Development, User Stories, BDD, SBE, ATDD, TDD po wrzucania do jednego kotła i odpowiednim zamieszaniu otrzymujemy…(?) Przepis na sukces… Lub wiele mitów i nieporozumień! Sukces lub totalną porażkę naszego produktu… Współczesne metody wytwarzania oprogramowania, nowoczesne technologie i narzędzia, masowy klient/odbiorca oraz dobrze wykwalifikowani, wszechstronni developerzy dają nam możliwości, o których nie mogliśmy marzyć jeszcze kilka lat temu. Niemniej jednak nadal popełniamy wiele błedów i nasze projekt raczej stosunkowo niezbyt często kończą sie spektakularnym sukcesem. Być może jednym z powodów tej niedoskonałości w procesach wytwarzania oprogramowania jest niekoniecznie dobre zrozumienie wspomnianych wyżej metod i narzędzi. A jeśli o zrozumienie chodzi to myślę, że najelpiej zacząć od początku naszego procesu czyli od wymagań. I właśnie o tym jest ta prezentacja… Jeśli wydaje Ci się, że wiesz już wszystko na temat BDD i wymagań w Agile to… Pewnie jesteś w błędzie… Nie, nie twierdzę, że na tym wykładzie dowiesz się wszystkiego w tym temacie… Być może jednak dowiesz się o rzeczach, które nie są oczywiste i które realnie pomoga Ci w pracy. Jeśli uważasz, że User Stories, BDD, ATDD i SBE nie mają sensu to… Zgadzam sie z Tobą i z chęcią powiem Ci dlaczego w Twoim kontekście im tego sensu brakuje (wspomożemy się w tym celu Cynefin Framework). Mowa będzie o mitach związanych z User Stories, Specification By Example, Behavior Driven Development, różnicy pomiędzy wymaganiami a specyfikacją, Cynefin Framework oraz Continuous Delivery.
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (16)
Similar a Bdd and Agile Requirements Boiling Frogs 2016
Similar a Bdd and Agile Requirements Boiling Frogs 2016 (11)
Bdd and Agile Requirements Boiling Frogs 2016
- 5. @streser Specyfikacja Funkcjonalna // given Kontekst – co jest potrzebne by wykonać testowaną funkcję? // when Wykonanie testowanej funkcjj/właściwości aplikacji // then Asercje – oczekiwane zachowanie systemu
- 6. @streser Co może pójść źle? // given Open login page // when Type login Type password Click login button // then Assert that main page is open Assert that login page is not open Assert that menu is clickable Assert that <a href=”/logout”> is visible
- 7. @streser Specyfikacja // given Start application (?) // when User log in with correct credentials // then User should be logged in
- 8. @streser Specyfikacja jest opisem funkcji systemu // given Start application Log in as user with admin role assigned Navigate to admin panel // when Add new admin user // then New user should be visible in the system Should be possible to log in as new user New user has access to admin functions
- 9. @streser Specyfikacj może być poparta przykładami // given Bank account A with balance equals <balance A> Bank account B with balance equals <balance B> // when Transfer <amount> from account A to account B // then New account A balance should equals <new A balance> New account B balance should equals <new B balance> <error> should be thrown Examples: |balance A | balance B | amount | new A balance | new B balance| error | |100 | 100 | 100 | 0 | 200 | No errors | |100 | 0 | 100 | 0 | 100 | No errors | |100 | 100 | 0 | 100 | 100 | No errors | |100 | 100 | 100 | 0 | 200 | No errors | |0 | 100 | 100 | 0 | 100 | No money error |