Centralised Testing Functions – Oversight and Governance

I’ve been working on a project over in Sweden, and have found it unlike anything I’ve ever seen before. Sadly, this is for all too familiar reasons.

I work for an organisation with a small performance testing function centralised across all the projects that can be conjured up. As a result, there are often a lack of resources available to conduct testing, or even to conduct an assessment of whether testing is necessary and appropriate. The knock-on effect of this is that large third party consultants are drafted in to pick up the bigger projects and the centralised testing function – the Test Center – take a back seat.

In practice, that back seat is often in a different vehicle, and so the Organisation as a whole lose ownership and governance of their own IT projects, ceding it to the consultants.

It is in the nature of the larger consultancies to be concerned with one thing only – Successful Delivery. It is a known side effect of this concern that the contracts will often be drawn up to include bonuses and interim payments based on successful delivery.

In many ways this is absolutely fine, but it requires an oversight position from the test center to conduct reviews upon such deliverables as:

  • the test approach
  • the test scripts
  • the test results
  • defects
  • the deployment decision

The question is: What happens when you have an immature IT organisation, who have ceded control of the project to a large 3rd party supplier – focused on delivery at all costs – with no checks and balances in place to ensure the quality of that delivery.

We end up with an immature IT organisation, an obfuscating 3rd party vendor hiding meaningful results whilst ensuring that something (ANYTHING) is delivered, so that they can meet the project milestones and ensure payments are made.

Essentially, the organisation order 1 ton of oranges, the third party vendor deliver 1 ton of lemons and claim success.

Importantly it is in no small way the fault of the purchaser for ceding that control in the first instance.

Let’s be clear, the larger third party suppliers often use primarily low-cost offshore resources. These resources are typically low-cost due to a lack of experience and exposure to the larger business-world around them. Additionally, these resources are used as a delivery factory, churning out scripts of varying need and quality according to a vague set of requirements. The requirements are generally vague due to the IT immaturity of the organisation.

The 3rd party vendor then adds a layer of project management around release and defect management whose role seems to be to obfuscate clear communication, to actively seek to remove any review process and oversight from the organisation. They effectively become closed shops of development and testing who produce results that mean very little to the overall organisation but ensure that project milestones are met.

Everything becomes deadline-based, and measured in time rather than overall quality.

All of which can be avoided by maintaining a level of governance and oversight over the project.

The delivery factory will continue to churn out scripts of varying quality and need but this need and quality will be assessed and reviewed by an employee of the test center. The same applies to the approach documentation, the test scenarios, the load and data models.

You can leave a response, or trackback from your own site.

Leave a Reply

Powered by WordPress and ThemeMag