obstacle driven development: extending test driven development

Obstacle Driven Development

Extending Test Driven Development

©odd.enterprises

31/10/2014

Obstacle Driven Development

31/10/2014 ©odd.enterprises 2

ODD Control Model

31/10/2014 ©odd.enterprises 3

ODD Process

31/10/2014 ©odd.enterprises 4

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

31/10/2014 ©odd.enterprises 5

Testing in History

Testing has been implemented on certain products for many years.

• Armour which was designed to be bullet proof would be tested

• Non standard components required this approach

31/10/2014 ©odd.enterprises 6

Test Driven Development

When using TDD there comes a very important and difficult stage of writing tests.

Obstacle Driven Development is used to help define tests and extend TDD principles.

Development of ODD began with the question

• Where do the tests come from?

31/10/2014 ©odd.enterprises 7

Write Test

Write Code

Refactor

Behaviour Driven Development 1

• Behaviour driven development has been described as “TDD done right”

• Suggests that behaviours should influence the testing and design process

• ODD is effectively a reordered and extended version of this process applied to all development stages

31/10/2014 ©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

31/10/2014 ©odd.enterprises 9

Write Test

Write Code

Validate / Refactor

Behaviour

Obstacle Driven Development 1

If tests are used to verify and validate code then the principle can be extended and adapted to create a new development model.

• Applications to hardware, software and embedded

• Links the stages with tests used for verification and validation

31/10/2014 ©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

31/10/2014 ©odd.enterprises 11

Verify Solution

Solution for Obstacle

ValidateSolution

Obstacle

Obstacle Driven Development 3

Verification and validation processes for the stages.

• Specification

– Verification and validation

• Solution

– Testing and design

• Production

– Quality assurance and control

• Analysis

– Utilisation and elicitation 31/10/2014 ©odd.enterprises 12

ODD Solution 1

Using a specification allows the creation of tests based on the described behaviours.

• If a solution is designed to pass tests from the outset then testing becomes easier

• Solution is used to describe the individual and integrated designs

31/10/2014 ©odd.enterprises 13

Create Test

Design Solution

PassTest

Specification

ODD Solution 2

ODD Solution is intended to be generic and used for software, hardware and embedded design.

• Red light now used for unverified and unvalidated specification

• Amber light now used when tests are created and solution created

• Green light used when the tests have been passed

31/10/2014 ©odd.enterprises 14

Create Test

Design Solution

PassTest

Specification

ODD Specification 1

A specification which is described directly from expected situations allows full coverage

• Tests are used to verify and validate described behaviours cover situations

• Once all expected situations are covered and tests verified then the solution can be created confidently

31/10/2014 ©odd.enterprises 15

Verify Specification

DescribeSpecification

Validate Specification

Situation

ODD Specification 2

ODD Specification is extended into a separate stage intended to be a full description of behaviours.

• Unit tests applied to a specification allow cross examination of behaviours

• Important to create a full specification to allow detection of errors at an early stage

31/10/2014 ©odd.enterprises 16

Verify Specification

DescribeSpecification

Validate Specification

Situation

ODD Specification 3

Adaption of ODD gives a sequence which follows

• Red light used for unverified and unvalidated behaviour for a situation

• Amber light used when verification tests are created and behaviour specified

• Green light used when the behaviour has been validated

31/10/2014 ©odd.enterprises 17

Verify Specification

DescribeSpecification

Validate Specification

Situation

ODD Production 1

A production process which is organised directly from the solution can have assured and controlled quality.

• Solution is used to ensure continuous and predictable quality

• Quality assurance tests are created with passes a measure of quality control

31/10/2014 ©odd.enterprises 18

Assure Product Quality

ProduceProduct

Control ProductQuality

Solution

ODD Production 2

A solution is required to have production assured and controlled.

• Red light used for no quality assurance and control

• Amber light used when tests for assuring product quality and production are created

• Green light used when quality control is passed

31/10/2014 ©odd.enterprises 19

Assure Product Quality

ProduceProduct

Control ProductQuality

Solution

ODD Analysis 1

Once a product, and by extension the production process, has been created then utilisation is used to verify the product.

• Once the product is utilised in situations then elicitation can proceed as validation

• Process used to link the stages to allow continuous improvement and adaption

31/10/2014 ©odd.enterprises 20

CustomerUtilisation

Situation Analysis

ElicitCustomers

Product

ODD Analysis 2

Analysis may be performed to give feedback on the success of the product.

• Red light used for no utilisation and elicitation of product

• Amber light used when tests for customer utilisation are created

• Green light used when tests for customer elicitation are passed

31/10/2014 ©odd.enterprises 21

CustomerUtilisation

Situation Analysis

ElicitCustomers

Product

ODD Process 1

A traffic light system has been developed. The lights have been arranged to demonstrate how one stage links the next.

• Each stage is began with a red light.

• Amber lights are obtained when tests are created for next stage

• Green light is for when tests are passed and next stage linked

31/10/2014 ©odd.enterprises 22

ODD Process 2

Each part of analysis, specification, solution and production will have tests.

• Each process begins as unverified and unvalidated

• Tests are created to verify a process

• Tests are passed to verify and validate the process

31/10/2014 ©odd.enterprises 23

Testing Procedure

Unit testing is used and extended throughout the ODD testing procedure.

• Each stage and test 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

31/10/2014 ©odd.enterprises 24

Unit Testing 1

Unit tests are used in order to facilitate the testing process.

• 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 next stage linked

31/10/2014 ©odd.enterprises 25

Unit Testing 2

• Analysis of situations

– Create a test to ensure a situation is covered by a behaviour

– Pass the test ensuring a behaviour covers the situation

• Specification of behaviours

– Create a test to ensure a behaviour is implemented by solution

– Pass a test ensuring a behaviour is implemented by solution

31/10/2014 ©odd.enterprises 26

Unit Testing 3

• Creation of solution

– Create a test to ensure a solution is created by production

– Pass the test ensuring a solution is created by production

• Production of product

– Create a test to ensure a product is utilised in a situation

– Pass a test ensuring a product is elicited in a situation

31/10/2014 ©odd.enterprises 27

Linking Tests 1

• Situation A is analysed

– Tests created to verify and validate Behaviour A

• Behaviour A covers Situation A

– Tests created to verify and validate the testing and design of Solution A

31/10/2014 ©odd.enterprises 28

Linking Tests 2

• Solution A implements Behaviour A

– Tests created to verify and validate the quality assurance and control of Production A

• Production A implements Solution A

– Tests created to verify and validate the utilisation and elicitation of product in Situation A

31/10/2014 ©odd.enterprises 29

ODD Process Model

31/10/2014 ©odd.enterprises 30

ODD Traffic Model

31/10/2014 ©odd.enterprises 31

Legal Stuff

ReferencesTest 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.

31/10/2014 ©odd.enterprises 32