obstacle driven development: extending test driven development

32
Obstacle Driven Development Extending Test Driven Development ©odd.enterprises 31/10/2014

Upload: jonathan-herring

Post on 10-Aug-2015

98 views

Category:

Engineering


8 download

TRANSCRIPT

Page 1: Obstacle Driven  Development: Extending Test Driven Development

Obstacle Driven Development

Extending Test Driven Development

©odd.enterprises

31/10/2014

Page 2: Obstacle Driven  Development: Extending Test Driven Development

Obstacle Driven Development

31/10/2014 ©odd.enterprises 2

Page 3: Obstacle Driven  Development: Extending Test Driven Development

ODD Control Model

31/10/2014 ©odd.enterprises 3

Page 4: Obstacle Driven  Development: Extending Test Driven Development

ODD Process

31/10/2014 ©odd.enterprises 4

Page 5: Obstacle Driven  Development: Extending Test Driven Development

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

Page 6: Obstacle Driven  Development: Extending Test Driven Development

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

Page 7: Obstacle Driven  Development: Extending Test Driven Development

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

Page 8: Obstacle Driven  Development: Extending Test Driven Development

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

Page 9: Obstacle Driven  Development: Extending Test Driven Development

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

Page 10: Obstacle Driven  Development: Extending Test Driven Development

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

Page 11: Obstacle Driven  Development: Extending Test Driven Development

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

Page 12: Obstacle Driven  Development: Extending Test Driven Development

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

Page 13: Obstacle Driven  Development: Extending Test Driven Development

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

Page 14: Obstacle Driven  Development: Extending Test Driven Development

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

Page 15: Obstacle Driven  Development: Extending Test Driven Development

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

Page 16: Obstacle Driven  Development: Extending Test Driven Development

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

Page 17: Obstacle Driven  Development: Extending Test Driven Development

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

Page 18: Obstacle Driven  Development: Extending Test Driven Development

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

Page 19: Obstacle Driven  Development: Extending Test Driven Development

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

Page 20: Obstacle Driven  Development: Extending Test Driven Development

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

Page 21: Obstacle Driven  Development: Extending Test Driven Development

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

Page 22: Obstacle Driven  Development: Extending Test Driven Development

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

Page 23: Obstacle Driven  Development: Extending Test Driven Development

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

Page 24: Obstacle Driven  Development: Extending Test Driven Development

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

Page 25: Obstacle Driven  Development: Extending Test Driven Development

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

Page 26: Obstacle Driven  Development: Extending Test Driven Development

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

Page 27: Obstacle Driven  Development: Extending Test Driven Development

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

Page 28: Obstacle Driven  Development: Extending Test Driven Development

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

Page 29: Obstacle Driven  Development: Extending Test Driven Development

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

Page 30: Obstacle Driven  Development: Extending Test Driven Development

ODD Process Model

31/10/2014 ©odd.enterprises 30

Page 31: Obstacle Driven  Development: Extending Test Driven Development

ODD Traffic Model

31/10/2014 ©odd.enterprises 31

Page 32: Obstacle Driven  Development: Extending Test Driven Development

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