22/03/2011 | Expert opinion - Rémy Dujardin, Head of Test Offering, Hardis Group
A study by Pierre Audoin Consultants in October 2010 confirms that application testing is a fast-growing market. But in people's minds it's still often equated with long, costly constraints. And yet quality of information systems is not incompatible with agility. We need to get away from the idea of a cost incurred at the end of the development, and to see testing as an ongoing investment throughout the application design and development processes.
Application testing is one of the most dynamic activities in the IT sector, according to a recent study by Pierre Audoin Consultants: the market for application testing (including certification of information systems) is expected to grow by an average 10% a year in the next few years. This acceleration reflects the growing awareness of the need for quality in IT assets, in terms of services provided to business lines, brand image and costs.
Testing provides real assurance against risks (bugs, breakdowns, etc.) and hidden costs (loss of operation, teams idle, late delivery penalties, etc.) resulting from quality defects, and as such testing is an investment that can no longer be neglected. On average, the cost of correcting an error in production is one hundred times the cost of correcting the same error in the design phase. So the earlier in the development cycle of the application the tests occur, the lower the cost of corrections.
In parallel, tests must support IT departments' strategic decisions in adapting the IT tools to the constantly changing requirements of the business lines. That's why tests must not be thought of as expensive and unnecessary extra quality, nor must they be allowed to induce inertia in the information system, since this is fatal to time to market. The main difficulty thus consists in finding the right balance between unstretchable IT budgets and the return on investment that business lines can expect from a quality information system adaptable to change.
Incorporate application testing into a business-line logic
Long considered as an end in itself, IT is slowly finding its rightful place in organizations: a support to the business lines. In addition to the technical aspects, IT certification must therefore also be functional. That is to say, it must determine whether or not the tool responds to the needs defined by the business lines. Needs which may be more or less critical to the company's business. In that case why try to test everything?
Nowadays we have to be pragmatic, by designing sets of tests and defining failure rates that will be tolerated, depending on the criticality of the business processes, as is the practice in the industry. For example, in most companies processes such as passing orders or managing deliveries are among the most critical, where an error in production can have very serious consequences. It is therefore on these processes that the tests must concentrate.
In parallel with this, and as part of the real professionalization of the application testing sector, we need to think in terms of continuous improvement. Notably by carrying out quality reviews in order to optimize the actual testing processes themselves. In order to be effective, these meetings must involve mixed teams, and therefore necessarily bring together technical and functional personnel, thus improving communication among the various participants in the project.
Build in tests right from the initial design of the application
Despite the development of so-called "agile" methods, in most cases methods for designing application solutions have barely evolved: specifications, development, formulas, start of production. And when budgets and/or deadlines are exceeded, it is very often the formula phase that allows adjustment, to the detriment of quality.
In order to avoid this pitfall, the whole project cycle needs to be rethought. And notably by permanently involving the business line participants throughout the entire project cycle. But also by including the testers in the project, right from the start of the application design phase. So that they can understand which critical processes and therefore what scope are to be tested. Objective: to enable them to design test scenarios that will later serve as a design review to be carried out on the successive prototypes.
In this approach, the role of the tests becomes central, continuous and above all integrated into the whole project cycle. The approach therefore requires the setting up of real multi-discipline teams, composed of a user, an analyst and a tester, so that the projects can perform effectively and with agility. Teams that share a common vision of the scope and objectives of the tests, thanks to a common tool: the test frame of reference. It then becomes possible to rely on this frame of reference in order to industrialize the test processes and continuously improve them, by tooling up and/or by outsourcing them.
When tests are integrated throughout the project life cycle in this way, quality is no longer seen as a brake on the agility of the information system in responding to the business line's tendency to evolve.
Application testing: ask the right questions
So we see that in order to reconcile quality and agility, we need to be pragmatic. And to follow a few good practices, while asking the right questions at the right time. To what extent should we invest in tests and formulas? What scope and what level of risk should we accept? Who do we include in the teams?
Lastly, it's also a matter of putting in place a continuous improvement system and using the project-maintenance-project cycle in order to industrialize and improve the testing process.