Q-Course Quality & Organization
Q-Course Quality & Organization

Q-Course Case Study

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.


  1. Create a decision diagram for this process
  2. Create a cause-effect diagram for this process on a high abstraction level (max 20 points)
  3. 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”, “performance”, “transfer”?
  4. Create a detailed cause-effect diagram for message 30
  5. Create a T/F table for message 30; how many test cases do you have?
  6. Create a test script for test nr 5.
  7. 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?
  8. 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?
  9. What test that you already defined would you use for load and performance tests?

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 diagram

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

Solution 4: detail of a cause – effect diagram for message 30

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.

Solution 7:

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 testing environment.

Solution 8:

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

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 time etc.