Obstacle Driven Development
Extending Test Driven Development 2
©odd.enterprises
18/02/2015
Obstacle Driven Development
18/02/2015 ©odd.enterprises 2
Background
Ideas of Obstacle Driven Development (ODD) are based on numerous development processes including:
• ISO V-model
• Test Driven Development
• ISO specifications
• Requirements analysis spiral
• Agile principles
18/02/2015 ©odd.enterprises 5
Testing in History
Testing has been implemented on certain products for many years.
• Armour designed to be bullet proof is tested
• Non standard components required this approach
18/02/2015 ©odd.enterprises 6
Test Driven Development
Using TDD there is a very important and difficult stage of writing tests.
Obstacle Driven Development helps define tests and extends TDD throughout development.
Development of ODD began with the question
• Where do the tests come from?
18/02/2015 ©odd.enterprises 7
Write Test
Write Code
Refactor
Behaviour Driven Development 1
• Behaviour driven development has been described as “TDD done right”
• Suggests behaviours should influence testing and design
• ODD is an extended version of BDD applied to all development stages
18/02/2015 ©odd.enterprises 8
Write Test
Write Code
Refactor
Think
Behaviour Driven Development 2
Reordering the BDD sequence gives a sequence similar to traffic lights.
• Red light now used for unverified and unvalidated processes
• Amber light now used when tests are created and code written
• Green light used when the tests have been passed
18/02/2015 ©odd.enterprises 9
Write Test
Write Code
Validate / Refactor
Behaviour
Obstacle Driven Development 1
Tests used to verify and validate code are extended and adapted to create a new development model.
• Applications to hardware, software and embedded
• Links stages with tests used for verification and validation
18/02/2015 ©odd.enterprises 10
Verify Solution
Solution for Obstacle
ValidateSolution
Obstacle
Obstacle Driven Development 2
Obstacle Driven Development is used to find solutions to obstacles.
An obstacle is broken into four stages of development when using ODD.
• Analysis
• Specification
• Solution
• Production
18/02/2015 ©odd.enterprises 11
Verify Solution
Solution for Obstacle
ValidateSolution
Obstacle
ODD Flow Chart
Flow chart to demonstrate a generic ODD process.
Problems or obstacles to be overcome are divided into 4 stages with appropriate testing.
• Analysis
• Specification
• Solution
• Production
18/02/2015 ©odd.enterprises 12
Obstacle Driven Development 3
The ODD Process is expressed using four stages in sequence.
The diagram is simplified to demonstrate a basic ODD process.
• Analysis
• Specification
• Solution
• Production
18/02/2015 ©odd.enterprises 13
Specification
Solution
Production
Analysis
Obstacle Driven Development 4
Verification and validation are applied to link stages and provide feedback.
• Verification is ensuring a product is built in the right way
• Validation is ensuring a product is built right
• Creating and solving tests give verification and validation
19/02/2015 ©odd.enterprises 14
ODD M-model
Verification and validation are to the left of each stage.
• Specification
– Verification and validation
• Solution
– Testing and design
• Production
– Quality assurance and control
• Analysis
– Utilisation and elicitation 18/02/2015 ©odd.enterprises 15
ODD Process 1
A traffic light system demonstrates how one stage links the next.
• Begin with a red light and element from previous stage
• Amber lights are given when tests are created
• Green lights are given when tests are solved and stage linked
18/02/2015 ©odd.enterprises 16
ODD Process 2
Each stage of ODD has tests for each element of development.
• Each element begins as unverified and unvalidated
• Tests are created to verify an element
• Tests are solved to verify and validate the element
18/02/2015 ©odd.enterprises 17
ODD Combined Model
The diagram shows an ODD process combined with an M-model and the resulting model.
• Traffic lights between stages indicate unit tests required
• Linking tests and elements ensures obstacles are solved
• Each element is created through a unit test
18/02/2015 ©odd.enterprises 18
ODD Solution 1
Using a specification allows creation of tests based on described behaviours.
• Solution is used to describe individual and integrated designs
• If a solution is designed to pass tests then testing becomes easier
• Unit testing and test suites used
18/02/2015 ©odd.enterprises 19
Create Test
Design Solution
PassTest
Behaviour
ODD Solution 2
ODD Solution is generic and used for software, hardware and embedded design.
• Red light used for behaviour contained in specification
• Amber light used when tests are created and solution designed
• Green light used when a test has been passed
18/02/2015 ©odd.enterprises 20
Create Test
Design Solution
PassTest
Behaviour
ODD Solution Flowchart
A flow chart has been designed to explain use of an ODD Solution.
1. A behaviour is selected which has to be covered by a solution
2. Unit test is created
3. Solution is designed
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all behaviours are specified
18/02/2015 ©odd.enterprises 21
ODD Specification 1
A specification describes all behaviours used to cover expected situations and requirements.
• Tests used to verify and validate whether described behaviours cover requirement
• Once expected situations are covered and tests verified a specification is complete
18/02/2015 ©odd.enterprises 22
Verify Specification
SpecifyBehaviour
Validate Specification
Requirement
ODD Specification 2
ODD Specification is extended into a separate stage containing a full description of behaviours.
• Unit tests applied to a specification allow cross examination of behaviours
• Important to create full specification to allow detection of errors at an early stage
18/02/2015 ©odd.enterprises 23
Verify Specification
SpecifyBehaviour
Validate Specification
Requirement
ODD Specification 3
Adaption of ODD gives a sequence as follows:
• Red light used for a requirement
• Amber light when verification tests are created and behaviour specified
• Green light used when a behaviour has been validated
18/02/2015 ©odd.enterprises 24
Verify Specification
SpecifyBehaviour
Validate Specification
Requirement
ODD Specification Flowchart
A flow chart designed to explain use of an ODD Specification.
1. A requirement is selected which is to be covered by a behaviour
2. Verification test is created
3. Behaviour is specified
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all behaviours are specified
18/02/2015 ©odd.enterprises 25
ODD Production 1
Production is organised directly from a solution to give assured and controlled quality.
• Solution used to ensure continuous and predictable quality
• Quality assurance tests are created
• Number of passes a measure for quality control
18/02/2015 ©odd.enterprises 26
Assure Product Quality
Produce Product
Control ProductQuality
Solution
ODD Production 2
A solution is required to have production assured and controlled.
• Red light for a solution with no quality assurance and control
• Amber light used when tests for assuring product quality are created
• Green light used when quality control is passed
18/02/2015 ©odd.enterprises 27
Assure Product Quality
Produce Product
Control ProductQuality
Solution
ODD Production Flowchart
A flow chart has been designed to explain use of ODD Production.
1. A solution is selected which has to be produced
2. Quality assurance test created
3. Production process
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all production is assured
18/02/2015 ©odd.enterprises 28
ODD Analysis 1
Utilisation and elicitation are used to verify and validate product features.
• Once product features are utilised then elicitation can proceed as validation
• Process links stages and allows continuous improvement and adaption
18/02/2015 ©odd.enterprises 29
CustomerUtilisation
Situation Analysis
ElicitCustomers
Feature
ODD Analysis 2
Analysis may be performed to give feedback on success of a product.
• Red light for no utilisation and elicitation of feature
• Amber light when tests for customer utilisation are created
• Green light when tests for customer elicitation are passed
18/02/2015 ©odd.enterprises 30
CustomerUtilisation
Situation Analysis
ElicitCustomers
Feature
ODD Analysis Flowchart
A flow chart has been designed to explain use of ODD Analysis.
1. Product feature is selected
2. Elicitation test is created
3. Product is utilised
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until elicitation is complete
18/02/2015 ©odd.enterprises 31
Testing Procedure
Unit testing is used and extended throughout each stage for ODD testing.
• Each stage is assigned a red light to begin
• Amber lights are obtained when tests are created for next stage
• Green light is for when tests are passed and next stage linked
18/02/2015 ©odd.enterprises 32
Unit Testing 1
Unit tests are used to facilitate ODD through test suites.
• Every stage is tested
• Each test has a single result
• Unit tests can be combined to give complex testing processes
• Green light is for when tests are passed and element created
18/02/2015 ©odd.enterprises 33
Unit Testing 2
• Requirements analysis
– Test ensures behaviour covers situation
– Solving test ensures behaviour covers situation
• Specification of behaviours
– Test ensures solution implements behaviour
– Solving test ensures solution implements behaviour
18/02/2015 ©odd.enterprises 34
Unit Testing 3
• Solution design
– Test ensures production creates a solution
– Solving test ensures production creates a solution
• Production quality
– Test ensures product utilisation in a situation
– Solve to ensure product elicitation in a situation
18/02/2015 ©odd.enterprises 35
ODD Elements
• Elements are the smallest practical levels of a product and are sub divided
18/02/2015 ©odd.enterprises 36
• Elements are solutions of verification tests generated by a previous stage
Linking Stages, Tests and Elements
• Situation A is analysed
– Tests verify and validate Behaviour A
• Behaviour A covers Situation A
– Testing and design of Solution A
• Solution A implements Behaviour A
– Tests for quality assurance and control of Production A
• Production A implements Solution A
– Tests for utilisation and elicitation of product Situation A
18/02/2015 ©odd.enterprises 37
Further Information and Questions
• Website
• Presentations
18/02/2015 ©odd.enterprises 39
Legal Stuff
ReferencesTest Driven Development for Embedded C
James Grenning, 2011
Test Driven Development
http://en.wikipedia.org/wiki/Test-driven development
Behaviour Driven Development
http://en.wikipedia.org/wiki/Behavior-driven development
Unit Testing
http://en.wikipedia.org/wiki/Unit testing
DisclaimerThe ODD M-model and associated processes are provided by odd.enterprises and may be used for any purpose whatsoever.
The names odd.enterprises and associated logos should not be used in any representation, advertising, publicity or other manner whatsoever to endorse or promote any entity that adopts or uses the model and/or associated processes.
odd.enterprises does not guarantee to provide support, consulting, training or assistance of any kind with regards to the use of the model and/or processes including any updates.
You agree to indemnify odd.enterprises and its affiliates, officers, agents and employees against any claim or demand including reasonable solicitors fees, related to your use, reliance or adoption of the model and/or processes for any purpose whatsoever.
The model is provided by odd.enterprises “as is” and any express or implied warranties, included but not limited to the implied warranties of merchantability and fitness for a particular purpose are expressly disclaimed.
In no event shall odd.enterprises be liable for any damages whatsoever, including but not limited to claims associated with the loss of data or profits, which may result from any action in contract, negligence or other tortious claim that arises out of or in connection with the use or performance of the model.
18/02/2015 ©odd.enterprises 40