Du bœuf chevalin dans les tests de logiciels ? Peut-on se contenter du moins cher ?

La recherche facile de gains au dépens de la qualité n’est pas limitée à l'agroalimentaire. Le domaine des tests est fortement touché par ce phénomène, qui permet à des sociétés de vendre des vessies pour des lanternes.

L’actualité nous amène à remettre en question un certain nombre de pratiques habituelles de la consommation, mettant en balance des aspects économiques avec aspects qualitatifs, cela en relation avec des objectifs de réduction de risques. L’exemple des viandes chevalines et ovines à la place de viande bovines est flagrant dans l’industrie agroalimentaire. Il se fait que les mêmes pratiques ont lieu dans le domaine des tests de logiciels.
Dans le domaine des certifications de testeurs
de logiciels, le CFTL s’assure d’un niveau de qualité des examens de certifications. La norme ISO17024 est appliquée, séparant clairement les personnes en charge des examens des personnes en charge des formations. Cependant, l’acquisition d’une certification de niveau Fondation n’a pas la même valeur que l’acquisition d’une certification de niveau Avancé, et l’acquisition d’une certification d’un niveau avancé n’implique pas l’acquisition du niveau avancé complet (lequel recouvre les trois modules du niveau avancé). Nous sommes ici – comme dans les cas de protection européenne – sur des dénominations différentes et de nombreux organismes ou individus jouent sur ces ambiguïtés pour faire avancer leurs propres ambitions.

Pour vous assurer de la qualité des personnes, le CFTL répond à toute demande d’information sur le fait qu’une personne ait passé ou non une certification gérée par le CFTL (certifications ISTQB de testeurs et REQB en gestion des exigences). Dans vos recrutements, sélectionnez-vous des personnes « ayant le niveau bac+3 » ou des personnes « ayant un bac+3 » ?  Pourquoi feriez-vous différemment dans votre sélection de testeurs ?
Dans le domaine des formations aux tests aussi, la fourniture de produits low-cost peut cacher des différences notables. Le CFTL propose un cahier des charges de ce que devrait connaître un testeur, et partant, de ce qu’une formation de testeur devrait contenir. De nombreuses formations ont vu le jour proposant des cursus similaires au cursus du CFTL, mais seules les formations accréditées par le CFTL ont été vérifiées par le CFTL comme répondant à ce cahier des charges.

Certains produits « low-cost » sont des produits non accrédités par le CFTL, ou les organismes de formation ne souhaitent pas la vérification du CFTL, que ce soit pour des raisons pécuniaires ou pour des raisons de qualité.
Parmi les formations accréditées, certaines se limitent à du bourrage de crâne, alors que d’autres aident réellement à acquérir les techniques et méthodes qui seront nécessaires pour améliorer la qualité des logiciels. Les produits « low-cost » peuvent cacher d’autres choses, comme l’utilisation en sous-traitance par un organisme de formation non-accrédité d’une formation accréditée (ou non), ou l’utilisation d’un formateur n’ayant que peu – voire pas – d’expérience en test.
Comme pour le cas des certifications, dans l’achat des formations de testeurs, les termes sont importants, et une évaluation du contenu des formations l’est tout autant. Il est évident qu’une formation en ligne mise à disposition pendant trois semaines, suivie d’une formation présentielle, avec une période de préparation à l’examen, aura une valeur intrinsèquement plus importante qu’une formation présentielle de trois jours par une personne peu expérimentée.

Dans le domaine des outils de tests aussi, des solutions « low-cost » existent. Certains produits commerciaux ont un coût de licence quasi prohibitif, d’autres sont plus raisonnables. Certains logiciels sont même gratuits ou presque (solutions open sources et shareware). Les outils « low-cost » peuvent l’être parce que les fonctionnalités qu’ils offrent sont plus limitées, ou que l’effort de développement est moindre, ou que la documentation est très succincte et non mise à jour, ou alors que les technologies mises en œuvre sont quasi obsolètes. Ceci ne devrait pas poser de problème, l’utilisation d’un outil de test devant être associée à un objectif de rentabilité des tests ou du projet de test. Cette rentabilité doit être mesurable bien entendu. Cependant, aucun éditeur de logiciel de test ne vous garantira une quelconque rentabilité à l’utilisation de ses outils, et très peu d’équipes de test mesurent leur rentabilité ou leur efficacité. De nombreuses techniques de test, décrites dans les syllabus du CFTL, peuvent être supportées par des outils.
Le CFTL a récemment effectué un sondage [1] pour identifier les pratiques du test logiciel en France. En termes d’outillage, dans plus de 50 % des cas, les environnements de test et les données de test ne sont pas gérés de façon automatisée (comment tester sans un environnement de test ni des données de test ?). Les résultats nous apprennent que dans 72 % des cas les équipes de test automatisent moins de 25% des tests qu’ils conçoivent. La rentabilité des outils de test « low-cost » ou non devra donc être pondérée par cette limitation.
De nombreux ouvrages indiquent que l’efficacité des outils de test est inférieure à l’efficacité de certaines méthodes de vérifications manuelles (p.ex. revues, inspections, etc.). Donc une solution d’outillage – même « low-cost » – devrait être comparée à une solution sans outil, à la fois en termes de coûts et en termes d’efficacité.

