NYS Forum. Optimized Test Driven Development Maximize development efforts through Behavior Driven Development and Model Based Testing

Transcription

1 NYS Forum Optimized Test Driven Development Maximize development efforts through Behavior Driven Development and Model Based Testing November 6 th, 2015

2 Driving Principles: Clarity and Collaboration BDD was put forward by Dan North as a way to combat the defects that arise from ambiguity in requirements It sought to foster collaboration between the business and IT, so that software will deliver as intended It proposes a ubiquitous language, which is often semi-formal and can be created by the business, but also implemented by IT

3 Out-side in Requirements gathering 1. Outside In: means working primarily from the interactions of core stakeholders, which lead to the low-level precision business outcomes or goals 2. Specification by Example: Stakeholders interaction focuses on concrete examples/real life scenarios 3. This interaction focuses on the behaviour - i.e. the actions performed by a certain stakeholder or group, as part of their role

4 Behaviour Driven Requirements This is User Centred Design: design based on users usage and behaviour patterns The Real Life Scenarios reflect how a system should appear to a user, from the outside Behaviour: Interactions performed by a person/group as part of their role It forms behaviour driven requirements how core stakeholders want the system to appear Which are implemented by the Incidental Stakeholders: tester and developers

5 User Stories and Acceptance Criteria From the business outcomes or goals, functionality & features can be derived Users stories are formulated, and contain acceptance criteria, the requirement and the benefit. They often contain a title, narrative and acceptance criteria. A common structure for the narrative aspect of the user stories is: 1) value proposition or benefit the story would bring 2) who wants it (what their role as stakeholder is) 3) what effect, behaviour, or feature is needed to bring the benefit about for said person Acceptance criteria are given after the narrative, and are presented as scenarios

6 Testing and the feedback loop These scenarios in the user stories correspond to test scenarios, and are written in a semi-formal language Cucumber, for example, can automatically read the semi-formal language, Gherkin, executing the steps of the test scenarios: Given; When; Then (BDD Keywords) The Feedback Loop is complete: the tests are fed back to the core stakeholders, who give feedback to the developers

7 Completeness? Deriving test scenarios on the basis of business objectives and desired behaviour, testing emphasizes what should happen The structure of Gherkin, for example, focuses on the IF, AND, and THEN, but not the OR of a system s logic Scenarios are presented in isolation, are tested separately, and are not modelled as a complete system over-testing is likely Under-testing will occur as testing is ad hoc, and will only test scenarios included in the BDD requirements, or that occur to testers - for example, there will be little or no negative testing

8 Modeling a Gherkin Scenario Completeness?

9 What is a negative test case?

10 Modelling a Gherkin scenario A Boolean ring consists of a set of predicates X (which will represent decisions/decision points), the unary operator NOT, the binary operators AND and OR, and the identity elements 0 and 1 (false and true), such that the ordered set (X, OR, AND, NOT, 1, 0) form a ring (essentially, if you think of OR as addition, AND as multiplication, NOT as subtraction and substituting 0 and 1, it works just like the ring of numbers). Now, in terms of Given, When, Then: let s use an example: Given: A current account with negative balance When: Customer attempts a payment Then: Go into overdraft

11 Flowchart modeling as Specification by Example Either the core stakeholders (the business) themselves build flowcharts Or, testers reverse engineer examples and user stories formulated by the core stakeholders The flowchart is the ubiquitous language: the business already use flowcharts they are used to them! Testers and developers combine these scenarios into a complete flow or set of flows Tooling will help guarantee completeness it will generate a model and identify dangling elses Visio and BPMN2 Diagrams

12 Modelling Scenarios User stories are too high level for testing the scenarios should form the test cases The steps of the scenario form the process and decision blocks, forming paths Gherkin, Rspec, Narratives, etc. are all readily transferrable to a flowchart Multiple scenarios can be covered by a given set of paths for example, due to combinatorial methods, 5 scenarios might be fully covered by 2 paths If every scenario is modelled, every user story is covered this = maximum coverage

13 Verifying the model the shortened feedback loop Part 1 1. The system has been modelled by users or the business: no verification of the model is needed The unambiguous, mathematical precision of the model also makes the amount of clarification required by testers and developers far smaller 2. Testers have modelled the system and can easily verify the model with users and BAs The paths through the flowchart are equivalent to use cases these are in a format accessible to the business (flowchart/plain text), who can quickly confirm that the desired functionality has actually been modelled Verifying a use case

14 Validating the model the shortened feedback loop Part 2 Automatically generate the smallest set of test cases needed to provide 100% functional coverage, linked to the right data and expected results i.e. the paths which cover 100% of scenarios More testing, fewer tests Test Optimization combines scenarios into the smallest possible set of tests, with invalid or redundant tests These test cases can then be exported and executed manually, or can be pushed out and executed in existing engines No manual test case definition required for example, Gherkin step definitions do not need to be converted to Ruby and then executed in Cucumber

15 But won t this compromise ability to respond to change..? Notion of embracing uncertainty : as in Agile, teams should favour the ability to respond to change over having complete documentation However, with model based testing, tests can be derived from complete documentation and changes can be made quickly To make a change, users simply add a new piece of functional logic, and auto-update the test cases, test scripts, etc.

16 Initial time spent making flowchart is vastly outweighed by the time saved 1. Building test cases, and writing test scenarios as Ruby Scripts 2. Executing more tests than are necessary 3. Rework and debugging 4. Implementing Change Requests

17 Questions Gordon Brandyburg CA Technologies

18 NYS Forum Web and Accessibility Workgroup Test and Behavior Driven Development

19 Test Driven Development Anticipate design before code is written Write test Fail test Write code Pass test Refactor code Better vision of the interface and improved code quality 21 21

20 Test Driven Development TDD Demo 22 22

21 Behavior Driven Development BDD is an extension of TDD Write test cases in a language that stakeholders can understand 23

22 Behavior Driven Development BDD Demo 24

23 Questions Joseph Payette Jr. Greane Tree Technology (518)