ODD: Extending Test Driven Development 2

Obstacle Driven Development

Extending Test Driven Development 2

©odd.enterprises

18/02/2015

http://odd.enterprises/


Obstacle Driven Development

18/02/2015 ©odd.enterprises 2



ODD Circle Model




ODD Process




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




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




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?


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


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


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


Verify Solution

Solution for Obstacle

ValidateSolution

Obstacle




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


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





The ODD Process is expressed using four stages in sequence.

The diagram is simplified to demonstrate a basic ODD process.

• Analysis

• Specification

• Solution

• Production


Specification

Solution

Production

Analysis




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




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




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




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




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


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


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




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


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



SpecifyBehaviour


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



SpecifyBehaviour


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


5. Repeat Stages 1 – 4 until all behaviours are specified




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


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


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


5. Repeat Stages 1 – 4 until all production is assured




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


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


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


5. Repeat Stages 1 – 4 until elicitation is complete




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




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




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




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




ODD Elements

• Elements are the smallest practical levels of a product and are sub divided


• 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




ODD Flowchart




Further Information and Questions

• Website

• Presentations

• Facebook

• Twitter

• Email





http://www.odd.enterprises/odd-presentations.html

https://www.facebook.com/odd.enterprises

https://twitter.com/odd_enterprises

mailto:[email protected]

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.




http://en.wikipedia.org/wiki/Test-driven_development

http://en.wikipedia.org/wiki/Behavior-driven_development

http://en.wikipedia.org/wiki/Unit_testing

ODD: Extending Test Driven Development 2

Engineering

Transcript of ODD: Extending Test Driven Development 2