• No results found

Case study AllianzNet

N/A
N/A
Protected

Academic year: 2021

Share "Case study AllianzNet"

Copied!
19
0
0

Loading.... (view fulltext now)

Full text

(1)

11-11-2005 final 1.1 webversion Case study AllianzNet, 11th Dutch Testing Day 1

D E G O U D E N D R A A D D O O R U W B E D R I J F S V O E R I N G

©2 005 IN QA Qual it y C onsul tants B V

Case study AllianzNet

(2)

©2 005 IN QA Qual it y C onsul tants B V

Pleased to meet you

• Hans van Loenhoud

– secretary TestNet

– managing partner INQA

• Quality management

• Test management

• Service management

• Project management

• Guido van Leeuwen

– consultant INQA

(3)

3 Case study AllianzNet, 11th Dutch Testing Day

11-11-2005 final 1.1 webversion ©2 005 IN QA Qual it y C onsul tants B V

Contents

• The context: Allianz and AllianzNet

• Testing AllianzNet: the strategy

• Automated testing: what did we do?

• And here are the results …

(4)

©2 005 IN QA Qual it y C onsul tants B V

Allianz

• A company of the Allianz Group, one of the

largest integrated financial service providers

in the world, with over 60 million clients in

over 70 countries

• Allianz Schadeverzekering NV

– in the Dutch general insurance market, one of the

largest players, in particular in the fire and motor

classes

– distribution exclusively through the intermediary

channel (insurance agents)

(5)

5 Case study AllianzNet, 11th Dutch Testing Day

11-11-2005 final 1.1 webversion ©2 005 IN QA Qual it y C onsul tants B V

AllianzNet

– the past

agent

front office

back

office

policy

customer

(6)

©2 005 IN QA Qual it y C onsul tants B V

AllianzNet

– the future

policy

customer

agent

back

office

(7)

7 Case study AllianzNet, 11th Dutch Testing Day

11-11-2005 final 1.1 webversion ©2 005 IN QA Qual it y C onsul tants B V

AllianzNet

– the application

• Internet application, developed on COTS

Java based web engine

– replaces current mainframe based front office system

• Automated input forms for 6 insurance types

– home, car, motor, caravan, boat, legal assistance

• Online ...

– completion, verification and validation of data

– calculation of premiums

– acceptance of insurance

• Work flow between agents and Allianz

©2 005 IN QA Qual it y C onsul tants B V 7

(8)

©2 005 IN QA Qual it y C onsul tants B V

AllianzNet

– the project

• First phase 1½ years

(proposals & new orders)

– >25 man years spent on IT work

• of which >25% on testing

– separate development teams

• vendor

– enhancements to web engine

• Allianz

– infrastructure

– customisation of web engine

– interfaces between web based front office and mainframe

based back office system

– step-wise development

• multiple releases, builds and patches

(9)

9 Case study AllianzNet, 11th Dutch Testing Day

11-11-2005 final 1.1 webversion ©2 005 IN QA Qual it y C onsul tants B V

Testing strategy

- risk

• Extremely high risk project

– new business process

– new technology

– new methodology

– new organisation

(both business and IT)

– high complexity

– high volumes

– high potential damage

(e.g. acceptance of bad risks)

(10)

©2 005 IN QA Qual it y C onsul tants B V

Testing strategy

- master test plan

• Unit testing

– developer teams

• System testing

– dedicated test team

• Integration testing

– dedicated test team

• Acceptance testing

– dedicated business team

(UAT)

– exploitation & maintenance team

(PAT)

(11)

11 Case study AllianzNet, 11th Dutch Testing Day

11-11-2005 final 1.1 webversion ©2 005 IN QA Qual it y C onsul tants B V

Testing strategy

- test automation

• High complexity

(30 years of insurance knowledge)

– current front office system contains “the truth”

– automated output prediction from front office system

• validations

• premiums

• High volumes

(~ 1000 concurrent agents)

– automated performance tests

• Multiple releases

– automated regression tests

(12)

©2 005 IN QA Qual it y C onsul tants B V

Let’s test!

(13)

13 Case study AllianzNet, 11th Dutch Testing Day

11-11-2005 final 1.1 webversion ©2 005 IN QA Qual it y C onsul tants B V

What did we do …

• Automated

– premium calculation

– performance

– regression testing

• Manual

– premium calculation

– workflow

– field validations

– verification rules

– acceptance rules

– external connections

(14)

©2 005 IN QA Qual it y C onsul tants B V

What did we do

- time line

Test project

Sept 2004

Today

Building scripts

Dec 2004

Oct 2005

•Test conditions

•Test cases

April 2005

Sept 2005

Premium

June 2005

Today

Testing strategy

Acceptance

test

Integration

test

Live!

System

test

Preparation

(15)

15 Case study AllianzNet, 11th Dutch Testing Day

11-11-2005 final 1.1 webversion ©2 005 IN QA Qual it y C onsul tants B V

The figures

• Conditions, cases and findings

• Effort on automated testing

– 40% during system testing

– 20% during integration testing

5% during acceptance testing

1250

810

1300

100

Manual

1350

90

450

140

Automated

Effort (hrs)

Findings

Cases

Conditions

(16)

©2 005 IN QA Qual it y C onsul tants B V

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

The findings

• Total amount of findings 900

(17)

17 Case study AllianzNet, 11th Dutch Testing Day

11-11-2005 final 1.1 webversion ©2 005 IN QA Qual it y C onsul tants B V

• Automated premium calculation tests

• Automated performance tests

• Automated regression tests

Succeeded, at a cost:

manual testing:

3,5 hours per finding

automated testing: 15,0 hours per finding

Succeeded, could not have done without

(reusing existing scripts)

Did not utilize, except for premium testing

Evaluating the testing strategy

(18)

©2 005 IN QA Qual it y C onsul tants B V

Lessons learned

• (To) Early start of building scripts

– time lost in rebuilding scripts

• Quality of test scripts determines value of

automated testing

– need for structured design of test scripts

• Be selective

(19)

19 Case study AllianzNet, 11th Dutch Testing Day

11-11-2005 final 1.1 webversion ©2 005 IN QA Qual it y C onsul tants B V

Recommendations

• Choice for automated testing should depend on

+

reusability of test scripts

+

stability of application

– need for flexibility

• When choosing for automated testing, make sure

– there is a clear and smart scope for automated testing

– there is a structured design approach for developing

standardised test scripts

– enough expertise on automated testing is available

– maintenance of test scripts is embedded

References

Related documents