Dans le domaine de l’exécution des tests, pour les nouveaux développements ou les évolutions de logiciels, les aspects de « low-cost » jouent aussi. Ils s’identifient par une réduction des charges de test pour tenir dans des délais intenables, ou par l’appel à une sous-traitance – nationale ou off-shore – avec des contrats peu clairs, ne définissant pas les livrables, ni le niveau de qualité attendus. Comme le domaine du test de logiciels est complexe et mal maîtrisé par les DSI et les clients, il est fréquent de voir des contrats ne mentionnant ni niveau de qualité mesurable (en termes de fiabilité ou de MTBF), ni de pénalités pour la société prestataire au cas où le niveau de qualité n’est pas présent. Nous nous retrouvons exactement comme dans le cas du bœuf chevalin, où un intermédiaire n’aurait pas correctement interprété un code abscond. Le client final est floué, les risques sont largement disséminés dans la chaine de sous-traitance entre la MOA, la MOE et les divers niveaux de sous-traitance.
Tout travail mérite salaire ; si on souhaite l’effectuer correctement, le test est un travail complexe touchant des aspects fonctionnels et des aspects techniques (p.ex. performances, sécurité, portabilité des applications et des données, maintenabilité des logiciels, optimisation de l’utilisabilité, etc.). Acquérir les compétences nécessaires – logicielles, fonctionnelles, techniques, opérationnelles – prend du temps. Mettre en œuvre des techniques de test efficaces et rentables sur des logiciels de plus en plus complexes prend du temps, que ce soit fait en France ou à l’étranger.
Une solution de test « low-cost » impliquera soit une réduction de périmètre, soit une réduction de la profondeur des tests (de l’effort de test), soit l’utilisation de personnel meilleur marché. Dans le cas d’une réduction de périmètre, cela implique que des parties de l’application ne seront pas – ou pas totalement – testées ; dans le cas d’une réduction de la profondeur des tests, cela implique que le niveau d’effort sera réduit – souvent sur des caractéristiques critiques – avec une augmentation proportionnelle des risques associés. Du personnel « low-cost » – par exemple offshore – est une solution que plusieurs sociétés ont pris pour des raisons financières, mais beaucoup sont revenues sous nos cieux pour des raisons de qualité non tenue … une leçon à méditer ? Du personnel « low-cost » peut aussi résulter de l’absence de certification, et donc probablement d’une absence de connaissance des méthodes et techniques les plus efficaces.
Rechercher des solutions à coût réduit n’est pas en soi une erreur. La réduction de prix s’effectue toujours en rognant sur quelque-chose. Souvent ce qui disparaît est la qualité du produit ou du service. Vous n’aurez pas un véhicule haut de gamme pour le même prix d’un véhicule « low-cost ». Vous n’aurez pas un service de qualité au même prix qu’un service « low-cost ».

Une évaluation des risques ? La perception du risque impactera le choix d’une solution ou d’une autre. Mais évaluons-nous correctement les risques ? Nous remarquons parfois que les crues « centennales » semblent arriver tous les dix ans, et que fréquemment vos systèmes vous proposent d’installer l’une ou l’autre mise à jour « critique » ou « de sécurité ». Cela ne génère pas toujours des soucis, … pas toujours.
Avec des systèmes de plus en plus complexes, aux interactions de plus en plus nombreuses, des soucis comme ceux de Google Drive [2] deviendront plus fréquents. Tout décideur doit évaluer les risques associés à ses choix, à la fois en termes de probabilité (fréquence d’apparition du risque) et en termes d’impact pour sa société.  Cela sera applicable aussi pour votre société, si ce n’est que vous en pâtirez directement ou indirectement. Est-ce cela que vous souhaitez ? Réfléchissez-y lors de vos prochaines décisions d’achat.

---------------------------

[1] http://www.programmez.com/actualites.php?titre_actu=Les-resultats-du-1er-Observatoire-des-Pratiques-du-Test-Logiciel-&id_actu=13132

Autour du même sujet