Скачать презентацию Testing From The Start Test Driven Development Скачать презентацию Testing From The Start Test Driven Development

fe4d1aac070170cd0a9692725e6a1629.ppt

  • Количество слайдов: 12

Testing From The Start – Test Driven Development TM Summit Fran O’Hara, Insight Test Testing From The Start – Test Driven Development TM Summit Fran O’Hara, Insight Test Services www. insight-test. com fran. ohara@insight-test. com Copyright Insight Test Services 2007 1

Testing from the start – what is it? • Early testing, front-loading, preventative testing. Testing from the start – what is it? • Early testing, front-loading, preventative testing. . • ‘Using tests to Influence and Direct software design and development. Implies concurrent engineering of testware and software’ – Rick Craig SQE • Test early – some examples. . – Analysing/reviewing requirements and other docs early in lifecycle as soon as they become available. – Validation prototypes – Identifying test conditions and designing test cases as soon as requirements/designs become available – ‘. . one effective way to specify something is to describe (in detail) how you would evaluate (test) it if someone gave it to you’ – Bill Hetzel Copyright Insight Test Services 2007 2

Testing from the start – some key elements • Deliverables reviewed for defects • Testing from the start – some key elements • Deliverables reviewed for defects • Tests used as requirements and usage models • Testware leads software design • Defects detected earlier or prevented • Testers and developers work together • No docs? – inventory of prioritised test conditions/objectives - coverage Copyright Insight Test Services 2007 3

Early test design V-Model Acceptance test Requirements System test Functional Spec. Reviews Hi level Early test design V-Model Acceptance test Requirements System test Functional Spec. Reviews Hi level design Integration test Unit test Lo level design Static Analysis Code Static Testing Copyright Insight Test Services 2007 Dynamic Testing 4

Benefits of early test design - It will allow for a deeper review of Benefits of early test design - It will allow for a deeper review of the requirements as the test team try and develop test cases from the requirements document. - It also encourages collaboration between the test team and development and the business analyst or who ever developed the requirements documents. - It also helps to refine the test estimates and improve accuracy. - The test cases can also be reviewed by the development team to ensure that the development team are developing according to the requirements, but also to ensure that the test cases are complete. Copyright Insight Test Services 2007 5

Using test cases to model requirements - R 1: A valid user must be Using test cases to model requirements - R 1: A valid user must be able to withdraw up to £ 200 or the maximum amount in the account - TC 1: W/D £ 200 from account with £ 180 balance - TC 2: W/D £ 1 m from account with £ 1 m balance - TC 3: W/D £ 186. 35 from account with £ 200 balance From: Rick Craig ‘Preventative Testing, BCS SIGIST Dec 2006 Copyright Insight Test Services 2007 6

Cost of fixing faults - what about absolute costs? From an analysis of 63 Cost of fixing faults - what about absolute costs? From an analysis of 63 projects (Boehm 1981) Copyright Insight Test Services 2007 7

Iteration testing From Bret Petticord – challenges of agile Copyright Insight Test Services 2007 Iteration testing From Bret Petticord – challenges of agile Copyright Insight Test Services 2007 testing 8

Test Driven Development • Never write a single line of code unless you have Test Driven Development • Never write a single line of code unless you have a failing automated test • Eliminate duplication Kent Beck • Write the test • Write the code • Refactor Copyright Insight Test Services 2007 9

Test Driven Development • Can be applied at all levels of test e. g. Test Driven Development • Can be applied at all levels of test e. g. Unit and Acceptance • Preventative/early testing – not new… but many benefits • Testing takes on a specification role… …not a verification role? – A feature is not specified… • Until it’s acceptance test is written. – A feature is not done… • Until all it’s acceptance tests pass. – Acceptance and Unit tests become key requirements/feature and design artefacts Copyright Insight Test Services 2007 10

Unit level automation • Automation Of Unit Test – More likely to be done Unit level automation • Automation Of Unit Test – More likely to be done – As development is done – Coverage – Unit Test Regression • Need to engineer unit test code with same discipline as application code • ‘Coverage complacency’ – ‘happy path testing’ Copyright Insight Test Services 2007 11

Discussion Copyright Insight Test Services 2007 12 Discussion Copyright Insight Test Services 2007 12