La maitrise des coûts est un sujet essentiel pour les entreprises, notamment quand il s’agit d’externaliser des prestations. Souvent on applique pour le test les mêmes règles que pour les autres prestations, mais est-ce toujours adapté ? Mieux vaut-il externaliser les tests au forfait ou en régie ?

De manière générale, on externalise trois grands types de prestations : la conception fonctionnelle, le développement et le test. Le problème est que les activités de conception fonctionnelle et de développement sont relativement « unitaires » (une règle puis une autre, un écran puis un autre), là ou le test est en partie unitaire mais aussi global.

Par global j’entends que pour tester certaines situations, processus, il faut croiser les règles de gestion. C’est donc l’intégration qui représente une différence. Je ne parle pas d’intégration technique, mais d’intégration fonctionnelle et d’intégration logicielle.

On pourrait appliquer les mêmes règles pour les activités de test des Users Stories, hors test de non régression, mais il ne faut pas oublier les tests des fonctionnalités dans leur ensemble et des processus. Ces aspects ont un impact sur le chiffrage et donc sur la capacité à budgétiser un forfait de test. Il est donc nécessaire d’avoir les règles de gestion et une stratégie de testafférente.

On voit bien qu’il faut distinguer les activités de stratégie de test qui s’apparentent à un cadrage, des activités « opérationnelles » de test. De la même façon que la conception fonctionnelle et le développement sont forfaitisés sur la base d’un cadrage, les activités de test doivent aussi être forfaitisées sur la base de leur cadrage : la stratégie de test.

Comparatifs

En ce qui concerne le cadrage des tests, à la différence du cadrage « projet », il est relativement linéaire par rapport à la taille du projet ou programme. Il est donc relativement simple de forfaitiser le cadrage des tests.

De plus, hors gros projets ou programme, cette phase est souvent plus du délai que de la charge, nécessitant la disponibilité d’autres acteurs amonts. Forfaitiser le cadrage des tests permet donc aussi de gérer les ruptures de charge sur cette activité.

Nous l’avons vu précédemment les activités « opérationnelles » de test peuvent se forfaitiser sur la base d’une stratégie de test, mais est-ce le seul critère ?

Les phases de test sont en fin de projet, tout aléas sur une phase amont a donc un impact calendaire sur celle-ci. Les jalons finaux étant souvent figés, ce sont donc les tests qui doivent adapter leur périmètre, avec un impact sur la qualité finale et les engagements…

De plus on peut avoir des changements de périmètre, qui sont « indolores » pour les phases amont, mais qui peuvent engendrer une complexité de test différentes, qui change la stratégie de test …

Pour finir, on exécute rarement un test une seule fois. On l’exécute et le réexécute en fonction des corrections d’anomalies. Le problème c’est qu’on ne connait, hors RUN et encore, la qualité qu’en commençant les tests. On ne peut donc estimer le nombre de rejeu et donc budgétiser réellement les tests qu’après les avoirs démarrer…

Pour toutes ces raisons, un forfait de test est souvent une « machine à avenant ». On penche donc plutôt vers des régies pilotées pour gérer les activités « opérationnelles » de test.

Dans certains cas, on peut mettre en place des forfaits, mais sans engagement qualité… L’engagement est donc plutôt sur X rejeu d’un périmètre de test de telle taille. Le problème est, comme on l’a vu sur l’article sur les combats de granularité de pas de test, que certains prestataires de services peuvent profiter de ce flou pour maximiser leur gains… La régie pilotée reste donc préférable.

Finalement on est plutôt sur des règles inversées par rapport aux autres activités, on va plus facilement forfaitiser le cadrage des tests, et mettre en place une régie pour les activités « opérationnelles ».

Un combat passionnant avec un double vainqueur, tout dépend de l’activité…