Calculating the test cost based on segregation

Nowadays (certainly since the 2008 financial crisis), companies want to have figures and graphs that show the financial way to go. This post tries to give an answer on how the cost of the test effort within an infrastructural project can be calculated.

For ICT infrastructural changes or projects, drafting the financial balance is not a walk through the park; this is certainly the case for estimating the test effort.  An experienced test engineer keeps the following in mind: “Simplicity is not the trademark of the beginner. It’s the hard-weiring mark of the master.”
Normally, a rule of thumb can be the development cost divided by four or three (so 25% or 33%) to have a quick view on the test cost. However, since there  needn’t be any development within an infrastructural project other methods of calculation need to be applied.

We propose using a method of segregation.  This will be established by looking a number of questions based on following example.

  • Company ABC wants to upgrade the current Oracle 10G client towards Oracle 11G on their laptop and PC park. A premise that has been imposed is that the currently used applications do not experience any hindrance of the aforementioned migration.
  • The testing department of company ABC is asked to assess the test cost for this upgrade. The test scope (meaning applications using Oracle) has been determined by the application architects of ABC.

The first questions, the ABC-test engineer can pose are:

  1. Are there regression test cases in place ?
  2. If so, how long does it take to execute the regression tests ?

The test engineer can use the time needed for the execution of the regression test set(s). If a regression test set is not available, a set should be build based on the experience of a key user of the application.  He/she will also be able to provide the test engineer with data concerning the required effort for executing the test set.

A second layer of applications that can be segregated is done by answering the next questions:

  1. Is the impacted application a COTS or a third-party application ?
  2. If so, do they support the planned upgrade ?

Applications which have been bought, can already be compliant with the plannedupgrade.
This can be an indication to reduce the test execution effort since the upgrade has been covered by the manufacturer of the software.  Of course, the specifications of the software have to be compared with the configuration of the package ABC intends to distribute to their PC and laptop park.  If these third party applications were already been covered by the presence of regression test cases, a second reduction of effort can be applied.

To further finetune the test cost, the next question can be of help:

  1. How great was the development/configuration effort ?

In the previous paragraphs, we tackled applications for which regression test cases were in place.  The last segregation that can be made, is the in-house builtor configured applications for which no regression test cases have been designed. In this particular case, the ABC-test engineer can consult, if available, the developer or development team, to have a notion of the development effort.  Probably, the developer(s) will know whether these applications are supported for the upgrade.  Also, the consultation of a key user can help to forecast the test cost.  These parameters (time to build, compatibility and getting information of a key user) can be used to derive the test cost.


Drawing up the financial part of an infrastructural test project is a tough nut to crack. Nevertheless, the experienced test engineer will be able to estimate the test cost applying several segregation layers (available regression test cases, COTS/third party and in-house built applications).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>