Bridging the communication Gap & Continuous Delivery
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Bridging the communication Gap & Continuous Delivery

on

  • 3,361 views

This is a case study of a top retailer in UK which was following Agile but not all the Agile practices. We will discuss how collaboration between business and engineering team improved using BDD and ...

This is a case study of a top retailer in UK which was following Agile but not all the Agile practices. We will discuss how collaboration between business and engineering team improved using BDD and how it was used to generate automated acceptance tests. We will also discuss how continuous integration was implemented which laid foundation for continuous delivery.

Statistics

Views

Total Views
3,361
Views on SlideShare
1,652
Embed Views
1,709

Actions

Likes
1
Downloads
27
Comments
0

10 Embeds 1,709

http://www.mazataz.com 1029
http://mazataz.com 450
http://qssinsoftware.blogspot.ro 194
http://qssinsoftware.blogspot.com 25
http://translate.googleusercontent.com 4
http://qssinsoftware.blogspot.de 2
http://qssinsoftware.blogspot.in 2
http://qssinsoftware.blogspot.ru 1
http://qssinsoftware.blogspot.com.br 1
http://qssinsoftware.blogspot.fr 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • This is a case study of a top retailer in UK which was following Agile but not all the Agile practices. We will discuss how collaboration between business and engineering team improved using BDD and how it was used to generate automated acceptance tests. We will also discuss how continuous integration was implemented which laid foundation for continuous delivery.
  • This is a case study of a top retailer in UK which was following Agile but not all the Agile practices. We will discuss how collaboration between business and engineering team improved using BDD and how it was used to generate automated acceptance tests. We will also discuss how continuous integration was implemented which laid foundation for continuous delivery.

