La pyramide des tests impose de garder une bonne proportion de l’effort de test à réaliser sur son produit (produit réalisé en pratiques agile) :

Voici une très belle présentation du sujet par Damien Beaufils

Ce que Damien nous montre est dans le cadre du développement de votre produit, mais comment faire si vous avez un produit non maintenue (legacy) et que vous devez faire des modifications ?
Comment faire si mon produit est basé sur un progiciel (logiciel propriétaire, sur étagère à paramétrer) dont je ne connais pas la qualité ?

Il faut mettre en place une chaîne de test TNR ( test de non régression) fiable et sécuriser avec vos scénarios les plus importants.
L’automatisation de vos tests de non régression permet de faire vivre votre produit dans un cycle agile afin de vous permettre de le modifier quand vous voulez et d’avoir un feedback immédiat pour mettre en production dans la journée.
Vous y gagnez du temps de réaction et réduirez votre coût de recette car votre équipe recettera uniquement les changements.
Dans le cadre du logiciel à intégrer dans votre entreprise , les paramétrages du logiciel doivent être sous le contrôle de tests automatisés.

Si votre produit est prioritaire, stratégique pour votre entreprise, vous comptez l’utiliser sur plusieurs années et le faire évoluer, vous devriez faire appel à un qualiticien expérimenté pour la mise en place des outils de tests et son DSL de test.

Deux approches de test à faire :
Via la couche API :
Si votre produit est récent, vous devriez avoir accès aux APIs des services du produit (rest, soap, client-serveur).
Cette méthode est privilégié car plus simple à mettre en place afin d’éviterez les temps de latence de la couche IHM ou le scripting sur l’XLM qui provoque souvent des faux-positifs.
Via la couche IHM :
Utiliser des robots via des scriptes pour remplir les champs et valider les résultats via votre IHM logiciel : voir Robot Framework ou Cucumber.

Dans votre stratégie de test, chaque paramétrage a un objectif de comportement du produit, c’est ce comportement que vous devez tester et que vous devez rendre testable.
Pour cela votre qualiticien basera ses efforts en suivant le pattern SOLID :

Responsabilité unique (single responsibility principle)une classe, une fonction ou une méthode doit avoir une et une seule responsabilité
Ouvert/fermé (open/closed principle)une entité applicative (class, fonction, module …) doit être ouverte à l’extension, mais fermée à la modification
Substitution de Liskov (Liskov substitution principle)une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme
Ségrégation des interfaces (interface segregation principle)préférer plusieurs interfaces spécifiques pour chaque client plutôt qu’une seule interface générale
Inversion des dépendances (dependency inversion principle)il faut dépendre des abstractions, pas des implémentations

Pourquoi un qualiticien pour réaliser votre stack de tests ?
Le plus compliqué n’est pas d’écrire le test ou de tester, le plus compliqué est de définir les bons outils à mettre en place pour tester votre produit, et ensuite de mettre en place une mécanique de test résiliant aux changements des données sur votre environnement de test et minimiser les faux-positifs.
Ensuite, son travail est de gérer l’effort à mettre dans chaque test par rapport à son ROI car rappelez-vous la pyramide de tests présenté par Damien plus haut, les tests d’IHM et d’intégration sont les plus chers à faire et maintenir.

C’est la mission du Qualiticien Agile afin de vous permettre de sécuriser votre produit avec la mise en place du BDD Behavior Driven Development ou pour nous ici du TDS : Test Driven Settings.

Si besoin, nous travaillons avec des partenaires experts dans la mise en oeuvre de l’automatisation de vos tests de non régression TNR.