|Electronic claims Handling system for
Car Lease companies
An electronic claims handling system is
created to make it possible that dealers can handle damage repair with
car lease companies through the internet. The process is as follows: the
driver of the lease car has an accident and the car is brought to a garage.
The garage reports the car being brought in to the lease company (message
10). The lease company answers “yes, it is our car” (message
20) or “it is not out car” (message 21). The car is checked
for license number, brand and type. After 21 the process stops, after
20 the garage then sends message 30 to the lease company: the estimate
of time and cost to be spent on the repair. The lease company evaluates
the estimate and either approves (message 40) or disapproves (message
41). On the side of the garage this message is answered with either 30
(change of the estimate, when the estimate is not approved) or with 50
in which the actual cost is presented. Die rechnung. This can be approved
by the lease company (message 60) or disapproved (61). After 61 a change
of the bill can be presented in message 50 which will lead to either 60
or 61 again. After 60 the process stops. If along the way the car lease
company rejects the message of the garage the process stops and the garage
is forced to stop any activities regarding that car.
The message is received in XML format. It had to be transformed to Sybase
SQL to be able to process it in the back office application of the lease
company. The messages from the lease company to the garage have to be
transformed to XML again.
All messages contain some important information:
- message id
- from address
- to address
- license plate of the car
- model / type of the car
- name of the driver
For the different messages some specific information is required:
For message 21 see 20, for 41 see 40, for 61 see 60. In these messages
also the reason for rejection is indicated. The information that is added
in every new message is added to the dossier history.
- Create a decision diagram for this process
- Create a cause-effect diagram for this process on a high abstraction
level (max 20 points)
- In a cause-effect diagram the cause is drawn on the left side of the
effect. Causes lead to effects. An arrow is drawn from the cause in
the direction of the effect. In the picture below, where would you put
in “print-out”, “load”, “required performance”,
- Create a detailed cause-effect diagram for message 30
- Create a T/F table for message 30; how many test cases do you have?
- Create a test script for test nr 5.
- You are sitting alone in your office with no one to talk to but a
nervous project manager who is getting on your nerves. With respect
to environment, what do you need to perform proper tests on this system?
- How would you do the user acceptance test? Which people inside and/or
outside the organization do you require for that? As a test coordinator,
what would you do?
- What test that you already defined would you use for load and performance
Solution 1: decision diagram
Solution 2: example of a high level cause-effect graph
Every precondition can be split up further and further. E.g. the correct
car should be registered in the database which is checked by the back
office application. The car should be present in the database. The license
number should be correct, as well as model and type.
Usually the accident is first reported to the lease company before it
is brought to the garage (or shortly after). In that case for message
10 a check is done that the accident for the car was already reported.
And of course a message must be received before it can be processed by
the back office application.
Solution 3: place for certain activities in the cause-effect
Output like print-out is not really part of the process and is drawn
on the right of the effects, they are ways to measure or show the output.
The print-out is a loose end in the flowchart and therefore usually left
out. The performance is measured and is output of the process. The load
is input of the process. The way the system reacts to the load is the
Solution 4: detail of a cause – effect diagram for message
Solution 5: T/F tabel for message 30
Other solutions are not necessarily wrong. In the reduced solution the
things that can be tested parallel are put in the T/F table parallel.
In this solution we find only 8 test paths. The actual number of tests
is really 12: all the requirements have to be tested true and false (normal
version). The superfluous tests are allready left out (combinations of
more than one False). There are 11 requirements (causes) that have to
be tested false once, plus the one true path where all causes are true.
So this really is a tricky question: the number of tests are not reduced
by reducing the number of test paths. However: for test automation reducing
the number of test paths can be very beneficial.
As long as you are not communicating with real garages you will need
a couple of test accounts: one for an imaginary garage and one for you,
the lease company. The tests have to be performed on an isolated testing
environment that resembles the production environment (usually a copy
of the production environment is put on the testing environment once a
month). Of course the electronic claim software must be installed on the
For the user acceptance test you need at least one senior user (preferably
two) who can evaluate the product from the point of view of the car lease
company. Furthermore you need at least one user from a related garage.
For the user acceptance test you will send to and receive messages from
a real garage. You will be in direct mail and phone contact during the
tests. You will do this on the up to date test environment or on a separate
It is advisable to make a small test script for the users to do as a
user acceptance test. You may think it is sad, but users don’t think
about creating acceptance tests before doing them. They are usually blank
and they need your help… and if you help them by giving them a small
set of test cases and tell them “but of course you can do your own
tests”, then usually the user acceptance test well run smoothly.
Solution 9: The true path, with a lot of data for measuring process