J’ai pu interviewer Lionel Ducrocq sur une expérience de projet d’automatisation pleine de rebondissements.

Je souhaitais partager plus en détail les pratiques que nous avons identifiées en rétrospective de notre échange.

• Rester maître de son référentiel de test, spécifications et entrants est un actif

• Tester rapidement les use-cases structurants et critiques y compris les exigences  non-fonctionnelles

• Anticiper les charges d’automatisation directes et indirectes pour bâtir un plan réaliste

• Utiliser son instinct en guide complémentaire de gestion des risques

• Comprendre l’origine et les contours d’une solution permet de mieux cerner son intégration naturelle

Les sections suivantes détaillent les points avec des préconisations actionnables.

Rester maître de son référentiel de test, spécifications et entrants est clef à tout horizon

Externaliseriez-vous des fonctions coeurs de votre entreprise?

J’imagine que non et je suis convaincu que le raisonnement doit être similaire pour son référentiel d’exigences.

La connaissance des tests est en grande partie le reflet des besoins métiers, qui évoluent, et reflètent les modes opératoires de l’entreprise.

C’est là qu’est la valeur métier, différenciante, qui se révèle être un véritable actif de l’entreprise si elle est maîtrisée.

Un référentiel maîtrisé est un véritable actif de l’entreprise : un reflet des exigences apportant une flexibilité d’implémentation.

Antoine Craske

Sa maîtrise permet d’assurer la pertinence des cas de tests, qu’ils soient manuels ou automatisés, en interne ou en externe.

Le contrôle de ses entrants est une réelle force par la flexibilité qu’elle apporte dans un environnement de plus en plus dynamique.

De l’expérience partagée, cela leur a permis de pivoter rapidement en changeant d’outils, d’équipes et de partenaires.

De manière exceptionnelle, cela permet également de faire du test manuel si un problème est rencontré sur les tests automatiques.

Tester rapidement les use-cases structurants et critiques avec les exigences  non-fonctionnelles

Dans ce cas précis une centaines de cas de tests étaient identifiés dans le périmètre d’automatisation.

L’étude de faisabilité a porté sur quatre tests permettant de valider différentes typologies. 

Néanmoins, la parallélisation des tests et leur stabilité n’a pas été évaluée dans la première partie du projet.

Tester les exigences non-fonctionnelles sont également structurantes dans un projet d’automatisation.

Antoine Craske

Au regard des problèmes structurels d’infrastructures rencontrés par la suite, tester ces exigences non-fonctionnelles aurait pu détecter la problématique de stabilité.

On en retient que les exigences non-fonctionnelles sont également structurantes dans un projet d’automatisation.

Il convient donc d’expliciter ces exigences tôt dans un projet, et en définir un plan de test adapté.

Moins visibles et naturellement évoquées, elles sont facilement mises de côté, à un prix qui peut se révéler coûteux par la suite.

Anticiper les charges d’automatisation directes et indirectes pour bâtir un plan réaliste

Dans le partage d’expérience, on s’aperçoit que la charge de revue et de validation n’a pas été prévue.

Du délai se crée et s’accumule, accentué par les divers aller-retours, le contexte de travail à distance et des priorités différentes.

On peut faire un parallèle avec des projets de développement informatiques, oú des charges indirectes aux tâches de production doivent être prévues.

Les tâches d’automatisation ont des charges indirectes associées, telles que la spécification, revue, intégration et test.

Antoine Craske

C’est souvent un aspect négligé dans les projets d’automatisation. On raccourcit le projet uniquement aux tâches d’automatisation.

Cette charge peut être estimée en amont du projet afin de garantir un meilleur répondant aux livrables, inspiré du cycle de vie de test (STLC).

Une pratique commune est d’allouer une charge indirecte par grande catégorie de complexité des cas de tests identifiés.

Cette charge est ensuite à adapter lors de l’exécution du projet confronté à la réalité, et est sujette à de possibles optimisations.

À l’instar du peer review du développement logiciel, dédier des créneaux de revue des tests et de validation peut faciliter les retours directs, la collaboration et la compréhension mutuelle.

Utiliser son instinct en guide complémentaire de gestion des risques

Plusieurs personnes de l’équipe ont remarqué des tests stables uniquement chez le partenaire et en démo planifiée.

Dans le projet, la stabilité de l’environnement s’est révélée être un réel facteur limitant d’itérations, qui s’est finalement relevé bloquant.

D’autres facteurs sont entrés en jeu, comme les contraintes de sécurité et d’accès aux infrastructures.

Néanmoins, on sent que suivre son intuition et son instinct peuvent parfois nous mettre sur les bonnes pistes.

Notre intuition peut nous guider vers les bonnes pistes.

Antoine Craske

Ne pas les sous-estimer et agir tôt peut faire la différence. Un problème non traité a tendance à se multiplier plutôt que de se résoudre de lui-même.

Pragmatiquement, dédier personnellement une heure par semaine bloquée dans son agenda de revue et de prise de recul pour planifier des actions.

Personnellement c’est une pratique que j’utilise pour me distancier de sujet opérationnels et reprendre de la perspective sur les objectifs et l’évolution du contexte.

Dans un aspect de collaboration et d’intelligence collective, organiser toutes les 2 à 3 semaines des sessions de revues des risques avec l’équipe projet est aussi pertinent.

On parle de rétrospective dans le monde agile, mais reste moins naturel dans les projets traditionnels.

La gestion des risques reste parfois fermée au chef de projet, mais elle a bien mérité d’ être ouverte et partagée pour plus de valeur.

Comprendre l’origine et les contours d’une solution permet de mieux cerner son intégration naturelle

Je partage ici une réflexion que j’ai pu lire du livre The Software Architect Elevator, de Gregor Hohpe.

Dans l’histoire partagée, on se rend compte que la plateforme technique déployée en interne a finalement posé des problèmes.

Avec du recul, on se questionne si le produit était en fait adapté pour un déploiement on-premise, on comprend qu’il était plutôt fait pour un autre type de déploiement.

C’est ici que comprendre l’origine d’un produit, y cerner son cœur, lá oú il est s’est créé, est très bon et s’est développé nous permet également d’en délimiter les contours.

Comprendre l’origine d’un produit permet d’en délimiter les contours et d’identifier ses limites.

Antoine Craske

Dans ce cas précis, si la solution était déjà instable en première présentation dans l’environnement mis en place, il était questionable d’avancer avec son déploiement plus large.

Concrètement, se construire une liste de questions pour les évaluations de solution est une pratique commune.

Personnellement, je pense qu’il faut rester simple et avec une vision large sur une première approche, évitant les matrices de décisions à 100 critères.

Les questions doivent permettre d’effectuer un 80/20 en cernant les points clefs de compréhension et d’attentions.

Cette approche permet de limiter quelques choix pertinents qui seront eux creusés plus en détail.

Un projet d’automatisation reste un réel défi de par sa complexité et transversalité

On se rend bien compte qu’un projet d’automatisation de tests nécessite une réelle organisation, pilotage et une analyse accrue du contexte.

Les fondamentaux de gestion de projet, d’équipe et de qualité logicielle sont clefs pour réussir un projet d’envergure.

J’espère que cet article vous aura été utile en partage, concret et actionnable, n’hésitez pas à commenter à réagir pour continuer l’échange.