Gestion des sorties de produits : le retour d’expérience de SoftFluent – 6/12

Test & Assurance Qualité

Nous avons un produit étendu ce qui signifie une grande complexité à tester toutes les différentes combinaisons d’options. En raison de cette complexité, nous avons réalisé rapidement que le recours à des testeurs classiques – même situé en offshore – serait prohibitif et exigerait beaucoup de temps pour valider chaque nouvelle version.

C’est pourquoi nous avons décidé d’investir de manière conséquente dans l’automatisation de la plupart de nos tests. Nous avons fait cela assez tôt pour la 1ère version de CodeFluent Entities (la version "Core" basée sur XML sans le Modeler graphique intégré à Visual Studio) et cela nous permet de comparer les fichiers générés par différentes versions.

A chaque version, nous générons de nombreux modèles, les modèles échantillons livrés avec le produit, des modèles qui ont été conçus pour utiliser toutes les options du produit et maximiser la couverture de nos tests et les modèles de projets clients réels afin de limiter au maximum les risques de régression.

Ensuite nous déroulons les résultats de ces tests automatisés et le rapport de test nous souligne les différences (voir ci-dessous). Parfois ces différences sont normales (un changement qui a été décidé par exemple) mais si ce n’est pas le cas, nous pouvons identifier rapidement un dysfonctionnement et réaliser une correction avant de publier la version.

Depuis que nous avons développé le modeleur graphique, nous devons également faire des tests sur l’interface utilisateur. Cela s’avère d’autant plus délicat que les outils classiques de test d’interface utilisateur ne sont pas très résistants aux changements réels qui se produisent pendant le processus de développement. Si un contrôle est déplacé vers une position différente sur l’écran, il est probable qu’il faille réécrire le scénario, etc…

Nous avons donc construit notre propre framework de test pour introduire les concepts spécifiques à notre produit et proposer une API pour créer des scénarios de tests qui peuvent être programmés et rejoués sur l’interface utilisateur.

En fait, nous nous appuyons sur les 2 briques en bleu qui sont fournies par Microsoft (et sont disponibles de base sur chaque installation de Windows), mais nous avons développé le framework suivant les couches décrites ci-après :

· Manipuler les concepts de scénario typiques, indépendants de tout produit : session, login, traçabilité, copies d’écran, souris, clavier etc… (Automatisation SoftFluent)

· Encapsuler les principaux éléments de l’interface utilisateur de Visual studio comme explorateur de solutions, la grille de propriété, la dialogue nouveau projet, menu principal etc… (Automatisation Visual Studio)

· Encapsuler les principaux éléments de l’interface utilisateur du modeleur graphique de CodeFluent Entities : ruban, menu principale et boîtes de dialogue spécifiques (Automatisation CodeFluent Entities Automation)

Notre scénario de test utilisateur final tire ensuite parti de ces couches pour simuler des actions sur l’interface utilisateur et nous pouvons jouer des scénarios complexes pendant des heures sur des machines différentes afin de maximiser notre couverture de test.

Notre outil enregistre tout ce qui se passe et prend une image de l’écran chaque fois que nous le demandons ou lorsqu’une erreur se produit (voir ci-dessous).

C’est une approche très puissante dans la mesure où le travail n’est pas à refaire à chaque génération. Bien sûr, le scénario est testé ce faisant, et les erreurs relèvent parfois autant du scénario que du produit mais cela aide énormément à trouver rapidement les problèmes et à converger dans un temps court. Sans une bande passante humaine énorme, nous pouvons détecter la plupart des régressions susceptibles de se produire. Du coup, notre base de bogues connues reste proche de zéro, et est constituée essentiellement d’une zone tampon alimentée par le support.

Les tests d’utilisation sont également un domaine auquel nous pensons pour améliorer l’ergonomie et s’assurer que les développeurs aient la meilleure expérience avec notre produit dès la première utilisation. Nous prévoyons d’investir sur ce sujet dans le futur.