28/03/2012 | Expert opinion - Rémy Dujardin, Head of Test Offering, Hardis Group

Setting up a dedicated testing unit: is it appropriate? How far do we go? How do we justify this investment? How do we align its activity with the flow of projects? What are the pitfalls to avoid and the best practices to follow?

For some twenty years or so information system have been supporting corporate transformations, enabling them to achieve gains in productivity and competitiveness. Information systems are complex and diverse, and they need to evolve quickly in a context in which interaction among their various components (ERP, CRM, business line office applications, web applications, specific developments, etc.) is increasingly intense. Hence the need for information systems management (ISM) to control the impacts of each development, whether technical or functional. Some ISMs are considering setting up a testing unit, others have already done so. Is this approach really effective? What are the risks and pitfalls to be avoided?

The risks and downsides of dedicated testing units

Sclerotically attached to its own principles, cut off from the realities on the ground, stigmatized by the development or production teams, who feel as though they are always being checked up on, even counter-productive when the project teams rely entirely on the testing team for verification at the end of the line. Such are the main complaints about testing units among the ISMs that have implemented them.

During economically difficult periods and/or periods of budget restrictions, it becomes tempting to reduce or even eliminate these transversal services, which end up appearing as cost centers, without any real added value. However, a well organized, upgradeable testing unit that is integrated with the business processes contributes far more than it hampers. Providing a few good practices are observed and providing we think long term.

Six key points for a durable and effective testing unit

In order for a durable testing unit to be put in place, it must be designed, organized and valorized as a genuine service center, conforming to six key points.

1 - Organization: a service-oriented business model

In setting up a testing unit, the approach is actually very similar to that of an entrepreneur meeting his future investors. And it boils down to answering a few simple questions: who are my clients? What are their needs? What catalog of services do I offer in order to satisfy them? Etc. In other words, it's a matter of designing the testing unit as a genuine service center for all clients, in-house and external, involved closely or from afar in the design, operation and development of the information system.

2 - Service catalogs: demonstrate added value

The offering proposed may be fairly wide: advice, project support, performance of non-regression tests (NRT), etc. In any case, it's a matter of building trust-based relationships with both the technical teams and the business units. To this end, apart from putting SLAs (service level agreements) in place, it is essential to involve the unit's "clients" regularly in order to avoid its becoming isolated.

So the idea is not to replace the project teams but to support them with methods and tools, without dispossessing them or relieving them of responsibility. Implementing NRT is generally a good way of showing the added value of a testing unit: being transversal by nature, these units are generally less well treated in organizations, since they are the responsibility of all and hence ultimately of no-one.

3 - Tools and processes: gradual industrialization of tests

The establishment of a testing unit is inseparable from the implementation of an appropriate frame of reference. However, as its name suggests, a frame of reference is above all just that, a reference, which all must subscribe to, starting with the business lines. Up to a year may be needed for the design of a coherent frame of reference, which it will then be essential to update and adjust as the IS and the business needs evolve.

This first phase, in which needs are expressed, critical processes identified and the frame of reference for the tests iteratively established, is the opportunity for the project teams to get to know the project and each other and to build trust.

Not until the second phase can certain tests be entrusted to the unit for it to take sole charge. Its involvement is then not seen as repressive as regards the work of the developers or the production teams, but rather as preventing quality problems.

In the third phase, automation tools and even the outsourcing of certain tests may be put in place for continuous improvement. The unit is then at "industrial cruising speed", with fixed and variable capacities depending on the load, as part of a long-term vision.

4 - Return on investment: a self-financing approach

Without an estimate of the return on investment at more or less long term, there will be no investors. In order to convince General Management of the solid grounds for setting up a testing unit, it is necessary to first evaluate its cost/benefit ratio. And to estimate approximately at what time horizon the unit will become self-financing.

While the cost of the unit is fairly simple to estimate (tools, personnel, etc.), estimating the gains it will produce is much harder. The implementation of indicators and metrics enables the direct benefits to quality to be evaluated and measured, and in particular compared with the direct or indirect costs of non-conforming quality: number of deliveries reported, number of anomalies corrected in production, business risk, etc.

5 - Valorizing the unit: don't forget anyone

Quality is measured overall. In order to evaluate the real contribution and benefits of the unit objectively, a period of at least two years is necessary. In all cases, valorizing the gains by means of regular communication about achievements is one of the keys to success. The metrics may be multiple: measurement of business lines' satisfaction (survey), quality indicators (compliance with or reduction of delivery times, percentage of anomalies corrected during integration, formula and production phases), estimated FTE (full time equivalent) positions gained, etc.

Moreover, in order for all players to feel involved and valued, communication must not be limited to General Management and Information Systems Management. Reducing resistance to change both in the business lines and in project management is crucial, but so it is with the IT Teams too, so that they don't feel threatened but on the contrary supported by the unit.

6 - HR policy: think in terms of career development

This is one of the key success factors. And yet the management of the testing unit's human resources is all too often neglected. To avoid creating a team of experts, cut off from the business lines and with limited development prospects, it is necessary to plan and carry out their renewal. Thus, assignments carried out by an employee in a testing unit must be valorized and included in a career plan.

In all cases, the unit team must combine the skills of professional testers (particularly as acquired on specific courses such as those of the CFTL or ISTQB) and of employees from the business units and the IT department, so as to respond to the business and technical challenges.