Les tests logiciels sont stratégiques, en particulier dans la finance, soumise à des contraintes réglementaires, ou dans l’internet des objets et les Apps mobiles. Il faut alors absolument faire communiquer Etudes et métier. Oliver Denoo, vice président du CFTL s’explique avant la journée consacrée aux tests le 12 avril prochain.
Question : quelles sont les bonnes pratiques en matière de test logiciel ?
Olivier Denoo : il faut partager. Les barrières entre l’informatique et les métiers sont plus que jamais d’actualité. Ces barrières sont nombreuses et difficiles à passer. Bien souvent, Etudes et Métier s’ignorent, se regardent en chiens de faïence ou refusent même de collaborer. La confiance est limitée et les communications sont dégradées.
Question : quel est le remède pour établir la communication entre métier et études ?
Olivier Denoo : la plupart du temps, ce sont les testeurs et les analystes métier qui doivent « percer des fenêtres dans ces véritables murs d’incommunicabilité » pour aider ces deux pôles majeurs des entreprises à se comprendre et à aboutir à leurs objectifs communs qui sont des logiciels utiles, utilisables et de qualité. La communication passe par une volonté de s’impliquer, un langage commun et des attentes claires. Cela passe par des exigences, des délais, des PV, etc.
Question : quelles sont les autres bonnes pratiques dans les tests logiciels ?
Olivier Denoo : il faut mesurer et penser aux environnements techniques associés. L’absence de métriques est aujourd’hui absolument catastrophique. Les entreprises se bornent généralement à des métriques simples surtout liées au pilotage du projet et pas toujours aux tests et aux anomalies. Rares sont celles qui mesurent leur productivité, le retour sur investissement de leurs tests ou même le coût engendré par le traitement de leurs défauts.
Enfin, il faut penser aux environnements. Les environnements de test, de qualification, de recette, de pré production, de performance, de développement, d’intégration, de bout-en-bout…
Il y en a tant dans notre vocabulaire et parfois si peu sur le terrain. Au point qu’on se collisionne, qu’on se marche dessus, qu’on ne peut estimer l’impact ou tester les processus, qu’on ne dispose ni de données fraîches, ni de données réalistes. Bref! La question environnementale reste bien souvent une préoccupation majeure du testeur, vous l’aurez compris.
Question : quel pourcentage des tests est automatisable aujourd’hui ?
Olivier Denoo : je dirais que de 30% à 50% du périmètre fonctionnel me paraissent un maximum raisonnable. Mais il n’y a pas une seule réponse à cette question. L’idée n’est pas de tout automatiser, mais d’automatiser ce qui est stable, récurrent et relativement facile, et donc ennuyeux à tester manuellement.
Le pourcentage d’automatisation dépend de la stabilité fonctionnelle et de l’IHM (interface homme machine) des applications sous test, de la maturité du processus de test, des technologies ou même de l’approche. Certaines technologies, plus anciennes ou obsolètes, sont moins facilement automatisables. Quant à l’approche, l’intégration continue ou l’agilité sont plus propices à l’automatisation.
Question : où sont les difficultés d’automatisation ?
Olivier Denoo : les difficultés portent surtout sur les interfaces complexes, moins bien reconnues par les outils et sur les gestes métier complexes qui nécessitent l’emploi de calculs élaborés ou de données consommables pour obtenir les résultats.
C’est le cas particulièrement lorsque le rafraîchissement ou la restauration des données et des environnements sont compliqués, ainsi que pour les aspects liés à l’ergonomie ou à l’aspect des interfaces.
Certains aspects me semblent automatisables dans le futur, notamment dans le domaine des comparatifs visuels pour lesquels la puissance de calcul toujours croissante et les algorithmes toujours plus puissants nous ont permis de faire d’immenses progrès mais à un coût élevé.
D’autres me paraissent plus délicats parce qu’ils touchent, à la fois aux aspects techniques comme la manipulation, la génération de la donnée en cohérence avec le système d’information donc transverse et aux aspects financiers avec la multiplication des coûts de licence avec un impact direct sur le retour sur investissement.
D’un point de vue métier, l’automatisation fonctionnelle reste aujourd’hui largement cantonnée aux tests de non régression (TNR).
Quel est le coût des tests dans un projet informatique ?
Olivier Denoo : on considère que le pourcentage des tests se situe en général entre 20% et 40% du budget du projet. Il existe de nombreuses références, abaques et méthodes sur la question.
Une fois encore, il faut raison garder. Une modification « simple » mais touchant au cœur d’un système transverse pourrait nécessiter un pourcentage de TNR (Test de Non Régression) bien plus élevé. C’est donc là aussi très relatif.
Pour l’avenir, il est difficile de dégager des tendances générales en termes d’évolution de ces proportions. Les méthodes Agiles intégrant le test au cœur du développement, cette proportion devient même plus intangible.
Il est clair en tout cas que la qualité (et donc le test logiciel) sont et resteront des éléments différenciateurs positifs sinon obligatoires à l’avenir.
Toutefois, la nature même des tests devrait évoluer dans un avenir plus ou moins proche en raison de l’inter connectivité toujours accrue des systèmes d’information qui nécessiteront plus de sécurité et de performance ainsi que de nos attentes toujours plus poussées de réponses immédiates et généralisées qui pousseront vers plus d’ergonomie et d’interopérabilité, notamment via les objets connectés qui n’en sont qu’à leurs débuts.