Bridging the communication Gap & Continuous Delivery Presentation Transcript

  • 1. Bridging the communication Gap & Continuous Delivery Case study of a top retailer in UK Masood Jan Mazataz Ltd
  • 2. Agenda Communication Gap. Bridging the Gap. Simplifying Automated Functional & Unit Testing. Continuous Integration. Path to Continuous Delivery.
  • 3. The CommunicationGap • The BA/Arch agree with business regarding stories (epics) and creates HLD/LLD. • The Developer reads the LLD and sometimes makes a different set of assumptions to create code. • The Tester reads the requirements and may make a second set of assumptions to create test plans • The Developer finishes the story, does the “Works On My Machine” stuff, and checks in. • The Testers wait for a build in Test Environment, usually couple of hours/days. • If Build was successful tester verifies function against test plans. • Identifies defects raises them. • Developer analyses the defect, debugs to fix it. • The Testers wait for another build.
  • 4. The Result Late feedback. Confusion during development and testing. Change of requirements not clearly propagated. Surprises.
  • 5. What was needed  Focus on development and delivery of Prioritised, Verifiable Business Stories.  Focus on providing a common vocabulary that bridges the gap between Business and Technology.  Focus on exposing business rules to be reviewed by stake holders.  Focus collaboration between Developers, Testers, Architects, BA’s and the Business.  Make it easy to Automate functional testing.
  • 6. What did we doWe behaved ourselves!
  • 7. How did we do that Have Small Vertical stories of Business Value. Agree & Document business rules. Agree & Document the behaviour. Agree how story would be accepted. Create executable scenarios for each behaviour.  Given, When and Then. Develop the behaviour and verify the scenarios. Show completed scenarios to Truth. React to feedback. We synched up!
  • 8. The Result Business and engineering team speak same language. Quick Feedback. Requirements changes were easily communicated. No surprises.
  • 9. What tools we used ? JBehave (Java) Selenium for web applications.
  • 10. Why JBehave? Java, all the teams were aware of it. Built on JUnit framework. Scenarios written in text file. Given , When & Then annotations. JBehave code generator (custom). Integrates well on CI.
  • 11. The JBehave Framework
  • 12. See it in Action ! Simple Login Story
  • 13. Example StoryStory Title: Login to the Customer Service Centre (CSC)So That: I can resolve customer issue with an orderAs: A userI Need: To Login to the CSCAcceptance Criteria:1. I should be able to login using valid username and password2. I should not be able to login using invalid username or password
  • 14. Defining ScenariosScenario 1: Valid LoginGiven the user is on Login PageWhen the user types user name service And the user types password service And clicks login buttonThen the user should be logged in And the user should see a message, Welcome, Service Administrator.Scenario 2: Invalid LoginGiven the user is on Login PageWhen the user types user name wrong And the user types password wrong And clicks login buttonThen the user should not be logged in And the user should see a message, Invalid Username or Password.
  • 15. JBehave Code Generator • Create valid_login.scenario file in eclipse. • Copy login scenario into it and save. • Right click on this file and choose • JBehaveCodeGenerator • Generate Code • This will create two java files • ValidLogin.java • ValidLoginSteps.java
  • 16. ValidLogin.javapublic class ValidLogin extends Scenario { public ValidLogin () { super(new ValidLoginSteps()); }}
  • 17. ValidLoginSteps.java public class ValidLoginSteps extends Steps { @Given("the user is on the Login Page") public void theUserIsOnTheLoginPage() { throw new RuntimeException("Step not yet implemented"); } @When("the user types username $username") public void theUserTypesUsername(String username) { throw new RuntimeException("Step not yet implemented"); } @When("the user types password $password") public void theUserTypesPassword(String password) { throw new RuntimeException("Step not yet implemented"); } @When("clicks login button") public void clicksLoginButton() { throw new RuntimeException("Step not yet implemented"); } @Then(“the use should be logged in") public void theUserShouldBeLoggedIn() { throw new RuntimeException("Step not yet implemented"); } }
  • 18. Working Example A Happy Path Order Capture
  • 19. JUnit Testing using BDD Mockito
  • 20. Mockito Mockito library enables mocks creation, verification and stubbing. Similar to Jbehave with given, when, then steps.. Enables Behaviour testing of java components i.e Formhandlers, Managers, Repositories.. etc. Mocks all objects a component uses and verifies if it is using it correctly according to the behaviour.
  • 21. Mockito Example public class RepositoryUpdaterTest { @Mock MutableRepository mockRepository; @Mock MutableRepositoryItem mockRepsitoryItem; @Test public void shouldUpdateRepositoryWithAString() throws Exception { //given String valueToBeCreated ="Test"; RepositoyUpdater repositoyUpdater = new RepositoyUpdater(); repositoyUpdater.setSomeRepository(mockRepository); //when repositoyUpdater.updateRepositoryWithThisString(valueToBeCreated); //Then verify(mockRepository).createItem(valueToBeCreated); } }
  • 22. Continuous Integration A quick feedback
  • 23. What we have CI Topology Check in build Pipeline Release Builds Pipeline Check-in best practice
  • 24. The CI
  • 25. Check-in Builds Pipeline
  • 26. Check-in Builds
  • 27. Static Code Analysis
  • 28. Sonar Report
  • 29. Release Build Pipeline
  • 30. Release Builds
  • 31. Deployment Pipeline
  • 32. Automated Database ChangeProcess Using DBDeploy
  • 33. Acceptance Tests
  • 34. The Status
  • 35. Check-in Best Practice  CI monitor close vicinity  Checkout when CI is green  Just before checkin see if CI is still green  If Red then wait until green, find out why it is red  Do a get when its green  Build locally again with tests.  Then Checkin  Check for CI building your code.  If Red due to your checkin, fix it ASAP  When CI is green after your checkin, then relax
  • 36. For more information BDD : http://dannorth.net/introducing-bdd/ Jbehave : http://jbehave.org/ Mockito : http://mockito.googlecode.com/svn/tags/latest/j avadoc/org/mockito/Mockito.html Jbehave Code generator : http:/www.mazataz.com/resources.html
  • 37. Questions?